亲手搭骨架还是全权交给代理：两种AI辅助编程范式的深度对比

一、对比背景：当“代码生成”不再是瓶颈

AI编程代理的能力在过去一年里快速跃升。需求描述交给代理，代码由它生成，测试和审查还可以交给另一个代理——软件似乎从来没有这么容易做出来过。但另一种情况也越来越常见：项目启动得很快，做了几轮后却很难继续。代理悄悄换掉原有部署脚本，同一个功能在代码库里被实现了五遍；一旦需要大幅调整架构，它往往选择继续打补丁。开发者拥有了大量能运行的代码，却未必还看得清系统究竟是怎么搭起来的。

这引出了本文要对比的两类编程范式：

• 范式A：人类主导骨架，代理执行填充——开发者亲自确定目录结构、关键文件、函数签名和模块边界，代理在既定框架内完成具体实现。
• 范式B：代理主导全流程，人类事后审查——开发者把需求整体交给代理，由其自行规划结构、生成代码、修改文件，人类主要在结果层面做验收。

需要说明的是，这两类范式并非互斥，而是一个连续光谱的两端。本文对比的是两种典型工作方式背后的工程逻辑差异，帮助读者判断在什么条件下更应偏向哪一端。原始讨论中提出的五条“反常识”原则，本质上都是范式A的具体化表达，而它们之所以“反常识”，恰恰是因为当前的主流使用习惯更偏向范式B。

二、对象定义：两种范式各自解决什么问题

范式A（人类搭骨架） 的核心假设是：系统的结构性决策——模块如何划分、依赖朝哪个方向流动、关键接口长什么样——属于工程判断范畴，不应外包给生成式代理。它解决的是“代码量快速增长但系统可理解性下降”的问题。开发者先手写骨架，等于把架构意图固化成代理必须遵守的约束，后续生成内容再多样，也不会偏离主干。

范式B（代理全流程） 的核心假设是：代理对上下文的理解能力已足够强，能够根据需求自行推导出合理结构，人类只需在输出层面把关。它解决的是“从想法到可运行原型的速度”问题，适合探索性任务和快速验证。

两者的分歧点不在于“要不要用代理”，而在于结构性决策权放在哪一侧。

三、相同点分析

在展开差异之前，先明确两类范式的共同基础：

1. 都依赖代理的代码生成能力。区别只在约束强度，而非是否使用代理。
2. 都面临代码审查压力。范式B把审查放在结果层，范式A把审查前移到骨架层，但审查动作本身不可省略。
3. 都受限于上下文窗口与需求清晰度。需求越模糊，两种范式的产出质量都越差。
4. 都需要版本控制作为安全网。差异在于隔离粒度：范式A通常在主干上受控推进，范式B更依赖工作树隔离、分支对比等机制来防止污染。

四、核心差异分析

4.1 架构控制力与结构漂移风险

范式A中，目录、关键文件和函数签名由人预先确定，代理的生成空间被约束在“实现填充”层面。结构漂移的概率显著降低，因为代理没有权限重新发明模块划分。这正是“禁止主代理直接修改代码和文件”原则的由来：执行代理在隔离环境中产出结果，人类确认其符合预期结构后再合入。

范式B中，代理在生成过程中自行决定结构。单次任务内往往合理，但多轮迭代后容易出现结构不一致——同一功能被重复实现、部署脚本被替换、补丁层层叠加。这类问题的根源不是代理能力不足，而是缺乏一个稳定的结构参照系。

4.2 代码可理解性与“看不懂就扔”的取舍

范式A天然要求开发者理解骨架，因为骨架是自己写的。代理填充的部分即使不完全看懂，也能通过接口契约定位其职责边界。

范式B则容易出现“能运行但看不懂”的代码。原始讨论中提出的处理方式是：生成的代码看不懂就扔掉重来，并把执行结果隔离在独立工作树中，一旦发现偏离预期结构就直接舍弃。这看似浪费，实则是对“不可维护代码沉没成本”的止损——一段看不懂的代码留在库里，后续每次修改都要为理解它付出代价。

4.3 任务粒度与补丁化倾向

范式A倾向于让代理一次性完成较大任务。原因在于：骨架已定，大任务的边界清晰，代理在完整上下文内一次性产出，比反复小修更不容易产生补丁式堆叠。

范式B如果按小步快跑的方式推进，每次只让代理改一点，短期看风险可控，长期看却容易演化为“哪里报错改哪里”的局部修补，架构层面的问题被不断延后。

