做了这么多年AI交付,第一次在现场差点接不住

就在几天前，我参加了一个企业AI项目的现场交付「怎么给AI下指令？」——客户一句话，把我问回了AI落地的起点。

那是我做过最乱的一次。

一堆只有客户内部才听得懂的名词术语，好几个场景在并行推进，N个人同时在聊需求。这边还没弄明白一个字段是什么意思，那边已经在问什么时候能给结果。

这几年我做过不少企业 AI 的培训和咨询，也下场带过智能体和项目陪跑。但这次现场难度更高。业务陌生，几件事同时展开，还要求尽快拿出东西。

现在回过头来复盘，我发现自己当时一直没定下来一件事：今天这个现场，到底要立刻交出什么。

后来我也试着把客户讨论的主题往回收，但还是做得有点晚了。

信息问得再细，没先圈定要交付什么，细就变成了散。

这次经历让我意识到，控制复杂度，也是FDE交付的一项基本功。

过去我认为，FDE 的基本功是这几样：懂 AI 的能力边界，能快速理解业务，能把业务需求翻译成 Agent、Workflow 或者 Skill，再靠测试把它跑起来。

• 信息不完整时，先能圈定一段做得完的工作。

• 需求变化时，知道哪些之前的判断要重新确认。

• 人离开现场后，别人还能接着往下推。

这三件事得有固定做法。不能等忙起来，再靠临场反应去补。

所以这次复盘下来我发现，除了AI能力和理解业务的速度外，也要构建起一套适应现场变化的落地机制。我把这套机制，整理成了五个现场动作。从接到需求到交出结果，整个过程都覆盖到了。下次再遇到这种局，你也可以照着这套机制走。

01

动手之前，先问这东西给谁用

这次让我感触最深的，是自己太容易顺着具体要求往下想实现。

客户说要处理数据，就去看数据定义。客户又说想要生成文件，就去研究文件组成。

响应确实快。但可能漏掉了一个更要命的问题：这个结果出来以后，究竟要用在哪项工作里。

所以每次动手前，一定要先把这四个问题问完。问的过程，本身也是在判断这件事值不值得现在投入。

这些问题最后要落到一个明确的输出物上。跟业务确认清楚：它接收什么材料，在哪个环节处理，结果能支持什么操作，人工怎么确认。

聊完，把目标、输出物、完成标准、确认人单独记一张表。以后冒出新需求，就拿这张表判断：在不在当前范围内。

我以前把这些当成开发前的准备工作。

现在我认为，它们本身就是交付的一部分。

02

理解业务，靠还原，不是靠听懂

现场那几天，我花了不少时间抠文件和字段。

现在回看，单个名词解释清楚了，文件之间的关系还是模糊的。好多业务人员熟到不用想的一个动作，对第一次进场的人来说，中间缺了好几层的潜台词。

怎么办？不可能当场变成业务专家。那就请业务同事拿一份真实材料，按平时的操作，从头演示一遍。你在旁边记，把这条链子串起来。

触发→输入→查询→规则→输出→异常

触发　什么事情发生后，会开始这项工作？

输入　最初拿到哪些材料，由谁提供？

查询　还要去哪里找资料，查出来的结果用来做什么？

规则　根据什么做判断、匹配、计算或取舍？

输出　最后交出什么，交给谁继续使用？

异常　信息缺失、互相冲突或判断不了时，怎么处理，由谁拍板？

这张表的作用，是让你发现自己还没想清楚的地方。哪一行答不上来，就知道还得问什么，也可以直接请业务纠正你的理解。

走完一个正常样本还不够。还要看两类：走不同处理结果的样本，以及业务平时最耗时的地方。样本拿不出来，就把对应规则标成待确认，写清楚由谁来补。

什么时候可以动手？标准只有一个：你能拿着样本，把输入怎么变成输出讲完整，并且让业务确认关键判断。

当然要留余地。有些事必须先做个小试验，才能知道技术上行不行。那就说清楚这次试验只回答哪一个环节的问题，然后继续确认业务目标和处理规则。

FDE 理解业务，不靠听懂，靠还原。

03

同一时刻，只能有一个主任务

现场人一多，很容易变成人人都在提需求。

