很多人第一次用 Codex，都是打开一个项目丢一句话进去："帮我修这个 bug"、"帮我写个页面"。这当然没错，但如果你只把它当成"会写代码的聊天框"，就有点可惜了。
真正拉开差距的，不是你会不会多写几个提示词，而是你会不会把一个模糊任务，交代成 Codex 能持续推进、能看现场、能跑工具、能被你中途纠偏、最后还能验收的工作流程。
一、固定线程：别每次都重新开一个临时工位
很多人用 Agent 有个坏习惯：每来一个任务，就新开一个对话。短任务还好，但一旦做的是长期项目，新开线程就像每天换一个新同事上班。昨天刚交代过项目目标，今天又要重讲。昨天刚说过哪些文件不能乱改，今天又要提醒。
固定线程的价值不是"聊天记录更长"，而是给同一类任务一个长期工位。可以先建 3 个最简单的线程：
- 项目维护线程：专门处理这个项目的改代码、跑测试、看 diff
- 文档审查线程：专门检查 README、教程、文章草稿、发布说明
- 每日整理线程：专门整理收件箱、待办、网页资料、消息摘要
就像厨房里切菜、炒菜、洗碗各有地方。Codex 也一样，固定线程跑顺以后，它更容易记住这个任务的上下文，你也更容易回头检查它之前做过什么。
二、先让它看现场：别再靠嘴描述半天
以前用 AI 最累的一件事，是描述现场。网页哪里挤？按钮怎么错位？报错弹窗长什么样？你要么复制一堆文字，要么截图以后再补一句"你看右上角那个地方"。
现在 Codex 已经越来越像一个能看现场的工作台。Appshots 可以把当前应用窗口交给 Codex；浏览器工具可以看网页渲染效果；Computer Use 可以在 Mac 上点击、输入、滚动。
新手第一步不要急着让它操作。先让它复述现场：
请先看当前窗口，不要点击、不要输入、不要修改任何内容。请只做三件事：1. 复述你看到了哪些主要区域；2. 指出你认为最可能有问题的 3 个地方；3. 告诉我下一步如果要检查，应该点哪里，但先不要点。
你不是一上来就把鼠标交出去，而是先让它像新同事一样站在你旁边，把现场说清楚。它说对了，再让它继续。它说错了，你马上纠正。
三、用 /goal：不要只说"帮我改好"，要说"怎样算做好"
/goal 真正改变的是：你不再只给 Codex 一个动作，而是给它一个完成标准。
普通提示词是："帮我优化登录流程。" Codex 很难知道什么叫"优化完了"。
更好的写法是：
/goal 让登录流程对新用户稳定可用。范围：只检查登录、注册、找回密码这三个页面；不重构用户系统；不改数据库结构。完成标准：新增或修复必要测试；本地登录主流程能通过；失败状态有明确提示；输出改动摘要和剩余风险。暂停条件：需要删除数据；需要改生产配置；需要输入密码、密钥或付款信息。
前一句像许愿。后一句像交活。Agent 最怕的不是任务大，而是任务没有终点。没有终点，它就像在雾里开车，看起来一直在努力，实际不知道什么时候该停。
以后写 /goal，记住 4 个词：目标 / 范围 / 验收 / 停止。
四、学会中途打方向：Steering 和 Queue
Agent 跑偏的时候，很多人第一反应是等它做完，然后说"不是这个意思"。这就像你坐出租车，司机已经开过三个路口了，你才说刚才应该左转。
Steering 适合改当前重点：
先停一下，当前重点不是重构组件。请只检查首页按钮、间距、移动端换行。不要继续改数据结构。
Queue 适合交代下一步：
当前这一步完成后，请不要直接继续。请先输出：1. 改了哪些文件；2. 跑了哪些验证；3. 哪些地方还需要人工确认。
一个管"现在别跑偏"，一个管"下一步别忘"。
五、分清 Browser、Chrome、Computer Use
三者能做的事不一样，风险也不一样：
- 内置浏览器像公共阅览室：适合读页面、截图、检查公开信息
- Chrome 像你的私人办公室：适合已登录后台，先限制范围，不要授权太多
- Computer Use 像你把同事请到电脑前：适合桌面软件、系统窗口，先让它复述现场，再批准点击
新手最稳的原则是：公开、低风险、可重复的任务，先给 Codex 做。登录态、隐私、付款、删除、发送消息这类动作，必须先停下来问人。
六、把重复流程做成 Skill
如果你有一段提示词，已经复制过 3 次，就该考虑做成 Skill。Skill 不是插件，更像一张"标准作业卡"。
比如经常让 Codex 做文章审查，每次都要说："请检查这篇文章是不是太空，标题有没有痛点，正文有没有可复制步骤，不要只夸优点，要指出可改的地方，最后给我一个改稿清单。"
更好的办法是沉淀成一个 Skill，让 Codex 帮你写最小版：触发场景、执行步骤、禁止事项、输出格式固定成：问题 / 原因 / 修改建议 / 可复制示例。
Skill 的价值不是花哨。它是让 Agent 每次按同一套流程干活，少一点随机发挥。就像餐厅后厨的出餐单，你不可能每来一份菜都重新教厨师盐放多少。
七、把规则写进 AGENTS.md
很多项目最怕的不是 Agent 不聪明，而是它不知道规矩。哪些文件不能随便动？测试命令是什么？提交前必须跑什么？UI 风格有什么禁忌？涉及外部消息、删除、上传时要不要停？
这些东西不要每次靠嘴说，写进项目规则 AGENTS.md：
- 常用命令：安装依赖、本地启动、最小测试
- 修改边界：不要改数据库 schema、不要删除用户数据、不要修改 .env 和密钥文件、大改动前先输出计划
- 完成要求：每次改完先看 git diff、能跑测试就跑最小相关测试、输出改动摘要/验证结果/风险点
- 必须暂停：需要付款、需要登录新账号、需要发送外部消息、需要删除文件或数据
这不是给 AI 写作文，这是给它贴一张办公室规章制度。有了这张纸，它下次进项目，至少知道哪些门不能乱开。
八、用 Automations：不是让 Codex 没事骚扰你，而是让它定时检查
真正适合自动化的任务，一般有三个特点：固定时间出现、输入来源稳定、结果需要你审一眼。
比如每天早上整理昨天的 issue 和失败 CI、每周五生成项目进展摘要、每天下午检查收件箱里有没有需要处理的反馈、每次发布后检查日志里有没有新增错误。
注意，不是让它直接替你拍板。更稳的做法是让它整理成"待审结果"：最紧急的 3 件事、每件事的证据链接、建议下一步、需要你确认的地方。
自动化不是把方向盘拆掉，它更像早上有人把报纸、待办和风险点放到你桌上，你喝口水就能开始判断。
九、质量门要前置
用 Codex 最危险的阶段，不是它不会写，恰恰是它写得太快。它三分钟改完一堆文件，给你一段很顺的总结。你一看"测试通过"，心里就想：那应该没问题吧。
别急。Agent 的总结不是证据。真正的证据是 diff、测试、截图、日志和可重复步骤。
每次让 Codex 改东西，最后都可以加 5 道质量门：
- 列出 git diff 中真正改动的文件
- 说明每个改动为什么必要
- 跑最小相关测试，并贴出命令和结果
- 检查是否改了依赖、密钥、权限、删除逻辑
- 给出剩余风险和需要人工确认的地方
这段很朴素，但很管用。它会把你从"听 Agent 自述"拉回"看真实证据"。
十、人的角色变了：你不是遥控器，你是验收人
Codex 这些功能加起来，不是在告诉你"以后什么都不用管了"。正好相反，它是在逼你换一种工作方式。
以前你像遥控器：做这一步、再做下一步、这里错了、继续、再继续。现在你更像一个小项目负责人：目标是什么、边界在哪里、看到什么现场、允许用哪些工具、成功怎么验收、什么时候必须停。
这才是 Codex 真正厉害的地方。它不只是帮你写代码，它把"如何把事情交代清楚"这件事，摆到了你面前。你越会定义目标，它越能持续推进。你越会提供现场，它越少猜。你越会写边界，它越不容易乱动。你越会验收，它交付的东西越可信。
给新手的一条最小上手路线：
- 固定一个项目维护线程
- 每次开始前，让 Codex 先复述目标和限制
- 涉及页面或桌面，先让它看现场但不要操作
- 完成后必须过 5 道质量门
等这 4 步顺了，再加 /goal、Skill、Automations。工具越强，越需要顺序。就像刚拿到一把很锋利的菜刀，不是马上表演花活，而是先学会怎么拿、怎么切、怎么收刀。