AI现在还是喜欢单兵作战

现在的 AI 更擅长在一个连续上下文里推进任务。

它可以读 spec，拆步骤，改代码，跑检查，再根据错误继续修。这个过程像一个人把项目从头到尾握在手里。即便背后有 Agent，最终也常常需要一个主执行者维护整体判断。

从 spec 开始开发，走的就是这条路。先把目标、边界、文件关系、验收方式和风险写清楚，再让 AI 沿着这条主线推进。它不是最理想的工程分工，但更贴合现在模型的能力形态。

模块独立开发的问题，不在于模块本身做不好。很多时候，每个模块单独看都可以。问题出在合作面。

合作面要求系统记住更多东西：接口约定有没有变，调用方有没有同步，状态流是不是一致，错误处理是不是同一种口径，命名和抽象是不是还在同一层。AI 很容易在自己的局部上下文里把这些事处理得合理，却没有守住全局一致性。

并发修改会把这个问题放大。

两个 Agent 同时改相邻文件，短期看速度更快。合并时才会发现，A 为了自己的路径改了数据结构，B 为了另一个路径补了兼容逻辑。两边都能解释自己的选择，但放在一起就变成了隐性冲突。

这种冲突很难修。因为错误不一定表现为编译失败，也不一定集中在一个文件。它可能藏在交互路径、状态更新、边界条件和用户看不见的假设里。

到了这个阶段，修复成本经常高过重做。

原因很简单：重做时还有一条清楚主线。修复并发产生的问题时，要先还原每个 Agent 当时的判断，再判断哪些要保留、哪些要回退、哪些要重新统一。这个过程本身就会消耗上下文。

拆模块可以做，但执行前要先收口。各自分析出来的接口、风险、实现顺序和验收条件，需要先汇成一份完整内容。

可以让 AI 分析模块、写局部方案、列风险、准备实现计划。但进入实际修改前，需要把这些输入汇成一份统一 spec，再由一条执行线统筹落地。

这会牺牲一些并发速度，但能减少后面的合并债。对现在的 AI Coding 来说，慢一点的串行，常常比看起来很快的并发更稳。