All articlesEN

· Elliot Hu

2027 年，大模型依旧没有解决编程

2027 年，大模型依旧没有解决编程 cover

写于 2026 年 10 月。开篇的 2027 年是一个假设场景。

把时间拨到 2027 年。模型又强了一大截，拿到需求后，读仓库、改代码、补测试、提交变更，连上线也能一并处理。演示视频里，程序员离开工位喝了杯奶茶，回来时功能已经做好了。

同样的模型放进一个项目，却在发布前被 QA 叫停了。这次要调整客户套餐计费，代码照着工单实现，测试也都通过了。只是上周的会议确认过，老客户要保留原有权益。这个决定留在会议和几条消息里，没进工单，也没进测试。倘若没人想起它，那批老客户就会跟着一起迁移。

说“大模型依旧没有解决编程”，到这里似乎也没什么不对。工程师还得找出遗漏，判断能否发布，出了问题也得有人负责。我想接着问的是：这位工程师刚才究竟做了什么？他用到了模型尚不具备的判断能力，还是补上了一条模型从未拿到的事实？

这两种情况需要不同的改进。笼统地说“人类理解项目”，很容易让讨论停在这里：代码生成进步了，理解、验证和维护还是离不开人。我做 Context Infra，需要把这些工作拆开，看看哪些还可以继续交给系统。

01｜代码便宜了，剩下的账还在

在约定的项目范围和维护周期内，软件交付的总成本可以粗略写成：

Ctotal=C明确目标+C实现+C验证+C运行维护+E[L失败损失]C_{\text{total}} = C_{\text{明确目标}} + C_{\text{实现}} + C_{\text{验证}} + C_{\text{运行维护}} + \mathbb{E}[L_{\text{失败损失}}]

AI 加快代码生成，首先压低的是实现成本。目标有没有理解对，验收有没有漏掉约束，上线后会不会破坏旧功能，这些事仍要花时间处理，失败也仍会造成损失。开头那次迁移，即使代码瞬间写完了，核对老客户权益的工作也不会跟着消失。

我认同对 AI 编程的一部分批评：补丁通过测试，离项目可以持续维护还差着不少工作，这些成本不能因为代码生成快就不算了。评测也在尝试单独衡量这部分能力。SWE-EVO 从七个成熟 Python 项目中收集了 48 个软件演进任务，要求 Agent 根据较高层的需求完成跨文件、多步骤修改。论文 2026 年 5 月的版本报告，GPT-5.4 与 OpenHands 的组合在该实验设置下完成了 25%。这个数字不能拿来预测下一代模型，但局部修复与长期演进确实需要分别评估。

我不太接受的是另一种推断：这些成本既然还在，就总有一部分工作是技术动不了的。一个工程师花了半天寻找最新需求，核对两份文档，再回忆某次会议的决定，我们可以把这半天叫作“项目理解”。但其中既有判断和取舍，也有查找和版本核对。不把这些动作拆开，就无从讨论下一步还能省掉什么。

责任可以继续由人承担，履行责任需要的证据、时间和操作方式却可以改变。今天必须有人想起那次会议，不足以证明以后每次发布都得靠一个人记住所有约定。

要判断这些成本还能降多少，得看系统怎样发现和纠正错误。

02｜把模型放回工作过程里

如果把编程简化成“需求进去，代码出来”，评价模型时就容易只看它一次能写对多少。实际开发还要反复尝试：先运行，看到异常，查日志，改实现，再跑一次。一次结果不对，未必就意味着任务做不成；反过来，一次运行成功，也未必足够交付。

这个过程里有观察、行动和反馈，可以借用控制论的语言来描述：

st+1=f(st,at,wt),ot=h(st)+vts_{t+1}=f(s_t,a_t,w_t), \qquad o_t=h(s_t)+v_t

sts_t 是真实工作状态，ata_t 是系统采取的行动，wtw_t 是外部变化。系统得到的观察是 oto_t，其中还可能混有噪声或误差 vtv_t。在软件项目里，真实状态包括代码、部署版本和数据，也包括当前需求、客户约束，以及正在进行的其他变更。模型拿到的则是文件、工具输出和事件记录，它得凭这些材料形成状态估计 s^t\hat{s}_t，再围绕目标 gtg_t 选择行动：

at=πθ(s^t,gt)a_t=\pi_\theta(\hat{s}_t,g_t)

