问题不在于还要不要更强，而在于强在哪里

过去两年，AI 编程领域几乎被一条叙事主导：模型越来越强，coding 越来越好，agentic workflow 越来越长，code review、bug fixing、repo-level editing 的效果越来越稳定。这个叙事没有错。强模型确实在快速吞掉软件实现中的大量机械负担：样板代码、框架胶水、测试脚手架、接口搬运、常规修补、局部重构，这些工作原本需要工程师花费稳定但低密度的注意力，现在越来越多地可以被自动化。

但当模型已经足够擅长这些事后，一个更关键的问题就出现了：我们继续追求“更强”，到底是在追求什么？

如果“更强”的含义仍然主要是更快补全、更会套主流框架、更会修常见 bug，那么这条路当然还有价值，但它的收益会越来越集中在实现层，而不是决策层。真正值得问的不是要不要更强模型，而是下一阶段的“强”，究竟应该体现在：

• 更会写代码；
• 还是更会恢复约束、暴露分歧、验证结果、控制演化。

这是两个完全不同的方向。

软件为什么会先在“默认实现”上趋同

很多人说，模型变强之后，软件会越来越同质化。这个判断有一半是对的，但需要说得更精确。

真正趋同的，首先不是软件的全部价值，而是它的默认实现、默认交互、默认架构和默认 tradeoff。

原因并不神秘。模型的工作方式决定了：当输入约束不足时，它会用统计先验填空；而模型越强，这种填空就越平滑、越稳定、越像一个“成熟团队应当写出来”的答案。于是，在缺少明确约束的情况下，越来越多的软件会在这些地方收敛：

• API 组织方式相似；
• 前端交互套路相似；
• 数据表设计相似；
• 常见功能的默认行为相似。

这并不等于所有软件都会失去差异化。真正能拉开差异的东西，很多本来就不主要住在代码表面，而住在更深的层次：

• 你服务哪类用户，优先满足谁；
• 你把什么当成功指标；
• 你容忍什么失败，不容忍什么失败；
• 你如何设计反馈闭环；

所以更准确的说法不是“软件会越来越同质化”，而是：

在约束表达不足时，软件的默认实现会越来越同质化；而真正决定差异化的那些取舍，如果没有被显式表达出来，也会被模型的强先验悄悄抹平。

前者往往是工业化红利，后者才是风险。

模型应该吞掉什么，不应该吞掉什么

这里有一个比“模型更强”更重要的区分：模型到底在吞掉什么信息。

我更愿意把工程里的信息分成两类。

第一类，是实现性信息。
它包括样板、胶水、框架约定、重复性的映射关系、机械性的测试补齐、固定套路下的迁移与修补。这类信息很重要，但通常不构成产品或系统的独特性。它消耗大量时间，却很少体现真正的业务判断。模型吞掉它，通常是好事。

第二类，是决策性信息。
它包括目标函数、约束边界、失败代价、默认值的取舍、性能与一致性的平衡、风险责任的归属、哪些边界 case 是核心而不是噪声。这类信息才真正定义一个系统“为什么是这样，而不是那样”。它不一定都写在 PRD 里，但它必须被某种形式显式化、可追溯、可讨论、可验证。

问题不在于模型会补全信息，而在于它是否开始替你补全本该由人明确决定的那部分决策性信息。

如果模型主要吞掉的是实现性信息，那么它在帮助工程系统消除偶然复杂性。这和过去几十年的软件工程主线是一致的：高级语言吞掉寄存器细节，运行时吞掉内存管理，云平台吞掉基础设施运维，框架吞掉界面和状态管理中的一部分样板。今天，编程模型吞掉更多实现层负担，也在这条线上。

但如果模型开始在约束不足时，替你决定默认策略、用户优先级、风险边界和系统取舍，那它吞掉的就不再只是实现成本，而是在用统计先验替代真实意图。这从简单的效率提升变成了决策权的转移。

下一阶段真正该押注的，不只是模型，而是软件生产系统

说到这里，一个更大的区分就必须讲清楚：下一阶段的竞争，未必是“谁的模型更会写代码”，而是“谁能把模型嵌进一个可验证、可审计、可演化的软件生产系统”。

这里至少有三层能力，不能混为一谈。

1. Base model 能力：这是大家最熟悉的一层：推理、编码、定位 bug、理解仓库、长上下文保持、一致性修改。它仍然是底座，没有它，上层都站不住。
2. Agent runtime 能力：这是模型真正进入工程流程时暴露出来的层：检索上下文、调用工具、维护状态、分解任务、执行计划、处理中断、管理多轮迭代。很多“agent 看起来不稳定”的问题，根本不是 base model 不够强，而是 runtime 没把信息流和执行流管好。
3. Engineering system 能力：这是最容易被忽视、却最决定落地价值的一层：测试、静态分析、变更影响分析、沙盒回放、发布、回滚。没有这一层，所谓 agent 只能写出第一版代码，不能在真实组织里持续工作。

因此，下一阶段真正值得押注的方向，至少包括三件事：