让 Codex 修一个前端 bug，它是怎么做的？

很多次我看到的是同一个循环。读完报错第一行，它就开始猜。可能是这里没判空，可能是这个接口参数不对，改一下，跑一下，不行，换个地方再猜。运气好改对了，运气不好一个简单问题来回绕。

问题不在 Codex 不够聪明，在于没有人拦住它。

所以我修 bug 时，会先给 Codex 套一层调试规则，让它在改代码之前，先完成定位。这套规则不是我发明的，来自 GitHub 上一个叫 systematic-debugging 的开源 skill。

这个 skill 从哪里来

它在 github.com/obra/superpowers 仓库里，MIT 许可。这个仓库本身是一整套给编码代理用的方法论，里面拆了很多 skill，调试只是其中之一。

我把 systematic-debugging 的 SKILL.md 拉下来核对过，它一开始就定了一条铁律，没完成根因调查之前，不允许提修复方案。

这句话是整套方法的开关。后面的内容都是围绕它展开的。

四阶段把修复过程钉在流程里

skill 把调试拆成四个阶段，要求每一步走完才能进下一步。

第一阶段是根因调查。仔细读错误信息，注意行号、文件路径和错误码。尽量稳定复现，确认是每次都触发还是偶发。检查最近改了什么，Git diff、依赖、配置。如果系统有多个组件，在边界上补日志，看数据从哪一层开始不对。最后沿调用栈往回追，找出脏数据最初从哪里来。

第二阶段是模式分析。在同一个代码库里找正常工作的相似实现，和出问题的代码逐行对照，把每一个差异都列出来，哪怕你觉得它不可能有关系。还要想清楚这段代码依赖哪些配置和假设。

第三阶段是假设与测试。一次只提一个假设，把最小的一处改动当作验证，而不是同时改好几处。验证没通过就换新假设，不要往上叠加修复。

第四阶段才是实现。改之前先写一个能复现失败的测试，然后只改根因那一处，再跑验证，确认没有破坏别的东西。

这套流程单独看并不惊艳，每一条都是老工程师会做的事。它的价值在于把"先定位再修"写成了强制顺序，Codex 没有跳过的余地。

我怎样让 Codex 按这套流程走

systematic-debugging 是纯方法论的 skill，不依赖脚本，我接进 Codex 的方式是把流程写进任务。

任务会这样下。

按 systematic-debugging 的流程处理这个前端 bug。
第一步先输出根因调查结论，覆盖错误信息、复现步骤、最近改动和涉及的数据流。
不完成这一步不要给出修复代码。
确认根因后，写出验证假设的最小改动。
实现前先补一个能复现问题的失败测试，再改根因。
改完说明验证结果，以及是否影响其他路径。

关键是最后一句话的顺序。Codex 习惯了先给答案，这个任务逼它先交调查结论，再谈方案。只要调查结论是空的，修复代码我就不会看。

还有一个细节我会额外要求。前端 bug 很多时候表现为"页面看着不对"，没有报错。这种情况我会让 Codex 在复现这一步写出具体的触发动作和预期表现，把"不对"变成可验证的描述，否则根因无从谈起。

修三次还不对，就该停下来质疑架构

skill 里有一条容易被忽略的规则。如果同一个问题改了三次还没好，停下来，不要试第四次。

它给出的判断依据是，如果每次修复都引出新的问题，说明问题可能不在单个点，而在结构本身。状态归属混乱、组件耦合过重、数据流有隐含假设，这类问题靠继续打补丁解决不了。

这条规则对前端尤其实用。我见过很多页面的 bug 修不完，不是因为某行代码写错，而是页面把请求、状态和渲染揉在一起，任何改动都会碰到别处的行为。这种情况该做的是重新划分边界，而不是让 Codex 继续猜第几处。

和生成类 skill 的功能差异

上一篇写的 web-artifacts-builder，功能是把前端代码从零生成出来，属于构建方向。它替 Codex 定技术栈、立骨架、管打包，解决的是"代码怎么写出来"。

systematic-debugging 功能正好相反，它管的是代码写出来以后出了问题怎么修，属于调试方向。它不帮你写一行新代码，它管住的是修改的过程，解决的是"改得对不对、是不是根因"。

两个 skill 一个向前一个向后，正好覆盖我日常两条最常用的路径。生成类管写，调试类管修，中间是 Codex 自己写的部分。

适用边界

systematic-debugging 不绑定技术栈，Vue、React、UniApp 都能用，这是它比生成类 skill 通用的地方。但纯方法论也有代价，它不提供任何脚本，不会自动给你复现环境，检查点要靠人盯。

我会把它当过程约束，而不是交付保证。Codex 按流程走完，只说明它没有跳过定位，不代表结论一定对。根因分析的质量，仍然要靠我自己读一遍它的调查结论来判断。

这也是 GitHub 上开源 skill 的共同边界，规则可以很好，落到具体项目时，人的校验一步都不能少。

下一篇我会继续沿着这个方向，看这类方法论 skill 里哪些条款值得沉淀成项目自己的规则，而不是每次重新贴一遍。

本系列持续更新。从 GitHub 找 skill 时，我先看它补的是生成、修复还是验证，功能不重叠才值得写进同一套流程。