do-in-steps

do-in-steps 技能概览

do-in-steps 技能帮助 agent 处理复杂工作：把任务拆成有顺序的子任务，按步骤依次执行，并在进入下一步前验证每一步是否达标。它最适合存在依赖关系、涉及多个文件或系统，或者如果不逐阶段检查就很容易出现“静默失败”的场景。

这个 do-in-steps 技能尤其适合仓库改动、多步骤重构、迁移工作、agent 编排，以及任何你希望减少假设、让步骤之间交接更受控的任务。它最核心的区别在于内置的 meta-judge → LLM-as-a-judge 流程，会在执行和推进之间加一道质量闸门。

这个 do-in-steps 技能适合做什么

当任务不能安全地一次做完，而且每一步的结果都应该影响下一步时，就该用 do-in-steps。它的设计目标是保持上下文紧凑、顺序清晰，并在复杂执行过程中减少连锁错误。

它为什么更突出

和那种只会说“按步骤思考”的通用提示词不同，do-in-steps 是一个面向 Agent Orchestration 的工作流技能。它强调任务拆解、按子任务选择模型、上下文传递和独立验证，因此更适合较长的任务，也更可靠。

适合哪些读者

这份 do-in-steps 指南更适合在代码库上工作的 agent、自动化脚本作者，或者需要结构化执行而不是创意发散的用户。如果你要的是一个带有每步检查的编排计划，它比单轮提示词更合适。

如何使用 do-in-steps 技能

安装并加载技能

对于 do-in-steps install，先从你所在环境使用的仓库路径添加该技能，然后把 SKILL.md 作为主要指令来源加载进来。在这个仓库里，技能位于 plugins/sadd/skills/do-in-steps，所以关键是在开始工作前，把技能文件放进 agent 的活动技能集合里。

把模糊目标变成可执行输入

do-in-steps usage 模式在你的提示词包含目标、目标仓库或系统、约束条件和预期完成标准时效果最好。高质量输入要写清交付物和高风险部分，而不只是主题。

更强的示例提示词：
Refactor UserService to remove duplicated validation, update all callers, keep public APIs stable, and verify behavior with tests.
这比下面这句更好：
Improve the service layer.

先阅读这些文件

先看 SKILL.md，理解编排逻辑；如果你的安装方式会暴露更多引用内容，再检查相关项目文档或相邻的技能文件。在这个仓库里，没有配套的 rules/、resources/ 或 scripts/ 文件夹，所以技能文件本身承担了大部分操作指引。

按有序阶段执行

把这个技能当成一个顺序工作流来用：先分析任务、拆分依赖、执行第一步、验证结果，然后只把与下一步相关的上下文继续传递下去。质量提升来自于保留步骤边界，而不是让后续工作偏离前面的决策。

do-in-steps 技能常见问题

do-in-steps 比普通提示词更好吗？

是的，尤其是任务存在依赖关系，或者需要在步骤之间做验证时。普通提示词适合小任务，但当你需要受控编排、按子任务选模型、并尽量减少隐藏失败时，do-in-steps 更合适。

什么时候不该用它？

不要把 do-in-steps 用在简单修改、一次性问题，或者直接回答就足够的任务上。只有当顺序控制和验证确实能显著改善结果时，这种编排开销才值得。

它适合新手吗？

适合，只要你能把任务描述清楚。主要学习成本在于：为任务拆解提供足够上下文，并接受工作流可能会在继续前要求中间证据。

它和 Agent Orchestration 怎么结合？

它就是为 do-in-steps for Agent Orchestration 明确设计的：由一个 supervisor 协调多个专门子 agent，将摘要向前传递，并使用独立 judge 来降低步骤级错误。这让它在多 agent 编码或运维工作流里尤其有用。

如何改进 do-in-steps 技能

给它更清晰的边界

提升 do-in-steps 效果最快的方法，是明确哪些内容不能改、哪些内容必须验证，以及最终输出应该长什么样。清晰的约束能帮助 orchestrator 选对子任务，也能减少返工。

提供会影响决策的上下文

如果你想要更强的输出，最好一开始就给出受影响文件、目标环境、测试预期和任何兼容性要求。这个技能在能基于真实约束进行拆解时表现最好，而不是等到后面再去猜。

留意常见失败模式

最大的风险是任务定义得不够具体，这会导致拆解无力或验证流于表面。另一种失败模式是把第一步塞进太多上下文；更好的做法是先给出足够信息让它定计划，然后让每个子任务只继承自己需要的内容。

在第一次执行后继续迭代

如果第一次结果已经接近目标，但还不完整，就用具体缺口来细化任务：缺少测试、依赖顺序不清楚，或者变更边界还不够宽。对 do-in-steps 来说，提升通常来自更好的任务 framing，而不是要求它多写几句话。