分页错位那组写到最后，留下了一个问题。

复现测试红过，页面路径也验了，根因找到了。接下来要不要把这次经验写进项目规则？

这一步很容易做过头。Codex 修完一个 bug，常常会顺手总结几条“以后应该注意”。话都对，放进项目规则却未必合适。项目规则一旦变厚，后面每次任务都要读，读完还要判断哪条适用。规则太多，Codex 的上下文会被小经验占满，真正重要的边界反而被挤掉。

所以我会让它先过三道门。

第一看同类问题会不会反复出现

我先看高频。

分页错位这个例子里，如果只有某个页面在一次特殊接口下出错，它更适合留在任务记录。比如订单列表第二页混入第一页数据，原因是这个页面临时拼了一个参数。这个问题很具体，写进长期规则会显得小题大做。

但如果多个列表页共用同一套分页查询方式，错误来自“翻页时直接读编辑态表单值”，那就不一样。这个根因以后还可能出现。筛选、重置、翻页、删除后刷新都会碰到同一类状态关系。

我会让 Codex 先写成这样。

高频判断
- 这次根因是否可能出现在多个列表页
- 是否与公共查询流程、分页流程或表单状态有关
- 是否只属于当前页面的一次性字段问题
- 若只能影响当前页面，建议留在任务记录

高频不等于“以后可能也会遇到”。前端里很多东西都可能再遇到。我要看它是否贴着项目里的共用流程。

第二看规则会不会随页面变化

第二道门是稳定。

一条规则如果强依赖某个页面、某个接口字段、某个临时状态名，它就不稳定。比如“订单页翻第二页前要清空 orderKeyword”，这种写进项目规则没有意义。换一个页面，字段名变了，规则就失效。

稳定的写法应该抽掉页面名字，留下能长期成立的约束。

不适合进项目规则
- 订单页翻页前清空 orderKeyword
​
可以继续观察
- 翻页请求参数必须来自已提交查询条件
- 重置后分页回到第一页，并清空已提交条件
- 输入框草稿值不能自动污染当前列表请求

我用了“继续观察”，没有立刻写成必须。因为这几条还要看项目现有写法。如果项目已经有成熟的查询状态分层，就把它对齐到原有规则里。若项目没有这类规则，可以先记到候选区，等第二个同类任务出现再写入长期规范。

规则稳定，Codex 才能在不同页面里复用。否则它只是在背一次 bug 的细节。

第三看 Codex 能不能照着验

第三道门是可验证。

规则写得再对，Codex 无法检查，也不适合放进项目规则。比如“分页逻辑要合理”“查询状态要清晰”，这类话我一般不留。它们听起来很稳，落到代码审查时抓不住。

我更愿意写成能查的动作。

可验证规则
- 翻页处理函数不得直接读取编辑中的表单草稿值
- 翻页请求参数应来自已提交查询条件
- 新查询和重置必须把页码恢复到第一页
- 删除后刷新应沿用已提交查询条件

这几条 Codex 能查。它可以看翻页函数读的是哪个状态，可以看请求参数怎么组装，可以看查询和重置有没有改页码。

可验证规则还要配证据位置。

规则证据
- 触发路径
- 修复前错误表现
- 修复后验证方式
- 对应代码位置
- 适用页面范围

没有证据位置的规则，过一周就会变成口号。

我会让 Codex 给规则找去处

三道门过完，规则有三个去处。

去处	适合内容	处理方式
本次任务记录	当前页面特有根因	留在交付说明
项目规则候选	可能复用但还缺第二次验证	写到候选清单
项目长期规则	高频、稳定、可验证都满足	写入规范或 AGENTS

我不会让 Codex 直接把所有总结写进长期规则。它要先给出建议去处。

请对本次 bug 根因做规则去处判断。
​
每条候选规则必须包含
- 来源 bug
- 高频判断
- 稳定判断
- 可验证判断
- 建议去处
- 暂不写入长期规则的原因

这段要求会让 Codex 慢一点，但慢得有价值。它从“修好了”往后走一步，把这次经验放到合适的位置。

写在最后

bug 根因很诱人。刚修完，记忆新，最容易觉得应该马上写成规则。

我现在会克制一点。先问同类问题是否贴着共用流程，再问规则能不能脱离页面细节，最后问 Codex 能不能照着检查。三道门都过，才考虑进入项目长期规则。

下一篇换一个 bug 载体。分页错位讲的是状态和参数，接口异常讲的是失败路径和页面退化。我会用接口异常类 bug 再跑一次启动模板，看 systematic-debugging 怎样先接住错误信息，避免 Codex 直接补一个弹窗。

本系列持续更新，继续围绕 Codex 和 GitHub Skills，把修过的问题变成能审查、能复用的前端规则。