我宣布， CC 目前最佳使用方式是 Spec+Agents+TDD

2025 年 7 月 31 日
 sampeng

这一周都在自己的 mcp 上尝试各种开发方法。

最终结论是 Spec 先定义好需求，实现计划，然后进行 TDD 是最舒服，成功率最高的方式。

之前我实现了一个 gitlab 的 Spec 的 mcp ，但是还是不得劲，单元测试瞎写，纯炼丹。就是属于那种他过不去就自己改单元测试，或者单元测试写一大堆但是重复的不少。最主要的问题是上下文问题。claude code 在使用 Spec 的开发模式进行开发的时候非常容易触发压缩。尤其是对于大一点的 Spec 。压缩带来的问题更严重，随机的丢失上下文。这是一件非常麻烦的事。

这周发布的 agents ，让我眼前一亮，因为上下文隔离就可以很好的避免上下文污染。

我测试了 3 天，完全是可行的。QA 的 agents 只负责单元测试的修改。Developer 的 agents 只负责代码的编写保证单元测试通过。最后的重构和优化阶段非常重要，我调试了很多次才搞定。也就是形成 Red-Green-Refactor 的完整流程。一开始我没觉得最后的阶段有用，真的实现和跑了一些复杂接口实现的时候这玩意就有用了。不会一直拉屎拉到无法看懂。我要求他重构的时候把不用的清理掉，大函数拆解，发现重构机会。但当然还是有点问题，10 次里有 1 次没聚焦到这次的修改范围，目前把上下文在 prompt 里补充了好像还行。

prompt

please think hard about, 请读取 issues $ARGUMENTS 的详情，你会得到一个任务树;

你不得实现任何业务，应该调度角色来完成

## 名词理解
**业务实现计划**
指定的 $ARGUMENTS 是业务实现计划的 issue ID ，包含了业务实现的详细步骤和文件修改计划。

**单元测试计划**
查看 `$ARGUMENTS` 的详情，你会得到一个任务树,link 中的 labels 含有`type::Testing`的 issue 是单元测试计划的 issue ID ，包含了单元测试的详细步骤和文件修改计划。

**使用子任务尽可能的并行的分析和拆解 TDD 循环列表**

子任务中 link 的 label 为`type::TDD-interface`的 issue 是以接口为单位的 TDD 工作大纲。
读取 tdd-interface 的子任务的 label 为`type::TDD`的 issue 是 TDD 工作流中的具体的 TDD 循环任务
请创建和使用子代理来并行的调查 TDD 循环的列表。子任务中 link 的 label 为`type::TDD-interface`的 issue 是以接口为单位的 TDD 工作大纲,TDD 工作大纲的子任务的 label 为`type::TDD`,并且状态为 open 的 issue 是 TDD 工作流中的具体的 TDD 循环任务。
  - 每开始一个 TDD 循环，必须先设置 tdd 循环任务状态为`inprogress`，使用`gitlab-issues-workflow-status(issue_id="", status="inprogress")`。
  - 每完成一个 TDD 循环的步骤，必须设置 tdd 循环任务中的 AC 对应步骤为 checked 。
    - 完成 RED 阶段，设置 TDD 循环任务中的 AC 的 RED 步骤为 checked
    - 完成 GREEN 阶段，设置 TDD 循环任务中的 AC 的 GREEN 步骤为 checked
    - 完成 REFACTOR 阶段，设置 TDD 循环任务中的 AC 的 REFACTOR 步骤为 checked
  - 每完成一个 TDD 循环，必须检查 tdd 循环任务的 AC 是否完全满足，使用`gitlab-issues-workflow-status(issue_id="", status="done")`将任务状态改为`done`。
  - 分析和检查 AC 的步骤一步完成了哪一步没完成。

对 TDD 循环列表创建 todowriter 列表，每一项就是 TDD 的一个循环,tdd 循环来源于子任务的调查结果。

### TDD 工作流的阶段

**角色定义**：

**QA**: `tdd-qa-partner`子代理角色负责实现单元测试,只允许实现测试代码，不允许修改业务代码。
**Developer**: `tdd-code-implementer`子代理角色角色负责实现业务代码,只允许实现业务代码，不允许修改测试代码。


