我在设计一个 mcp ，当前 mcp 是 spec 的一个架子。像这些约束不好处理的，我打算用外部 mcp 来逻辑强制串联来解决。比如 tdd 是标准流程，可以通过 mcp+hooms 来串联强制检查每一步的结果，自动在代码层逻辑上强制设置状态。在考虑咋做 ing…

@Philippa 回车快了…你猜为什么我的提示词里

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

这里在优化和检查要用英文解释？嘿嘿，因为我还有 zen-mcp-server 。这两个字是关键词。重构和检查阶段是由外部的 gemini 和 opus 共同 review 和检查提出想法后嚷 sonnet 来解决的。效果相当可以，每次都能发现一些实现的小问题和 bug

@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%（因为单元测试更详细，非常的规范）。问题还是出在慢上面。

我要知道我会告诉你？

@zqguo 都不用再改，在要求里不让他用子代理。消耗 token 就少一个数量级了。。我也在调查。。这个子代理的 token 消耗多的不能理解。。我 max 都会吃 cd 。但不用子代理。依然进行 TDD 。效果也不差，可能会不稳定。我调查 ing 。。。总的来说是一个思路。。

@Philippa 有一点搞错了。核心并不是上下文，而是 TDD 的流程。
在 agent 看来。1 ，2 ，3 都是上下文。这是很自然的事。如果是我做。就是一个 issues 是总需求，3 个子需求是 1 ，2 ，3 。
这样 tdd 的流程就是

RED 阶段：QA ，知道人和动物的 class 是怎样的，创建人应该预期是什么样，结果是如何。然后针对这个编测试代码。预期失败
GREE 阶段：Developer ，知道人和动物的 class 是怎样的定义的，行为是什么。根据测试代码。编写实际的创建人的代码。
重构阶段：QA 和 Developer 交替优化各自的代码，清理临时函数，拆解大函数，检查是不是真的完成了创建人这样的动作。

这是一个 TDD 循环，再做创建人物的 TDD 循环。最后做人物去摸宠物的 TDD 循环。

你理解的是一个 agent 干所有事，并不是这样的。agent 是把这些需求作为上下文。目的是什么在创建 context 的时候会明确的说明。

我尝试这个流程，搞出奇怪 code 的原因基本是自己上下文没说清楚或者说没有 review 。

AI 是工具，不是魔法。我没打算一个需求給他，就自动 spec+tdd 完事了。这是不可能的，质量没法保障。我要事先 review 上下文的顺序是否合理，内容是否能够指导开发。主控的 prompt 的过程我会先 plan 模式看一眼是不是理解偏差了。

我这只是方法论。我有个暴论，通过一个工具，一个命令，在人完全不参与的情况下就把需求完全实现并且代码质量都极其好的都是吹牛逼。

@zqguo 只能说提供思路了，mcp 是我自己开发的基于 gitlab 进行上下文的传递。可能要找一些 spec 管理的 mcp 吧。

@heiya 个人端部署要啥 redis…也就一个 java+数据库就完事了…

@heiya 还要 windows 个人电脑？这一套下去有啥坑鬼知道啊…这其实就比较难搞了…一般这种都是干脆直接重新开发了。你这套架构就 minio 和 redis 。在单机环境下，都是可以替代的。整半天还不如重新写一份…把这两个替代掉就可以了

如果是非集群部署。最舒服的方式是自己定制 iso 。安装 iso 系统啥就都好了。而且都是一个样。然后这个 iso 的定制做成一个系统能自动构建出来。因为 iso 是不可变的，只要你们 release 了。产生的产品都是一个样。
什么 docker ，ansible ，不是不能用，就是维护比较恶心。。

@mydev6666666 补充一下。其实我试了一下。没上下文也能工作。就是在/tdd 的时候要把上下文说清楚。他这个子任务角色很有意思，会传递你的上下文进行分析后給子代理。但有时候会传递错意思或者丢了意思。。要 ctrl+r 看一眼，因为我大部分重要的任务是 gitlab 来传递上下文，就没这个问题。。。可以看到 prompts 里面很多是告诉他 gitlab 的 issues 的结构

@mydev6666666 两个 agents ，一个是 qa 的角色，一个是 developer 的角色。tdd.md 是一个斜杠命令。可能需要处理一下我这些任务的上下文要有地方来。。没有上下文来源是转不起来的。。全靠有个外部上下文供应

@oudioppa @hihanley

https://gist.github.com/SamPeng87/bcd420be34f84957897637596937d71d

理论上能用，但可能会有点问题，就是我在 prompts 里面强制使用一些我自己定义的 tools 。。。因为上下文都是通过 gitlab 的 issues 来供应的，因为太多了。md 文件其实不是太好管理。。多了就乱套了

但用了几天，确实已经能够标准的 TDD 流程运转了。。只不过。。是个 token 怪物。因为从逻辑上来说是每个函数的接口的新增，修改，都自动是干净的上下文，要重新获取上下文。但是效果确实还可以。中间有问题你停下来，也能理解继续调度正确的子任务去干活

@oudioppa 有道理

不怕坏人灵机一动，就怕蠢人灵机一动…这句话在赛博世界也是有效的。

你是说 wsl 下？还是 windows 原生下？ wsl 是因为 ntfs 的缘故…原生好像没碰到过…

实现 TDD 。最小单元是函数，以红-绿-重构优化为一个循环。15 分钟一个接口。但前期准备要 2-3 小时，后面还要 review 最少得 10-15 分钟？其实整体效率并没提升，但让我用 tdd 完全实现一套功能。每 2-3 天我都搞不完。。。

所以一定需要 plan…看一眼他怎么做…全自动的拉屎会被坑死的…

去年年底我也是这样。。每周必崩。重装也不行。。把 docker 干掉就一切正常了。。