💻 computer science

Co-Located Tests, Better AI Code: How Test Syntax Structure Affects Foundation Model Code Generation

该论文通过大规模实证研究与机制分析发现，将测试代码与实现代码共置（如使用 Python doctests）能显著提升大语言模型生成代码的质量、确定性与正确性，表明测试语法结构已成为基础模型时代的关键软件设计考量。

原作者： Éric Jacopin

发布于 2026-04-23

📖 1 分钟阅读☕ 轻松阅读

原作者： Éric Jacopin

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文探讨了一个非常有趣且实用的问题：当我们让 AI 写代码时，测试代码（用来检查代码对不对的“小测验”）放在哪里，会直接影响 AI 写出来的代码质量。

简单来说，作者发现：把测试代码和主代码“贴”在一起（共址），AI 写得更好；把测试代码和主代码“分开”放，AI 就容易“偷懒”或“装傻”。

为了让你更容易理解，我们可以用几个生活中的比喻来拆解这篇论文的核心发现：

1. 核心比喻：家教与作业本

想象一下，你雇佣了一位超级聪明的家教（AI 模型）来帮你写数学作业（代码）。

场景 A：共址测试（Inline Tests / 像 Python Doctests）
你把题目和答案直接写在同一个笔记本的同一页上，甚至答案就写在题目旁边。
- 比喻： 就像家教在解题时，旁边就贴着“标准答案”和“解题步骤”。
- 结果： 家教非常清楚要做什么，几乎不会出错，而且会严格按照你给的答案来写。无论这个家教是新手还是专家，表现都非常完美。
场景 B：分离测试（Separated Tests / 像 Rust #[test]）
你把题目写在作业本的前半部分，把“标准答案”和“检查清单”写在作业本最后面的一个独立附录里，或者甚至放在另一个文件夹里。
- 比喻： 家教在写题时，得翻到最后一页才能看到“检查清单”。
- 结果：
  - 新手家教（小模型）： 可能会完全忽略附录，或者根本不知道附录是干嘛的，直接写了一堆没用的东西。
  - 专家家教（大模型）： 有些专家家教虽然能写出完美的解题过程（代码逻辑是对的），但他们故意把附录里的“检查清单”给撕掉了！他们觉得：“我写的代码肯定对，不需要你那些小测验来验证。”
  - 后果： 代码逻辑是对的，但因为没有保留测试代码，你无法验证它，或者在后续维护时容易出问题。

2. 论文发现了什么？（三大关键结论）

结论一：位置决定命运

作者让 12 种不同的 AI 模型去写同一个复杂的“堆栈”数据结构。

当测试代码紧贴在功能代码旁边时（Python 风格），所有 AI 的表现都接近完美（92%~100% 正确）。
当测试代码分开存放时（Rust 风格），AI 的表现出现了巨大的两极分化。有些模型能完美保留测试，有些模型（特别是某些高端模型）会直接删除所有测试代码，只给你留一个看起来很好但无法验证的“黑盒”。

通俗解释： 就像有些学生，如果考试卷子和答案印在一起，他就能考满分；如果答案在另一本书里，有些聪明的学生反而会把答案书扔掉，觉得自己不需要答案。

结论二：AI 也会“变心”

作者发现 AI 的行为不是一成不变的。

有些 AI 模型在升级后，反而变得更“坏”了（比如删除测试代码）。
有些模型在升级后，又变“好”了。
启示： 如果你公司用 AI 写代码，不能以为“上次用这个模型没问题，这次升级了也没问题”。每次模型更新，都要重新检查它是不是还保留测试代码。

结论三：为什么 AI 会这样？（大脑里的秘密）

作者不仅看了结果，还像做“脑部扫描”一样，分析了 AI 内部是如何处理这些信息的（这叫“可解释性”研究）。

发现： 当测试代码和主代码靠得很近时，AI 大脑里的“注意力机制”（就像聚光灯）会强烈地聚焦在测试标记上。这种强烈的连接让 AI 觉得：“这个测试很重要，必须保留。”
发现： 当测试代码离得远时，AI 的“聚光灯”就照不到那里了，或者照得很弱。对于某些模型来说，离得远的测试就像“背景噪音”，直接被过滤掉了。
有趣点： 即使不是最新型的 AI 架构（比如一种叫 RNN 的老式架构），也有同样的规律。这说明“把测试和代码放一起”是一个通用的设计原则，不管未来 AI 怎么变，这个原则都管用。

3. 这对我们普通人意味着什么？（行动指南）

这篇论文给所有使用 AI 辅助编程的人（无论是程序员还是管理者）提出了三条建议：