开头的模型如果把老客户一起迁走，就可能错在这份状态估计上。它读到的工单没有反映最新决定；即使完全照工单办，也会偏离真实目标。当然，信息齐全以后仍然选错行动，是另一种可能。评价系统时，这两处都得查。

控制论中的可观测性，讨论的是能否通过输入和输出的测量恢复内部状态；观测器利用测量持续更新状态估计，控制器再据此行动。企业项目不能直接套进一个线性控制模型，不过，“知道当前发生了什么”和“据此决定怎么做”的区分很有用。读到了哪些事实、哪些已经过期、行动以后发生了什么，都影响最终结果。

考虑到后续检验，仅凭模型具有概率性，还不能断定它无法产出可靠软件。系统可以生成带随机性的候选方案，再运行、检验、筛选。AlphaEvolve 把模型生成程序、自动评估和演化搜索结合起来，依据可测量的结果选择后续改进方向。前提是任务能够提供有辨别力的自动评价。

套餐迁移就未必满足这个条件。测试没覆盖老客户约定，多跑一遍也不会发现这项遗漏；修复已有问题时，还可能引入回归，或者把一次偶然成功记成经验。每轮纠错都可能带来新偏差，需要把两者一起考虑。

03｜软件闭环收敛律

令 EnE_n 表示系统完成第 nn 轮“执行、验证、修正”后，相对真实目标的预期风险加权偏差。这里算的是实际偏差，测试失败数量和模型自报的置信度都不能直接替代它。像老客户约定这样的遗漏，即使测试全部通过，也不能算作没有偏差。

假设每轮平均消除现存偏差的比例为 qq，同时平均引入新偏差 bb。修复造成的回归、错误的状态更新，以及外部变化，都可能计入 bb。于是有：

En+1=(1−q)En+b0<q<1,b≥0\boxed{ E_{n+1}=(1-q)E_n+b } \qquad 0<q<1,\quad b\geq0

下一轮的预期偏差，等于这一轮尚未消除的部分加上新增偏差。这不保证某次运行一定变好，也要求在所研究的任务范围内，qq 和 bb 可以近似看作常数。我把它导出的条件性关系叫作“软件闭环收敛律”：

当有效纠错率与新增偏差近似稳定时，超出当前稳态的预期偏差按几何级数衰减；稳态水平取决于新增偏差与有效纠错率的比值。

名字里虽然有“定律”，它仍然只是一个一阶递推模型。摩尔定律有长期数据作为经验依据；这里能证明的是假设成立时的数学结论，项目是否满足假设，得另行测量。

有效纠错率还可以拆成：

q=d pq=d\,p

dd 是偏差被有效发现的比例，pp 是发现之后的条件修复成功率。两者采用一致的风险权重，这个条件分解不要求发现与修复相互独立。

拿套餐迁移来说，系统先得知道老客户权益受到了影响，随后才谈得上修正实现。只提高修复能力，解决不了始终没被发现的问题；找出了一堆问题却修不好，也交付不了。模型、上下文、测试和工具都可能影响 dd 与 pp，不能简单地把“发现”分给基础设施，把“修复”分给模型。

先求它会停在哪里

假如系统达到稳态 E∞E_\infty，下一轮的期望偏差就不再变化：

E∞=(1−q)E∞+bE_\infty=(1-q)E_\infty+b

移项可得：

E∞=bq\boxed{ E_\infty=\frac{b}{q} }

每轮消除的旧偏差与引入的新偏差相等时，预期偏差就会维持在这个水平。从递推式两边减去稳态，可以看出接近它的过程：

En+1−E∞=(1−q)(En−E∞)E_{n+1}-E_\infty = (1-q)(E_n-E_\infty)

连续展开，得到：

En=bq+(E0−bq)(1−q)n\boxed{ E_n= \frac{b}{q} + \left(E_0-\frac{b}{q}\right)(1-q)^n }

只要前面的假设成立，系统就会接近 b/qb/q。初始偏差高于稳态时，多跑几轮会逐渐降低预期偏差，只是越往后，下降的幅度越小。

再看需要多久

令 Δn=En−E∞\Delta_n=E_n-E_\infty。超出稳态的这部分偏差减半，所需的等效轮数为：

N1/2=ln⁡2−ln⁡(1−q)\boxed{ N_{1/2}=\frac{\ln 2}{-\ln(1-q)} }

实际执行要取足够的整数轮数。若每轮耗时约为 τ\tau，对应的时间半衰期就是 τN1/2\tau N_{1/2}。这样便能同时看纠错效果与耗时：系统要花多久，才能把超出当前稳态的偏差减少一半？

