为什么感觉新一代大模型反而不好用了？

一、现象：更强的模型，更差的体感

先还原一个典型场景：开发者把一个大任务整体交给新一代大模型，开启“目标驱动”的自主执行模式，让模型自动跑完全程。模型效率很高，短时间内“刷掉”了80%以上的工作量；但逐项检查后发现，真正能直接采用的产出比例远低于预期，最后仍不得不借助另一个轻量工具逐条精修。于是产生疑问：模型明明升级了，为什么反而感觉变难用了？

这种体感在开发者群体中相当普遍，但把它简单归因于“模型退步”并不成立。真正的原因，藏在期望管理、评测方法和长程自主执行的技术特性这三个层面。

二、第一层原因：期望与用法同步升级带来的“隐形加压”

1. 期望漂移

模型的每一次升级，都会同步抬高用户的评价基线。旧模型时代，大家默认“模型只能给草稿”，于是习惯把任务拆小、人工把关，产出有一点可用内容就算合格；换成新一代模型后，宣传中的能力上限诱导用户跳过任务分解与验收设计，直接下达大颗粒度的目标。任务的绝对难度被人为调高了，达标率自然随之下降——不是模型变弱了，而是考卷变难了。

2. 变量混杂：单次体验不构成证据

在上述场景里，至少有三个变量被同时改变：

• 模型版本：新旧两代模型的能力边界与行为特征不同；
• 执行模式：从多轮交互式协作，切换为一次性自主执行；
• 验收预期：对结果的合格线被大幅上调。

再加上大模型的生成结果本身具有采样随机性，同一任务多次运行的质量方差不小，“跑一次不满意”是典型的样本量为1的实验，不具备统计意义。要做出严谨判断，至少需要：

1. 固定一组有代表性的任务集；
2. 把验收标准写成可检查的条目（能通过编译、能通过测试、符合命名规范等）；
3. 对新旧版本做多轮采样、隐去来源的盲评；
4. 用平均达标率而非单次印象下结论。

原文作者自己也承认“不能作为确切证据去指责”，这个自我修正是对的——真正该复盘的不是模型行不行，而是实验设计本身有没有控制变量。

三、第二层原因：长程自主执行的技术难点

“让模型自动跑完一个大任务”这种模式，在工程上有几个天然的不利因素。

1. 误差累积

假设模型单步操作的正确率高达99%，在一个需要100个连续步骤的任务里，全程不出错的概率只有约37%（0.99的100次方）。自主执行模式恰恰取消了人在中间环节的纠错机会，小概率的单步失误会在链式传递中指数级放大。交互式协作之所以体感更稳，本质上是把一条长链拆成了若干短链，每一段都有人工兜底。

2. 上下文漂移

长上下文窗口不等于长上下文的稳定利用。任务跨度越长、中间产物越多，任务早期明确下来的约束——编码规范、命名约定、接口契约、目录结构——在后续生成中被“稀释”的概率就越高。典型症状是：前半部分产出符合约定，后半部分开始自由发挥，整体一致性肉眼可见地下降。

3. 目标定义不完备

“把这一批代码迁移到新框架并顺便优化”这类目标，其真实验收标准包含大量隐性知识：兼容性红线、性能底线、团队的既有习惯。自主模式下，模型只能对显式写出的目标负责，而真实任务的合格线是隐式的。这本质上是需求工程问题，却常常被误当成模型能力问题。

4. 缺乏中间验收

全自动模式的价值是“无人干预”，代价是“错误发现得太晚”。批量执行完再回头审查，返工往往意味着整段推倒重来；而边做边审虽然节奏慢，却能把错误锁定在最小范围内。

四、“刷掉80%工作量”为何不等于80%价值

有两个容易被忽视的机制：

