# Claude Code TDD Workflow：用隔离代理强制测试驱动开发

> 一个Claude Code插件，通过七个上下文隔离的代理强制执行红-绿-重构TDD循环，解决AI辅助开发中程序指令不可靠和会话漂移的问题。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-31T06:45:14.000Z
- 最近活动: 2026-05-31T06:49:51.305Z
- 热度: 141.9
- 关键词: Claude Code, TDD, 测试驱动开发, AI编程, 代理隔离, 红绿重构, LangGraph, 开发工具
- 页面链接: https://www.zingnex.cn/forum/thread/claude-code-tdd-workflow
- Canonical: https://www.zingnex.cn/forum/thread/claude-code-tdd-workflow
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**: hugo-bluecorn
- **来源平台**: GitHub
- **原始标题**: claude-code-tdd-workflow
- **原始链接**: https://github.com/hugo-bluecorn/claude-code-tdd-workflow
- **发布时间**: 2026年5月31日

---

## 背景：AI辅助开发的困境

随着Claude Code等AI编程助手的普及，开发者面临一个悖论：AI能力越强，协作越需要纪律。实践中暴露两个核心问题：

### 程序指令不可靠

告诉Claude"先写测试再实现"有时奏效，有时却会被忽略。作者通过12次以上对照实验证实：相同的提示在不同运行中产生质量差异。当AI拥有直接修改代码的权限时，口头约束难以保证执行。

### 会话漂移不可避免

随着对话增长，早期指令的模型注意力逐渐衰减。自动压缩机制会丢弃定义会话行为的关键约束。即使100万token的上下文窗口（Opus 4.6和Sonnet 4.6自2026年3月起普遍可用）也无法完全消除长会话的漂移问题。

开发者不得不在每次启动或恢复会话时重复相同的设置指令——身份定义、约束条件、工作流程。这种重复劳动消耗了本该用于解决问题的认知资源。

---

## 核心理念：Unix哲学的AI实践

该插件的设计遵循Unix哲学——每个工具做好一件事，然后组合成管道。规划者只规划，实现者只实现，验证者只验证。每个代理都是最小化的、专注的，通过工具限制和生命周期钩子约束在单一职责内。

开发者编排管道并做出决策，代理则以纪律执行。这种分离不是限制，而是解放——它让AI的能力在受控边界内最大化发挥。

---

## 系统架构：三层设计

### TDD管道层

结构化工作流将功能描述从规划到实现、验证再到发布，每个阶段由专用代理处理：

**规划阶段（/tdd-plan）**

`tdd-planner`代理以只读模式研究代码库，将功能分解为可独立测试的切片，附带Given/When/Then规格说明，提交人工审批。规划者被严格限制为只读访问，防止其直接修改代码。

**实现阶段（/tdd-implement）**

对每个已批准的切片，`tdd-implementer`代理执行红-绿-重构循环：
- 编写失败的测试
- 实现代码使其通过
- 重构优化

`tdd-verifier`在独立上下文中进行黑盒验证——它不知道实现者的意图，这种隔离确保验证的客观性。

**发布阶段（/tdd-release）**

`tdd-releaser`代理更新CHANGELOG、提升版本号、推送代码、创建PR，完成整个发布流程。

### 角色系统层

角色编码了开发者每次会话开始时需要重复提供的工作流模式、知识参考和行为约束。它回答三个问题：

1. **这个会话是谁？** — 身份、职责、约束
2. **这个会话知道什么？** — 项目上下文、架构、关键路径
3. **这个会话如何工作？** — 启动程序、审查清单、协调协议

通过`/role-create`命令，角色创建者代理研究项目、访谈开发者的工作流，生成符合角色文件格式规范的验证角色文件。生成的角色自动作为Claude Code技能可被发现，如`/role-ca`加载架构师角色，`/role-ci`加载实现者角色。

角色是推荐方案而非强制要求。TDD管道独立于角色文件运行，核心工作流中的任何代理、技能或钩子都不检查、引用或要求角色。

### 约定系统层

插件是语言无关的。它知道*如何做*TDD，但将*什么构成地道代码*委托给外部约定包：

- 约定存在于独立仓库（如`hugo-bluecorn/tdd-workflow-conventions`）
- SessionStart钩子将它们获取到本地缓存
- 编写或指定代码的代理（规划者、实现者）根据项目类型检测动态加载相关约定
- 添加新语言意味着添加约定包，无需修改插件

目前已存在Dart/Flutter、C++、C和Bash的约定包。

---

## 技术实现：四大原语组合

插件组合Claude Code的四个原语：

| 原语 | 提供能力 | 插件用法 |
|---|---|---|
| **代理** | 每次调用的隔离上下文、受限工具访问 | 每个TDD阶段在独立代理中运行，仅使用所需工具 |
| **技能** | 面向用户的命令、编排逻辑 | `/tdd-plan`生成规划者，处理审批，写入文件 |
| **钩子** | 生命周期事件处理器（PreToolUse、PostToolUse、Stop等） | 强制执行测试先于实现的顺序、自动运行测试、保护规划者 |
| **脚本** | 代理和钩子调用的共享工具 | 项目检测、约定加载、版本传播、角色验证 |

### 代理配置

| 代理 | 模型 | 上下文 | 用途 |
|-------|-------|---------|---------|
| tdd-planner | opus | 只读、规划模式 | 研究代码库，返回结构化规划文本 |
| tdd-implementer | opus | 读写、完整工具 | 按切片执行红-绿-重构 |
| tdd-verifier | haiku | 只读 | 黑盒验证——不了解实现意图 |
| tdd-releaser | sonnet | 仅Bash写入 | CHANGELOG、版本传播、分支、PR |
| role-creator | opus | 只读 | 项目研究、角色文件生成、验证 |

四个代理拥有持久内存（`memory: project`），跨会话累积知识：规划者、实现者、验证者和上下文更新者。

### 钩子强制执行

钩子是代理遵循TDD纪律的机械保证。它们不能被对话上下文或模型漂移覆盖：

| 钩子 | 强制执行 |
|---|---|
| `validate-tdd-order.sh` | 直到该切片的测试文件存在才允许写入实现文件 |
| `auto-run-tests.sh` | 每次文件变更后运行测试套件——实现者必须在看到结果后才能继续 |
| `planner-bash-guard.sh` | 为规划者白名单只读Bash命令 |

---

## 实践价值

该插件解决的是AI编程的真实痛点：

**可靠性**：机械强制执行消除了"有时奏效有时失效"的不确定性。钩子不依赖模型的善意，而是硬性约束。

**可重复性**：角色系统让工作流模式可编码、可复用。启动新会话不再需要重复相同的上下文设置。

**客观性**：验证者的隔离上下文确保测试的独立性。它不知道实现者如何思考，只能根据规格判断对错。

**可扩展性**：约定系统让插件保持语言无关，新语言支持通过外部包实现，不触及核心代码。

---

## 设计启示

这个项目展示了AI辅助工具设计的一个重要原则：**能力越强，约束越重要**。

当AI可以直接修改生产代码时，简单的提示词不足以保证质量。需要架构层面的隔离、机械层面的强制执行、流程层面的编排。

同时，它也体现了Unix哲学在AI时代的适用性：小工具、单一职责、管道组合。每个代理只做一件事，但组合起来完成复杂工作流。

对于正在构建AI开发工具的开发者，这是一个值得参考的架构模式：不是让AI做更多，而是让AI在更清晰的边界内做得更好。