AI 修好了一个 bug，然后呢？

设想你让一个 AI 助手写函数，计算一组数的平均值，并要求空列表返回 None。它交出这样的代码：

def mean(xs):
    return sum(xs) / len(xs)

输入 [2, 4, 6]，结果是 4。输入空列表 []，程序却会除以零。你指出它漏掉了空输入要求。助手加上判断，修好了这个 bug。

这次修改解决了眼前的问题。接着你关闭对话，让它写另一个处理列表的函数：它会不会主动检查空输入？

答案取决于这次修复留下了什么。我们用这个 bug 比较三种助手：只修改当前答案、保存一条经验，以及修改自己产生补丁的程序。三种设定都保持基础模型权重不变。它们是独立的教学例子，不对应论文实测，也不代表系统必经的升级阶段。

关闭对话后，修复留在哪里？

第一个助手只在对话中修改了函数。修好的代码交给了你；助手没有更新模型权重，也没有把这次经验写进下一项任务能读取的记录。

如果下一次调用仍使用原来的模型和空上下文，它就读不到这次修复。它仍可能凭原有能力写对代码，但这次对话没有给它增加可复用的信息。

这样看，“修好了代码”和“从修复中学到了东西”就有了可以检查的区别。前者看这份代码是否满足要求，后者还要看下一次任务能否用上这次经验。仅比较初稿和终稿，只回答了第一个问题。

给它留一条能用上的经验

第二个助手在修复之后，额外保存了一条记录：

计算列表的统计量之前，检查输入是否为空；空输入该返回什么，要依据当前任务的要求。

现在让它写一个求方差的函数。如果系统会在相关任务开始时检索这条记录，助手就多了一条检查输入的线索。模型权重可以完全不变，经验通过外部记忆进入下一次调用。

这条记录特意没有写成“空列表一律返回 None”。那是平均值任务给定的要求。另一个接口可能要求抛出异常，照搬旧答案也会出错。可复用的部分是检查方法，具体处理仍要看新任务。

记录能被保存，还只是第一步。它会不会被检索到？被读到以后，助手会不会遵守？遇到不适用的场景，是否仍然套用？这些都会影响后续表现。

我们可以设计一个简单对照：给同一个基础助手两份副本，一份读取这条记忆，一份不读取；在相同预算下，让它们完成一组新任务。除了检查空输入的任务，也加入这条经验派不上用场的任务，观察它是否引入额外错误。

这是检验记忆作用的实验建议，本文没有运行这个实验。它至少明确了应该比较什么：保留这条经验，对下一批任务有什么影响？如果评测时先把两份副本的记忆都清空，就无法测量这条经验的作用。

让产生补丁的程序也发生变化

第三个助手可以修改更多东西。它有一个负责修补代码的程序，我们叫它“改进器”。改进器决定给模型什么信息、先尝试哪种修改，以及怎样使用有限的尝试次数。

设想原来的改进器 A 很简单：看到报错，就请模型提出一个补丁。这次，A 把自己的源码也作为待修改对象，生成了一个候选改进器 B。两者的规则可能是：

回到平均值函数，B 会尝试把“输入为空”纳入检查，而不必等到用户报告这个错误。这里描述的是候选规则，尚未证明它更有效。

还要发生一次实际交接：如果 B 通过接受检查，下一轮就由 B 来产生修改，而 B 自身的源码仍在可修改范围内。若 B 只是被写进文件、之后仍由 A 工作，后续修改过程就没有按这个设定改变。

这便指出了递归自我改进的一个关键位置：负责产生修改的程序，也进入了系统可以修改的范围。Generalized Agent Iteration（GAI）用这一点区分固定改进过程与递归自我改进。我们前面的 A、B 是帮助理解这一区分的教学例子，不是 GAI 报告的实验。

修改权限、实际交接和修改后的效果是三件事。B 多做边界检查，可能找到 A 漏掉的问题，也可能花掉太多时间，挤占提出补丁的机会。

要检验它是否更会改进程序，可以冻结 A、B 两个版本，准备一组没有用于开发 B 的新编程任务。对每项任务，让 A、B 从相同的初始代码出发，在相同总预算下产生补丁，再用事先留出、不向它们公开的测试评价最终程序。这个对照也是本文的建议。

下一个任务开始时，系统多了什么？

回看同一个空列表 bug，三个助手留下的东西已经可以具体指出来：

这三个位置帮助我们解释“改进”发生在哪里。它们不会自动排出能力高低：一条适用的记忆可能很有帮助，一个可自改的程序也可能越改越差。

下一次看到 AI 修好了自己的错误，可以接着看它开始新任务的那一刻：它读入了什么新状态？调用的是哪一版改进程序？这两处记录，会让“它学到了什么”成为一个能继续验证的问题。

延伸阅读：GAI 原文，重点看修改器是否可修改的区分。本文只用它说明系统结构，不据此宣称性能提升。案例和对照设计均为教学示意。

本文的研究依据沿用文献纳入截至 2026 年 9 月 17 日的书稿。本文没有新增实验结果。