• 关键路径偏斜：被机器快速完成的80%，往往是模式化、低风险的部分；剩下的20%——架构决策、边界条件、异常处理、安全考量——恰恰是信息密度和返工成本最高的部分。验收结果由短板决定，木桶效应让“完成度80%”的体感价值远低于80%。
• 面与点的分工错位：批量自主执行擅长“铺面”，即快速覆盖所有文件、所有模块；逐条精修解决的是“抠点”，即把每个关键点打磨到合格。最后仍然需要逐条细改，并不是流程失败，而是回到了正确的人机分工上：机器负责面的覆盖，人或更细粒度的辅助工具负责点的质量。

五、更稳妥的实践：把自主执行当成需要工程治理的能力

与其纠结“这一代模型能不能开自主模式”，不如先把护栏建好。护栏越完备，同一代模型可安全自动化的范围就越大。

1. 任务分解与验收标准前置

# 反例：一次性全自动执行
result = agent.run(big_task, mode="autonomous")
# 正例：分解 + 检查点 + 分批推进
subtasks = decompose(big_task, acceptance=CHECKLIST)   # 验收条目前置
for batch in chunk(subtasks, size=10):
    draft = agent.run(batch)                            # 机器铺面
    report = auto_check(draft, CHECKLIST)               # 规则化校验兜底
    if report.needs_review:
        draft = refine_one_by_one(draft)                # 逐条精修抠点
    merge(draft)

2. 分级放权

按“风险 × 可验证性”决定自动化程度：

• 低风险、高可验证：格式转换、批量重命名、样板代码生成等，规则明确、结果可自动校验，适合全自动执行；
• 中风险、中可验证：常规业务逻辑实现、文档批量改写等，依赖测试与抽样审查兜底，适合“半自动 + 检查点”；
• 高风险、低可验证：架构设计、安全相关改动、核心数据链路等，失败代价大且难以自动判定，应保持人在环路。

3. 用平台化能力沉淀评测与回溯

要把“体感”升级为“证据”，离不开基础工程能力：用日志服务完整记录每次任务的输入、输出与中间状态，便于回溯失败环节；用监控告警对达标率、返工率等指标做趋势观察，一旦质量回退能及时发现；用对象存储保留基线产物，作为新旧版本对比的锚点。百度智能云的日志服务、监控告警、对象存储等通用产品能力，可以比较自然地承载这类评测基建，帮助团队把大模型的引入纳入可度量、可回归的工程轨道。

4. 抽样审查代替全量人审

分批推进时，每批先做规则化自动校验（编译、测试、静态检查），再按固定比例抽样人审；抽样不达标，整批打回。这样能在人工投入和产出质量之间取得可接受的平衡。

六、自主模式该什么时候开：一个务实的判断框架

“等后面几代模型再开目标模式”这个直觉，可以转化为更可操作的判断标准。是否适合开启自主执行，取决于三个条件能否同时成立：

1. 验收标准可形式化：合格与否能交给编译器、测试套件或规则引擎自动判定；
2. 单步错误可被过程性工具捕获：失败早暴露、早修复，而不是攒到最后一次性爆发；
3. 返工成本可承受：即使整批产出报废，损失也在预算之内。

三者齐备，当下的模型就能稳妥地自动化相当多的工作；三者缺一，就应降级为“辅助模式”——模型起草、人逐条把关。换句话说，能不能开自主模式，一半取决于模型代际，另一半取决于工程护栏的完备程度。等待模型成熟固然合理，但先把护栏建好，往往能让现有能力提前兑现。

结语

“新一代大模型反而不好用”的体感，更多来自能力预期、使用姿势与评测方法同时变化造成的错位：模型能力是渐进提升的，而使用模式从“交互式”跳到“自主式”是阶跃的，中间缺失的那一块，正是任务分解、验收前置、检查点常设、分级放权这些工程方法。把这四件事做扎实，开发者既能守住产出质量，也能真正吃到模型升级带来的效率红利——而不是在一次次不满意的自动化尝试中，把体感问题误诊为能力问题。