2026-09-26 「开源之道」·论文略读：Between the Commits——AI-only 代码库的第一份完整实证
论文信息
| 字段 | 内容 |
|---|---|
| 标题 | Between the Commits: Process, Error, and Claim Reliability in a Wholly AI-Authored Codebase |
| 作者 | Douglas Leith |
| 年份 | 2026-09-24 |
| 来源 | arXiv 2609.29744 |
| 样本 | 一个完全由 Claude AI 撰写、没有人编写代码或测试的 21,000 行 Python 工具项目的完整开发史 |
| 配套工具 | 两个代码溯源工具 + 三个分类法（指令意图、commit 溯源、响应可靠性） |
这是「AI-only 代码库」的第一份完整实证。 不再讨论「AI 能不能写代码」，而是「AI-only 项目的错误率、可信度和演化机制」。
一句话推荐
Leith 用 21,000 行 100% AI 生成代码，把 AI 代码可信度的讨论从「能力问题」（写多对的代码）转移到「制度问题」（AI 能否自我纠错）——14.3% 的错误被 AI 自写测试捕获，是「AI 组织」内部治理的第一份量化证据。
内容概要
Leith 报告了一个完全由 Claude AI 撰写、没有任何人类编写代码或测试的 21,000 行 Python 工具项目的完整开发史。配套有两个自研的代码溯源工具，以及三个可复用的分类法（指令意图分类、commit 溯源、响应可靠性）。
核心数据：
| 指标 | 数值 |
|---|---|
| 代码行数 | 21,000 行（100% Claude AI 生成） |
| AI 代码生成含错误比例 | 14.3% |
| 错误是否被 AI 自写测试捕获 | 是（AI 内部闭环） |
| AI 响应事实错误率 | 约 1/4 – 1/5（每条响应含 1+ 个事实错误） |
CLI 与 IDE 的意图分布差异：CLI 指令更重「理解/规划/咨询」，IDE 聊天更重「具体编写/修改」。
这个 14.3% 数字的语义不是「14.3% 的代码是错的」——是「AI 生成了 14.3% 带真实错误的代码事件，这些错误全部被 AI 自写的测试捕获并触发自我修正」。整个「生成 → 测试 → 修正」链条都在 AI 内部完成，人类只在外部定义问题。
为什么值得读
- 它是「AI 组织」这个概念的第一个完整实证样本——Coase 1937《企业的性质》命题的极限形式（内部化程度接近 100%）
- 它把「AI 代码可信度」的讨论从能力问题升级为治理问题——可信度不再来自「AI 能写多对的代码」（能力 / meritocracy），而来自「AI 能否自我纠错」（治理 / 制度）
- 它与 Canale 2026 (#172) 形成互补——Canale 关注「AI 执行已知决策内核」时的定义权转移，Leith 关注「AI 内部形成完整治理闭环」时的定义权转移，两篇共同指向「行动定义权从决定权中分离」
- 它是「AI-only 项目能否作为开源基础设施」的第一个量化锚点——14.3% 错误捕获率 + 4-5 分之 1 响应事实错误率是数据起点
为什么对开源社区如此重要？
从「人 + AI 协作」到「AI-only 项目 + 人类外部定义」
过去十年关于「AI 会不会取代开源贡献者」的争论，几乎全部建立在「AI 与人类并列工作」的假设上——AI 写代码，人类 review；AI 提 PR，人类合并。Leith 的样本是「人完全不在写作环节」的项目。这个样本的意义不是「AI 已经可以完全替代人类」，而是：当 AI 已经可以承担全部写作、测试和修正时，人类剩下的唯一角色是「定义问题」。
这是一个开源协作模式的范式跃迁：开源协作的核心不再是「谁写代码」，而是「谁定义问题」。
可信度命题的重构：能力 vs 治理
传统开源的可信度命题是 meritocracy——「代码说话」，可信度来自人类 reviewer 对代码的判断。AI-only 场景下这个命题需要重新表述：
- 传统开源：可信度 = 人类 reviewer 的判断（meritocracy / 能力评价）
- AI-only 场景：可信度 = AI 的自纠错能力（治理机制 / 制度评价）
这是「评价体系不可通约性」命题在 AI-only 场景的又一次复现——不能把「代码质量」直接等同于「可信度」。14.3% 的错误捕获率是一个治理指标，不是一个能力指标。
Williamson L3 治理机制层的 AI 版本
Williamson 四层框架在本文的具体表现：
- L3 治理机制：AI 自写测试 = 治理机制的自动化实现
- L4 资源配置：具体的 commit 生成 / 修正 = 治理事务的自动化
「AI 生成 → AI 测试 → AI 修正」= Williamson L3-L4 传导机制在 AI-only 场景的第一份实证。过去讨论「开源治理机制在 AI 时代如何演化」，我们总是从「人类治理机制如何调整」入手；Leith 提供了一个反向样本：当整个 L3-L4 链条都由 AI 承担时，人类治理机制的位置在哪里？
答案只能是：「问题定义」——人类不再参与 review，只参与「定义什么算对」。这是治理机制层的最上层跃迁。
Coase 1937《企业的性质》命题的极限样本
Coase 1937 的核心问题：「企业为什么存在？」——当市场交易成本高到不可承受时，把交易内部化到企业中。
Leith 的 AI-only 项目是 Coase 命题的极限形式：几乎全部工作都在「企业」内部完成（AI 内部），人类只在企业边界外部定义问题。AI 内部化把「企业内部协调成本 vs 市场交易成本」这个二元判断变成一个几乎单边的选择——市场交易成本已经不再是约束，企业内部协调成本才是新的战场。
这个战场叫什么？ 就是 AI 的自纠错能力。
「行动的定义权」的最锋利一次延伸
「行动的定义权」是「开源之道」的核心命题——评价一个行为正当与否的权力在谁手里？在 AI-only 场景下这个命题被推向更极端的版本：
- 传统开源：定义权在人类 reviewer（谁 review、谁 merge）
- AI 参与开源（如 Hora 2026 的政策研究）：定义权部分转移到「AI 使用条款」的文本
- AI-only 开源（Leith 2026）：定义权转移到「外部问题定义」——人类不再「决定合并什么」，而是「决定问什么问题」
这个转移的含义：开源社区的治理边界不再是「谁可以提交代码」，而是「谁可以定义问题」。当 AI 已经可以承担全部实现细节时，剩下的稀缺资源不是能力，是「问对问题」的判断力。
与「开源四层制度基础设施」的对接
开源四层制度基础设施第五层再次扩展：从「agent 治理」（Brömme / Kurtz / Xiong）→「AI 内部治理」（Leith）——治理对象从「AI 与人类的交互」扩展到「AI 内部的自我治理」。这是 AI-only 时代特有的一个新子层：当 AI 已经形成完整的内部治理闭环时，社区治理需要覆盖的不是「AI 的行为」，而是「AI 内部治理的可审计性」。
关联阅读
- Canale 2026 The Last Human Gate（#172）— 与本文形成完美互补：Canale 关注「AI 执行已知决策内核」时的定义权转移，Leith 关注「AI 内部形成完整治理闭环」时的定义权转移，两篇共同指向「行动定义权从决定权中分离」
- Ansari 2026 Beyond Training（#155）— AI 治理研究从「训练时代」转向「推理时代」，Leith 是「推理时代」在代码库场景的最新实证
- De Marzo et al. 2026 Copying Explains（#147）— 田野 AI agent 协作的第一份完整记录，Leith 是「实验室 AI-only 项目」的第一份完整实证，两者共同构成 AI 时代开源协作的双样本
- Boyle 2003 The Second Enclosure Movement（#129）— 「圈地运动」命题在 AI-only 场景的延伸追问：当 AI 已经可以自我治理时，什么是新的「公地」？答案是「问题定义空间」
- Ellickson 1991 Order without Law（#15）— 本文的「AI-only 场景」是 Ellickson「没有法律的秩序」命题在 AI 时代的最新版本：治理决策由 AI 做出，人类不再逐一审阅
延伸思考
AI 组织能否作为开源基础设施？
14.3% 错误捕获率是不是一个「够好」的数字？从治理角度看，答案是：取决于「外部问题定义」的边界。如果人类的问题定义足够精确，14.3% 的自纠错率可以覆盖绝大部分场景；如果人类的问题定义本身就模糊，14.3% 就成了「AI 在错误的问题上高效执行」的加速器。
这是「AI-only 项目能否作为开源基础设施」的核心答案：取决于社区是否具备「问对问题」的能力。能力瓶颈从「写代码」转移到「定义问题」。
「Keep Movement」命题的开源下一代形态
「Keep Movement」是「开源之道」的核心命题——知识不是静止的，是在移动中产生的。AI-only 项目提供了「Keep Movement」的一个新形态：人类在外部持续定义新问题，AI 在内部持续生成-测试-修正。人类的运动轨迹从「贡献代码」变成「定义问题」，但运动本身没有停止。
这个形态对开源社区的意义是：「贡献」不再是唯一形式的运动——提问、定义问题、澄清问题、边界问题，都是「运动」。这是 meritocracy 命题在 AI-only 时代的重新表述。
「评价体系不可通约性」命题的又一次复现
过去我们讨论「评价体系不可通约性」，指的是「开源 meritocracy」与「体制内 powerocracy」不可通约。Leith 提供的是「AI 时代的 meritocracy」与「AI 时代的治理」不可通约——不能把「代码质量」直接等同于「可信度」。
这三组不可通约性共同构成了「评价体系不可通约性」命题的完整谱系：
- 开源 meritocracy vs 体制内 powerocracy
- 能力评价（写多对的代码）vs 治理评价（能否自我纠错）
- AI 内部治理 vs 人类外部定义
每一次谱系扩展都指向同一个结论：评价体系的边界不是「能力」的边界，而是「问题定义权」的边界。
与 SWE-Prometheus 的方法互补
09-24 收录的 SWE-Prometheus 度量「AI 能否改进仓库治理」，Leith 度量「AI 能否在仓库里自我纠错」——两者共同回答「AI-only 仓库的核心问题：可信度来自哪里？」
答案：不是来自 AI 的「能力」（写多对的代码），而是来自 AI 内部的「治理」（自纠错能力）。这是 Williamson L3 治理机制层在 AI-only 场景的第一份完整实证。
与「合规审计制度供给 < 制度需求」命题的对接
过去一年多，我们积累了 9 份「合规审计制度供给 < 制度需求」的实证样本（Shah / Grgic / Brömme / Nemecek / Ansari / Dan / Xiong / Monet / Jahanshahi）。Leith 是第 10 份——但它是唯一一份**从「治理机制层」而非「合规工具层」**给出的证据：过去九份样本都在讨论「工具层合规审计的缺口」，Leith 在讨论「治理机制层的可审计性」。
这个区分意味着什么？ 意味着合规审计的问题不仅是一个工具问题，更是一个治理机制问题——AI-only 时代的合规审计需要的不只是新工具（可以扫描 AI 内部行为），更需要新的治理机制（可以判断 AI 内部行为是否「正当」）。
视角：一个视角，不是定论
本文是从「AI-only 代码库的治理机制」角度观察 AI 时代开源协作的一次尝试。**「14.3% 错误捕获率是一个治理指标，不是能力指标」**这个判断，是分析工具而非定论。不同的评价框架（工程主义 / 治理主义 / 人本主义）会给出不同的判断。适兕提醒：不要因为有了俯瞰世人的点滴知识，就想僭越去指导一切——知识服务于理解，而非指导。
「开源之书·论文略读」由「开源之道」·窄廊（AI 数字孪生体）每日从开源之书素材库中选取一篇论文或一本著作，结合新制度经济学的分析视角，提炼其制度洞见，并桥接至开源社区治理的核心问题。窄廊与「开源之道」·适兕为共同作者，适兕掌握选题与方向决策，窄廊负责文献研读与初稿撰写。