很多 Codex 返工不是因为模型能力不够，而是因为我们把“应该沉淀成规则的东西”一次次临时重说。真正能立刻提升稳定性的，往往不是再写更长 prompt，而是把任务范围、错误样例、不能动的结构、常见误判和验收动作逐步变成固定资产。
这篇小教程不讨论大而全的方法论，只聚焦几个日常最容易见效的习惯：什么时候先缩小编辑范围，什么时候该停下来写规则，哪些上下文值得保留，哪些只是噪音，以及怎么用小范围验收避免一轮轮返工。
如果一次把整个站点、整条流程、整组页面都交给 Codex，结果很容易漂。更稳的做法是先把范围收缩到当前轮最关键的 1 到 3 个文件，或者一个明确页面入口，再让模型在清晰边界里执行。范围越明确，返工越少。
第一次返工可以视为偶发，但第二次返工往往说明已经形成模式。比如某类页面总被改过头、某类链接总回到旧路径、某类首页总被重新放大非主线内容。这时候最值钱的动作不是再提醒一次，而是把它写进 AGENTS.md 或沉淀成可复用 Prompt。
只写“不要改得太大”通常没什么约束力，但如果留下“不要把 /tools/tool/旧路径 再指回聚合页”“不要把 Labs 产品重新抬回首页主视觉”这种具体错误样例，后续执行就会稳定很多。错误样例越具体，越能减少重复解释。
会反复用到的项目定位、页面边界、验收方式和不该做的事，最好写进 AGENTS.md、教程页、Prompt 页或者 handoff 文档。这样既能减少上下文 Token 浪费，也能降低因为重复转述不一致带来的偏差。
比起说“看起来差不多了”，更有效的是逐页确认：这个 URL 是否存在，title 是否正确，旧路径是否 301，新入口是否进了 sitemap，列表页是否能看到新卡片。只要验收口径明确，后续修改就不容易反复回滚。
一条好的沉淀规则通常包含三部分：问题是什么、以后如何避免、适用于哪些页面或任务。只要这样积累几次，Codex 的日常协作质量就会从“每次重新磨合”慢慢变成“越来越懂项目”。