很多项目的起点是一次需求会。业务方讲痛点，技术方记功能，双方很快形成一张漂亮的路线图。

问题是，业务真正的规则往往不在会议纪要里。

比如，同样一个工位需求，有经验的工程师会先看环境，再看动作方式，还会顺手核对某个附件是否必须配套。他可能只花几秒就做完判断，却很难把这几秒完整地讲出来。

于是，系统按照“显性流程”跑通了，到了真实订单却不断遇到例外：同样的输入，不同人给出不同结果；资料缺失时系统照样输出；产品版本更新后，旧价格还在被调用。

这类项目不是没有做出Demo，而是Demo证明了“技术可以展示”，没有证明“业务可以交付”。

隐性知识，是那些人会做、却不一定说得清的经验。老师傅听声音判断设备状态，销售看到客户描述就知道要追问哪个参数，都属于隐性知识。AI落地最难的一步，往往不是把文档喂给模型，而是把这些藏在判断动作里的经验找出来。

这个项目的输入并不神秘，就是一份固定格式的Excel：项目基本信息，加上多个自动化工位的需求。

但从“填表”到“报价”，中间有一条很长的链：

任何一环出错，最后的数字就可能失去意义。

客户的担心也很具体：模型会不会把相近的产品混在一起？缺少关键参数时，会不会给一个貌似合理的答案？BOM里的每一行，能不能说清楚来自哪个工位、哪条规则？

所以，这个项目从一开始就没有把目标定义成“让AI自动写方案”，而是把问题改成了：能不能把一次人工选型和报价，拆成一套可验证、可追溯、可以重复执行的规则链？

太乙团队提供的FDE服务，没有先讨论用哪个大模型，而是进入客户现场，把业务人员、工程师和产品资料放到同一张桌子上。调研先围绕四个问题展开：谁在什么场景下使用？输入数据从哪里来？中间要做哪些判断？什么结果才算正确？

这听起来朴素，却能很快暴露出真正的问题。

例如，表格里的“动作方式”究竟允许哪些值；某类产品除了主件，哪些附件必须一起出现；报价引用的是哪一版价格；如果需求描述互相矛盾，系统应该继续生成，还是停下来请工程师确认。

这些问题没有一个能靠模型自己猜。FDE要做的，是把它们从口头经验变成字段定义、校验规则、映射关系和人工介入条件。

FDE通常指Forward Deployed Engineer，可理解为“前线部署工程师”。它既不是只写代码的开发，也不是只收需求的顾问，而是站在业务与技术之间：进入现场理解工作，再快速做出能被真实业务验证的产品。

现场团队给自己设了一个很窄的目标：先证明从Excel输入，到方案、报价和BOM输出的主链路能稳定闭环。

这意味着第一版主动不做很多“看起来更完整”的功能：不急着接CRM、ERP和PLM，不搭复杂的账号权限，也不试图替代工程师处理非标设计、机械电气细节和现场确认。

它重点完成四件事：

这最后一点尤其重要。一个真正能进入业务的AI系统，不只是要知道什么时候回答，还要知道什么时候不该回答。

“人在回路中”不是让人工给AI兜底，而是提前规定哪些节点必须由人确认。比如低风险、规则明确的标准件可以自动处理；涉及非标设计、信息缺失或高金额报价时，系统必须暂停并交给工程师。好的自动化不是把人删掉，而是把人的注意力留给真正需要判断的地方。

他们关心的是：相同输入能否得到一致结果；BOM数量与方案是否对得上；每条结果能否追溯到来源工位和规则依据；换一版产品主数据后，系统能否记录版本与生效时间；遇到不确定项时，是否真的会停下来。

这也是MVP和普通演示的分水岭。演示追求“第一次看起来很惊艳”，MVP追求“第十次运行仍然说得清楚”。

客户对验证结果满意后，项目进入二期工程化。前期Demo里沉淀下来的字段定义、校验规则、BOM映射、人工介入条件、输出结构和版本要求，并没有推倒重来，而是被继续复用。

这说明第一阶段真正有价值的，并不只是那段程序，而是一套经过现场验证的业务骨架。

Demo主要证明“可以展示”；POC主要证明“技术上可行”；MVP则要证明“最小业务闭环可以被真实使用”。三者没有绝对高下，但如果把Demo当成MVP，就很容易在工程化阶段发现：演示里的捷径，全都成了后面要补的债。

FDE的价值，也不只是“驻场开发得更快”。更重要的是，它把业务现场的模糊语言，翻译成工程系统可以执行的约束；再把系统做出的结果，翻译回业务人员可以检查的依据。

所以，FDE做的第一件事不是选模型，而是跟着客户上班。

只有真正看过一张需求表如何变成选型、BOM、方案和报价，才知道AI应该在哪里自动前进，又应该在哪里停下来等人。

AI项目能不能落地，最后比拼的往往不是谁先做出一个会说话的Demo，而是谁先把业务里的“不确定”，变成一套人人都能复核的规则。