001 AI-FDE 的职责模型-第二篇

对话版 · 第 2 篇／共 2 篇（周蓝／杨橙）

杨：

理论我懂了，能不能走个真例子？光听我怕记不牢。

周：

就拿一个 60 人 SaaS 公司的"销售 AI 助手"项目，走完三段看 5 个职责怎么落地。

入场段（2 周）

搭建段（6 周）

离场段（4 周）

这个案例的关键点：入场花 2 周做需求翻译和风险识别，搭建只做一个场景，离场做充分交接。如果跳过入场直接搭建，至少返工 2 次；离场不交接，系统上线就死。

杨：

那反面教材呢？我想知道偷工减料会咋样。

周：

同一家公司，第二年做"客户服务 AI 助手"，换了个更急的节奏——客户说"这简单，就是把知识库接上赶紧做"，团队跳过入场直接开搭。结果三段各自失控：

最终比计划多花约 6 周工时（约 2 人月），上线后因为旧制度仍在被检索，还出现过两次"按作废政策回复客户"的投诉。技术方案和第一期几乎一样，差别只在于第一期花 2 周把入场做完了，第二期省了这 2 周，却赔进去 6 周和两次线上事故。这就是"入场段不是流程官僚主义"最直接的一笔账。

周：

---

杨：

我注意到你一直在强调"边界"，这玩意到底多重要？

周：

边界不是限制，是跟客户对齐预期最快的方式。不写边界，客户期望会无限膨胀；写清边界，大家都知道首期做到啥程度，后续迭代有节奏。

杨：

不写会咋样？

周：

客户说"做一个 AI 助手"，团队直接开工。做着做着客户说"能不能接 CRM""能不能自动写回""能不能做客户画像""能不能预测成交"。需求不断膨胀，团队加班加点，三个月后还是没法验收，因为没有一条明确的"完成"标准。团队崩溃，客户不满意，项目黄了。

杨：

那正确的写法？

周：

入场时就列三档：

每档都要有具体内容，不能写"视情况而定"。三档写清楚后，业务方、研发、测试三方签字，后续任何新需求都走变更流程，不直接塞进首期。

杨：

有实际好处吗？

周：

有。某项目入场写清了边界，搭建到第 4 周客户说"能不能加个语音输入"。因为边界里写了"暂缓"，所以走变更流程，评估后放二期，首期没被打乱，按时上线。要是没写边界，这需求直接塞进来，首期至少延期 2 周。

周：

---

杨：

这么多条，真上线前我咋确保没漏？

周：

每个 AI FDE 项目上线前，必须落一份 YAML 工程契约——把模糊的"承诺"翻译成可验收的字段，四方（业务/合规/研发/测试）共同签收。给你看个示例骨架：

这份契约不是走形式，是把"我们承诺做啥"变成一条条能核对的条目。上线前对照清单逐条验收，任何一条不达标就不上线，别"感觉差不多了"就上线结果出事。

周：

---

杨：

还有个困惑：我们 Demo 跑得挺好，客户一看就满意，可一上生产就出事，咋回事？

周：

因为 Demo 能跑通 ≠ 生产能上线。很多团队 Demo 做得很漂亮，一上生产就出问题，就是下面 8 项没对齐。这张表入场时就发给客户逐条对齐——比如客户说"我们就要 Demo 那种效果"，你就指给他看"Demo 和生产的差距在这 8 项，首期做哪几项、二期做哪几项"，这样他对交付范围有合理预期，不会拿 Demo 标准要求生产。

周：

---

杨：

你讲的都是"该咋做"，那现场最常踩的坑能不能归归类？

周：

把前面的线索合起来，客户现场反复出现的偏差就三类，提前识别比事后补救成本低一个数量级：

1. 跳过业务翻译直接动手：客户只说"用 AI 提效"，团队没先把职责边界和交付物讲清就急着接 API、写提示词。结果很快能跑个原型，但没有可验收的任务定义，评审时谁都说不清"做完了没有"。正确做法：先翻译成需求卡六字段，把"谁在什么场景完成什么动作"钉死再动手。

2. 一次接入全部数据：首期就把 CRM/ERP/工单所有数据源都接进来想"一步到位"。结果数据治理失控，没一个场景能跑通验收，上线后反复返工。正确做法：首期只选 1–2 个高频可验证场景，其余放二期排期。

3. 职责边界不写清就上线：Demo 跑通即交付，"剩下的后续再说"。结果半年内被不断涌来的新需求压垮，团队疲于救火，项目逐渐失控。正确做法：需求卡必须写明首期不做什么，其余一律走变更流程。

周：

---

杨：

内容好多，能不能给我一份能贴工位上的速查？

周：

没问题，记这一句就行：入场摸红线、搭建做闭环、离场交能力——每段都有退出条件，不达标不进下一段。

三段分工速查

边界三档速查

现场症状速查

判断顺序记牢：先过红线（合规/数据/依赖）→ 再看首期场景是否高频、边界清楚、结果可观察 → 再看四类指标有没有口径和责任人 → 最后看客户团队能不能独立发布和排障；上一步不过，不进下一步。

杨：

收到！这段话我截图了😎

周：

最后一句收尾你得记住：三段式的价值不在流程本身，而在于把"复盘时才发现的问题"提前放进每一段的退出条件里。

周：

---

杨：

周哥，给我留个作业呗，我回去自己捋一遍。

周：

行，就一道：客户说"我们想要一个 AI 助手，能帮销售自动跟进客户"，你觉得这个需求里有几个字段是空的？入场第一周你会做哪几件事？

杨：

让我想想……"自动跟进客户"这话太虚了。

周：

参考答案：六个字段全空——没有具体的人（哪些销售）、没有触发场景（什么时候跟进）、没有数据范围（读什么数据）、没有输出物（产出什么）、没有验收标准（什么叫好）、没有边界（不做什么）。入场第一周做三件事：1）访谈 3–5 个真实销售，还原跟进工作流，找最高频痛点；2）盘点 CRM 数据，确认能不能拉、要不要脱敏；3）画边界，首期只做一个场景，比如"每周五生成跟进摘要"，不做自动跟进。

杨：

懂了！这下我知道下周那个项目该怎么接了，先别急着写代码，先把入场段的三段红线摸清楚👍 谢周哥！

周：

去吧。记住，FDE 的价值就是把交付现场变成可复用能力——你这次踩的坑、写的契约、画的边界，下次直接能套。

📝 本篇注释（第 2 篇／共 2 篇）

本篇覆盖：三、贯穿案例：销售 AI 助手、四、工作边界：写清边界比加班救火划算 10 倍、五、把本章翻译成工程契约、六、Toy Project vs. 生产级系统 · 8 项关键差异、七、客户现场最常见的三种反模式、八、三段式交付速查（小抄）、九、思考题（练手用）。