12.3 C 能力沉淀（4 问）

Q9：项目那么忙，哪有时间做沉淀？

「有空再做」等于永远不做，这是行业里最普遍的失败原因。两个具体解法：

第一，把沉淀写进项目目标。 项目立项时就明确「本项目产出 N 个可复用 Skill / 1 个行业模板 / 1 套测试用例集」，和交付里程碑同级，而不是附加项。

第二，边做边沉淀而不是事后补。 每解决完一类问题，立刻花 20 分钟抽象一次——此时上下文还热、失败样本还在。结项后补，成本高三倍，质量还差。

如果考核上完全不认沉淀，那这不是时间问题而是机制问题，需要向上反映。

核心要点回顾

项目总结是记录，不是资产。资产的判定标准只有一条：下一个人不需要读懂全部上下文，就能直接调用它。

更硬的验证：一个 Skill 必须在第二个场景上被用过一次，才算沉淀完成。从没被复用过的 Skill，只是格式好看一点的笔记。

另外注意区分载体（第 8 章「沉淀」的载体对比）：可复用方法进 Skill，系统接入方式进连接器，客户专属文档进资料库，岗位角色设定进专家配置。装错载体会导致复用时找不到、或者一复用就要大改。

Q11：AI 有时会编内容，客户一旦发现就不信了，怎么处理？

不要试图靠「把准确率调到 100%」来解决，那做不到。正确做法是让不确定性变得可见。

用第 8 章的三态溯源：知识库实证（可点回原文）、接口实证（可查调用记录）、AI 推断（无客户侧证据）。三类在界面上明确区分，推断类必须显式标注。

同时在验收条款里写上**「拒答优于胡答」**：信息不足时明确说明「我没有依据，建议找 XX 确认」，这种回答不算失败；编造一个看起来合理的答案，算失败样本。

实践中，一个会承认自己不知道的助理，比一个什么都答得出来的助理更容易被长期使用。

Q12：怎么判断我们团队的 FDE 模式跑通了没有？

只看一个指标：第 N 个同类客户的现场投入，是否明显低于第一个。

参照第 8 章的成本曲线——项目制是 1× → 8–9×，本体化是 3× → 4–4.5×。如果到第四单还在 6× 以上，说明沉淀是假的，实质仍是项目制。

三个辅助自查问题：① 新人加入后，多久能独立跟一个项目？（沉淀好的团队应该显著缩短）② 上个项目产出的资产，这个项目用上了几个？③ 商务定价还是按人天吗？（如果是，沉淀在财务上是负激励）