从经验到复利
约 726 字大约 2 分钟
2026-06-01
一次问题被解决，不等于团队获得了复利。只有当解决过程被整理成可检索、可复用、可更新的资产时，下一次类似任务才会更快、更稳。
这就是从经验到复利。
经验为什么会流失
AI 协作让问题解决速度变快，但也让经验更容易散落在临时位置：
| 位置 | 问题 |
|---|---|
| 聊天记录 | 难搜索、难审查、难和代码版本对应 |
| PR 评论 | 只服务当前变更，后续不一定能被发现 |
| 个人记忆 | 无法被团队复用，也容易过期 |
| 零散文档 | 没有结构和 frontmatter，难以检索 |
| 代码 diff | 只显示结果，不显示调查路径和取舍 |
AI 可以帮你更快解决问题，但不会自动把解决过程变成团队资产。
复利需要什么
| 资产 | 用途 |
|---|---|
| solution docs | 记录问题、根因、方案、验证和后续注意事项 |
| review findings | 把风险类型和发现模式沉淀下来 |
| memory | 保存长期有效的项目偏好和决策 |
| skill | 把重复流程变成稳定能力 |
| template | 让下一次 artifact、检查清单或报告更快开始 |
| source map | 让人和 Agent 更快找到相关代码和文档 |
这些资产的共同点是：未来的 Agent 和人都能重新读取。
Compound Engineering 的位置
Compound Engineering 关心的不是单次 AI Coding 是否完成，而是一次工程工作是否留下下一次可复用的东西。
解决问题
-> 记录根因和方案
-> 提炼可复用模式
-> 放入可检索位置
-> 后续任务读取
-> 更新过期知识如果没有最后两步，所谓“复盘”很容易只是写完就沉底。
什么值得沉淀
不是所有任务都值得写长文档。可以用下面的判断：
| 值得沉淀 | 不一定需要沉淀 |
|---|---|
| 反复出现的问题 | 一次性文案调整 |
| 调查成本高的问题 | 明显拼写错误 |
| 涉及架构或流程取舍 | 局部样式微调 |
| review 中发现的系统性风险 | 已由测试完全覆盖的小修 |
| 能转成 skill 或模板的流程 | 临时实验结论 |
和 OpenSpec 的关系
OpenSpec 记录一次变更的目标、行为、设计和任务；Compound 记录一次工程工作的执行经验、评审发现、调试路径和可复用知识。
两者组合后，团队既知道“系统为什么变成这样”，也知道“下一次遇到类似问题怎么更快处理”。
核心结论
AI 让工程执行更快，但团队复利不会自动发生。复利来自结构化沉淀：把有价值的经验放到未来能被人和 Agent 重新读取的位置。
