Scan to join WeChat groupAI对话TDD工作流专家
定位： 日常 AI 对话中执行任何任务的通用方法论——如何与 AI 协作完成高质量交付
适用场景： 功能开发、Bug 修复、代码重构、需求分析、文案写作、研究调查、方案规划、学习理解、决策分析
适用 Agent： 所有 AI 对话界面（ChatGPT、Claude、OpenAI、OpenCode、Claude Code、Hermes、Cursor、Windsurf 等）
版本： 2.0.0
触发调用方式
何时调用本Skill
当出现以下情况时，触发使用本Skill：
- 需要AI完成具体任务时 - 有明确交付物要求（文档、代码、方案等）
- 任务较复杂需分阶段时 - 简单一句话无法描述清楚的任务
- 对输出质量有较高要求时 - 需要确保AI输出符合特定标准
- 需要迭代优化时 - 初稿不满足要求，需要AI修正
调用方式
在AI对话中直接说明任务和标准，无需特殊命令：
# 直接调用示例
帮我完成：[任务描述]
标准：[成功标准]
约束：[约束条件]
格式：[输出格式]
适用Agent触发
所有支持AI对话的Agent均可调用：
- Claude Code（命令行对话）
- ChatGPT / Claude Web
- Cursor / Windsurf
- OpenAI Codex
- Hermes Agent
一、核心原理：为什么 AI 对话也需要 TDD
1.1 TDD 的三条铁律在 AI 对话中同样有效
| # | TDD 铁律 | AI 对话版本 | |---|---------|------------| | 1 | 先写失败的测试 | 先定义清楚"什么样的结果算成功"（RED） | | 2 | 不允许写超出测试需求的代码 | 不允许 AI 提供超出你要求范围的内容（GREEN） | | 3 | 每写完测试后立即运行，确保没有破坏已有功能 | 每完成一步后确认结果符合预期，再推进下一步（验证） |
1.2 传统 TDD vs AI 对话 TDD
传统 TDD（代码）：
人 → 写测试 → 看失败 → 写代码 → 看通过 → 重构
AI 对话 TDD：
人 → 定义成功标准(RED) → AI 生成初稿 → 人确认符合标准(GREEN) → 优化完善(REFACTOR)
1.3 关键映射关系
| 代码 TDD 概念 | AI 对话中的对应 | |--------------|----------------| | 测试用例 | 你的验收标准（脑子里的成功画面） | | 测试框架 | 你对 AI 输出的审视和判断 | | 产品代码 | AI 生成的内容（文字、代码、分析、方案等） | | 测试失败 | AI 的输出不符合你的标准 | | 测试通过 | AI 的输出满足你的标准 | | 重构 | 在达标基础上优化完善 |
1.4 AI 对话中最大的三个坑
| # | 坑 | 后果 | |---|-----|------| | 1 | 不定义清楚成功标准就让 AI 干活 | AI 按自己的理解做，你拿到的东西不是你要的 | | 2 | 不阶段性确认就让它继续 | 方向错了，走得越远越难回头 | | 3 | 接受了不符合标准的输出 | 质量不达标，最终交付物有问题 |
1.5 人与 AI 的分工
| 人的责任 | AI 的能力 | |---------|----------| | 定义"成功长什么样"（验收标准） | 快速生成各种可能的内容初稿 | | 阶段性确认输出是否符合标准 | 快速迭代、修改、补充 | | 判断内容的质量方向 | 提供多个方案供人选择 | | 决策最终方案和优化方向 | 执行重复性写作/分析任务 | | 审查内容是否符合真实意图 | 扩展细节、补充边界情况 | | 对最终结果负责 | 提供参考和建议 |
核心原则：AI 负责生成，人负责判断。AI 写的东西必须经过人的确认才能信任。
二、RED 阶段：定义清楚成功标准
2.1 什么是 RED 阶段
RED = Requirements Established & Defined
在让 AI 做事之前，先把"成功的标准"定义清楚。这个标准就像测试用例——如果 AI 的输出能通过这个"测试"，就是成功的。
RED 阶段是最重要的阶段。 据统计，80% 的 AI 对话问题源于 RED 阶段定义不清。
2.2 RED 阶段的核心要素
每次让 AI 做事之前，先想清楚这 5 个要素：
1. 背景：我为什么需要这个？解决了什么问题？
2. 任务：我具体要 AI 做什么？
3. 成功标准：什么样的输出算成功？（必须具体可衡量）
4. 约束：有没有什么边界或限制？
5. 格式：输出以什么形式交付？
2.3 RED Prompt 模板
标准版（复杂任务用）：
## 任务背景
[为什么需要这个？解决了什么问题？有什么上下文？]
## 任务
[具体要做什么？用一句话描述，越具体越好]
## 验收标准（必须全部满足，每条都要可衡量）
- [ ] 标准1：具体描述，包含数字或明确结果
- [ ] 标准2：具体描述，包含数字或明确结果
- [ ] 标准3：具体描述，包含数字或明确结果
## 约束（明确边界）
- [ ] 不要做...
- [ ] 避免...
- [ ] 限制范围...
## 输出格式
[文字/代码/表格/大纲/JSON...]
[字数/长度要求]
## 参考示例（如有）
[给 AI 一个参考范例，帮助它理解你要的风格和方向]
快速版（简单任务用）：
帮我做：[具体任务]
标准：[成功的样子，越具体越好]
约束：[不要做的事]
格式：[输出格式]
参考：[参考范例，可选]
2.4 什么是好的验收标准
好的验收标准（可衡量）：
✅ "字数在800-1000字"
✅ "包含3个具体案例，每个案例有背景、做法、结果"
✅ "语气轻松，口语化，像朋友聊天"
✅ "输出JSON格式，包含title、content、tags三个字段"
✅ "分析维度：经济、社会、文化、个人各至少2点"
差的验收标准（模糊）：
❌ "内容要丰富" → 多少算丰富？
❌ "分析要透彻" → 什么是透彻？
❌ "写得专业一点" → 什么样的算专业？
❌ "不要太差" → 什么是不要太差？
❌ "看着差不多就行" → 差不多是什么？
三、GREEN 阶段：获取最小化达标输出
3.1 什么是 GREEN 阶段
GREEN = Goal Reached Enhanced Early Now
AI 根据你定义的标准，生成满足要求的最小化输出。
3.2 GREEN 阶段的核心原则
最小化交付： 让 AI 先出一个满足基本要求的版本，不要追求完美。
"作弊"是允许的： 先满足标准，后续可以优化。过度设计是 GREEN 阶段最大的敌人。
GREEN 阶段的目标是"达标"，不是"最优"。
3.3 GREEN 阶段的验证流程
1. AI 生成初稿
2. 人对照 RED 标准逐条检查（每条标准都要验证）
3. 满足标准 → GREEN 完成
4. 不满足标准 → 指出具体问题，让 AI 修正
5. 修正后再次检查，直到达标
3.4 GREEN 阶段的反馈技巧
好的反馈（具体可操作）：
✅ "第三点不够具体，需要补充：具体的执行步骤是什么？"
✅ "案例太少，需要再增加2个国内案例"
✅ "太长，压缩到500字以内"
✅ "语气太正式，改成轻松口语风格"
✅ "第一条标准没满足：需要的是价格分析，你写的是功能对比"
✅ "缺少对'用户画像'的分析，这是标准里要求的"
差的反馈（AI 难以处理）：
❌ "不够好" → AI 不知道哪里不好
❌ "再来一遍" → 同样的问题会重复出现
❌ "重新写" → 没有指出问题在哪里
❌ "差点意思" → AI 不知道差在哪里
❌ "优化一下" → 不知道优化什么
❌ "好一点" → 什么算好一点？
四、REFACTOR 阶段：优化完善
4.1 什么是 REFACTOR 阶段
REFACTOR = Refine Excellence For All Concise Tasks Of Result
在 GREEN 达标的基础上，进行优化——但不改变核心交付物。
4.2 REFACTOR 与 GREEN 的区别
| 维度 | GREEN | REFACTOR | |------|-------|----------| | 目标 | 满足标准，达标 | 超出标准，更优 | | 原则 | 最小化，不多做 | 优化已有，不是新需求 | | 允许改变 | 满足标准就行 | 可以改变表达方式、结构 | | 不允许 | 添加新内容 | 改变核心结论或事实 | | 什么时候做 | 第一轮输出 | GREEN 达标之后 |
4.3 什么时候需要 REFACTOR
需要 REFACTOR 的情况：
- GREEN 达标了，但你想让质量更好
- 内容技术上正确，但表达不够清晰
- 结构合理，但不够吸引人
- 有多余废话，需要精简
不需要 REFACTOR 的情况：
- GREEN 勉强达标，但时间紧迫，先凑合用
- 内容本身已经足够好
- 后续还有人工编辑，不需要 AI 优化
4.4 REFACTOR 的常见任务
| 任务 | 说明 | 示例 | |------|------|------| | 精简表达 | 同样的意思，更简洁 | "总而言之、因此、所以" → 直接说结论 | | 优化结构 | 让逻辑更清晰 | 调整段落顺序，让重点更突出 | | 补充案例 | 让观点更有说服力 | 增加 1-2 个具体案例 | | 统一风格 | 让语气、用词一致 | 全篇都用"你"而不是混用"您" | | 美化格式 | 让排版更专业 | 增加小标题、列表、空白行 | | 强化开头 | 让开头更有吸引力 | 换成更有冲击力的开场 | | 改善过渡 | 让段落之间更连贯 | 增加过渡句 |
五、AI 对话 TDD 完整流程
5.1 标准流程图
┌─────────────────────────────────────────────────────┐
│ 开始 │
└─────────────────────────┬───────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ RED：定义成功标准 │
│ - 说清楚做什么 │
│ - 说清楚做成什么样（每条标准可衡量） │
│ - 说清楚不要做什么（约束） │
│ - 说清楚输出格式 │
│ 自检：5个要素都齐全吗？ │
└─────────────────────────┬───────────────────────────┘
↓
？
┌───────────┴───────────┐
│ 任务复杂度？ │
└───────────┬───────────┘
YES ↓ ↓ NO
┌──────────────┐ ┌─────────────────────┐
│ 单轮直接问 │ │ 分阶段执行 │
│ （简单任务） │ │ RED→GREEN→REFACTOR │
└──────────────┘ └─────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ GREEN：获取达标输出 │
│ - AI 生成初稿 │
│ - 人对照 RED 标准逐条检查 │
│ - 不达标 → 具体反馈 → AI修正 → 重新检查 │
│ - 达标 → 进入下一步 │
└─────────────────────────┬───────────────────────────┘
↓
？
┌───────────┴───────────┐
│ 需要优化吗？ │
└───────────┬───────────┘
YES ↓ ↓ NO
┌──────────────┐ ┌─────────────────┐
│ REFACTOR │ │ 完成 │
│ 优化完善 │ │ 交付使用 │
└──────────────┘ └─────────────────┘
↓
人确认满意
↓
┌─────────────┐
│ 完成/交付 │
└─────────────┘
5.2 判断任务复杂度
简单任务（单轮对话）：
- 简单问答（定义、解释、查找）
- 格式转换（JSON转表格等）
- 简短文案（1-2段）
- 快速信息查询
- 简单计算
→ 直接提需求，快速完成
中等复杂度（RED → GREEN）：
- 有明确多条标准的内容
- 有格式要求的输出
- 需要真实信息的研究
- 需要多版本选择
- 简单文案/邮件/消息
→ 标准版 RED + GREEN 验证
高复杂度（RED → GREEN → REFACTOR）：
- 完整方案/文档/报告
- 代码实现和测试
- 系统设计
- 多章节长文
- 需要精修的重要内容
- 决策分析报告
→ 完整三阶段 + 多次迭代
六、快速参考卡
RED 快速模板
帮我做：[任务]
标准：[成功的样子，越具体越好，可带数字]
约束：[不要做的事]
格式：[输出格式]
参考：[参考范例，可选]
GREEN 反馈模板
已收到初稿，对照标准检查：
✅ 满足：
- 第X条标准：[描述]
- 第Y条标准：[描述]
❌ 不满足：
- 第X条标准：原因[具体问题]
请修正：[具体要求]
请修正后重新输出。
REFACTOR 快速模板
基础版本已确认，现在优化：
重点：
1. [优化点1]
2. [优化点2]
约束：
- 不改变核心内容
- 不超出字数范围太多
目标：[具体优化目标]
任务复杂度判断
| 任务类型 | 推荐流程 | |---------|---------| | 简单问答 | 单轮直接问 | | 有明确要求的内容 | RED → GREEN（两轮） | | 复杂方案/文档 | RED → GREEN → REFACTOR（三轮） | | 10页以上长文 | 分章节处理，最后统稿 | | 不确定要什么 | 让 AI 先提建议，确认后再生成 | | 重要内容 | RED → GREEN → REFACTOR → GREEN' → REFACTOR' |
七、FAQ 与常见问题
Q1: RED阶段最重要吗？
是的。 80%的AI对话问题源于RED阶段定义不清。定义清楚成功标准，比生成过程更重要。
Q2: 什么时候应该停止迭代？
- GREEN阶段：所有验收标准都满足时停止
- REFACTOR阶段：达到"超出标准"的程度时停止，不必追求完美
Q3: GREEN阶段允许"作弊"吗？
允许。 AI可以生成最小化满足标准的输出，即使不是最优解。目标是"达标"而非"最优"。
Q4: REFACTOR和GREEN的区别是什么？
| | GREEN | REFACTOR | |---|---|---| | 目标 | 达标 | 更优 | | 能添加新内容吗？ | 可以 | 不可以 | | 能改变核心结论吗？ | 不可以 | 不可以 |
Q5: 如果AI输出完全不达标怎么办？
回到RED阶段，重新定义成功标准。问题往往是标准定义不够清晰，而非AI能力不足。
Q6: 所有任务都需要三阶段吗？
不是。简单任务单轮即可，复杂任务才需要完整的三阶段循环。
八、安全与信任机制
8.1 使用安全
本方法论是纯对话流程，不需要执行任何代码，不涉及网络请求或数据外传。
8.2 信任机制
| 维度 | 说明 | |------|------| | 输入验证 | RED阶段定义的验收标准就是隐性的输入验证 | | 输出验证 | GREEN阶段逐条对照标准检查，确保每条都满足 | | 阶段性确认 | 每个阶段结束前都需要人确认，不达标不进入下一阶段 | | 可回滚 | 任何阶段发现问题都可以回到上一阶段重新来 |
8.3 适用边界
- 适用于文字/代码/分析/方案等软输出任务
- 不适用于需要实时数据或网络请求的任务
- 重要任务建议保留完整的RED→GREEN→REFACTOR记录
版本历史
| 版本 | 日期 | 变更 | |------|------|------| | 2.1.0 | 2026-05-25 | 优化显示名称和描述（SEO优化） | | 2.0.0 | 2026-05-25 | 优化为标准Skill结构，添加完整frontmatter | | 2.0 | 2025-04-27 | 初始版本发布 |
文档版本：2.1.0 更新日期：2026-05-25 核心能力：AI对话TDD方法论