### TDD 循环
**Workflow Guidance**：

- **第一**让`tdd-code-implementer`基于设计文档的接口定义，实现最小的接口或者 struct 定义,要确保 make test 是能通过的。
- tdd 以接口为单位进行迭代开发，每个接口都经过严格的测试驱动开发（ TDD ）流程,确保每个接口都经过 Red-Green-Refactor 的完整流程。
- 要告知角色，只做一个阶段的事，不允许做任何其他阶段的工作。
- 避免一次性创建所有接口，专注于一个功能一个功能地 TDD 循环，确保每个功能都经过测试和验证。
  - 严格检查每个 Phase 的 TDD 循环的 Red ，Green 和 Refactor 阶段是否都做了。不能跳过任何阶段。
  - 不是 QA 和 Developer 的任何独立完成的任务，是描述的 Phase 的 TDD 循环。
  - 确保都做过步骤 Red→Green→Refactor
  - QA 和 Developer 角色需要紧密协作，交替按照 TDD 循环进行红绿优化循环。
  - 每个循环步骤都务必聚焦于设计需求和测试需求所涉及的文件和代码，**不得擅自修改和优化其他的代码文件**
  - QA 和 Developer 都不是一次性完成他们的工作，而是一个接口一个接口的去进行实现和测试。
  - 每次 QA 和 Developer 开始的时候，你**必须把设计文档和测试文档的 issues id 以及 TDD 循环迭代給到子代理角色**，并让子代理角色先自己去分析和理解上下文。
- 在一个循环完整结束后，在需求设计的 issues 上使用`gitlab-workitem-create-note(issue_id="", description="TDD 循环完成，进入下一个循环")` 添加进度笔记，记录当前循环的完成情况。
- QA 和 Developer 除了在 TDD 循环中使用绝对不会自行去实现实现计划的接口和单元测试任务。

#### Phase 0: Ready for TDD,
1. 只定义即将测试的一个方法（如 AddLabel ）
2. 创建必要的数据结构

#### Phase 1: **TDD 循环**
每次 QA 和 Developer 开始的时候，你**必须把设计文档、测试文档和 TDD 循环迭代的 issuesID 給到子代理角色**，并让子代理角色先自己去分析和理解上下文。
1. Red: QA(`tdd-qa-partner`) 为接口编写失败测试
2. Green: Developer(`tdd-code-implementer`) 实现最小代码让测试通过
3. Refactor: QA(`tdd-qa-partner`)和 Developer(`tdd-code-implementer`)，都需要检查(codereview)和优化(refactor)在这个循环中自己修改过的代码,重构不需要考虑向下兼容，务必一次性改成最正确的实现,为了避免代码修改冲突，交替进行重构和协调。不能并行执行

#### Phase 2: 逐步扩展
1. 添加下一个方法到接口
2. 重复 TDD 循环
 
#### **phase 分解的例子**
分解的任务必须严格按照 TDD 循环的步骤进行，确保每个方法都经过 Red-Green-Refactor 的完整流程。

⏺ Update Todos ☒ Phase 0: Ready for TDD - 创建最小接口定义，确保 make test 通过
☒ TDD 循环 1: ContentBlockHelper.GetAcceptanceCriteria() - Red→Green→Refactor ☒ TDD 循环 2: ContentBlockHelper.SetAcceptanceCriteria() - Red→Green→Refactor ☐ TDD 循环 3: ContentBlockHelper.GetImplementationPlan() - Red→Green→Refactor ☐ TDD 循环 4: ContentBlockHelper.SetImplementationPlan() - Red→Green→Refactor ☐ TDD 循环 5: IssuesManager.SetAcceptanceCriteria()编排逻辑 - Red→Green→Refactor ☐ TDD 循环 6: IssuesManager.AddLabel()去重逻辑 - Red→Green→Refactor



##### TDD 工作流的重构阶段
QA 负责：
- 重构测试代码（提取测试辅助函数、优化测试数据设置）
- 确保测试仍然验证正确的业务逻辑
- 检查测试覆盖率是否受影响
- 验证重构后测试仍然能发现潜在 bug
- 发现的改进机会都必须在重构阶段处理，不得延后到下一个 TDD 循环

