CoAI 开发日志 #002｜项目不是靠过程推进，而是靠状态推进
最近做项目时，我确认了一个判断：
项目不是靠保存全部过程推进的，而是靠维护当前状态推进的。
这句话听起来有点抽象，但其实我是在实际做项目时，被迫意识到这件事的。
尤其是开始大量使用 AI coding 之后，这种感觉特别明显。
前几轮对话时，很多信息都很有用。
agent 会解释它为什么这样改。
会总结这一轮做了什么。
会告诉你下一步准备怎么做。
这些内容在当下往往都很有价值。
我自己也会认真看。
因为那时候它确实能帮我判断：
- 方向有没有偏
- 理解有没有错
- 这轮是不是朝着我想要的地方在走
但问题是，这些信息通常只在那个时刻特别有用。
再过几轮之后，项目状态一变，它们就开始变旧了。
不是因为当时写错了。
而是因为：
- 文件结构变了
- 功能边界变了
- 一些实现移动了
- 之前的判断被新的实现覆盖了
于是你再回头看那些总结，会发现一种很熟悉的感觉：
它们不是没用。
但也已经不是当前最值得依赖的认知。
这件事我后来越想越觉得正常。
因为人做长周期的事情，本来也不是靠保存全部过程往前走的。
一个项目做久了之后，没有人会真的一直回放每一步。
真正支撑继续推进的，通常是这些东西：
- 现在项目处于什么状态
- 哪些功能已经成立
- 哪些关键决策不能忘
- 哪些实现点最值得进入
- 下一步从哪里接着做
也就是说，项目的推进，靠的不是“完整过程回放”，而是“当前有效状态”。
这一点在 AI coding 里尤其明显。
因为 AI 很擅长快速制造大量过程信息。
一轮又一轮的解释、总结、拆解、推理，在当下都很有帮助。
但如果没有一层东西把真正有效的认知留下来，这些内容很快就会过时。
然后项目就会进入一种奇怪的状态：
你明明做了很多。
功能也在继续长。
但如果现在让你快速说清楚“这个项目的当前状态是什么”，你不一定讲得出来。
这就是为什么我后来把“状态”放到了更重要的位置。
不是因为过程不重要。
而是因为过程很容易失效，状态才更适合被持续维护。
这也慢慢影响了我对文档的看法。
我以前也会下意识觉得，既然 AI 对话很有价值，那是不是应该尽量保留下来？
但后来发现，不对。
如果把全部过程都留下来，项目不会更清楚，只会更重。
真正应该保留下来的，不是每一次怎么想，而是：
- 现在这个功能到底是什么
- 它当前有效的理想路径是什么
- 哪些说明仍然有帮助
- 代码入口在哪里
- 当前主线推进到了哪
这也是为什么后来我会把 CoAI 的一些设计越收越窄。
比如：
feature.md负责功能级认知current.md负责当前项目进展mapper负责把认知稳定地挂回代码node负责 Hover 入口
这些东西的作用，都不是保存完整过程。
它们是在维护当前仍然有效的认知状态。
这可能是 AI coding 时代一个很重要的变化：
以前我们以为难点是“怎么把事情做出来”。
现在很多时候，新的难点变成了：
怎么在事情持续变化之后，仍然知道它现在是什么。
这也是我为什么会说，项目不是靠过程推进，而是靠状态推进。
因为真正会长期留下价值的，不是那一长串已经过时的上下文，
而是你能不能在项目持续演进之后，依然保留一个清楚、稳定、可继续接下去的当前认知状态。
如果今天要把这篇压成一句话，我会这样写：
过程帮助你走到这里，认知状态决定你还能不能继续走下去。
这是 CoAI 开发日志第 2 篇。
记录我在 AI coding 时代，如何理解人与 AI 应该怎样协同工作。
