8.7 沉淀载体——资产放在哪里、长什么样

概念

前面几个知识点讲的是「沉淀什么、怎么沉淀、沉淀值不值得、沉淀的机制怎么设计」。这个知识点讲最后一个落地问题：沉淀出来的东西，放在哪里、长什么样、谁能调？

这就是沉淀载体。一个团队能不能真正把经验变成资产，最后就看载体设计得好不好。载体太重，没人愿意往里放东西；载体太散，放了也找不着；载体没权限，客户敏感的东西可能泄露。

沉淀载体有三种基本形态：Skill 库 = 有元数据的 Skill 文件，资料库 = 按客户分目录的配置，踩坑库 = 卡片式记录。

🖼 图：asset carriers three

这三种载体三种都要有，单选哪一种都不够。因为沉淀的内容本身是分层的：

• 通用方法（跨客户复用）→ 进 Skill 库；

• 客户特化（只此客户适用）→ 进资料库；

• 踩坑经验（防止重复踩）→ 进踩坑库。

用法

设计沉淀载体，要考虑五个关键属性：

示例

一个团队的载体设计可能长这样：

Skill 库：团队公共 Git 仓库，每个 Skill 一个目录。目录里有：

• skill.md ：Skill 定义（触发条件、步骤、输入输出）

• metadata.yaml ：三态溯源标注（见 8.3，实证/推断显式区分）+ 版本号

• changelog.md ：迭代记录

skills/

├── kb-slice-quality-check/

│   ├── skill.md

│   ├── metadata.yaml

│   └── changelog.md

├── permission-check/

│   ├── skill.md

│   ├── metadata.yaml

│   └── changelog.md

└── ...

资料库：按客户分目录，权限隔离（客户间不可见，见上图）：

data-room/

├── client-A/

│   ├── kb-config.yaml  ← 切片参数、数据源配置

│   ├── field-mapping.csv  ← 客户业务字段映射

│   └── notes.md  ← 客户特化备注

├── client-B/

│   └── ...

踩坑库：卡片式、团队公共（不按客户隔离，踩坑经验本身通用）：

pitfalls/

├── 001-table-slice-cut.md  ← 标签：知识库/切片/表格

├── 002-permission-inheritance.md  ← 标签：权限/继承

└── ...

每条踩坑记录长这样：

标题：表格切片被切断导致问答效果暴跌

场景标签：知识库 / 切片 / 表格

现象：客户 A 知识库接入后，问答效果测试准确率仅 60%

根因：切片器 max_chunk_size 800 token，超过 3 行的表格被切断

修正：max_chunk_size 调为 600，"保留结构"参数设为 true

关联 Skill：kb-slice-quality-check

这样，团队成员遇到类似问题时，按「知识库/切片/表格」标签检索，就能找到这条踩坑记录，进而关联到对应的 Skill，直接调用。

注意事项

• 不要把三种载体混在一起 ：有些团队图省事，把 Skill、客户资料、踩坑记录都塞进一个飞书文档。结果：Skill 夹杂着客户敏感数据，没法跨客户复用；踩坑记录和通用方法搅在一起，检索时分不清「这是通用解法还是某次特例」。三种载体各司其职，不要混。

• 载体不要太重 ：如果要求每个 Skill 必须填 20 个字段、经过三级审批才能进库，工程师会放弃沉淀。载体设计的核心是「低门槛进、有版本管、能迭代修正」。第一版粗糙没关系，后续通过版本管理和反馈机制提升质量。

• 踩坑库不是「错误日志」 ：踩坑库的价值不在记录「出错了」，而在记录「出错了→根因是什么→怎么修的→关联哪个 Skill」。一条只有「出错了」没有根因和修正的踩坑记录，信息量为零。

• 载体层面守住四条红线 （见 8.3）：客户原始业务数据和敏感信息只进资料库、不进 Skill 库（不碰不该碰的数据）；失败样本进踩坑库、不隐藏（不藏失败）；每条 Skill 只写验证过的做法（不空头承诺）。

8.8 本章小结

项目总结 ≠ 可复用资产：项目总结记录「这次发生了什么」，可复用资产是「下一个人不需要读懂全部上下文就能直接调用」。蒸馏就是从混杂信息里提取可复用精华，双向蒸馏=面向客户沉淀 + 面向产品沉淀，缺一不可。

Skill 沉淀的正确姿势是拆两层：共性方法进 Skill、客户特化留资料库和参数。封装四步：识别→剥离→封装→验证。在第二个场景上验证过才算沉淀完成，只有一个客户验证过的 Skill 只是草稿。

三态溯源是数据诚实底线：输出证据来源分三态——知识库实证（可回溯原文，可信度最高）、接口实证（可复查调用记录，可信度高）、AI 推断（无客户侧证据，必须显式标注）。四条红线是职业行为底线：不碰不该碰的数据、不替客户做终审决策、不隐藏失败样本、不承诺自己没验证过的效果。

成本曲线说明沉淀的商业价值：项目制 1×→8–9×（不沉淀，成本不降），本体化 3×→4–4.5×（沉淀，第二个项目起边际成本递减）。3× 的前期投入是买后面的斜率；如果到第四单还在 6× 以上，说明沉淀是假的，实质仍是项目制。沉淀的价值在第二个项目兑现，判断值不值得沉淀的标准是「同类场景会不会出现第二次」。

冷启动四条铁律与定价陷阱：只打一个场景、选愿意共建的客户、第一单就设沉淀交付物、定价不按人天。按人天定价使沉淀成为财务负激励——沉淀得越好能收的钱越少，这是机制问题不是执行问题，必须在组织层面解决。

信任四问是机制问题不是道德问题：贡献（保留署名与来源）、收益（先让 AI 替他省事，收益早于索取）、边界（只沉淀岗位方法，不索取个人资源）、安全感（参与判断与校验环节，不被替代）。必须靠机制回答，不能靠口号。

沉淀载体三件套：Skill 库（放通用方法）、资料库（放客户特化，按客户隔离）、踩坑库（放踩坑记录，团队公共）。守住四条红线：不碰数据、不替终审、不藏失败、不空头承诺。