Developer 负责：
- 重构实现代码（提取小函数、优化算法、改善命名）
- 确保代码结构更清晰
- 优化性能（在不改变行为的前提下）
- 处理代码重复和设计改进
- 发现的改进机会都必须在重构阶段处理，不得延后到下一个 TDD 循环


共同协作：
- 讨论接口设计是否需要调整
- 确保测试和实现的重构方向一致
- 运行完整测试套件验证重构成功
- 代码审查确保质量

实际操作流程：
重构阶段开始：
├─ QA：重构测试代码，保持测试意图不变
├─ Developer：重构实现代码，保持行为不变
├─ 协作：运行测试确保全部通过
├─ 协作：代码审查和讨论
└─ 提交重构后的代码，进入下一个 TDD 循环
3247 次点击
所在节点    程序员
29 条回复
sampeng
2025 年 8 月 2 日
@Philippa 回车快了…你猜为什么我的提示词里

Refactor: QA(`tdd-qa-partner`)和 Developer(`tdd-code-implementer`)，都需要检查(codereview)和优化(refactor)在这个循环中自己修改过的代码,重构不需要考虑向下兼容，务必一次性改成最正确的实现,为了避免代码修改冲突，交替进行重构和协调。不能并行执行

这里在优化和检查要用英文解释？嘿嘿，因为我还有 zen-mcp-server 。这两个字是关键词。重构和检查阶段是由外部的 gemini 和 opus 共同 review 和检查提出想法后嚷 sonnet 来解决的。效果相当可以，每次都能发现一些实现的小问题和 bug
sampeng
2025 年 8 月 2 日
我在设计一个 mcp ，当前 mcp 是 spec 的一个架子。像这些约束不好处理的，我打算用外部 mcp 来逻辑强制串联来解决。比如 tdd 是标准流程，可以通过 mcp+hooms 来串联强制检查每一步的结果，自动在代码层逻辑上强制设置状态。在考虑咋做 ing…
lthon
2025 年 8 月 2 日
code 跑测试真的好耗 token
JasperHale
2025 年 8 月 24 日
鄙人, 改 RIPER5 -> RIP-TDD-R 效果上佳.. 唯耗时...😂..

借楼请赐教, @sampeng 是怎么解决 运行时间过长问题的?
- red-green-r 无法并行化, cc 一次仅运行一个同名的 subagent..
- 昨天一夜上, 只完成了 3 个 red-green-r 循环....
sampeng
2025 年 8 月 24 日
@JasperHale 耗时可以试试把 node 的 heap 调大点。他这个大 json 会经常拉住。会好一点，但还是卡…我打算自己写和调度坐 red-green-r 。主线程明显快很多。
JasperHale
2025 年 8 月 24 日
@sampeng 鄙人余暇时光尝, cc 可拉起多个同质 subagent = 并行多个 R-G-R 循环, 限制并行 3, 效果尚可.
JasperHale
2025 年 9 月 4 日
https://github.com/Jasper-1024/DPTR-SIGMA
CC 多个 subagent (同一个 subagent 也可并行) 并行供参考;
最主要的是: PARALLEL EXECUTION: For |cycles| instances, invoke Task tool |cycles| times in ONE message. Example: [Ω₃ᵍ×|cycles|] where cycles={1,2} requires 2 Task invocations in the same message.
要求 CC 在一个 mes 中有几个 subagent 就调用几次 task 工具
aulaia
2025 年 9 月 9 日
@JasperHale 兄台妙啊，仓库我看了，如何运行起来呢？没太看懂你的设计思路
JasperHale
2025 年 9 月 16 日
@aulaia 此仓库还在修缮中,鄙人不才,至今还有 bug.
原理: 原楼主仓库中制定计划提示词提取为独立 subagent,要求识别无互相依赖 r-g-r 循环,编纂一个批次.
同一批次,方执行时一次回答时 多次 invoke task, 此效果如下, 1msg 一行
r1 r2 r3
g1 g2 g3
r1 r1 g3
g1 跳过 g3
r1 跳过 跳过
g2 跳过 跳过
完成

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.xtra.eu.org/t/1149022

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX