检索概况
检索时间：2026-06-04。来源：arXiv (export.arxiv.org API)。关键词覆盖 ontology、spreadsheet、knowledge engineering、business rules、requirement engineering、example-driven development、executable specification 等方向。共筛选 10 篇高相关论文，时间跨度 2006–2025。
一、本体工程 (Ontology Engineering) —— TDD 在知识表示领域的典型案例
1. Test-Driven Development of Ontologies (extended version)
1512.06211 | 2015-12 | Keet & Lawrynowicz | cs.AI
核心贡献：首次系统地将 TDD 方法论引入本体工程。定义了 36 个通用测试（TBox 查询 + 通过个体测试的 TBox 公理），完整覆盖 OWL 2 DL 语言特性。实现了 Protégé 插件。
STDD 启示：本体 = 知识规范。TDD 在这一领域的成功证明：测试先行的模式可以应用于"定义概念及关系"这类非编程任务——规格（OWL 公理）就是可执行的测试。
2. More Effective Ontology Authoring with Test-Driven Development
1812.06015 | 2018-12 | Keet, Davies & Lawrynowicz | cs.AI
核心贡献：在前作基础上提出了完整的 TDD 算法，覆盖任意 OWL 2 类表达式和主要 ABox 断言，并证明了算法正确性。实现为 Protégé 插件 TDDonto2。评估结论：TDD 比传统编辑界面更快（尤其大中型本体），且建模者错误显著减少。
STDD 启示：这是 TDD 在非编程领域最有说服力的实证——知识建模者在 TDD 流程中犯错更少、完成任务更快。为 STDD 扩展到非编程领域提供了直接证据。
二、表格工程 (Spreadsheet Engineering) —— 面向非程序员用户的 TDD
3. Investigating the Potential of Test-Driven Development for Spreadsheet Engineering
0801.4802 | 2008-01 | Rust, Bishop & McDaid | cs.SE
核心贡献：最早将 TDD 应用于电子表格开发的探索。通过两个案例研究证明 TDD 可以应用于非编程领域的表格建模。开发了配套工具。
STDD 启示：表格 = 非程序员使用频率最高的"计算规格"。TDD 在这里的角色不是传统意义上的代码测试，而是 对计算结果进行预期定义。
4. Leveraging TDD with LLMs for Reliable and Verifiable Spreadsheet Code Generation
2510.15585 | 2025-10 | Thorne & Sarkar | cs.SE, cs.CL, cs.PL
核心贡献：提出将 TDD 与 LLM 结合的框架用于电子表格公式生成。测试优先方法论既提供"技术约束"也提供"认知支架"，引导 LLM 输出更准确的解决方案。
三、规则/策略系统 (Rule-Based Policy & Contract Systems)
5. Verification, Validation and Integrity 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 启示：规则/策略 = 决策逻辑的规格。TDD 在规则验证中的"关注行为而非结构"原则，直接支持 STDD 中"Spec 定义预期行为"的非编程应用。
四、示例驱动开发 EDD (Example-Driven Development)
6. Example-Driven Development: Bridging Tests and Documentation
2409.00514 | 2024-08 | Nierstrasz, Chiş & Gîrba | cs.SE
核心贡献：提出 EDD——示例既是被执行的测试，又是可检查、可复用的"活文档"。示例是 TDD 测试的扩展：不像传统测试只返回 pass/fail，示例返回被测试对象以便检查和复用于更丰富的场景。
STDD 启示：EDD 的核心思想——"测试即文档"——与 STDD 中 Spec = 可执行的规格定义高度一致。示例在非编程领域天然适配：用具体输入/输出来定义规格，比自然语言更准确。
五、验收测试驱动的 LLM 系统治理 (General-Purpose ATDD)
7. 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 系统的行为治理。
六、推理引擎/知识查询 —— 非编程任务的 TDD 工具
8. Unit Testing in ASP Revisited: Language and Test-Driven Development Environment
2401.02153 | 2024-01 | Amendola et al. | cs.SE, cs.AI
核心贡献：为 Answer Set Programming（ASP，一种知识表示和推理范式）设计了 TDD 环境。提出新的单元测试规范语言，支持在 ASP 程序中内联测试，用计算复杂度分析支撑正确性。
STDD 启示：推理模型/规则库的测试——非编程但是逻辑密集型任务。TDD 在这里的角色是验证推理结果是否符合预期，而非验证代码本身。
9. Are Query-Based Ontology Debuggers Really Helping Knowledge Engineers?
1904.01484 | 2019-04 | Rodler et al. | cs.AI
核心贡献：交互式本体调试的用户研究。发现基于查询的调试比基于测试用例的算法调试更高效，但也揭示用户在这个过程中经常出错，提示了测试用例设计的必要性。
STDD 启示：知识工程行为本身需要测试驱动——验证知识工程师的推理过程是否正确。
七、跨域理论框架
10. The Role of Slicing in Test-Driven Development
2407.13258 | 2024-07 | Dieste et al. | cs.SE
核心贡献：提出 TDD 的理论框架——每个 TDD 周期 = 用户故事的垂直切片，通过"契约"（contracts）捕获。本文的框架不限于编程，描述了 TDD 的普适性本质。
关键趋势与 STDD 启示
| 非编程域 | 核心对象 | TDD 应用点 | STDD 启示 |
|---|---|---|---|
| 本体工程 | OWL 公理、类表达式 | 预定义分类正确性测试 | 规格（概念/关系定义）可测试 |
| 表格工程 | 公式、计算逻辑 | 预定义计算结果预期 | 规格 = 输入/输出预期 |
| 规则/策略 | 决策逻辑规则 | 行为验证而非结构验证 | 关注行为结果，独立于规则复杂度 |
| 示例驱动 | 活文档、可检查对象 | 示例 = 测试 + 文档 | Spec = 可执行的示例定义 |
| LLM 治理 | 非确定性 AI 行为 | 验收测试驱动的治理 | ATDD 适配 LLM 输出验证 |
| 逻辑推理 | ASP 程序、知识查询 | 推理结果预期验证 | 推理模型输出需要测试先行 |
跨域聚类
1. 知识工程系（2+2=4 篇）：本体工程 + 规则系统 + 本体调试 + ASP TDD。共同特征：以知识/逻辑表征为输出，测试验证的是"推理结果"而非"代码正确性"。
2. 计算工具系（2 篇）：表格工程 x 2。共同特征：面向非程序员终端用户，测试验证的是"计算结果"是否符合业务预期。
3. 通用框架系（3 篇）：EDD + 切片理论 + ATDD。共同特征：描述 TDD 超越编程本身的本质——契约、切片、验收条件——这些都是通用概念。
4. LLM/AI 治理系（1 篇）：ATDD for LLM Systems。特征：把 TDD 引入非确定性系统的行为控制——这是新兴方向。
对 STDD 非编程域扩展的建议
- 知识工作者的 Spec = 示例 + 约束：本体工程 TDD 和 EDD 都表明，非编程领域中最有效的 Spec 形式是"具体示例 + 约束条件"的组合，而非自然语言描述。
- 测试独立于领域复杂度：规则系统 V&V&I 论文指出 TDD "独立于规则语言复杂度"——这一结论同样适用于 STDD：测试框架不应依赖底层领域逻辑的复杂度。
- 交互式 vs 全自动的选择：LLM4TDD 和 GenAI for TDD 论文区分了协作模式和全自动模式。非编程领域更适合协作模式——领域专家定义 Spec，AI 辅助生成候选方案。
- 验证链完整性：STDD 的三层验证（Spec 验证 → 测试验证 → 集成验证）可以抽象为任何领域的"规格定义 → 实现匹配 → 整体一致性"。