这个指标比单看 Agent 每分钟调用多少次工具更有意义。跳过检查固然能让一轮更快结束，却可能降低 qq、抬高 bb。循环转得快了，任务未必更早完成。

那条水平线也会动

b/qb/q 只是当前参数对应的稳态。提高有效纠错率，或者减少每轮新增偏差，稳态就会下降。

软件闭环收敛示意

图 1 为数学示意，非实测。初始偏差均为 100。A 的稳态为 20；提高纠错率后，B 的稳态降到 10；进一步减少新增偏差，C 的稳态降到 2.5。验收阈值设为 8，C 在第 6 轮达到要求，A、B 在这些固定参数下无法达到。

参数不变，继续运行只能接近既有稳态；改进观察、验证、修复或执行机制，则可能改变参数。只要 b/qb/q 还能降低，剩余偏差就还有下降空间，不能根据当前结果断定存在永久下限。

这里还得留意等式与不等式的区别。如果实际能够建立的只有：

En+1≤(1−q)En+bE_{n+1}\leq(1-q)E_n+b

那么推导得到的是偏差的上界，不能把它当成不可突破的下界。上界、稳态和永久下限，说的是三件不同的事。

不过，即使偏差确实降下来了，我们也还没证明交付更便宜。每多运行和验证一轮，都有开销。

04｜多跑一轮，要不要钱？

设项目的验收阈值为 ϵ\epsilon，初始偏差 E0>ϵE_0>\epsilon。在前面的等式模型下，要在有限轮次内达标，必须满足：

bq<ϵ\boxed{ \frac{b}{q}<\epsilon }

稳态若高于验收标准，在这组固定参数下再试一百次也达不到要求。此时需要改变工作方式，或者请人介入。满足这个条件时，达标所需的最少轮数为：

nmin⁡=⌈ln⁡ ⁣[(ϵ−E∞)/(E0−E∞)]ln⁡(1−q)⌉n_{\min} = \left\lceil \frac{ \ln\!\left[(\epsilon-E_\infty)/(E_0-E_\infty)\right] }{ \ln(1-q) } \right\rceil

所以，改进闭环可能带来两种收益：已经能做的任务，用更少轮次完成；原来始终达不到标准的任务，开始具备自动交付的条件。能否省钱，还要把获得这些改进的费用加回来。

设 FF 包括初始实现、环境准备和分摊后的基础设施成本，cc 是每轮执行与验证的成本，再用局部线性近似 ℓEn\ell E_n 估算残余偏差对应的预期损失。保持验收标准不变，在所有达标的执行轮数中选总成本最低的那个：

C∗(ϵ)=min⁡n∈N0En≤ϵ(F+nc+ℓEn)\boxed{ C^*(\epsilon) = \min_{\substack{n\in\mathbb{N}_0\\E_n\leq\epsilon}} \left(F+nc+\ell E_n\right) }

多跑一轮带来的成本变化是：

C(n+1)−C(n)=c−ℓq(En−E∞)C(n+1)-C(n) = c-\ell q(E_n-E_\infty)

cc 是新增开销，后面减掉的是这一轮降低的预期损失。任务已经达标时，如果继续运行的收益小于开销，就没有经济上的理由继续跑，即使系统还有能力纠错。

相同验收标准下的交付成本

图 2 为参数化示意，非实测。两条曲线采用相同验收阈值。环境 2 更容易发现偏差、每轮新增偏差更少，同时承担更高的固定成本；在这组参数下，其最优总成本仍然更低。横轴是条件修复成功率，不代表年份或通用智能水平。

软件成本因此更适合画成一组曲线。模型能力会影响它，观察与验证条件也会影响它，而基础设施新增的部署、计算和维护成本必须一并计入。误差能继续降低，推不出成本会归零；眼下仍然有成本，也推不出一个永远不变的正下限。

这个简化模型还不足以处理不可逆操作、尾部损失和硬性安全要求，它们需要单独的约束，不能只靠平均值判断。套餐迁移还留下了一个问题：系统能否发现那条漏掉的客户约定？

05｜缺失的事实，不能靠多想几遍补出来

给开头的场景加一个限制。设想两个世界：世界 A 要求老客户保留旧权益，世界 B 要求所有客户迁移到新权益。模型能读到的代码、工单、测试，以及所有允许查询的记录，在两个世界里完全相同。决定怎么迁移的那条事实，没有进入任何可访问的信息渠道。

如果两个世界等概率出现，模型以概率 rr 选择保留旧权益，它的平均正确率就是：

