CoAI 开发日志 #001｜代码生成不再是瓶颈，掌控感才是新的瓶颈
现在用 AI coding ，代码写得很快。
功能经常下一秒就能落地。
你给一个目标，agent 很快就把页面、逻辑、接口、异常处理都铺出来了。
前面几轮的时候，人的感觉通常还不错。
每轮输出你都在看。
每轮思路你也都在判断。
你会觉得自己还在“指挥”这件事。
你提需求，AI 去实现，你再纠偏。
推进速度很快。
但这个状态，通常只在前面成立。
指挥棒，会一点点交给 AI
轮数一多，代码开始上规模，事情就慢慢变了。
那个最开始还握在你手里的“指挥棒”，会一点点交给 AI agent。
表面上看，好像还是你在主导。
但实际上，你开始反复输入同一句话：
继续下一步。
然后一个很微妙的变化就来了：
你开始不愿意碰源码文件了。
不是因为源码写得差。
也不是因为功能不能跑。
而是因为你慢慢不知道：
- 这个功能的代码入口到底在哪
- 下一步跳转会落到哪里
- 数据流在源码文件里是怎么分布的
- 如果现在动一个地方，会牵出哪些实现
于是你能直接处理的事情变少了。
你不再直接进代码。
你开始更多地问 AI：
- 这个逻辑在哪？
- 这个流程怎么走？
- 这里改了会影响什么？
- 你继续往下做吧
到这里，项目其实还在推进。
功能也还在继续增加。
但人的掌控感，已经开始往下掉了。
这不是“写不出来”，而是“开始不在自己手里”
后来我发现，这不是“代码写不出来”的问题。
而是“项目开始不在自己手里”的问题。
我做 CoAI 之前，甚至做别的项目时，也有过类似感受。
并不是没有 spec。
也不是没有规划。
一般一个项目开始时，都会有一些基础 spec：
- 项目目标是什么
- 用户是谁
- 想解决什么问题
- 大概有哪些模块
- 技术方向是什么
这些当然有用。
但它们的焦距太粗了。
它们能告诉你“这个项目是什么”，
却不一定能告诉你“这个功能具体该怎么进入”。
但如果继续往下压，细到每个节点、每段代码都解释一遍，问题又反过来了。
信息量会迅速变大。
文档会变重。
认知成本反而更高。
所以后来我慢慢有了一个很明确的判断：
问题不是有没有 spec，而是认知焦距有没有调对。
如果只停在项目级 spec，太粗。
如果细到代码段落级，太重。
真正比较合适的，是功能级。
也就是：
- 这个功能的理想路径是什么
- 关键环节是什么
- 技术方向大概怎么走
- 真正的实现入口在哪里
- 需要的时候，怎么快速回到代码
这一层刚刚好。
不会空到只剩愿景。
也不会细到把代码再讲一遍。
项目不是靠保存全部过程推进的，而是靠维护当前状态推进的
还有一个判断，是我在几轮真实开发后确认下来的：
很多 agent 的总结，在当下其实都很有价值。
我每轮也都会认真看。
因为在那个时刻，它确实能帮我判断：
- 方向有没有偏
- 理解有没有错
- 这一轮是不是朝着我想要的地方在走
但过几轮之后，很多总结其实就“过时”了。
不是因为它们写得不好。
而是因为项目状态已经变了。
文件改了，结构动了，功能扩了。
以前那轮对话里的好解释，不再等于当前最有效的认知。
所以我现在的判断是：
项目不是靠保存全部过程推进的，而是靠维护当前状态推进的。
人做长周期的事，不会一直回看每一步。
真正有用的是：
- 现在项目是什么状态
- 哪些功能已经成立
- 哪些关键判断不能忘
- 哪些实现点最值得进入
- 下一步从哪里接着做
这也是我为什么开始做 CoAI
做到这里，我才慢慢明白自己真正想做的东西是什么。
不是更重的节点蓝图。
不是把一切都写成过程文档。
也不是再造一套完整 spec 系统。
而是一层刚刚好的功能级认知。
项目级 spec，继续放在 README、docs 那种地方。
真正进入开发和维护阶段之后，需要的是功能级认知入口。
既能让人快速理解这个功能，
也能在需要的时候，很快回到代码实现。
对我来说，CoAI 后来真正想解决的，就是这个问题：
当 AI 把代码越写越快之后，人怎么还能不失去对项目的控制。
所以如果今天要把这个判断压成一句话，我会这样说：
代码生成不再是瓶颈之后，掌控感才是新的瓶颈。
我现在做 CoAI，就是在试着回答这个问题。
这是 CoAI 开发日志第 1 篇。
记录我在 AI coding 时代，如何理解人与 AI 应该怎样协同工作。