4.4 方案探索的并行度

范式B在探索阶段有天然优势：让多个代理并行开发不同方案，再由一个比较代理汇总结果、只合并好的部分。这种“多路生成+择优合并”的模式，在需求方向尚未收敛时效率很高。

范式A同样可以并行，但并行发生在骨架约束之下——各路方案共享同一套接口契约，合并成本更低，比较维度也更聚焦。

4.5 协作深度与工程判断的培养

这是两类范式最深层的差异。范式B的即时性会改变思考习惯：遇到问题先问代理，代理回答快且可能顺着预期说，人与人之间的讨论、质疑和反馈随之减少。PR里的讨论变少，产品意识被削弱——能快速做出演示，和真正理解用户、把软件长期做好，是两回事。

范式A把结构性决策留在人这边，等于强制保留了“反复思考架构”的环节。对初级工程师而言，亲手搭骨架是理解系统如何组织的最直接训练；完全交给代理，则可能跳过这段必要的学习曲线。

4.6 对比表格

维度	范式A：人类搭骨架	范式B：代理全流程
结构决策权	人	代理
结构漂移风险	低	较高，随迭代累积
代码可理解性	骨架可读，填充部分有契约约束	依赖审查，易出现看不懂的代码
任务粒度倾向	一次性完成较大任务	易滑向小步补丁
并行探索	受骨架约束，合并成本低	自由度高，合并成本较高
协作与学习	保留人与人讨论与架构思考	即时问答替代讨论，学习环节易跳过
上手速度	前期慢，后期稳	前期快，后期维护压力大
适用阶段	中长期演进的生产系统	原型验证、方向探索

五、典型场景选择

更适合范式A的场景：

• 需要长期演进的生产系统，架构调整频繁；
• 多人协作、需要稳定接口契约的项目；
• 团队中有初级工程师、需要保留学习路径；
• 部署脚本、配置文件等“非业务但关键”的资产需要严格管控。

更适合范式B的场景：

• 需求方向尚未收敛的探索性原型；
• 一次性脚本、数据处理的临时工具；
• 多方案并行验证，需要快速比较结果；
• 团队已具备较强审查能力，能对生成结果做结构级把关。

混合策略在实践中往往更现实：探索阶段用范式B快速试错，方案收敛后切换到范式A固化骨架，再让代理在骨架内完成规模化实现。

六、选型建议

1. 看系统的预期寿命。短期工具偏向范式B，长期系统偏向范式A。
2. 看团队审查能力。若团队能对生成代码做结构级审查，范式B的风险可控；若审查主要停留在“能否运行”，范式A的约束更稳妥。
3. 看变更频率。架构需要大幅调整时，范式A的结构参照系价值最高；范式B在此类场景下往往选择继续打补丁。
4. 看人才培养诉求。若团队需要培养能独立做架构判断的工程师，应保留亲手搭骨架的环节。
5. 不要做绝对化选择。两类范式的边界可以按任务类型划分：结构性任务走范式A，填充性任务可放开给范式B。

七、迁移与使用注意事项

从范式B转向范式A时，需要注意：

• 存量代码的结构梳理成本。已有代码可能已存在重复实现和补丁堆叠，切换前需先做一轮结构清理，否则骨架会建在流沙上。
• 工作树隔离机制的建立。执行代理的产出应隔离在独立工作区，经结构比对后再合入，避免直接污染主干。
• 代理权限的收窄。禁止主代理直接修改代码和文件，改为“理解需求后启动执行代理”，权限边界要落到流程上而非口头约定。
• 审查标准的调整。从“结果能否运行”升级为“结构是否符合骨架”，审查清单需要同步更新。
• 节奏预期管理。范式A前期更慢，需要向团队说明这是为后期稳定性付费，避免中途因短期速度压力回退。

八、总结

两类范式的核心差异不在工具能力，而在结构性决策权的归属。范式B用速度换取结构控制力，适合探索与原型；范式A用前期投入换取长期可维护性，适合需要持续演进的生产系统。当代码越来越便宜，真正稀缺的是工程判断、代码审查能力和对“系统为什么这样搭”的理解——这些能力不会因代理变强而自动获得，反而更需要有人主动保留练习的环节。选型的关键，是判断当前任务属于“探索方向”还是“固化结构”，并据此决定把决策权放在哪一侧。