很多人装完 Codex 就卡在第一步：不知道让它干什么、指令怎么写、它改完的代码不敢用。这篇按「装好之后先做什么、写代码任务怎么下、结果不对怎么查」的顺序走一遍，不堆概念，每一步都给你能直接照做的动作。涉及额度、价格和当前可用模型，一律去站内对应页面看当时的数字，别照抄别人的截图。
很多人装完 Codex 就卡在第一步：不知道让它干什么、指令怎么写、它改完的代码不敢用。这篇按「装好之后先做什么、写代码任务怎么下、结果不对怎么查」的顺序走一遍，不堆概念，每一步都给能直接照做的动作。
涉及额度、价格和当前可用模型，一律去站内对应页面看当时的数字，别照抄别人的截图。别人的截图可能是半年前的，口径、档位和通道状态都变了，照抄只会白折腾一轮。
装好之后先别急着写代码：把三件事定下来
第一件事是明确它在你项目里的角色。是补全单文件、跨文件改需求，还是只做解释和排查？角色不同，你要给的上下文和验收方式完全不一样。只想让它解释代码，就别把整个仓库塞进去，反而干扰判断。
第二件事是起手任务选小的。让它在已有仓库里改一个函数、加一段测试、解释一个模块，比一上来就「帮我做个功能」成功率高得多。小任务你能一眼判断对错，大任务你连它改歪了都看不出来。
- 把仓库状态弄干净：先提交一次、建个分支再让它动手，出问题能一条命令退回；这条对任何 AI 编程工具都成立
- 先摸清额度口径：去 /coding-plans 看当前各档编程套餐的额度说明，别把额度耗尽当成工具坏了
- 顺手看一眼通道状态：去 /codex-radar 看它最近的可用状态，遇上不稳定时段，排查半天其实是它那边在抖
- 准备一份最小复现材料：一个能跑的命令、一段相关代码，后面下指令和排查都要用
写代码任务怎么下指令：把话说成可验收的格式
一句话里至少给三样东西：改哪个文件或目录、要什么行为、怎么算改对了。缺一样它就只能猜。比如「把 utils/parse 里那个日期函数改成遇到空字符串返回默认值，改完让现有的单测全过」，比「优化一下解析逻辑」有用得多。
另一个高频技巧是要求它先复述方案再动手。让它列一句「我打算改哪几处」，你确认后再执行。这一步花十秒，能省掉大量来回改。
| 指令写法 | 它可能怎么理解 | 建议改成 |
|---|---|---|
| 优化一下这段代码 | 方向全靠猜，容易顺手改无关部分 | 把 X 循环改成提前返回，输出保持不变 |
| 加个功能 | 范围无限大，改动越多越难验 | 在 Y 文件加一个处理空输入的分支，配一个用例 |
| 帮我看看哪里错了 | 可能只贴出错误处理建议 | 贴报错和最小相关代码，问哪一行导致这个报错 |
| 一次把这几件事都做了 | 多改动混在一起，出错难定位 | 拆成三次，每次只做一件并各自提交 |
- 先复述让它用一两句话说明打算改哪几处、为什么这样改，你扫一眼确认方向
- 再执行确认后让它动手，改动范围只限你点名的文件或目录
- 给验收告诉它改完跑哪条命令、看哪个输出算过，别只说「看起来对」
- 看 diff自己过一遍改动，重点看有没有顺手改无关代码、有没有留下调试语句
结果不对怎么查：按这个顺序往下走
别一上来就怀疑工具坏了。结果不对，多数时候是输入或环境的问题。按下面顺序走，基本能在前三步定位到原因。
- 看上下文够不够它有没有读到相关文件和依赖？没读到就补上再问一遍，别指望它猜项目结构
- 看指令有没有歧义把「优化一下」换成「把这段的循环改成提前返回，保持输出不变」，效果差别很大
- 换成小样本复现把报错和最小相关代码贴给它，比贴整个仓库更有效，也更快
- 确认不是环境问题本地依赖版本、命令写错、路径不对，这些它看不出来；语法报错和运行时报错的排查路径也不一样
- 再看要不要换接入方式如果是额度、并发或通道问题，去 /sites 对照中转站目录，去 /tools/verify 实测在线情况
这里有个不适用的场景：如果项目里有大量隐式约定、或者构建流程本身很特殊，靠补上下文未必能解决，那就先把约定写进仓库里的说明文件，再让它读，效果比反复在对话里解释好。
用顺之后要固化的几个习惯
个人用顺了不等于团队用顺了。真正省时间的是把好用的东西固化下来，让下一个人不用重新踩一遍。
- 把好用的指令攒成模板存在仓库里，新同学直接照抄，比口口相传稳
- 生成代码一律走一次人工 review，重点看边界条件、错误处理和权限相关逻辑，这几块它最容易想当然
- 别把密钥、生产配置、客户数据贴进对话，需要脱敏就在本地先处理
- 定期回看用量和花费：去 /usage 看真实用量榜，去 /price-watch 追价格变动，成本失控往往是一点点涨上来的
- 遇到拿不准的中转站或通道，先去 /tools/speed-test 跑一轮，再决定要不要长期用
| 习惯 | 怎么落地 | 什么情况下不适用 |
|---|---|---|
| 指令模板化 | 把常用指令写进仓库说明文件 | 项目约定变化快时，模板要定期更新，别当死规矩 |
| 人工 review | 每次改动都过一遍 diff，重点看边界和权限 | 纯格式调整类改动可以放宽，但涉及数据读写不能省 |
| 数据脱敏 | 贴代码前先替换密钥、内网地址、客户标识 | 开源项目里本身公开的代码，不用多做这一步 |
| 成本跟踪 | 固定周期去站内页面核对一次数字 | 小团队试水阶段频率可以低些，但别完全不看 |
常见问题
Codex 和普通聊天式 AI 写代码有什么不一样？
差别主要在能不能直接读你的项目、动你的文件、跑命令。聊天式工具你得手动复制粘贴代码，它更像在编辑器里和你一起改。但这也意味着权限更大，动之前先提交、建分支，别在没有版本控制的项目里直接让它改。
它改的代码我不敢直接用，怎么办？
正常，就当它是手很快但不熟悉业务的同事。做法是让它小步改、每步你扫一眼，重点盯边界条件、错误处理、权限和并发这几块。再让它自己补一个能跑的测试，跑通再合。跨文件大改一次提交，很容易没人看得懂。
用着用着变慢或者报错，是工具坏了吗？
先分清三类原因：额度用尽、并发被限、通道本身不稳。额度和当前可用状态去 /codex-radar 和 /coding-plans 看，通道问题去 /sites 换一个再试，或者去 /tools/verify 实测在线情况。分清楚再动手，比反复重装省时间。