把测试“粘”在代码旁边：
如果你用 AI 写代码，尽量让测试用例（Test Cases）直接写在函数定义的旁边（比如写在文档字符串里），而不是单独放在一个长长的文件末尾。这就像给 AI 贴了个“便利贴”，提醒它：“别忘了这个！”
不要只看代码，要跑测试：
不要以为 AI 生成的代码跑通了就是好的。一定要运行它生成的测试代码。因为有些 AI 会生成“看起来很美”的代码，但偷偷删掉了验证步骤。
- 比喻： 就像买房子，不能只看装修图（代码），得亲自去敲敲墙、试试水管（运行测试）。
警惕“模型升级”：
如果你发现 AI 突然不写测试代码了，不要急着怪 AI 变笨了，可能是它“变聪明了”（自以为不需要测试），或者是它“变懒了”。你需要检查模型版本，并调整你的提示词（Prompt）或代码结构。

总结

这篇论文告诉我们：在 AI 时代，代码的结构设计不仅仅是为了人类看得舒服，更是为了“哄”AI 写出更好的代码。

把测试和代码共址（Co-locate），就像给 AI 提供了一个清晰的“导航仪”，让它知道该往哪里走，从而减少迷路和偷懒的概率。这是一个简单但能显著提升 AI 生成代码质量的设计技巧。

这是一篇关于基础模型（Foundation Models, FMs）时代下，测试代码的语法结构如何影响 AI 代码生成质量的实证研究论文。作者通过大规模实验和机械可解释性分析，发现将测试代码与实现代码共置（Co-located）（即内联测试）能显著提升 AI 生成代码的保真度和正确性，而分离式测试结构则会导致模型表现出现巨大差异。

以下是该论文的详细技术总结：

1. 研究背景与问题 (Problem)

随着 AI 编程助手（如 GitHub Copilot, Claude Code 等）的普及，AI 不仅生成实现代码，还生成或处理测试代码。传统的测试组织方式存在一个光谱：

最大共置 (Maximum Co-location): 如 Python 的 doctest，测试用例直接嵌入在函数的文档字符串（docstring）中，使用 >>> 标记。
同文件分离 (Same-file separation): 如 Rust 的 #[test]，测试函数位于同一文件的 mod tests {} 块中，但在结构上与实现代码分离。
文件分离 (Separate-file separation): 如 pytest 或 JUnit，测试代码位于独立文件中。

核心问题： 这种测试代码的放置位置和语法结构（内联 vs. 分离）是否会影响基础模型生成代码的质量？如果是，其背后的机制是什么？

2. 方法论 (Methodology)

2.1 实验设计

任务： 实现一个 d-ary 堆（d-ary heap） 优先队列。这是一个具有实际意义且复杂度适中的任务（需要 6+ 个公共方法、泛型支持、边界处理），足以区分不同模型的能力边界。
语言与条件对比：
- Python (内联): 使用 doctest（>>> 标记），代表最大共置。
- Rust (分离): 使用 #[test] 块，代表同文件但结构分离。
模型规模： 涉及 12 个模型（3 个提供商），包括 9 个 Claude 变体（覆盖 Haiku, Sonnet, Opus 三个层级及多代演进）和 3 个非 Claude 模型（Mistral, Devstral, EssentialAI）。
数据量： 生成了 830+ 个文件，每个模型/实验组合运行 50 次（温度设为 0，但发现 0 度并不保证确定性）。

2.2 评估框架：SEGA

作者提出了 SEGA (Statistical Evidence for Generative Accuracy) 三维评估框架：

确定性 (Determinism): 多次运行输出的一致性。
保真度 (Preservation): 生成的代码中是否保留了提示词中提供的测试用例（结构完整性）。
正确性 (Correctness): 保留下来的测试用例是否实际通过（功能正确性）。

质量区域可视化： 将模型映射到 (保真度，正确性) 的二维象限中，直观展示模型表现（如：高保真高正确性为“理想”，高保真低正确性为“危险”）。

2.3 机械可解释性 (Mechanistic Interpretability, MI)

为了探究“为什么”，作者在 7 个开源架构（6 个 Transformer 和 1 个门控线性 RNN RWKV-6）上进行了分析：

注意力模式分析： 测量测试标记（>>> vs #[test]）对函数签名 Token 的注意力强度。
因果验证： 通过 Knockout 实验（阻断注意力路径或抑制 RNN 状态写入）和 Steering 实验（增强注意力权重）来验证因果关系。

3. 主要发现与结果 (Key Results)

3.1 实证结果 (RQ1-RQ3)

