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

这一周都在自己的 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 循环

sampeng

57 天前

@Philippa 你说的其实没错，这是降低效率的行为。但是正确率上升了。测试覆盖的还不错，逃不过自己的 review 。我认为这是不可缺少的一步，比不可控的练丹是要强很多的，哐哐哐写一堆没用代码和一次写好代码还是有区别的，我愿意接受慢一点但是整体接受率提升。

还是有细节区别的，我昨天对比过不用 agents 和不用 tdd 。
1.单元测试更详细了，因为有 spec ，可以先仔细 review 单元测试有没错。
2.最后的 tdd 的最后的重构阶段效果让我眼前一亮，因为一直以来困扰我的全自动拉屎得到了缓解，可以看到代码质量在最后重构阶段会大幅度提升。
3.green 阶段不再一口气写一大堆看起来很牛逼但是没卵用的垃圾代码，不对、不是不会，是在大幅度减少，因为 green 阶段是参考单元测试，以单元测试为目标写最小化代码。我经常看到注释里：这个实现先简化，因为单元测试要求只处理 xx 情况。
4.整体流程可控，在 plan 阶段发现不是 tdd 就可以提前取消了，要求严格保证

不过你说的问题是存在的，比如偶尔 skip 掉状态设置，还是提示词没约束好。我也在改进，不要让在 agent 阶段做，让主控在一个循环的前后进行操作，这个可以在 todowriter 里观察到，没有就重来。

慢我觉得慢慢迭代 cc 会解决的，昨天我一直在 debug 观察到底啥慢。还是要官方下场解决更新。但 token 消耗确实很莫名其妙…找原因中…一个可能是 agents 的上下文处理和主控不一样。其实观察 ccusage ，每小时的 token 消耗只是大了 20-30%，但代码生成数也多了 20-30%（因为单元测试更详细，非常的规范）。问题还是出在慢上面。