客户说不清需求，FDE靠什么交付

去年冬天我去一家保险公司做驻场。对方CIO在会议室拍板："我们要上AI，处理理赔。"我问：具体哪一块？他说："就……理赔啊，你们不是做AI的吗，你们看着办。"

这就是FDE进场时的真实画面。没有SOW，没有需求文档，只有一个模糊的方向和一笔预算。

传统软件交付的第一件事是写需求文档。但AI Agent交付的第一件事，是替客户把他说不清的东西想清楚。

传统交付在AI时代为什么失灵

干了十几年交付的人都熟悉一套节奏：客户写SOW（工作说明书），开发团队照着实现，测试团队验证，交付团队部署上线。这条链路在确定性软件时代运转得很好——需求是死的，输出是确定的，文档写清楚就能按图施工。

AI Agent把这套逻辑整个掀翻了。

AI的需求是涌现的，输出是概率性的，技术迭代是按月计的。 你今天按SOW交付的"智能理赔系统"，上线两周后客户发现真正痛的是反欺诈，不是理赔提速，而反欺诈需要的能力SOW里一个字没提。这时候文档成了束缚，不是指引。

我见过最典型的翻车：一个团队按SOW做了三个月，交付了一个"能自动分类理赔邮件的Agent"。客户试用后说："分类准了，但分类完干什么？谁去跟进？"——原来客户要的不是一个分类器，是一条从收件到结案的工作流。三个月的活，方向错了。

FDE的交付逻辑完全不同。我们不交付"代码包"，我们交付"一种能力"：编排一群具备不同技能的智能体，让它们在客户的工作流里协同把问题解决了。

这个转变体现在三个层次：从"完成需求"到"实现结果"，从"线性交付"到"闭环迭代"，从"一次性项目"到"持续造血"。说白了，客户雇你不是为了拿到一份代码，是为了他那个业务痛点真的被解决。

四阶段闭环：从Mission画布到Production

FDE在客户现场的实际工作流，可以拆成四个清晰的阶段。我管它叫"交付闭环"。

阶段一：Mission定义——把模糊拆成结构。

客户很少能说清需求，更多时候他说的就是"我想用AI处理理赔"或者"跟单流程太慢"。FDE的第一项工作，是拿一张"Agent编排画布"，把这个模糊的Mission拆成一系列Agent能执行的任务步骤，然后跟客户对齐。

画布上要标清楚几件事：业务对象是什么（订单、客户、合同、工单），对象之间什么关系，现在有哪些状态，哪些动作能被AI接管，哪些必须留人工。

这一步的关键产出不是需求文档，而是一张"业务动作链"地图。我进场第一周基本泡在一线：谁在做判断？判断依据是什么？数据从哪来？动作在哪执行？哪些系统之间是断的？哪些经验只装在老员工脑子里？

这些问题不问清楚，后面写的每一行代码都可能打水漂。

阶段二：最小可行Agent——从零到能演示。

有了地图，立刻建MVP。MVP原则只有一条：快速搞一个只具备核心技能、能跑通最小闭环的Agent，拿来当场演示。

还是那家保险公司。我没有一上来做"智能理赔平台"，而是先做了一个"分诊Agent"——它只读邮件、判断紧急程度、在工单系统里建一条记录。就这三步，没了。客户当场看到一封理赔邮件进来，系统自动分了优先级、建了工单，眼睛亮了。

构建MVP的武器是低代码平台（Dify、Coze）加工程框架（LangGraph）。选哪个取决于场景复杂度和客户对私有化的要求。但无论选什么，MVP必须满足一个硬条件：能在客户面前当场演示、当场改。

阶段三：现场迭代——把反馈周期压到分钟级。

这是FDE方法论里最特别的一环。传统交付里，开发团队和客户之间隔着一个反馈周期：做完一版，交客户测，收反馈，回开发环境改，再部署。传统软件里这个周期可能是几周。

AI Agent交付里，这个周期必须压到分钟级。

我在客户现场的做法是：客户对着最小原型提意见，我当场改Agent的System Prompt，或者换掉其中一个Skill，立刻重跑给他看。"客户在场，我在改"——这种现场迭代能力，是FDE的核心竞争力。它不只是省时间，它让客户亲眼看见系统在他手里长出来，信任就是这么建立的。

▎ 传统交付赌的是文档写对，FDE赌的是客户在场时系统能当场变对。

阶段四：生产化演进——从Demo到Production。

Demo里跑得完美的Agent，进生产环境往往崩。上下文窗口溢出、API超时、权限缺失、模型行为漂移——任何一个都能让一个"看起来很聪明"的Agent在生产里翻车。

生产化阶段的原则是：从"调用一个模型"，进到"委托一个能自我监控的Agent"。FDE要给它上日志、上监控、上人工干预节点，让它从"黑箱玩具"变成"可管理的生产系统"。

重点不是模型多强，是系统可观测：每次调用成功没？每步决策合理不？每个错误能回溯不？ 这几件事没做，上线就是埋雷。

把每次交付变成资产，而不是外包

FDE交付的终局，不是让客户离不开你，是让客户没有你也能转。真正成功的标志不是系统多强，是客户内部团队能在没有FDE的情况下运营它。

但大多数人栽在这一步：项目做完，人撤了，经验也跟着撤了。下次来个新场景，从头再干一遍。这叫外包，不叫能力沉淀。

我在每个项目里强制沉淀五类资产：

业务对象库——把行业核心对象和它们的关系定义清楚，下个项目直接复用。工具调用模板——标准化的API接口和权限模型，别每次现接。评估集——Golden Dataset加失败样本库，这是判断"Agent到底行不行"的尺子。工作流模板——可复用的Agent编排逻辑，不是从零画。异常处理机制——失败回退和人审节点的设计。

没有沉淀，FDE就会退化成高级外包，按人天计费，越做越累。持续沉淀，FDE就变成产品壁垒——你的每个项目都在给下一个项目铺路。

从第一周就要布局交接

FDE的交付不以"系统上线"为终点，以"客户团队能独立运营"为终点。上线后的头120天，系统最不稳、问题最集中，也是用户信任真正建立的窗口期。这个阶段FDE必须还在场。

但交接不能等到最后一周才动手。我进场第一周就开始布局：找到将来接手系统的人，从第二周起让他参与每一个关键决策。全程避免自己成为单点依赖——我不在，系统就不转，那是交付失败，不是成功。

真正要移交的是四种能力：日常运营（客户团队能独立处理监控告警和常见问题）、问题升级路径（哪些内部解决、哪些找FDE，边界清晰）、质量维护（能看懂指标、能响应告警）、扩展判断（能评估新场景的可行性和风险）。

这四件事移交到位，我才算真正交付完成。否则系统再漂亮，也是个离不开人的盆景。

说给未来的FDE

这八讲走下来，你手里已经攒了工具、架构、规模化方案。但技术在客户现场那一地鸡毛面前，都会现原形。

FDE最难的不是写代码，是面对一个说不清自己要什么、系统还天天出幺蛾子的客户，依然能把一条可靠路径走出来。画布、MVP、现场迭代、生产化、知识沉淀、120天交接——这套打法不是为了炫技，是为了让你在混沌里不慌。

客户雇你，买的是确定性。而确定性，是你用方法一个阶段一个阶段挣来的。

下一讲，我们进多智能体协同——当一个Agent搞不定时，怎么让一群Agent分工把复杂业务啃下来。