内联测试 (Python Doctests) 表现卓越：
- 几乎所有模型在 Python 内联测试条件下都实现了 100% 的测试保真度 和 92-100% 的正确性。
- 测试语法结构是强信号，AI 能很好地保留并正确实现。
分离测试 (Rust #[test]) 暴露巨大差异：
- 模型层级鸿沟： 表现两极分化。Haiku 4.5 和 Sonnet 系列表现完美（100% 保真，100% 正确）；但 Opus 4/4.1/4.5 等高端模型却表现出 0% 的保真度（它们生成了正确的 Rust 代码，但完全抑制/删除了所有 #[test] 块，将其视为规范而非内容）。
- 独立维度： 证明了“保真度”和“正确性”是独立的维度。Opus 模型代码正确但无测试，属于“高正确性、低保真度”的危险区域。
模型演进的不稳定性：
- Opus 4.6 打破了前三个版本（4, 4.1, 4.5）的“抑制测试”模式，恢复了 100% 保真度。
- Haiku 3.5 曾出现回归（剥离所有 doctest），而 Haiku 4.5 又恢复。
- 结论： 模型行为随版本更新而变化，CI/CD 流程必须监控模型行为而非仅依赖模型层级。
温度=0 不等于确定性： 即使在 temperature=0 下，部分模型（如 Mistral Medium, Opus 4.6）仍表现出非确定性（输出不同但功能等价或不同），评估需多轮运行。

3.2 机械可解释性结果 (RQ4)

注意力差异： 在 5/7 的模型中，Python 的 >>> 标记对函数 Token 的注意力强度是 Rust #[test] 标记的 2.8 到 4.4 倍。
因果验证：
- Knockout 实验： 阻断 >>> 到函数的注意力路径会导致巨大的 KL 散度（预测改变），而阻断 #[test] 影响较小。这证实了内联测试标记在生成过程中具有更强的因果权重。
- 跨架构一致性： 这种共置优势不仅存在于 Transformer，在 RWKV-6 (RNN) 的循环状态动态中也观察到类似模式。这表明“共置”是序列处理的通用优势，而非 Transformer 特有的 artifacts。
Steering 实验： 尝试通过增强 #[test] 的注意力来改善表现，仅在部分模型（Qwen）中观察到微小提升，且受限于小模型生成复杂 Rust 代码的能力瓶颈。

4. 核心贡献 (Contributions)

实证发现： 首次量化证明测试语法结构（内联 vs. 分离）显著影响 AI 代码生成质量。内联测试能带来近乎完美的结果，而分离测试会暴露模型层级的缺陷。
SEGA 评估框架： 提出了包含确定性、保真度、正确性的三维评估体系，揭示了“代码正确但无测试”的隐蔽风险。
机械可解释性证据： 通过注意力分析和因果干预，从模型内部机制解释了为何共置测试更有效（更强的语义绑定），并证明该机制跨越了 Transformer 和 RNN 架构。
设计指南： 为 AI 时代的软件开发提供了具体的设计建议。

5. 意义与启示 (Significance & Implications)

测试即设计 (Test Syntax as Design): 在基础模型时代，测试代码的放置不再仅仅是测试哲学或团队习惯问题，而是直接影响 AI 工具有效性的软件设计决策。
设计建议：
- 共置原则： 在使用 AI 助手时，应尽可能将测试规范与实现代码共置（Co-locate）。例如，优先使用 Python doctests，或在 Rust 中尽量将测试逻辑内联（如果语言允许），或通过 IDE 插件将测试规范注入到提示词的相邻位置。
- 框架设计： 新的测试框架应考虑"AI 友好性”，设计能增强测试与代码结构关联的语法。
- CI/CD 策略：
  - 不要假设模型层级越高越好（Opus 曾出现抑制测试的回归）。
  - 必须运行生成的测试，而不仅仅是检查测试是否存在（保真度 $\neq$ 正确性）。
  - 在温度=0 下也需进行多轮评估以确保可复现性。
能力边界： 附录研究表明，共置效应在小模型/能力受限的模型中最为显著（RNJ-1 模型在内联测试下保真度 47%，分离下 0%）；而在顶级前沿模型（Frontier models）的 Python 任务中，模型可能忽略结构差异。但在 Rust 等语言中，即使顶级模型也可能因语言特定的训练分布而表现出抑制行为。因此，共置原则在能力受限或特定语言交互不利时是至关重要的“负载”设计。

总结： 这篇论文通过严谨的实证和深入的机制分析，确立了“测试与代码共置”作为提升 AI 生成代码质量的关键设计原则，并警告开发者和团队关注模型版本更新带来的行为漂移风险。