CoAI 开发日志 #003｜为什么我放弃了重节点蓝图
CoAI 一开始并不是现在这个样子。
最早我认真想过一条路线：把项目理解做成一种更重的“节点蓝图”。
也就是尽可能把一个功能拆成很多节点，
然后把它们之间的关系、流向、分支、异常都结构化地表达出来。
刚开始看，这条路其实很诱人。
因为它很“完整”。
你会觉得：
- 结构很清楚
- 流程被画出来了
- 节点之间有关系
- 一切都更可解释了
尤其是在 AI coding 这个语境下，它看起来更合理。
因为 AI 很擅长处理结构化信息。
人也会天然觉得：如果都拆清楚了，理解应该会更容易。
但我后来慢慢发现，不对。
问题不是这条路没有价值。
问题是，一旦项目开始规模化，它会变得很重。
而且这个“重”，不是工程实现重，
而是认知成本重。
节点一开始少的时候，看上去很美。
可当你一个功能往下拆出更多节点，
更多分支，
更多异常，
更多跨文件关系之后，
你会突然发现：
结构并没有自动带来理解。
很多时候，反而只是把复杂度重新表现了一遍。
甚至有时候，比直接看代码还累。
因为你眼前多了一层额外结构。
你要先理解节点图在说什么，
再去理解代码在说什么。
这就出现了一个很关键的问题：
文档到底是在帮人理解，还是在要求人先理解文档本身？
这是我后来反复检查的一点。
如果一个认知系统最后需要开发者花很多精力先读懂它自己，
那它很可能已经开始偏离“减负”这件事了。
这也是为什么我后来判断，
不是表达结构越细越好。
尤其是开发者语境下，有一个事实很难绕过去：
代码本身已经是最好的具体流程语言。
具体的 if-else 怎么走，
异常是怎么捕获的，
数据是怎么传下去的，
函数之间怎么调，
这些事情，代码往往比自然语言节点图更直接。
所以问题就变成了：
如果代码已经是最好的具体流程表示，
那文档到底还应该负责什么？
我后来给自己的答案是：
文档不该重复代码。
文档应该提供的是功能语义入口。
也就是说，它更应该解决这些问题：
- 这个功能到底是什么
- 它的理想路径是什么
- 哪几个环节最关键
- 哪些地方值得特别理解
- 需要的时候，怎么快速回到代码
一旦接受这个前提，重节点蓝图的问题就更明显了。
因为它想做的，已经不只是“入口”了，
而是在某种程度上想把功能理解本身重新建成一套完整结构。
这在小范围内可能成立。
但一旦规模上来，就会开始吞噬认知带宽。
后来我慢慢意识到，自己真正想要的，不是一个“更完整的结构系统”，
而是一个“刚刚好的认知焦距”。
太粗，只停在项目级 spec，不够用。
太细，细到节点蓝图级，也会太重。
真正合适的，是停在功能级。
所以 CoAI 后来才慢慢收敛成现在这条路：
- 用功能文档表达理想路径
- 用双链作为语义入口
- 用 mapper 和 anchor 把语义挂回代码
- 后续具体实现细节，继续交给代码和 IDE 原生跳转
现在回头看，我并不觉得节点蓝图这条路“错了”。
它更像是一个必要的试错。
正因为我认真往那边走过，
我才更清楚地看到：
很多时候，真正稀缺的不是更完整的结构，
而是更轻、更稳、更容易长期使用的认知入口。
如果今天要把这篇压成一句话，我会这样写：
当结构细节开始吞噬理解时，更完整的表达就不再是帮助，而会变成负担。
这也是我为什么最后放弃了重节点蓝图，
转向功能文档 + 双链 + 代码锚点这条路。
这是 CoAI 开发日志第 3 篇。
记录我在 AI coding 时代，如何理解人与 AI 应该怎样协同工作。