P(正确)=12r+12(1−r)=12P(\text{正确}) = \frac12r+\frac12(1-r) = \frac12

无论在内部多想几遍，相同证据仍然对应两个相反的正确答案。模型没有信息区分它们。它当然可以追问、寻找新的信息源，或者暂缓执行；这些做法之所以有用，是因为它们获取了新证据，或改变了决策流程。

如果某类偏差始终无法被现有机制发现，就不能在前面的模型里假定它有正的有效纠错率。同一套测试反复运行，不会自行补上那条客户约定。模型可以越来越擅长查找、理解和运用事实，但决定答案的事实，总要有地方可以查。

开头的项目里，决定还留在会议和消息中，只是工单与测试没有跟上。项目里的人常常就在做这种补充，指出哪份文档已经过期，提醒哪个客户属于例外，解释一次变更为何迟迟不能发布。信息彻底缺失，与信息已有记录却散落在不同软件、不同时间里，需要分别处理。后一种情况下，反复把事实找回来、核对有效性，是可以尝试工程化的劳动。

找到以后，系统还得正确使用它。把这次迁移改对，只解决了眼前的问题；下一次任务能否少犯同样的错，要看这次经历留下了什么。

06｜RSI 也得回答，怎样知道自己变好了

递归自我改进，也就是 RSI，同样需要回答这个问题。一个 Agent 根据报错改代码，直到测试通过，已经在利用反馈。但任务结束以后，如果模型、工具和方法都没变，它可能只是修好了当前补丁，下次遇到类似问题还得重来。

因此，谈“改进”之前，要先看变的是当前结果、执行系统，还是产生改进的方法。前面固定 q,bq,b 的循环描述了任务内的纠错；系统如果从经验中更新策略、工具、记忆或模型，可以抽象为：

θk+1=Uk(θk,Dk)\theta_{k+1}=U_k(\theta_k,D_k)

这里的 θk\theta_k 是当前系统，DkD_k 是经验，UkU_k 是更新机制。再往前一步，如果更新机制本身也允许修改：

Uk+1=G(θk,Uk,Dk)\boxed{ U_{k+1}=G(\theta_k,U_k,D_k) }

系统就开始修改自己寻找和验证改进的方法，这才涉及 RSI 中的“递归”。已有研究尝试改进的对象也各有不同。

2025 年的 Absolute Zero 让模型生成任务，用代码执行器验证任务和答案，再取得强化学习反馈。系统由此参与构造自己的训练课程。它仍然使用预训练模型；“Zero Data”说的是该阶段对外部任务数据的依赖，既不意味着没有既有知识，也没有省掉执行和验证环境。

Darwin Gödel Machine 尝试修改 Agent 自身的程序，再通过任务评估选择版本。它探索的改进范围包括代码编辑工具、上下文管理和工作方式。不过，论文中的开放式探索流程仍有固定部分，不能据此说整个研发机制都已能够自行改写。

2026 年 3 月的 Hyperagents 允许系统修改元层面的改进过程：任务 Agent 与负责修改系统的元 Agent 被放进同一个可编辑程序。论文报告了任务表现提升，以及部分改进机制的跨任务迁移。结果仍然限于其研究设置，还不足以推出无限、通用的自我加速。

借用前面的参数来理解，这些研究在尝试让后续任务拥有更高的 qq、更低的 bb，或者更低的纠错成本。一次任务留下的东西，开始影响下一次任务怎样完成。这也让验证变得更棘手：一次错误如果只影响当前答案，损失还有边界；一旦写进记忆、工具或更新方法，它就可能反复影响后面的任务。

《On the Fragility of Self-Improving Agents》重新评估了两类基于记忆的自我改进方法，发现多次运行的结果有明显波动，自我改进循环还可能放大噪声，任务顺序也会影响效果。补充更详细的任务标准和环境反馈，能缓解部分退化，但没有消除全部问题。

所以，听到“系统会自我验证”，我还想知道它拿什么验证，谁维护标准，以及它能不能靠放宽标准提高自己的分数。生成测试、寻找反例、设计实验，都可以交给系统尝试，连这些方法本身也可以改进。但判断进步，仍然需要独立于它自我评价的证据。否则，优化能力提高以后，系统也可能更快找到评分漏洞。

套餐迁移中缺了一条验收依据，RSI 中可能记错了一次成功的原因，两者都要求反馈能分清实际改进、偶然成功和错误归因。只看到循环一直在运行，还不知道它究竟在积累什么。

