iterative-development

iterative-development 技能概览

什么是 iterative-development

iterative-development skill 是一种 Claude Code 工作流：每次模型回应后都会运行测试，并通过 Stop hook 把失败结果自动反馈回来。它最适合你想要比普通提示词更紧的 TDD 循环，尤其适用于那种每一轮都应该先验证、再结束对话的功能开发场景。

适合谁安装

这个 iterative-development skill 适合已经依赖测试、lint 或类型检查的开发者，希望 Claude 一直待在修正循环里，直到这些检查全部通过。它也很适合 Workflow Automation 这类配置；但如果你的项目没有稳定可靠的测试命令，或者你更习惯在每次回答后手动审查，那它的价值就会明显下降。

它在实践中的意义

它的核心价值不是“提示词更强”，而是缩小代码生成和验证之间的距离。这个 skill 会让 Claude 直接响应真实失败，从而更早发现错误假设，避免一次性实现，并让每轮迭代始终围绕你这个仓库真正会拒绝的内容展开。

如何使用 iterative-development 技能

安装并定位工作流文件

按照 iterative-development install 的仓库安装流程操作，然后先打开 SKILL.md。这个 skill 没有辅助脚本，也没有额外的子目录，所以它的运行逻辑几乎都集中在这一个文件里。如果你想最快理解它，先读 SKILL.md，再看其他内容。

先写一个可验证的任务说明

iterative-development usage 这种模式最有效的前提，是你的提示词明确写出目标结果、相关文件，以及你希望循环执行的验证命令。一个好的说明会像这样：“在 src/auth/ 里添加密码重置校验，保持现有 API 形状不变，并在每轮后运行 npm test 和 npm run lint。”这比“改进 auth”更好，因为 hook 需要一个可确定、可验证的目标。

在依赖它之前先读 hook 逻辑

做 iterative-development guide 时，重点看解释 Stop hook 如何退出、stderr 如何回传给 Claude，以及每一轮 TDD 循环检查什么的部分。正是这些内容决定了工作流到底是在持续迭代，还是只是在命令失败后就直接停住。如果仓库里还有 Python 版本，先和你的 shell 方案对比，再考虑把它直接搬到别的环境里。

只在验证成本低、结果稳定的场景使用

最适合它的输入，是反馈快的任务：单元测试、lint 规则、类型检查，或者规模较小的集成测试套件。不要把它用在模糊的调研任务、没有可重复命令的一次性排错，或者结果无法用明确检查来判断对错的项目上。

iterative-development 技能 FAQ

iterative-development 只适合 TDD 吗？

不是。它确实很适合 TDD，但真正的前提是有一个可重复的验证命令，而且它能快速失败，并告诉 Claude 需要修什么。只要这个循环有清晰的通过/失败信号，你也可以拿它做代码修改、重构和清理工作。

它和普通提示词有什么不同？

普通提示词可能只产出一次代码，验证要你自己来做。iterative-development skill 则加入了自动停止和修复的循环，所以 Claude 会立刻看到测试失败，并在会话结束前修正它们。这让它比泛泛的“也顺手写测试”指令更适合 Workflow Automation。

它适合新手吗？

如果你已经会运行测试、也会看失败信息，那答案是适合。若你还在熟悉项目工具链，它就没那么适合，因为这个 skill 默认你能判断哪个检查命令可信，以及它为什么失败。

什么时候不该用它？

当项目的测试不稳定、端到端检查很慢，或者命令会产生很多与代码改动无关的噪音失败时，不建议使用。在这些情况下，这个循环可能只是在浪费时间，甚至把 Claude 卡在重复修复里，而不是收敛到真正的解决方案。

如何改进 iterative-development 技能

给循环加更明确的约束

质量提升最大的一步，是一开始就把准确的命令、文件和验收标准说清楚。不要只说“让它能用”，而要说明哪些必须通过、哪些不能改、以及哪一种失败应当被视为决定性信号。这样 iterative-development skill 才更可能收敛到正确修复，而不是四处游走。

让失败更容易被理解

如果测试输出很长、很不稳定，或者歧义很多，Claude 得到的反馈就会变弱。要改进这个 skill，可以缩短验证路径、把失败命令单独拎出来，并尽量压缩错误面。一个简洁明确的失败测试，比三个互相干扰、原因各不相同的宽泛检查更有用。

第一轮之后继续迭代提示词

如果第一次输出已经接近正确，但还差一点，就把那个差距直接补进提示词里：比如“tests pass, but the hook should also run npm run typecheck”，或者“保持对外 API 稳定，只改内部实现”。这比从头再问一遍更好，因为这个 skill 最有效的方式，就是每一轮只增加一个精确约束。

注意会打断循环的错误

常见问题包括：使用了一个永远不能干净退出的命令、要求无法自动验证的目标，或者漏掉了仓库真正的测试入口。如果循环看起来卡住了，就把任务简化，给 Claude 指向权威测试命令，并确认 Stop hook 的配置确实会通过 stderr 回传失败结果。