关注「索引目录」公众号，获取更多干货。
Claude Code 是我合作过的最快的程序员。他能在几分钟内搭建出一个功能框架、编写测试并提交 PR。但我一直遇到同样的问题：代码一开始运行正常，然后就失效了。
状态转换中的竞态条件。本应为常量的硬编码字符串。回滚了本应保留的审计记录的事务。断言了错误值true而非正确值。
修复速度总是很快。但每次修复都会带来一些后续问题：事故、回归、以及“为什么我们没发现这个问题？”的反思。修复速度很快，但扣除漏洞后，净修复速度却不高。
即便有了不错的表现CLAUDE.md，我仍然需要时刻关注每一个环节。这次可别忘了TDD（测试驱动开发）。嘿，你忘了检查Bug Bot了。你能在提交PR之前先运行一下测试吗？每一次提示都像是在和一个才华横溢却记忆力堪比金鱼的人对话。问题不在于Claude的能力，而在于那些写在Markdown文件里的好习惯并不会自动变成习惯。我就是流程本身。这意味着流程本身不稳定、容易遗忘，而且越来越令人恼火。
所以我尝试了不同的方法。我没有修改克劳德的输出结果，而是改变了克劳德的思维方式。
问题不在于智力，而在于处理方法。
观察一下初级开发人员的工作：他们阅读工单，打开文件，开始打字。他们速度很快。但他们也常常忘记检查自己调用的方法是否存在，或者引用的数据库列是否在三周前被重命名过。（它三周前就被重命名了。永远都是三周前。）
现在观察一下资深开发人员：他们会阅读问题单，阅读相关的代码，阅读测试用例，查看 Git 历史记录，然后才开始编写代码。他们启动速度较慢，但完成速度更快，因为他们无需回头修复自己造成的错误。
Claude Code 默认处于初级模式。这并非因为它缺乏知识，而是因为它缺乏流程。它没有内部检查清单来告诉它验证假设、先编写测试，或者思考当两个请求同时访问同一个端点时会发生什么。它热情满满，直接发布。但事实证明，热情并不能解决可为空日期时间类型的崩溃问题。
那份清单是我制定的。
介绍/wizard
/wizard是 Claude Code 的一项技能，它是一个 Markdown 文件，存在于你的项目中，并在你/wizard通过命令行界面 (CLI) 输入命令时激活。它能将 Claude 从一名快速编码者转变为一名严谨的软件架构师。你可以把它想象成一位资深工程师在 Claude 身后指导，只不过这位资深工程师永远不会问你是否尝试过重启它。
这是一个八阶段方法论，最好在以下几个前提下进行：CLAUDE.md定义项目规范、在工作开始前创建 GitHub issue（/wizard我可以帮助您创建 issue）、真正致力于 TDD，以及为每个任务创建一个干净的特性分支。对于持续集成 (CI)，我使用 GitHub Actions，但该技能本身并不在意。它只需要在第 8 阶段有内容可以响应即可。稍后会详细介绍。
以下是这 8 个阶段的运作方式。
第一阶段：动手之前先做好计划
Claude 会读取你的文档CLAUDE.md，找到关联的 GitHub 问题，并在编写任何代码之前构建一个结构化的待办事项列表。它会评估复杂性：可能受影响的文件数量、是否存在架构影响、可能出现的问题数量等等。然后，它会据此调整工作量。
这听起来显而易见，也确实显而易见。但这恰恰是你在匆忙之中最容易忽略的步骤，而这恰恰是你最需要它的时候。真是讽刺。
第二阶段：先探索再做假设
制定好计划后，克劳德开始探索实际的代码库。他使用 grep 命令查找打算使用的每一个模型、方法、关系和常量，并在代码中引用它们之前验证它们是否存在。
如果没有第二阶段，克劳德可能会自信地称之为user.clientProfile.accounts它凭空臆想出来的关系链，而且深信不疑。第二阶段的存在正是为了防止这种情况发生。仅仅这一改动就消除了我项目中一整类错误。事实证明，在基于现有基础进行开发之前，“这真的存在吗？”是一个非常值得提出的问题。
第三阶段：先编写测试用例
第三阶段强制执行测试驱动开发（TDD）。克劳德编写会失败的测试用例，运行它们（它们必须失败），实现使测试通过所需的最小代码量，然后进行验证。每次都按这个顺序进行，没有任何捷径。
但关键在于：它采用了变异测试的思维方式。它不是简单地assert($result)写成`$($($($($($($($($($($($($($($($($(($(($(( ))))))))))) ) ` ...assertEquals('completed', $result->status)
区别至关重要。assert(true)如果代码什么都不做，断言就会通过。而抗变异断言才能捕获真正的 bug。你的测试套件应该像个怀疑论者，而不是那种不看代码就告诉你 PR 看起来很棒的朋友。
第四阶段：实施最低限度
在测试失败的情况下，克劳德开始编写实现代码。他没有实现完整的愿景，也没有采用脑海中早已构思好的巧妙抽象，而只是编写了通过测试所需的最少代码。范围蔓延也是一种缺陷，而且是最昂贵的缺陷，因为它看起来像是在取得进展。
第五阶段：验证是否出现任何退化
第五阶段运行的是更广泛的测试套件，而不仅仅是新增的测试。目标是零回归错误。如果出现其他无关的问题，现在发现总比在 PR 审核评论中问“呃，为什么计费模块会出错？”要好得多。
第六阶段：趁热打铁，记录背景信息
内联注释、变更日志条目，以及任何需要更新的内容。这虽是小步骤，容易被忽略，但总值得在上下文消失之前完成。三个月后，下一个阅读这段代码的人可能就是你自己，盯着它却完全想不起来当初为什么会做出这样的决定。
第七阶段：对抗性审查
这就是/wizard它发挥作用的地方。每次提交代码之前，Claude 都会以攻击者的身份，而不是作者的身份，来审查自己的代码。检查清单如下：
-
如果这段代码同时运行两次会发生什么？ -
如果输入为空呢？或者为负数呢？ -
我有哪些假设可能是错误的？ -
如果生产过程中出现故障，我会感到尴尬吗？
这并非理论上的。在我的代码库中，这个阶段确实出现了问题：
-
一个缺少数据库锁定的状态转换服务。两个并发的 API 调用可能会应用冲突的转换。这种竞态条件就潜伏在那里，静静地等待着灾难的发生。 -
一个 Blade 模板调用 ->format()了一个可为空的日期时间字段。当该字段为空时，页面加载时会崩溃。崩溃前完全没有反应，直到该字段不为空为止。 -
通知负载使用了硬编码的类别字符串，而不是在同一个 PR 中创建的枚举类型。真是令人震惊。
单靠测试是无法发现这些问题的。这需要我们换个角度思考代码：像攻击者一样，而不是像作者一样。
第八阶段：质量门控周期
第 8 阶段负责 PR 的整个生命周期。/wizard它并非只是打开 PR 就认为任务完成，而是会监控自动审核机器人（例如 Bug Bot、CodeRabbit 等）的状态，读取每条发现的问题，修复有效问题，回复误报，并重复此过程，直到 PR 状态为“已清理”。
以前我需要手动完成这个步骤，但经常忘记，导致 PR 的机器人检测结果一直未解决，一放就是好几天。现在它已经成为流程的一部分了，这才是它原本应该在的位置。
一个真实的例子
以下是实际任务中所有 8 个阶段的示例：实现带有通知功能的 ACAT 传输状态跟踪。
第一阶段：Claude 阅读CLAUDE.md，找到 GitHub 问题，将任务评估为“复杂”（7 个以上文件，架构影响），并创建待办事项列表。
第二阶段：Claude 使用 grep 命令查找AcatTransfer模型，验证VALID_TRANSITIONS常量是否存在，检查其ClientProfile关系是否正确，并确认NotificationCategory枚举类型。没有出现任何错误的方法链。一切正常。
第三阶段：克劳德编写了 23 个失败的测试用例，涵盖状态转换、通知、命令行为和仪表盘渲染。运行这些测试用例。全部失败。很好。这就是目的。
第四阶段：Claude 实现了服务、命令、5 个通知类、控制器更改和 Blade 模板。运行测试。全部通过。
第五阶段：运行所有相关的测试套件（49 个测试）。未发现任何回归问题。
阶段 6：更新变更日志并向过渡服务添加内联注释。
第七阶段：对抗性审查会发现initiated_at->format()如果字段为空，则可能导致空指针异常 (NPE)。并在问题演变成凌晨 2 点的突发事件之前将其修复。
第 8 阶段：提交 PR。Bug Bot 发现 4 个问题：
-
硬编码的类别字符串（应该使用枚举）：已修复 -
状态转换时缺少数据库锁定：已修复 lockForUpdate() -
Blade 模板中的可空类型 initiated_at：已使用空安全运算符修复 -
完成事件通知音错误：已修复
经过 3 次修复循环后，Bug Bot 返回正常success。PR 已准备就绪。
总计：49 个测试用例，108 个断言，发布前发现了 4 个 bug。对于一份检查清单来说，这还不错。
如何安装它
一条命令：
curl -sL https://raw.githubusercontent.com/vlad-ko/claude-wizard/main/install.sh | bash这会将三个文件放入.claude/skills/wizard/：
SKILL.md核心的八阶段方法论 CHECKLISTS.md快速参考清单 PATTERNS.md常见模式和反模式
然后输入/wizard克劳德代码激活它。
让它成为你的
这项技能的设计初衷就是与框架无关。它不在乎你用的是 Laravel、Rails、Next.js 还是 Rust。其方法论——计划、探索、测试、实现、验证、文档编写、审查、发布——适用于任何框架。
但自定义后功能会更强大。在我的项目中，我添加了：
-
Laravel 特有的测试命令（ ./vendor/bin/sail test） -
我们的日志服务模式（ LoggingService::logPortfolioEvent()） -
我们 ORM 的数据库锁定约定 -
Bug Bot 线程解析命令（GraphQL mutations） -
Alpine.js 对 UI 组件的要求
项目相关的具体信息越多，克劳德需要猜测的地方就越少。克劳德猜测的地方越少，漏掉的 bug 也就越少。事实证明，这两件事是相关的。
它不是什么
/wizard它不能替代代码审查。它不是测试框架。它也不是持续集成流水线。
这是一个流程提示：一种将高级工程师的习惯编码到 Claude 的工作流程中的方法，以便这些习惯能够持续地应用于每一项任务，即使是在凌晨 2 点你很累，只想尽快发布功能的时候。
这份提示大约有 500 行 Markdown 代码。没什么特别的。它其实就是一份优秀的技术主管会走一遍的检查清单，只不过这次更加清晰明了，可以重复使用。唯一令人惊讶的是，居然没人早点把它写下来。
来源
完整的技能代码已在github.com/vlad-ko/claude-wizard开源，采用 MIT 许可证。欢迎 fork、修改和完善。
它源于wealthbot.io的开发，这是一个金融科技平台，在该平台上，“基本能用”绝非产品策略。这些模式是在数百次 PR 和实际生产环境中不断完善的。框架特有的部分已被移除，但方法论本身经过了实战检验。
如果你试过了，我很想知道它能捕捉到什么。
关注「索引目录」公众号，获取更多干货。