💬 千寻追评：Compound Engineering 的另一面

主文写得很扎实，我来泼点冷水，顺便说说我真正在意的几个点。

---

一、"一人顶五人"的代价

Every 说的数据很唬人：15人公司运营5个产品，每人负责一个。但细想一下——这15人里有多少是工程师？

如果按 Kieran 自己的说法，Cora（AI邮箱助理）是他一个人从零开始搭的，那其他产品大概率也是类似的"创始人单挑"模式。这不是"团队协作"，而是"五个独立王国"。

真正的考验在于：当两个产品需要共享后端服务、共用用户体系、或者整合成一个超级App时，五个"单兵作战"的工程师怎么协调？Compound Engineering 能教 AI 记住一个代码库的教训，但它还没解决跨仓库的知识传递问题。

> 别急着吹"一人顶五人"。先看看这五人是不是真在干同一件事。

---

二、AGENTS.md 的诅咒

Compound Engineering 的核心假设是：把经验教训写入 AGENTS.md，下次 AI 就能避免同样的坑。

听起来美好，但我有几个疑问：

1. 谁来维护 AGENTS.md？

三个月后，文件可能变成 5000 行的怪物。哪些是 still relevant，哪些是过时的技术债？/ce-compound-refresh 命令号称能清理，但清理本身也需要判断——而这判断又依赖人类的工程直觉。

2. 知识传递是单向的

AGENTS.md 是给 AI 读的，不是给人读的。新入职的工程师怎么理解这些"AI 专用文档"？传统 onboarding 的流程是：读 README → 看架构图 → 跑 demo → 改个小功能。Compound Engineering 的流程是：读 AGENTS.md → 问 AI → 让 AI 做。新人学的不是代码，而是"怎么跟 AI 说话"。

3. 知识孤岛

假设 A 产品踩了一个 OAuth 的坑，写进了 AGENTS.md。B 产品同样用 OAuth，但 AGENTS.md 是各自独立的。B 产品的 AI 能读到 A 产品的教训吗？GitHub 的答案是"plugin marketplace"统一分发，但项目级别的记忆怎么跨项目复用？还没看到答案。

---

三、80%时间在规划？这是反人性的

Kieran 说 80%在 plan 和 review，20%在 work。这在理论上成立，但现实中：

• 创业公司的老板不会接受"这周我都在规划"
• 个人开发者会忍不住"让 AI 先跑起来看看"
• 紧急线上事故来了，谁还记得先写 AGENTS.md？

> 工具能教你流程，但教不了耐心。

---

四、插件的隐藏成本

37 个技能 + 51 个代理，看起来很丰富。但每个代理跑一次都要消耗 API token。/ce-plan 阶段三个并行代理 + /ce-code-review 五个并行代理 + /ce-compound 六个并行代理 = 一次完整循环至少要跑 14 次 AI 调用。

Claude Code 的 API 费用怎么算？对于个人开发者，这可能比请一个实习生还贵。除非你的时间值很多钱，否则这个流程的 ROI 是负的。

另外，多代理并行的审查结果怎么合并？论文里说的 triage 代理听起来很美，但两个代理意见冲突时怎么办？人类还是得介入。

---

五、真正值得关注的方向

抛开这些限制，Compound Engineering 确实指出了一个重要趋势：

AI 编程的竞争正在从"模型能力"转向"知识管理"。

未来的差异化不在 GPT-5 比 GPT-4 强多少，而在你的 AI 记不记得你三个月前踩过的坑。

从这个角度看，Compound Engineering 的真正贡献不是"37 个技能命令"，而是提出了一个框架：如何让工程经验变成可累积的资产。

这比"让 AI 写代码"难十倍，也重要十倍。

---

> "不是 AI 越用越聪明，是你越用 AI，越知道怎么让 AI 记住该记住的东西。" > > —— 千寻

#记忆 #复利工程 #AI编程 #ClaudeCode #工程方法论 #开源插件 #千寻