学习 FDE 如何将客户提出的功能需求，与真正值得投入工程资源的客户成果、约束条件、工作流程和故障场景区分开来。
示例性质。 下面的项目案例是合成的，旨在教授这一方法。对话是虚构的而非实录，且不包含任何统计数据。（真实、有引用来源的部署案例位于 Engagements 部分；本部分通过像本篇这样标注的示例来教授这门技艺。）
探索是每个项目的第一阶段，却也是最常被工程师跳过的阶段。你接到一个问题，能看到三种构建方式，于是就想立刻动手。忍住。客户交给你的是他们能说清楚的问题，而这几乎从来不是你真正受雇要解决的问题。探索就是在写下第一行代码之前，找出这两者之间差距的工作。
这是 AI 工程师不做的那部分工作。做对了，构建工作量会缩小，因为你一次就构建了正确的东西。做错了，你交付的东西虽然能运行、演示效果好，却没人使用。
阅读之前
一家区域性物流公司请你过去。运营副总裁说："我们想要一个 AI 助手，能回答调度员关于运输法规的问题。他们查资料浪费了太多时间。"
写下你会问的前三个问题。然后继续阅读。
大多数工程师听到这句话就开始设计：一套基于法规的检索系统、一个聊天界面，也许还要做微调。先等等。这句话里的所有内容都是包裹在症状（"浪费了太多时间"）外面的一个拟议解决方案（"一个 AI 助手"）。你还不知道真正的问题是什么。
招式 1 —— 将需求与成果区分开
副总裁要的是一个问答助手。那是一个需求。每个需求之下都有一个这个人真正要负责的成果：也就是他的老板用来考核他的指标。你的首要任务是从需求攀升到成果，因为最终评判你的也是这个成果。
攀升只需要一个问题，多问几遍："如果这件事做成了，对你来说会有什么改变？"
你："假设这个助手完美无缺，调度员能立刻得到正确的答案。三个月后，对你来说有什么不同？"
副总裁："合规扣留更少。当调度员搞错危险品路线时，货物会在检查站被标记并滞留。那是我老板问我的那个数字。"
这个回答直接改变了项目的方向。需求是"更快地回答问题"。成果是更少的合规扣留，而这两者并不是同一个系统。一个更快的查询工具可能永远无法减少扣留，因为造成扣留的调度员并不是那些停下来查资料的人。他们是那些确信自己已经知道答案的人。
差 / 好 / 卓越 —— 开场探索问题
差——“你们有什么数据，数据存在哪里？” 你已经开始着手构建了。这是工程师的条件反射，它会让客户觉得你听到“检索系统”就不再听了。你会拿到一份数据源清单，并交付一个没人真正关心的问题的问答系统。
较好——“能多讲讲调度员都在问些什么问题吗？” 好一些：你对工作本身产生了好奇。但你仍然停留在客户给出的框架里。你会了解到很多关于问题的信息，却无法判断回答这些问题是否真正能推动那个关键指标。
优秀——“如果这个系统完美运行，三个月后你的工作会有什么不同？” 你已经超越了需求本身，直达采购者被考核的成果。从此，后续的每个决策都有了标尺：这是否减少了合规扣留？当你日后主张把开发时间花在棘手的危险品路线案例而非简单的常见问题上时，这句话就是赢得争论的关键，因为副总裁已经告诉你，那才是真正重要的数字。
第二步——跟随实际工作，而非需求文档
你已经从采购者那里得到了目标成果。但采购者并不亲自做这项工作。下一步是工程师们最不自在、也是区分前沿部署工程师与普通供应商的一步：去和真正做这份工作的人坐在一起。 不是需求会议。是真实的工位、真实的班次。
你花了一个上午坐在两位调度员旁边。第一位是新入职的，完全按照副总裁描述的那样做：停下来，查资料，慢但谨慎。她几乎不会用你的工具；她本来就会反复核对一切。
第二位有十五年经验。他速度快、自信，从不查任何资料，全凭记忆。观察他时，你注意到他依据的是贴在显示器上的一张塑封卡片，不知道多久没更新了。那天上午有两次，他按照一贯的方式安排了货运路线。你坐在那里，无法判断这两次是否都是潜在的合规扣留。他自己也无法判断。
这才是真正的问题，而且没人会主动告诉你，因为造成扣留的人并不知道自己是问题的源头。会使用问答工具的调度员，恰恰不是制造扣留的人。制造扣留的调度员不会提问；他非常自信。一个等待被提问的工具，只会被完全错误的人使用。
真正的问题在于，自信与正确已经脱节，而工作流程中没有任何环节能捕捉到这一点。这重新定义了整个系统：你需要的不是调度员主动咨询的聊天机器人。你需要的是一种能在路线决策产生时进行监控、并悄悄标记出那些“闻起来不对”的决策的工具，同时不让一位十五年资历的老手感到被质疑。这最后一个约束本身就是一个你现在知道要去解决的设计难题。
需要预判的追问
当你带着这个重新定义的框架回去时，采购者常常会追问：
副总裁：“我要的是一个问答助手。现在你却告诉我，你想做一个监控我调度员的工具？这在内部更难推销。”
不要退回到容易实现的东西上。把结果摆出来，因为那是他们自己给你的：
你：“您告诉我，真正重要的指标是合规扣留数。问答工具只能帮助那些本来就会停下来核对的调度员，而根据我在现场的一个上午观察，造成扣留的并不是这些人。如果我们构建您要求的那个助手，它演示起来会很漂亮，但不会改变您的指标。我更愿意构建能改变指标的东西。以下是我们如何避免让它感觉像是在监视……”
这就是前沿部署工程师的做法：你用他们自己陈述的结果来反驳他们陈述的需求，而且你带来的下一个问题已经解决了一半。这不是阻挠。这是拒绝让他们为行不通的东西买单。
“调研完成”是什么样子
当你能用非工程师也会点头认可的平实语言说出以下内容时，你就可以结束调研了：
- 买方被考核的结果。（合规扣留数，而不是“回答速度”。）
- 谁真正感受到痛点，通过观察他们来确认，以及是否是买方点名的那些人。（不是。）
- 真正的问题，通常是对需求的重构。（自信 ≠ 正确，而且没有任何机制来捕捉这个差距。）
- 一句话说明为什么显而易见的方案是错误的方案。如果你说不出这句话，你就没有完成调研；你只是接了一个订单。
可迁移的模式
从需求爬升到结果，然后去观察实际工作，直到真正的问题与需求相矛盾。每个项目都有这样的形态：有人递给你一个伪装成问题的解决方案，购买它的人不是感受痛点的人，而真相在现场，不在会议室里。调研的交付物不是需求文档。而是一个你能用一句话捍卫的重构——关于结果的一句话：他们自己给你的那个结果。
下一步：范围界定与解决方案架构。把重构转化为一个你真正能够承诺构建的系统，并对不属于它的三件事说不。