CoAI 开发日志 #007｜为什么 CoAI 不是另一个 spec 工具
做到这里，我不想再把 CoAI 讲成“另一种 spec 工具”。
不是因为它和 spec 没关系。
恰恰相反，它们有交叉。
CoAI 也会在编码前发挥作用。
也会帮助明确功能是什么。
也会帮助理清理想路径、关键环节、边界和方向。
所以如果只看表面，你很容易觉得：
这不也是一种 spec 吗？
我前面其实也想过这个问题。
甚至有一段时间，我自己都在反复确认：
CoAI 到底是在做一个“更轻的 spec 系统”，
还是在做别的东西？
后来我慢慢明确下来，
它和 spec 的区别，不在于“有没有计划”，
而在于：
它真正想长期保留的，到底是什么。
spec 类系统更擅长处理的是：
- 变更规格化
- 任务拆解
- 执行顺序
- 依赖关系
- 验证链路
也就是说，它更偏向：
如何组织并执行一次变更。
而 CoAI 更关心的是：
- 这个功能到底是什么意思
- 理想路径是什么
- 哪些认知点最关键
- 实现落在哪
- 实现之后，哪些认知应该被回流并留下来
也就是说，它更偏向：
如何让项目在持续演进之后，仍然保持可理解。
这两者当然有连接。
但不是同一种东西。
如果一定要把它们放到一条链路里，
我现在更倾向于这样看：
CoAI -> spec/plan -> coding -> validation -> CoAI
CoAI 在开始前，负责把功能语义和认知入口表达清楚。
如果需要，再由 spec / plan 系统把它转成更工程化的执行结构。
代码实现之后，再把稳定认知回流回项目。
所以它不是不碰“先做什么”。
但它参与的方式，和 spec 很不一样。
spec 更偏执行编排。
CoAI 更偏语义设计与认知回流。
这也是为什么我后来确认，
CoAI 不该往“更完整的工程编排系统”方向走。
因为一旦往那边走，它就很容易失焦。
它会开始去和很多已经很成熟的系统比：
- 谁的 plan 更完整
- 谁的 task 更细
- 谁的依赖关系表达更强
- 谁的验证闭环更标准
但这些并不是 CoAI 最独特的地方。
CoAI 真正独特的地方，反而在另外一边：
- 功能语义能不能表达得刚刚好
- 人和 agent 能不能从语义入口迅速进入代码
- 长对话和长项目之后，认知会不会漂
- 项目在持续变化后，是否还保留清楚的当前状态
这些问题，spec 类系统当然也会碰到。
但它们不是 spec 类系统最核心的主战场。
而恰恰是 CoAI 最应该聚焦的地方。
我现在的判断是，
CoAI 如果要把自己讲清楚，最重要的不是强调“它也能做一点 spec 的事”，
而是强调：
它解决的是另一层问题。
不是“这次改动该怎么拆”。
而是“这个项目在更多 AI 参与之后，怎么还不至于重新变成黑盒”。
所以我现在更愿意把 CoAI 定义成：
不是过程驱动的执行编排系统，
而是状态驱动的项目认知层。
这句话对我来说很重要。
因为它决定了 CoAI 该做什么，也决定了它不该做什么。
它不需要把自己做成另一个完整 spec 系统。
它真正要守住的是：
- 功能级认知焦距
- 语义到代码的桥梁
- 当前状态的持续可见
- 认知回流之后的长期可理解性
如果这些东西能做好，
CoAI 的价值就已经成立了。
如果今天要把这篇压成一句话，我会这样写：
spec 工具更擅长组织一次变更，CoAI 更擅长保留一个项目在变化中的可理解性。
这也是为什么我现在更明确地觉得：
CoAI 不是另一个 spec 工具。
它更像是 AI coding 时代的项目认知层。
这是 CoAI 开发日志第 7 篇。
记录我在 AI coding 时代，如何理解人与 AI 应该怎样协同工作。
