第 19 章 · 换个场景再走一遍

关于这一章

上一章那个竞品洞察智能体,走完了完整四周。你可能会想:那套方法,换个八竿子打不着的场景还灵吗?

这一章就换一个——某家 SaaS 公司的「知识库 + 客服工单分流」智能体:客户来的问题,能查知识库自动答的直接答,答不了的自动分派给对的人工组。表面看,这和「盯竞品」毫无关系。但我要带你看的,恰恰是同一套交付节奏,在不同场景下哪些照搬、哪些必须改。

我不再逐日记流水账(那上一章讲透了),而是压缩成四周骨架,把笔墨全花在取舍不同的地方——因为真正考验 FDE 的,从来不是套流程,而是在关键岔路口做对选择。

场景背景:一家 SaaS 公司,客服每天几百个工单,一半是重复问题(「怎么导出数据」「密码怎么改」),另一半得转给技术、账务、售后不同的组。现在全靠客服人肉判断、手动转派,又慢又常转错。他们的原话:「能不能让 AI 先答一遍、答不了的帮我们分对组?」

节奏和竞品案例几乎一样,证明这套骨架是可复制的:

周	目标	与上一章的对应
Week 0	需求共创,填场景卡、画介入点图	同构
Week 1	快验:知识库问答 + 工单分类先跑通丑版本	同构
Week 2	评估对齐:凑 Golden Dataset、定验收线、首轮跑分	同构
Week 3	迭代收敛:补齐、按失败样本调、达验收线	同构
Week 4	上线门禁 + 交接说明 + 五分钟路演	同构

骨架照搬。但一走进细节,三个关键决策就和上一章分道扬镳了。

竞品案例的数据是公开竞品页面 + 授权评论,主要合规风险是「采集频率别越界」。这个案例反过来:数据是内部知识库文档 + 真实客户工单,里面全是客户账号、联系方式、业务数据——PII(个人敏感信息)是主战场。

这个不同,逼出一连串不同动作:

📎 竞品案例不太碰的多租户与安全隔离,在这个场景是硬指标,工程实现见 Harness Agent Book · 第 28 章。

知识库本身也要体检。很多客服问答项目不是死在 RAG 技术，而是死在知识库质量：

竞品案例的人审门,插在「风险预警是否上报」——因为误报一次会吓到运营,所以让人拍板要不要推送。

这个案例的人审门,插的位置完全不同:在「AI 到底敢不敢直接把答案发给客户」。因为一旦 AI 自动回了个错答案给真实客户,那是对外事故,比内部误报严重得多。于是我们做了两道设计:

同样是「设人审」,竞品案例是「怕假警报」,这里是「怕对外答错」——人审门插哪儿,取决于哪种错的代价最疼。 这是 FDE 每个项目都要重新判断的事。

工单分流还要看错分代价：

指标也得跟着场景换。竞品案例最看重风险预警命中率(别漏掉集中差评);这个案例最看重的是引用可信度——答案有没有可核对的知识库出处。因为知识库问答最怕「一本正经地编」,而防编的办法就是「无出处不作答」。

样本还是四类(典型/边界/失败/高风险),但每一类装的东西,都是这个场景特有的。

四周走完,回头看交付包——和上一章那套,七成可以直接复用:

这就是「可复制交付包」的真正含义:你复用的不是内容,是结构和方法。 换个项目,骨架、清单、节奏、四类样本的框架原封不动;要重填的,只是具体的业务口径、样本、指标和人审位置——而这三成,正是靠 FDE 的判断力现场决定的。跑过一遍竞品案例,这一遍你会明显更快。

两类项目的架构差异，可以这样看：

往交付包里放一份「场景迁移对照表」:

挑一个和你主案例不同的新场景,列出三件事各自怎么变:数据来源(合规重点变没变?)、人审点(最疼的错换了没?)、验收指标(核心指标该换成什么?);再标出你的交付包里哪些能照搬、哪些要重填。这张表,是你把「一次交付」变成「一套可复制能力」的凭证。模板全部沿用附录 A–附录 F。