让 AI 自己修自己：Codex 的迭代修复闭环工作流

Sat, 16 May 2026 10:00:00 +0800

文档腐化：每个技术团队都在经历的慢性死亡

你写过技术文档吗？如果你写过，你一定经历过这个循环：

花了两周精心编写了一套 API 教程，代码示例跑得通，解释清晰，连边缘情况都考虑到了。三个月后，API 升级了 v2，你的文档里还在用 v1 的调用方式。六个月后，有人提了个 Issue：「这个示例跑不通。」你点开一看，发现依赖的库已经 breaking change 了三次。

这不是你的错。文档腐化（documentation rot）是软件工程的系统性问题。代码在演进，API 在迭代，但文档是静态的，它只存在于被写下的那个瞬间。之后每一次 SDK 升级、每一次接口废弃、每一次最佳实践的变更，都在悄悄地把文档推向「过时」的深渊。

大公司有专门的文档团队。小团队呢？靠记忆。靠用户提 Issue。靠「等有空了再说」。

OpenAI 自己也面临这个问题。他们的 Cookbook 仓库里有数百个 Jupyter Notebook，涵盖从向量数据库到函数调用的各种示例。API 从 client.chat.completions.create 进化到 client.responses.create，模型名从 gpt-4 变成了 gpt-5.5，嵌入模型从 text-embedding-ada-002 升级到了 text-embedding-3-large。每一个变更，都意味着一批 Notebook 悄悄过时。

2026 年 5 月，OpenAI Cookbook 团队发布了一套全新的方案：让 Codex 自己修自己。不是让 AI 写新文档，而是让 AI 检测旧文档的问题、针对性修复、运行验证、根据验证结果再修复，如此循环，直到文档真正可用。

这个模式被称为「迭代修复闭环」（Iterative Repair Loop），它不仅仅适用于文档维护。任何能让 AI 产出内容、又有客观验证手段的场景，都能套用这个模式。

核心架构：三步闭环

整个工作流的结构出奇地简单。三步，一个循环：

Review（审查）→ Repair（修复）→ Validate（验证）→ 回到 Review

但简单不等于简陋。这个架构的每一环都有精心设计的约束，让 AI 的行为可预测、可审计、可复现。

第一步：Review，只看不改

Review 阶段的目标很纯粹：读一遍当前内容，给出结构化的发现，但绝不修改任何文件。

为什么不让 AI 直接改？因为「先看清楚再动手」是人类工程师的直觉，对 AI 同样适用。当你让 AI 同时做「发现问题」和「修复问题」两件事时，它的注意力会分散，容易做出表面光鲜但经不起验证的修改。

文档维护 on Codexer

让 AI 自己修自己：Codex 的迭代修复闭环工作流

文档腐化：每个技术团队都在经历的慢性死亡

核心架构：三步闭环

第一步：Review，只看不改