@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 干掉就一切正常了。。

如果这个工具可以设置使用哪个模型就更好了

有没一个可能，我是说可能啊。问的是性能优化，其实是在看候选人有没简历造假？所有业务都可以背，leecode 可以背，只有这种开放式的问题考察你思维方式和解决问题的能力啊。25k 招个 curd boy ？小小厂也不是傻子啊

都没明白一个问题…claude code 是真的是最牛逼吗？不是哦。cline 已经很好用了，问题出在哪？ pro/max 啊。按 token 算，就没扛得住的…

@hackroad 其实这应该是研发协助处理的。研发应该提供工具能够随意替换不同版本的资源。因为测试方便了，研发的工作也自然有更好的兜底，这是相辅相成的事。况且研发是完全有能力做的，就看愿不愿意投入了，这要看研发老大的想法。其实和小兵没啥关系。投不投入资源小兵说了不算，做多了测试部嫌管闲事，老大也不乐意资源投入其他地方。如果你是 leader ，应该和测试老大讨论，然后上升到你们的老大。如果你是小兵，虽然你看见了，但不要动手做，直接找老大说你想优化，能提升 xxxx 。我不认为这是卷，一向认为，测试方便了，我写代码就更放飞自我了。。