想让 Claude Code 更懂怎么思考、怎么做检查？用 Waza 的时候，不用先盯着全部八个技能，先把 /think 和 /check 这俩用明白就够核心了——前者管开工前把问题捋实、方向掰正，后者管收尾前把结果验清楚。要是中间碰到 bug，再切到 /hunt 就行。

/think 解决“开工太快”

不少 Agent 一接到需求就火急火燎改文件，最大的问题是哪怕方向错了，也能攒出一大堆没用的代码。Waza 里的 /think 就专门治这个毛病：它会先把问题摸清楚，给出推荐方案，还会把风险和验证方法说透。像新功能开发、架构选型、判断需求值不值得做、方案会不会太冗余这类活儿，都适合用它。

/check 解决“收尾太松”

/check 就相当于任务收尾前的工程质量审查。它会盯着代码 diff、项目本身的约束条件、验证结果的实锤，还有发布或者合并前的各种风险。你写完功能之后，可以让 Claude Code 跑一遍 /check，让它结合整个项目的上下文来复查，别就听它一句“看起来没问题”就交差。

为什么要手动串联

Waza 的 README 里写得很明白：各个技能是可以串起来用的，但每一步切换都得你手动触发——/think 出了方案，你点头同意了再开始写代码；代码写完了，再触发 /check 做检查。这么设计是为了不让 Agent 自己闷头从计划一路跑到发布，特别适合对代码质量有要求的开发流程。

一个可复制的节奏

1. 需求没捋清楚的时候，先用 /think，拿到一份能直接落地的计划再动手。
2. 你确认方案没问题了，再让 Agent 去写代码，别赖在 /think 模式里硬写代码。
3. 碰到 bug 或者异常的时候，切到 /hunt，先把根因找着了再修，别瞎改。
4. 功能做完了，用 /check 过一遍代码 diff、测试结果和潜在风险。

Waza 最妙的地方就是把这些动作拆得明明白白。你不用再跟 Claude Code 说什么“认真一点”这种虚头巴脑的话来让它懂开发规范，直接走对应的技能入口，它就会切换到对应的工作模式。思考、排错、审查这几步分开之后，输出的质量自然就更稳了。