如何先写失败测试再修 Bugpstack TDD 技能完整流程指南【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Potetos pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude 今天带你认识pstack里的tdd 技能——这是 pstack-claude 项目中一套让 AI 代理先写出失败测试、确认它红了、再动手修 bug、最后看它变绿的 TDD 完整流程。pstack 是 Poteto 风格的 AI 代理工作流技能栈支持 Claude Code、Codex、Copilot、Pi 等多个运行环境而/tdd命令正是其中修 bug 场景下最有科学味的一环不猜测、不侥幸每一步都有可复现的证据。为什么 AI 修 bug 要先写失败测试用 AI 代理修 bug 时最容易踩的坑是改完代码说应该好了却没有证据证明它真的好过。pstack 的 tdd 技能把 TDD 经典节奏固化成了给 AI 的指令文件tdd/SKILL.md目标是写一个聚焦的回归测试——修复前它必须失败修复后它必须通过。这样做有三个直接好处✅红绿证据先看到测试为红失败原因正确修完再看到变绿证明修复真正生效而不是碰巧跑通了。✅防回归这个测试留在代码库里将来同一处 bug 再出现会被立刻抓住。✅测试测的是行为测试编码的是期望行为而不是照着当前错误的实现去镜像——这点由配套的 principle-test-behavior-not-implementation 原则保证。tdd 技能什么时候会被触发技能的 frontmatter 里写得很明确见 SKILL.md 第 2–3 行你明确要求TDD、要一个失败测试或回归测试时或者这个 bug 存在一条明显的、便宜的本地测试路径时。反过来如果测试路径不清楚、成本很高需要大量 mock、慢速端到端基建、生产环境状态它会主动跳过改用最接近的可执行验证——比如针对性脚本、手动复现命令、日志断言等。这是它和为了 TDD 而 TDD的最大区别宁可没有新测试也不要一个坏测试。完整六步流程从理解 bug 到交付证据以下是 tdd 技能规定的标准工作流原文见 tdd/SKILL.md 的 Workflow 一节步骤做什么关键点1️⃣ 理解 bug弄清期望行为、当前行为、受影响路径找到最小的可观察复现2️⃣ 选最窄的可执行检查优先复用该代码路径已有的单元/组件/集成/回归测试没有现成路径就别硬造3️⃣ 先写失败测试写一个当初能抓住这个 bug的最小测试编码期望行为不镜像实现4️⃣ 修复前先跑测试确认它因正确的原因而失败要引用失败现场而非只引用断言行5️⃣ 修 bug做满足期望行为的最小生产代码改动保留邻近契约6️⃣ 重跑回归测试确认测试变绿完成红绿闭环其中第 4 步有个很细的要求引用失败内容本身异常、空结果、不匹配的预测值而不是只看断言那一行——只有预测值 vs 实际值的 diff 才真正证明这个测试度量到了 bug。与 Bug Fix 剧本的协作方式tdd 技能不是孤立存在的它嵌入了 poteto-mode 的Bug fix 剧本bug-fix.md。完整修 bug 的剧本是复现 → 二分定位根因 → 规划修复跨函数边界先过 architect→ 在同一界面验证 →提交阶段安排失败复现先于修复进入 git 历史→ 开 PR。其中第 5 步直接引用了 tdd 技能把提交排成失败复现在前、修复在后的顺序。当 bug 有便宜的本地测试路径时遵循 tdd 技能先失败测试的节奏测试昂贵、偏集成或不明确时则跳过。这个失败测试在前、修复在后的提交顺序对应 pstack 的原则技能 principle-sequence-verifiable-units把工作拆成一个个可验证的小单元交付顺序本身就是一段论证——评审者能亲眼看到先红、后绿把相信我变成看着它变绿。护栏tdd 技能明令禁止的做法技能的 Guardrails 一节划出了清晰边界 不要为了让测试通过而去改测试迁就错误实现 不要削弱既有断言除非期望行为确实变了且理由清楚 回归测试要聚焦这个 bug避免牵动大量无关 fixture bug 是 flaky 的尽量让测试确定性并记录锁住的信号是什么。最后一步交付的是证据不只是结果tdd 技能还规定了最终回复的格式Final Response 一节报告证据而不只是结论——说出修复前失败的测试名引用它产生的失败现场裁剪到 diff说出修复后通过的那次运行以及顺带做过的邻近验证如果无法演示修复前失败说明为什么以及实际用了哪种最接近的回归检查。配套的 poteto-help 菜谱 里还给了一个现成的组合提示词Bug with a cheap test:/poteto-mode repro bug first. if theres a cheap test path, /tdd it. then fix and rerun.也就是说先让 poteto-mode 复现 bug有便宜测试路径就走/tdd然后修复并重跑——一套标准的 AI 修 bug 流水线。快速上手与延伸阅读安装 pstack按 README.md 中对应运行环境的说明安装Claude Code、Codex、Pi、GitHub Copilot 均有方式调用技能在 Claude Code 中使用/pstack:tddPi 用/skill:tdd或直接说帮我用 TDD 修这个 bug完整命令表58 个技能目录的斜杠命令对照见 docs/reference.md技能源码树所有技能定义位于 plugins/pstack/skills/tdd 技能全文仅 40 余行建议通读一遍。 一句话总结pstack 的 tdd 技能不是教 AI 背 TDD 口号而是把红-绿-提交顺序-证据汇报整套可验证节奏写进了工作流——这正是 AI 修 bug 从碰运气走向可审计的关键一步。【免费下载链接】pstack-claudeClaude Code, Codex, Copilot, Pi, OpenCode, Gemini, and Prime Agent versions of Potetos pstack. Rigorous agent workflows with Cursor primitives translated for other harnesses.项目地址: https://gitcode.com/GitHub_Trending/ps/pstack-claude创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考