你每个都认真听，结果就是每切一次，都要重新记一套材料、规则和使用要求。最后什么都记不住。

所以要给自己设一条硬限制：同一时段，只保留一个正在推进的主任务。其他需求先记下来，由项目负责人统一排序。现场填一张任务卡，当前任务永远写在最上面。

这张卡只管一件事：管住当下这一个人的注意力。团队有明确分工，可以分头推不同任务。当前任务卡住了，可以切到其他任务，但要先留下状态，约定什么时候回来继续。

新冒出来的需求，先放到暂存处。等当前任务跑通，再决定下一个处理谁。

我过去的习惯，是把接需求当成负责。现在我认为不是。真正的负责，是你能告诉客户需求该怎么提、优先级怎么排，让大家知道临时调整会带来什么影响，然后基于这个做决定。

FDE 不是现场谁提什么就做什么。那是外包开发。

FDE 的价值，是帮所有人维持一个能持续推进的节奏。

04

第一版跑出来，别急着让客户测试

FDE 现场时间都很紧。第一版一跑通，很容易马上想让业务试一下。

这个动作本身没错。但如果技术链路还没做基础验证，就交给客户，等于把一部分测试工作转嫁给了业务人员。正式交付前，先备好三类测试，自己先跑一遍。

• 正常情况　输入完整、规则明确时，能不能得到预期结果。

• 边界情况　空值、临界值、少见组合，是不是按约定规则处理。

• 异常情况　信息冲突、格式错误、判断不了时，能不能明确提示。

跑通之后再请业务确认。这时候你的说法也会变：技术流程已经验证过了，现在主要想请您判断几个业务口径对不对。

这跟「您帮我跑一下看看有没有问题」，体验完全不同。前者是业务验收，后者是拉客户一起找 Bug。

第一版快速给客户看，不叫敏捷。敏捷的前提，是最基本的交付质量。

05

FDE 离场后，客户得能自己跑

FDE 天生不是长期替客户干活的角色。我们进现场，是为了把业务问题拆清楚，把 AI 方案跑起来，再然后让客户慢慢接手。

所以，FDE 在场的时候把东西做出来，只完成了一半。另一半是：你走了以后，客户还能不能继续用、继续测，甚至自己做点简单调整。

FDE 一走，项目就停下来等下一次支持，这种交付很难规模化。

我现在把一次现场交付分成两段：前半段把东西做出来，后半段把它交到客户手里。后半段至少要确认下面这些。

这里有个细节：不是 FDE 演示成功一次，就叫客户会用了。

标准应该反过来：最后一次测试，让客户自己操作，FDE 坐在旁边看。客户自己上传文件，自己调用 Agent 或者 Skill，自己看结果，然后告诉我这个结果业务上对不对。

走到这一步，才能确认客户是不是真的理解了怎么用 AI 完成自己的任务。

而且客户拿到的也不只是工具。还包括我们前面花了很长时间梳理出来的业务判断：哪些情况可以交给 AI，当前方案有哪些已知限制。

怎么判断自己能不能离场？就问一句：

如果我明天不来了，客户能不能把今天跑通的这个场景，自己再跑一遍？

这也是我这次对 FDE 这个角色理解上的一个变化。以前我容易把交付理解成：我帮客户把东西做出来。

现在更完整的说法是：FDE 先带着客户跑通，再让客户自己跑通。

06

回到开头那个现场

我这个人，学新东西比较快，遇到陌生业务愿意花时间听，客户有问题也愿意下场解决，碰到卡点会想办法搞定它。

但这次让我意识到：现场复杂度再往上加一层，只靠个人能力就不够了。一个陌生、高并发、快节奏的 FDE 现场，真正要的是另外三种能力。

   收敛　·　取舍　·　外化 

收敛　在大量信息里，始终知道当前只解决什么。

取舍　能判断什么现在做，什么明确暂时不做。

外化　把脑子里的理解，变成流程、规则和客户能继续用的成果。

复杂现场里，FDE 更重要的能力，是把问题的数量和复杂度压到自己控制得住的范围里。

这次之后我给自己留了一份可以直接带进现场的清单：开工前四问、业务建模六问、任务卡、三类测试、离场确认。需要的话，在后台回复「现场清单」领取。