大模型自动化模式为何“越用越难用”

一、现象：自动化跑得越多，返工越重

不少开发者在使用新一代大模型时都有类似体感：模型能力指标在涨，但真正拿它跑一个完整任务时，结果反而不如预期。一个典型场景是——把需求描述清楚后交给模型“自动跑”，让它在目标模式下自主规划、自主执行，结果一轮下来大面积返工，最后不得不切回逐条人工修正的方式，一条一条地改。

这里需要做一个重要的归因区分：这种“不好用”的体感，未必是模型能力退化，更可能是任务模式与任务复杂度不匹配造成的。目标模式（让模型自主设定子目标、自主循环执行直到收敛）在设计上是一种高杠杆能力，它把“规划权”和“执行权”同时交给了模型。当任务边界清晰、验收标准可机器判定时，它能显著压缩人力；但当任务本身含糊、上下文庞大、失败代价高时，自主循环会把早期的小偏差不断放大，最终产出“看上去完整、实际不可用”的结果。

原文作者的自我反省很有价值：一是对模型期待过高，二是主动开启了目标模式，因此很难把结果不满意直接归因于模型本身。这正是一个值得展开的技术问题——何时该用自动化模式，以及如何把自动化模式用好。

二、根因分析：为什么自动模式会“跑偏”

2.1 任务拆解粒度失控

自动模式下，模型会自行决定任务分解的层级。粒度太粗，单步子任务覆盖过多文件或逻辑，一旦某一步理解偏差，后续全部建立在错误前提上；粒度太细，又会产生大量互相依赖的中间产物，任何一环的上下文丢失都会导致整体漂移。

关键在于：人类工程师拆任务时依赖的是对代码库结构的隐性认知，比如哪些模块是强耦合的、哪些改动会触发连锁反应、哪些地方有历史包袱。这些信息如果没有显式地写进上下文，模型只能靠猜测，而猜测在大任务上几乎必然出错。

2.2 长上下文中的约束衰减

自动模式往往意味着多轮循环、多次工具调用，上下文会不断累积。随着轮次增加，早期写下的关键约束（命名规范、兼容性要求、不可改动的接口、性能上限）在注意力分配上会被稀释，模型逐渐“忘记”最初设定的边界，产出越来越自由但越来越偏离需求的内容。

这不是某个模型的独有问题，而是当前长上下文处理的共性挑战。缓解手段是把约束从“一次性写在开头”改为“每个阶段重复注入”，或者把约束固化成可执行的检查规则而非自然语言描述。

2.3 验收标准不可机器判定

自动模式要收敛，前提是“完成”可被判定。如果任务是“优化这段逻辑的可读性”或“让这个模块更好维护”，标准是主观的，模型只能自我判断，而自我判断往往偏宽松——它会认为自己做完了，实际离人类期望还差很远。

可判定的标准应该是这样的：编译通过、单测全绿、静态检查零告警、接口契约不变、性能基准不退化。这些条件能被工具链直接验证，模型才有可靠的收敛信号。

2.4 失败回滚成本被低估

大任务自动执行后产生的大量改动，一旦方向错误，回滚和审查成本极高。审查一堆由模型生成、彼此关联的改动，往往比一开始就小步推进更耗时。这也是“刷掉大部分内容再重来”这种体验的来源——返工量本身抵消了自动化带来的时间收益。

三、实践路径：把自动模式用成可控的工程手段

3.1 分层编排：自动模式只负责“可验证的子问题”

推荐的策略是把任务切成三层：

• 决策层：由人确定目标、边界、验收标准，不由模型自主决定；
• 编排层：由模型在受限空间内做子任务分解，但分解结果需经过一次人工或规则校验；
• 执行层：对每个子任务启用自动循环，因为子任务边界清晰、可独立验证。

示意性的编排约束可以写成结构化配置，而不是自然语言：

task: refactor_module
constraints:
  - no_public_api_change
  - keep_error_codes_stable
  - max_files_touched: 5
verify:
  - build
  - unit_test
  - static_analysis
stop_on:
  - verify_failed_twice
  - diff_size_exceeded

这种配置的意义在于：把“模型自主”限制在可控半径内，同时给自动循环提供明确的停机条件，避免无限重试或越改越乱。

3.2 增量验证：每一步都要有可观测信号

自动模式最大的风险是“黑盒式长跑”。应强制要求每个子任务完成后产出可观测信号：改动范围、影响的调用方、测试结果、静态检查结果。任何一项异常即中断，转入人工介入。

这与持续集成中的质量门禁思路一致——不是等整个流水线跑完再判断，而是在关键节点设置检查点。把门禁前置，返工成本就从“整体重来”降为“局部修正”。

3.3 上下文治理：约束显式化、结构化

把隐性知识显式化，是提升自动模式成功率性价比最高的投入：

• 把编码规范、接口契约、目录约定写成结构化文档，随任务一起注入；
• 把“不可改动项”列成清单，在每个阶段重复提示；
• 用示例代码而非文字描述来锚定期望风格，减少理解偏差。

3.4 人机分工：细粒度修正仍是必要环节

原文提到“逐条细改”仍然有效，这恰恰说明人工审查不可省略。合理的分工是：自动模式承担机械性、可验证的批量改动；人工聚焦架构判断、边界取舍和最终验收。把两者对立起来是误区，把它们编排成流水线才是正解。

四、关于“目标模式何时值得开启”的判断框架

回到原文的核心疑问：目标模式是不是要等到更强的模型才值得用？更准确的判断标准不是模型代际，而是任务属性。可以用四个问题做快速筛查：

1. 任务是否有明确、可机器判定的完成标准？
2. 改动范围是否可预估、可限制？
3. 失败后的回滚成本是否可接受？
4. 是否有配套的验证工具链（构建、测试、静态检查）？

四项全部为“是”，自动模式收益明显；有两项以上为“否”，建议降级为半自动或逐条交互模式。随着模型能力提升，这个边界会向右移动，但判断框架本身不会失效——因为约束衰减、验收模糊、回滚成本这些问题，本质上来自工程系统而非模型本身。

五、小结

“新模型反而不好用”的体感，多数情况下不是能力问题，而是把高杠杆能力用在了低可验证性的任务上。自动模式的价值随任务可验证性单调上升，随任务模糊性单调下降。工程上的应对之道是三件事：把任务切到可验证的粒度、把约束写成结构化可复用的形式、把验证门禁前置到每个子任务。做到这三点，自动模式才能从“跑完一大片再返工”变成“小步快跑、持续收敛”的稳定生产力。