检索概况
检索时间：2026-06-04。来源：arXiv (export.arxiv.org API)。 两轮检索：Round 1 — TDD + AI/LLM 组合（代码生成方向），按关联度排序筛选；Round 2 — TDD 在非编程通用领域的应用（ontology、spreadsheet、knowledge engineering、business rules、EDD 等）。共 20 篇高相关论文，时间跨度 2006–2026。
Part A — Programming Domains（代码/软件工程方向）
A1. LLM + TDD 核心实证研究
1. LLM4TDD: Best Practices for Test Driven Development Using Large Language Models
2312.04687 | 2023-12 | Piya & Sullivan | cs.SE, cs.LG
核心发现：用 ChatGPT 在 LeetCode 问题上实施 TDD 式迭代代码生成。探究测试属性、提示属性、问题属性对 LLM TDD 效果的影响。这是该方向的开创性实证研究，建立了 TDD + LLM 的基本实验范式。
2. Test-Driven Development for Code Generation
2402.13521 | 2024-02 | Mathews & Nagappan | cs.SE, cs.AI
核心发现：给 LLM（GPT-4、Llama 3）提供测试用例作为输入的一部分，能显著提升代码生成成功率。在 MBPP 和 HumanEval 上验证了"测试先行"的 TDD 原则在 AI 代码生成场景中同样有效。结论：TDD 是确保 LLM 生成代码满足需求的可行范式。
3. Generative AI for Test Driven Development: Preliminary Results
2405.10849 | 2024-05 | Mock, Melegati & Russo | cs.SE
核心发现：提出两种 GenAI + TDD 交互模式：协作模式（开发者写测试、AI 每轮生成代码）和全自动模式（AI 自行完成，开发者仅在迭代结束时监督）。实验表明 GenAI 可有效用于 TDD，但产出需人工监督质量，且可能误导非专业开发者。
A2. TDD 驱动的 LLM 评测
4. Tests as Prompt: A TDD Benchmark for LLM Code Generation
2505.09027 | 2025-05 | Cui | cs.SE, cs.AI
核心发现：推出 WebApp1K 基准——1000 道跨 20 个领域的 TDD 代码生成挑战。评估 19 个模型发现：指令遵循能力和上下文学习能力比通用编程能力更关键。揭示了长提示下的"指令丢失"瓶颈。
5. Acceptance-Test-Driven Evaluation Protocols for Business-Centric LLM Systems
2606.02755 | 2026-06 | Liang | cs.SE, cs.AI
核心发现：将 TDD 的 red-green-refactor 适配为 red-train-green 生命周期：先定义验收测试 → 改进 LLM 系统（提示/检索/微调/护栏） → 通过多维门禁后发布。把验证从代码质量扩展到非确定性 AI 系统的行为治理。
A3. 智能体工作流
6. TDFlow: Agentic Workflows for Test Driven Development
2510.23761 | 2025-10 | Han et al. | cs.SE, cs.AI, cs.MA
核心发现：TDD 驱动的多智能体工作流，四个子智能体：补丁提议、调试、补丁修订、测试生成。SWE-Bench Lite 88.8%（+27.8%），SWE-Bench Verified 94.3%。关键洞察：主要瓶颈在于生成有效复现测试——而非代码修复本身。
7. Enhancing LLM Code Generation through TDD and Code Interpreter
2511.12823 | 2025-11 | Jalil et al. | cs.SE, cs.LG, cs.PL
核心发现：在资源受限场景（孟加拉语）中，TDD + Code Interpreter 将基线提升至 85%，无需微调。小模型可达大模型 98% 准确率。证明 TDD + CI 是低成本高效益方案。
A4. 工具与平台
8. LASSO: Test-driven Software Experimentation with LLM Prompt Benchmarking
2410.08911 | 2024-10 | Kessel | cs.SE, cs.AI
核心发现：TDSE（测试驱动软件实验）平台，提供 DSL 和数据结构的工具包来设计和执行软件实验。
9. CoSQA+: Pioneering the Multi-Choice Code Search Benchmark with Test-Driven Agents
2406.11589 | 2024-06 | cs.SE, cs.AI, cs.IR
核心发现：将 TDD 代理用于代码搜索基准测试，用测试执行来验证搜索结果的相关性。
Part B — Non-Programming Domains（非编程通用领域）
B1. 本体工程 (Ontology Engineering) —— TDD 在知识表示领域的标杆
10. Test-Driven Development of Ontologies (extended version)
1512.06211 | 2015-12 | Keet & Lawrynowicz | cs.AI
核心贡献：首次系统地将 TDD 引入本体工程。定义 36 个通用测试覆盖 OWL 2 DL 所有语言特性，实现为 Protégé 插件。
STDD 启示：本体 = 知识规范。TDD 在"定义概念及关系"这类非编程任务中证明有效——规格（OWL 公理）就是可执行的测试。
11. More Effective Ontology Authoring with Test-Driven Development
1812.06015 | 2018-12 | Keet, Davies & Lawrynowicz | cs.AI
核心贡献：提出完整 TDD 算法覆盖任意 OWL 2 类表达式和 ABox 断言，证明了正确性。实现为 TDDonto2（Protégé 插件）。评估结论：TDD 比传统界面更快（尤其大中型本体），建模者错误显著减少。
STDD 启示：TDD 在非编程领域最有说服力的实证——知识建模者 TDD 流程中犯错更少、完成任务更快。
B2. 表格工程 (Spreadsheet Engineering) —— 面向非程序员用户
12. Investigating the Potential of TDD for Spreadsheet Engineering
0801.4802 | 2008-01 | Rust, Bishop & McDaid | cs.SE
核心贡献：最早将 TDD 应用于电子表格开发。通过两个案例研究证明 TDD 可应用于非编程领域的表格建模。
STDD 启示：表格 = 非程序员使用频率最高的"计算规格"。TDD 的角色是对计算结果进行预期定义而非代码测试。
13. Leveraging TDD with LLMs for Reliable Spreadsheet Code Generation
2510.15585 | 2025-10 | Thorne & Sarkar | cs.SE, cs.CL, cs.PL
核心贡献：TDD + LLM 框架用于电子表格公式生成。测试优先方法论既提供"技术约束"也提供"认知支架"，引导 LLM 输出更准确解决方案。
B3. 规则/策略系统 (Rule-Based Policy & Contracts)
14. VV&I of Rule Based Policies and Contracts in the Semantic Web
cs/0609119 | 2006-09 | Paschke | cs.AI, cs.SE
核心贡献：将 TDD 引入规则引擎的验证/确认/完整性测试（V&V&I）。关键洞见：TDD 关注行为层面的结论而非规则库结构，因此独立于规则语言复杂度，对规则工程师和用户都更易用。
STDD 启示：规则/策略 = 决策逻辑的规格。"关注行为而非结构"原则直接支持 STDD 中"Spec 定义预期行为"的非编程应用。
B4. 示例驱动开发 EDD (Example-Driven Development)
15. Example-Driven Development: Bridging Tests and Documentation
2409.00514 | 2024-08 | Nierstrasz, Chiş & Gîrba | cs.SE
核心贡献：EDD——示例既是可执行的测试，又是可检查、可复用的"活文档"。示例不像传统测试只返回 pass/fail，而是返回对象以便检查和复用于更丰富场景。
STDD 启示："测试即文档"与 STDD 中 Spec = 可执行的规格定义高度一致。示例在非编程领域天然适配：用具体输入/输出来定义规格，比自然语言更准确。
B5. 推理引擎/知识查询
16. Unit Testing in ASP Revisited: Language and TDD Environment
2401.02153 | 2024-01 | Amendola et al. | cs.SE, cs.AI
核心贡献：为 Answer Set Programming（知识表示和推理范式）设计 TDD 环境。提出新的单元测试规范语言，支持在 ASP 程序中内联测试。
STDD 启示：推理模型/规则库的测试——非编程但是逻辑密集型。TDD 的角色是验证推理结果是否符合预期，而非验证代码。
17. Are Query-Based Ontology Debuggers Really Helping Knowledge Engineers?
1904.01484 | 2019-04 | Rodler et al. | cs.AI
核心贡献：交互式本体调试用户研究。发现基于查询的调试比基于测试用例的算法调试更高效，但也揭示用户易出错，提示测试用例设计需谨慎。
STDD 启示：知识工程行为本身需要测试驱动——验证知识工程师的推理过程是否正确。
Part C — Cross-Domain 理论框架
18. The role of slicing in test-driven development
2407.13258 | 2024-07 | Dieste et al. | cs.SE
核心发现：每个 TDD 周期 = 用户故事的垂直切片，通过"契约"（contracts）捕获。本文的框架不限于编程，描述了 TDD 的普适性本质。
19. Why Research on TDD is Inconclusive?
2007.09863 | 2020-07 | Ghafari et al. | cs.SE
核心发现：系统综述 TDD 研究矛盾结论的方法论陷阱。任何 TDD 研究者设计实验前应阅读。
20. Causal Factors, Benefits and Challenges of TDD: Practitioner Perceptions
2101.12393 | 2021-01 | Buchan et al. | cs.SE
核心发现：组织层面 TDD 落地的三年追踪——因果要素、益处与挑战。
跨域聚类分析
| 簇 | 篇数 | 共同特征 | STDD 启示 |
|---|---|---|---|
| 知识工程系 本体工程 + 规则系统 + 调试 + ASP | 5 | 知识/逻辑表征为输出，测试验证"推理结果"而非代码正确性 | Spec = 示例 + 约束的组合，而非自然语言描述 |
| 计算工具系 表格工程 | 2 | 面向非程序员终端用户，验证"计算结果"是否符合业务预期 | 测试独立于领域复杂度——TDD 不依赖底层逻辑复杂度 |
| 代码生成系 LLM4TDD + TDFlow + GenAI + TDD | 7 | LLM 辅助或驱动的代码生成，TDD 作为约束和验证机制 | 协作模式 vs 全自动——非编程领域更适合协作（专家定 Spec，AI 辅助方案） |
| 通用框架系 EDD + 切片理论 + ATDD | 4 | 描述 TDD 超越编程的本质——契约、切片、验收条件是通用概念 | 验证链可抽象为"规格定义→实现匹配→整体一致性" |
| 治理系 ATDD for LLM Systems | 1 | 非确定性系统行为控制，red-train-green 生命周期 | TDD 正在从确定性领域扩展至概率性 AI 行为 |
关键趋势
| 趋势 | 说明 |
|---|---|
| 从提示驱动 → 测试驱动 | 2023 的 LLM4TDD（探索）→ 2025 的 TDFlow（88.8%）。范式从"怎么让 LLM 按提示写代码"转向"怎么用测试约束 LLM 行为" |
| Agentic TDD | 多智能体分解 + TDD 流水线成为最强代码修复方案 |
| 测试质量成为瓶颈 | TDFlow 指出"生成有效复现测试"是最后屏障——而非代码修复本身 |
| TDD 在非编程领域的有效性已被实证 | 本体工程（Keet 团队，TDDonto2）→ 建模者错误减少、效率提升 |
| TDD 独立于领域复杂度 | 规则系统的 VV&I 论文证明 TDD 关注行为而非结构——对任何领域都适用 |
| EDD 弥合了测试与文档的鸿沟 | 示例既是测试又是活文档——Spec = 可执行的示例定义 |
STDD 非编程域扩展建议
- 知识工作者的 Spec = 示例 + 约束：本体工程 TDD 和 EDD 表明，非编程领域中最有效的 Spec 形式是"具体示例 + 约束条件"的组合，而非自然语言描述。
- 测试独立于领域复杂度：规则系统 VV&I 论文指出 TDD "独立于规则语言复杂度"——测试框架不应依赖底层领域逻辑的复杂度。
- 协作模式更适合非编程领域：领域专家定义 Spec，AI 辅助生成候选方案，而非全自动模式。
- 验证链的抽象方法：STDD 的三层验证（Spec 验证 → 测试验证 → 集成验证）可抽象为任何领域的"规格定义 → 实现匹配 → 整体一致性"。
- LLM 作为非编程 TDD 的执行器：TDFlow 的智能体解耦设计——Spec 设计层、测试生成层、执行层分离——可直接指导非编程 STDD 的架构。