来源笔记
Test-Oriented Programming: rethinking coding for the GenAI era
摘要
本文提出 Test-Oriented Programming（TOP），一种软件开发方式：开发者先审查生成的测试，再让 LLM 根据这些测试生成生产代码。作者构建了一个概念验证工具 Onion，并展示这种工作流可以完成一个小型命令行程序，但也有明确的限制和失败模式。
问题
- 现有的 LLM 编码工具仍然让开发者检查生产代码，因此抽象层级仍然接近普通编程。
- 自然语言规格本身有歧义，LLM 输出也不确定，所以直接把实现交给模型并不容易信任。
- 论文想知道，开发者能否把审查重点从生产代码转到测试代码；如果 GenAI 要在可靠的前提下减少人工编码，这个问题就很重要。
方法
- TOP 先根据自然语言规格生成测试代码，再用这些测试生成生产代码。
- 开发者会审查和编辑生成的 YAML 配置、系统结构和测试文件，但在目标工作流中不直接编辑生产代码。
- 作者把这个想法实现为 Onion，这是一个命令行 Python 工具，会迭代生成项目结构、验收测试、类测试，然后生成实现代码，直到测试通过或运行中止。
- 评估使用了一个小型 BibTeX 命令行应用，功能包括添加条目、列出条目和搜索文本，并对比了两个模型：GPT-4o-mini 和 Gemini 2.5-Flash。
结果
- Onion 在同一任务上每个模型运行 5 次，总共 10 次运行。
- 10 次运行全部成功 生成了目标应用。
- 在 0 次运行 中，开发者需要直接修改生产代码。
- 在 共 2 次运行 中（1 次使用 GPT-4o-mini，1 次使用 Gemini 2.5-Flash），开发者不得不给测试代码加注释，以便在同一组测试上多次失败后引导生成。
- 对于 GPT-4o-mini，作者报告有 1 次运行 需要在检查实现之前修改测试代码。
- 论文没有报告标准软件指标，例如基准通过率、节省时间、token 成本、准确率，也没有和 Copilot、TDD 或多智能体基线比较。最明确的结论是：在一个小任务上，生产代码可以从经过审查的测试中生成；不同运行之间的输出会变化；Gemini 2.5-Flash 生成的代码通常比 GPT-4o-mini 更长、注释更多。