红/绿 TDD¶
原文标题：Red/green TDD 原文链接：https://simonwillison.net/guides/agentic-engineering-patterns/red-green-tdd/ 原文作者：Simon Willison 访问日期：2026-03-25 原文发布日期：2026-02-23 原文最后修改：2026-02-28 译文版本：v0.1
译文说明¶
本文为 Simon Willison《Agentic Engineering Patterns》系列中《Red/green TDD》的示范中文版。本文沿用本项目既定术语约定，标题采用“红/绿 TDD”，并继续保留 TDD、Prompt 等高检索价值英文术语。文中将 test-first development 处理为“测试优先开发”，将 automated test / test suite 处理为“自动化测试 / 测试套件”，并强调红阶段先确认测试失败、绿阶段再确认测试通过的工作流含义。
正文¶
“Use red/green TDD” 是一种令人愉快地简洁的说法，用来从编码智能体那里拿到更好的结果。
TDD 是 Test Driven Development 的缩写，也就是测试驱动开发。它是一种编程风格，要求你写下的每一段代码，都要有自动化测试与之配套，用来证明这段代码确实能工作。
TDD 最严格的一种形式，是测试优先开发。你先把自动化测试写出来，确认它们确实会失败，然后围绕实现不断迭代，直到这些测试通过。
事实证明，这和编码智能体是 绝配。使用编码智能体时，一个很大的风险在于：它们可能会写出根本跑不通的代码，也可能会造出根本没必要、最后永远不会被用上的代码，甚至两种情况一起发生。
测试优先开发有助于防住这两类常见错误，同时也能建立起一套稳健的自动化测试套件，用来防范未来的 regressions。随着项目不断变大，一次新改动把原有功能搞坏的概率也会跟着上升。而要让这些功能一直保持正常，最有效的办法，归根结底还是一套足够完整的测试套件。
在动手实现代码、让测试转绿之前，先确认测试确实是失败的，这一点非常重要。如果跳过这一步，你就有可能写出一个本来就已经能通过的测试；这样一来，它既没有真正覆盖你的新实现，也无法证明你的新实现是对的。
这也正是 “red/green” 的意思：红阶段先看测试失败，绿阶段再确认它们现在已经通过。
每一个足够好的模型，都能把 “red/green TDD” 理解成一条更长指令的简写：也就是“采用测试驱动开发，先写测试，并且在动手实现那个会让测试通过的改动之前，先确认这些测试确实会失败”。
示例 Prompt¶
原文示例 Prompt 如下：
Build a Python function to extract headers from a markdown string. Use red/green TDD.