大佬用 Codex 厉害的地方，不是提示词写得长

很多人第一次看高手使用 Codex，会把注意力放在提示词上。

他用了什么开场白，怎样描述角色，规则写了多少行，为什么模型看起来格外听话。于是回去复制一整段提示词，换到自己的项目里，效果却很普通。

差距往往不在那段文字，而在他怎样定义任务、检查现场、处理失败，以及怎样证明事情真的完成了。

他交给 Codex 的不是一句愿望

“把这个功能做好”是一句愿望，不是一项可执行任务。

更成熟的做法会把目标写成可以观察的变化：哪个页面要改，用户执行什么动作，系统应该出现什么结果，现有行为哪里不符合预期，哪些文件和接口属于范围。

Codex 能够读代码、运行命令和操作工具，但它不会自动知道业务中最重要的边界。输入越模糊，它越容易交付一个“看起来改过”的版本。

高手不是更会命令模型，而是更早把模糊问题变成验收问题。

先看现场，再决定改哪里

普通用法经常从猜测开始：看到报错就让 Codex 改某个文件，界面不对就要求重写组件。

更稳的路径是先读取项目规则、当前分支、未提交改动、运行方式和相关测试，再复现问题。浏览器里看到的按钮没有点击，不一定是按钮选择器错了，也可能是标签输入框仍保留焦点，把下一次点击吞掉。

只有把页面状态、日志、网络请求和代码路径对上，才能区分表象、嫌疑对象和已验证根因。

这一步看起来慢，实际减少了反复补丁。

每次动作以后都取证

Codex 最容易制造的一种错觉，是命令已经执行，所以目标已经达成。

代码提交不等于部署成功，部署成功不等于线上版本已经更新；点击发布不等于平台接受文章，页面跳转也不等于文章已经公开。

高手会为不同阶段准备不同证据：测试结果证明代码行为，Git 提交证明版本已经保存，部署工作流证明服务器完成切换，线上接口和页面证明生产环境正在运行新版本。

证据必须对应结论。不能拿“命令没有报错”证明用户问题已经解决。

让失败回到流程，而不是留在聊天里

一次故障修好以后，如果经验只停留在对话中，下一次很可能重新踩坑。

可复用的做法是把稳定规则写回测试、脚本、项目说明或 Skill。选择器变化就补回归测试，发布状态曾被误清除就明确证据保留规则，某个平台正文不能带图片就把转换逻辑限定在该平台。

写回去的也不能只是“以后注意”。规则要说明触发条件、目标行为和验证方式，否则它只是换了位置的聊天记录。

给 Agent 权限，也要给它停止线

Codex 能做的事情越来越多：修改文件、运行测试、浏览网页、提交代码、触发部署，甚至操作已经登录的平台。

能力增加以后，最重要的设计不是怎样少点一次确认，而是哪些动作可以自动完成，哪些动作必须停下。

读取代码、运行非破坏性测试可以连续执行；覆盖用户改动、删除数据、公开发布、付款和发送消息需要更高的授权。风险越大，确认点越靠近最终动作。

所谓“接管”，不是让 Agent 不受约束地操作，而是把安全范围内的调查和执行做到底，在真正需要人决定的边界停下来。

一套可以复用的 Codex 工作法

完成不等于上线，每一层都要有对应证据。

把高手的做法压缩成流程，大致是这样：

1. 先定义结果和验收证据，不从文件名开始下命令。
2. 读取项目规则、Git 状态和运行环境，保护现有工作。
3. 复现问题，用页面、日志和代码建立证据链。
4. 做最小范围修改，同时补能够防止复发的测试。
5. 分别验证代码、提交、部署和线上状态。
6. 把稳定经验沉淀进项目或 Skill，删除只服务单次故障的补丁。

提示词当然有用，但它只是入口。真正拉开差距的，是任务有没有完成标准、每一步有没有证据、失败有没有被沉淀，以及权限边界是否清楚。

会用 Codex，不是把自己训练成更熟练的提问者，而是把工作组织成一套 Agent 可以执行、人能够验收的系统。