在 Opus 4.6 与 GPT-5.4 之后，我们需要的未必是“更会写代码”的模型
问题不在于还要不要更强，而在于强在哪里
过去两年，AI 编程领域几乎被一条叙事主导：模型越来越强，coding 越来越好，agentic workflow 越来越长，code review、bug fixing、repo-level editing 的效果越来越稳定。这个叙事没有错。强模型确实在快速吞掉软件实现中的大量机械负担：样板代码、框架胶水、测试脚手架、接口搬运、常规修补、局部重构，这些工作原本需要工程师花费稳定但低密度的注意力，现在越来越多地可以被自动化。
但当模型已经足够擅长这些事后，一个更关键的问题就出现了：我们继续追求“更强”，到底是在追求什么？
如果“更强”的含义仍然主要是更快补全、更会套主流框架、更会修常见 bug，那么这条路当然还有价值，但它的收益会越来越集中在实现层，而不是决策层。真正值得问的不是要不要更强模型，而是下一阶段的“强”，究竟应该体现在：
- 更会写代码；
- 还是更会恢复约束、暴露分歧、验证结果、控制演化。
这是两个完全不同的方向。
软件为什么会先在“默认实现”上趋同
很多人说，模型变强之后，软件会越来越同质化。这个判断有一半是对的，但需要说得更精确。
真正趋同的，首先不是软件的全部价值，而是它的默认实现、默认交互、默认架构和默认 tradeoff。
原因并不神秘。模型的工作方式决定了：当输入约束不足时，它会用统计先验填空；而模型越强，这种填空就越平滑、越稳定、越像一个“成熟团队应当写出来”的答案。于是，在缺少明确约束的情况下，越来越多的软件会在这些地方收敛：
- API 组织方式相似；
- 前端交互套路相似；
- 数据表设计相似；
- 常见功能的默认行为相似。
这并不等于所有软件都会失去差异化。真正能拉开差异的东西，很多本来就不主要住在代码表面，而住在更深的层次：
- 你服务哪类用户，优先满足谁；
- 你把什么当成功指标；
- 你容忍什么失败，不容忍什么失败；
- 你如何设计反馈闭环；
所以更准确的说法不是“软件会越来越同质化”，而是：
在约束表达不足时，软件的默认实现会越来越同质化；而真正决定差异化的那些取舍，如果没有被显式表达出来，也会被模型的强先验悄悄抹平。
前者往往是工业化红利，后者才是风险。
模型应该吞掉什么，不应该吞掉什么
这里有一个比“模型更强”更重要的区分：模型到底在吞掉什么信息。
我更愿意把工程里的信息分成两类。
第一类，是实现性信息。
它包括样板、胶水、框架约定、重复性的映射关系、机械性的测试补齐、固定套路下的迁移与修补。这类信息很重要，但通常不构成产品或系统的独特性。它消耗大量时间，却很少体现真正的业务判断。模型吞掉它，通常是好事。
第二类，是决策性信息。
它包括目标函数、约束边界、失败代价、默认值的取舍、性能与一致性的平衡、风险责任的归属、哪些边界 case 是核心而不是噪声。这类信息才真正定义一个系统“为什么是这样，而不是那样”。它不一定都写在 PRD 里，但它必须被某种形式显式化、可追溯、可讨论、可验证。
问题不在于模型会补全信息，而在于它是否开始替你补全本该由人明确决定的那部分决策性信息。
如果模型主要吞掉的是实现性信息，那么它在帮助工程系统消除偶然复杂性。这和过去几十年的软件工程主线是一致的：高级语言吞掉寄存器细节，运行时吞掉内存管理，云平台吞掉基础设施运维，框架吞掉界面和状态管理中的一部分样板。今天，编程模型吞掉更多实现层负担，也在这条线上。
但如果模型开始在约束不足时，替你决定默认策略、用户优先级、风险边界和系统取舍，那它吞掉的就不再只是实现成本，而是在用统计先验替代真实意图。这从简单的效率提升变成了决策权的转移。
下一阶段真正该押注的，不只是模型，而是软件生产系统
说到这里，一个更大的区分就必须讲清楚：下一阶段的竞争，未必是“谁的模型更会写代码”，而是“谁能把模型嵌进一个可验证、可审计、可演化的软件生产系统”。
这里至少有三层能力，不能混为一谈。
- Base model 能力：这是大家最熟悉的一层：推理、编码、定位 bug、理解仓库、长上下文保持、一致性修改。它仍然是底座，没有它，上层都站不住。
- Agent runtime 能力：这是模型真正进入工程流程时暴露出来的层：检索上下文、调用工具、维护状态、分解任务、执行计划、处理中断、管理多轮迭代。很多“agent 看起来不稳定”的问题，根本不是 base model 不够强，而是 runtime 没把信息流和执行流管好。
- Engineering system 能力：这是最容易被忽视、却最决定落地价值的一层：测试、静态分析、变更影响分析、沙盒回放、发布、回滚。没有这一层，所谓 agent 只能写出第一版代码，不能在真实组织里持续工作。
因此，下一阶段真正值得押注的方向，至少包括三件事：
- 约束恢复：从需求文档、历史提交、测试、工单、代码注释里恢复真实边界，而不是只盯着当前 prompt。
- 分歧显式化：不要静默地给出“最像标准答案”的方案，而要明确告诉用户：这里存在多个合理路径，它们分别牵涉什么成本、风险和责任。
- 验证闭环：生成不是终点，不能验证的 agent，只是写得快；能验证的 agent，才有资格进入主流程。
结论：我们需要更强模型，但不是只会更强地猜
所以，在 Opus 4.6、GPT-5.4 之后，我们仍然需要更强的编程模型。问题从来不在于“强模型是不是多余”，而在于我们到底希望这种“更强”意味着什么。
如果“更强”只是更会补全、更会 debug、更会套主流架构、更会把空白处用行业平均最佳实践填满，那么这条路当然还有价值，但它会越来越局限于实现层。它越成功，默认答案就越平滑；默认答案越平滑，真正重要却没有被显式表达的那些取舍，就越容易被一起抹平。
但如果“更强”意味着：
- 更擅长识别约束缺口；
- 更擅长暴露不能自动拍板的默认值；
- 更擅长把模糊目标转成可验证条件；
- 更擅长在真实工程系统里受控执行与持续演化；
那么这条路远远没有到头。
真正稀缺的，未必是一个更强的代码生成器，而是一个更强的约束解释器、分歧显式化器、验证协作者和演化代理。而要做到这些，它仍然需要强模型做底座，但评价标准已经不该停留在“它写代码像不像一个高手”，而应该转向：
它是否更少替你决策，是否更能逼近真实意图，是否更能在真实系统里把正确的事稳定做成。