8.1 双向蒸馏——从「项目总结」到「可复用资产」

本章导读

本 节 目 标

• 能辨析「项目总结」与「可复用资产」的差别。判断标准就一条，下一个人不需要读懂全部上下文，就能直接调用。
• 能说明面向客户与面向产品的双向蒸馏缺一不可。
• 能把一个解法拆成两层，共性方法进 Skill，客户特化配置留在资料库和参数。边做边沉淀，在第二个场景上验证过，沉淀才算完成。
• 能用成本曲线（项目制 1×→8–9× vs 本体化 3×→4–4.5×）评估沉淀的商业价值。
• 能回答一线员工交出经验前的信任四问，守得住三态溯源和四条红线。

先聊一个你可能很熟悉的场景。

你刚交付完一个企业知识库 RAG 项目，客户很满意，项目组庆功酒都开了。一周后，另一个行业的客户提了几乎一样的需求——也要知识库、也要问答、也要权限管控。你本以为「复用上次的东西，两周搞定」，结果一翻上次的工程目录：

• Prompt 散落在十几条对话记录里，你记不清哪条是最终版；

• 知识切片的规则只存在你脑子里，文档里写了一句「按语义切分」，但没人知道阈值是多少；

• 客户特化的字段映射表混在通用流程脚本里，换个客户就得从头改；

• 上次的踩坑笔记呢？在某个人的飞书私人文档里，团队其他人看不到。

于是「复用」变成了「重做」。第二个项目的成本几乎和第一个一样高——客户会觉得，我为什么花了同样的钱，买了一个「你已经做过一次」的东西？

这就是本章要解决的核心问题：怎么让经验真正变成资产，让第二个项目比第一个容易。

做 AI 前沿部署的工程师很多，但能把交付经验沉淀成可复用资产的人很少。区别不在于技术多牛，而在于你愿不愿意在忙碌的交付间隙里，把「我脑子里的解法」翻译成「别人能直接调用的资产」。这一章，我们就来把这个翻译过程拆解清楚。

概念

先说清楚两个词的差别：「项目总结」和「可复用资产」。

项目总结，就是你交付完一个项目后写的复盘文档。它记录的是「这次发生了什么」：遇到了什么问题、怎么解决的、客户反馈如何、下次要注意什么。它的读者是「了解这个项目上下文的人」——也就是当时的你和项目组。

可复用资产，是一种「下一个人不需要读懂全部上下文就能直接调用」的东西。它记录的是「遇到这类问题，你可以这么做」：通用的解决方法、可配置的参数、可替换的数据源。它的读者是「完全没有参与过上个项目的人」。

打个比方。项目总结像是你旅行回来写的游记：「今天去了某某景点，路上堵车，下次避开早高峰。」对你自己很有用，但你朋友去同一个城市时，未必翻得到这条笔记，翻到了也未必对得上他住的酒店位置。

可复用资产更像是你整理出来的一张「避堵路线卡」：不管你住哪，按出发地查表就能找到推荐路线。它没有具体某一次的上下文，但任何人都能直接用。

🖼 图：distillation two directions

蒸馏这个词，就是从一团混杂着上下文、个人经验、客户特例的信息里，把真正可复用的「精华」提取出来。之所以叫「双向」，是因为沉淀要同时面向两个方向：

• 面向客户 ：蒸馏目标是客户能持续使用、自主迭代的操作资产，读者是客户侧运维和业务人员。

• 面向产品 ：蒸馏目标是能跨项目复用的能力资产，读者是内部交付团队和产品研发。

为什么缺一不可？

• 只面向客户沉淀：你的经验锁死在这个客户里，下个项目还得从头来。对客户来说，你走了之后东西还能跑；但对你和团队来说，经验没有积累。

• 只面向产品沉淀：你的经验进了内部 Skill 库，但客户那边还是「离了你就不行」。客户花钱买的不仅是交付，还有「我们自己能持续用」的能力。

用法

蒸馏要贯穿交付全程，边做边蒸，别攒到交付完才动手。核心动作有三个：

示例

假设你在客户 A 那里做了一个文档问答系统。交付中你发现：客户的知识库里有大量表格，标准切片器把表格切断后，问答效果暴跌。你手动调了切片规则，加了「表格不切分」的特殊处理，效果恢复了。

项目总结式的记录会这么写：

提示

在客户 A 项目中，发现表格被切片器切断导致问答效果差，修改了切片规则，加了表格不切分的逻辑，效果恢复。下次遇到类似情况注意检查表格。

这段记录只有「参与了客户 A 项目的人」才看得懂——修改了哪个配置项？加在哪段代码里？阈值是什么？一概不知。

资产式的记录会拆成两层——通用方法层写清「什么情况下做什么」（具体怎么封装成 Skill 是 8.2 的内容），客户特化层留参数：

通用方法层（进 Skill 雏形）：「知识库切片质量自检——知识库接入完成、问答效果测试前，检查切片是否切断表格，必要时调整配置并回归测试。」

客户特化层（留在资料库）：

提示

客户A资料库备注：该客户知识库表格占比约 30%，表格列为「产品规格表」，切片阈值 800 token 仍会切断超过 3 行的表格，已将 max_chunk_size 调为 600。

第二个人拿到这段 Skill，哪怕没去过客户 A，也能在自己的客户那里照着做自检。客户 A 的特例留在 A 的资料库里，不污染通用方法。

注意事项

• 「项目总结」不等于「沉淀完成」 ：如果你交付完后写的文档，只有「参与了项目的人」才看得懂、才用得起来，那它还是项目总结，不是资产。检验标准很简单：找一个没参与过这个项目的同事，把你的沉淀丢给他，看他能不能在 30 分钟内理解并开始使用。能，才算资产；不能，回去继续蒸馏。

• 不要等到「完美」才沉淀 ：很多一线工程师的沉淀障碍是「我还没完全想清楚，等我想清楚了再写」。沉淀不是一次性的完美产出，是不断迭代的草稿。第一版 Skill 写得粗糙没关系，先沉淀、在第二个场景上验证、再修正，才是正常流程。等「想清楚」往往等于「永远不沉淀」。