07｜Context Infra 应该接走哪些工作

我做 Context Infra，关注的是系统怎样获取事实、形成对当前状态的认识。开头那次迁移，至少需要把会议决定与套餐需求关联起来，识别决定适用于哪些客户，发现工单和测试还在沿用旧口径，并在执行前暴露这个冲突。

光把所有材料放进上下文，离这一步还有距离。废弃的文档和刚确认的决定可以同时出现在窗口里，系统仍要判断当前该依据哪一个行动。同一项需求也可能在消息里讨论、在文档里修改、在工单里执行、在代码里实现。把这些记录找齐以后，还要保留它们之间的关联，区分哪些是建议，哪些已经决定，哪些真正发生了。“代码改好了”“验收通过了”“已经上线了”，不能统统记成“完成”。

我理解的 Context Infra，就是在授权和可观测范围内，持续获取软件环境中的结构与事件，将它们组织成带来源、时间、权限和有效状态的工作表示，再根据行动结果更新这份表示。

这需要接口、应用结构和事件流提供可观测证据，也需要模型参与语义整理、任务识别和状态推断。直接观察到的内容、模型推断出的结论，以及尚未确认的地方，也需要分别保留。系统看到一个人打开过文档，不能就把这件事记成他批准了里面的方案。

上下文管理本身也可以让模型参与改进。2026 年 9 月的 Context Language Models 预印本把上下文作为可编辑文件，让模型学习维护它，并研究相应的训练与推理机制。整理上下文因此成为模型能够学习的行为，不必始终依靠外部固定规则。

不过，整理已有材料与持续取得跨软件的新事实，仍是两项需要分别解决的工作。客户刚改了要求，原有决定被撤销，或某次操作其实没有成功，系统都要有渠道知道。否则，它可能把手里的旧材料整理得很好，却仍然依据过期状态行动。

有了这些事实，编程中的其他困难仍要解决。必要信息齐全后，模型仍可能误解约束、设计错误或修不好代码，这需要继续提高推理、规划和执行能力。验证与执行环境也要建设：业务约束要进入验收，运行结果要能观察，检查失败后要提供足够证据支持下一轮修改；高风险操作要有权限控制、灰度和回滚，候选方案的生成与最终验收也需要适当隔离。

完整的工作过程包括：

观察→状态估计→决策与执行→结果验证→状态和策略更新\text{观察} \rightarrow \text{状态估计} \rightarrow \text{决策与执行} \rightarrow \text{结果验证} \rightarrow \text{状态和策略更新}

如果还希望这次工作帮助下一次，保存经验时就不能只记“做过什么”。行动前有什么证据，当时依据什么判断，结果怎样验证，后来为什么修正，都可能影响经验能否复用。少了这些，系统可能完整保存一次操作，却不知道它为何成功；也可能把错误归因写成规则，以后照着反复执行。

Context Infra 能为这个过程提供事实与状态。经验是否成立，更新之后是否更好，仍要由评估确认；熟悉一个项目，也不能直接算作通用能力提高。我希望它先让人少重复解释已有事实，少花时间恢复工作状态，少在错误前提上写完代码以后再返工。

08｜最后还是要做实验

这些收益需要实验验证，递推模型也可能被实验推翻。首先要检查，在研究范围内，qq 和 bb 能否近似稳定。剩余错误越来越难发现，修复之间存在强耦合，或者目标不断变化，都可能让指数曲线失去解释力。那就该换模型，不能为了保住“定律”强行拟合。

验证 Context Infra 的价值时，应固定模型、任务范围和验收标准，比较人工补充背景、Agent 自主检索、普通文档索引，以及持续状态系统。除了任务完成率，还要记录人工补充信息的次数、遗漏约束被发现的时间、回归和返工的数量，以及最终交付风险的变化。采集、计算、部署和维护费用，则要完整计入总成本。

实验还要多次运行，打乱任务顺序，保留未参与改进的评估任务。自我改进研究提醒我们，单次运行与固定任务顺序可能掩盖重要的不稳定性。

那次套餐迁移就可以作为一个具体起点：系统能否在执行前找到保留旧权益的决定，确认它仍然有效，并将它纳入验收？完成这次任务以后，相关状态能否被下一次任务正确使用？

我做 Context Infra，最终要回答的是：在相同交付要求下，工程师花在解释背景、核对状态和处理返工上的时间减少了多少？把系统自己的费用也算进去以后，总成本又减少了多少？

参考资料