我一直以为自己 AI coding agent 用得还不错。
直到认真翻完 Codex 的官方最佳实践文档，才发现——有好几个地方，我一直在用“次优解”，而且完全没意识到。
不是那种「原来我完全不会用」的感觉。
更微妙一点：每天都在用，但始终差那么一口气。
下面是我读完之后，真正改掉的一些使用习惯。
一个好 Prompt，其实只有四件事
文档一开头就讲了这件事，但我以前从来没认真对待过。
一个高质量 Prompt，应该明确四个要素：
- Goal：你要做什么
- Context：相关文件、报错日志（用 @ 引用）
- Constraints：架构约束、规范、安全要求
- Done when：什么叫“完成”
👉 Prompt 四要素：Goal / Context / Constraints / Done when
我最大的坑，其实一直在最后一个。
以前的习惯是：
给任务 → 等结果 → 再反复改
但问题不在结果，而在一开始就没定义“完成标准”。
现在我会直接写清楚：
Done when：测试通过 + 无新增 lint 警告 + README 已更新
结果很明显：
来回确认减少了一大半。
推理等级：别每次都开满
另一个被我忽略的点是推理等级。
简单来说：
- 简单 bug → Low
- 常规开发 → Medium
- 跨模块 / 调试 → High
- 长链复杂任务 → Extra High
以前我几乎默认开高档。
但其实这就像人力分配：
不要让高级工程师去写简单 CRUD
更慢，而且没更好。
用语音写 Prompt，比打字更靠谱
文档里有个建议让我愣了一下：
👉 尽量用语音输入 prompt，而不是打字
原因很真实：
- 打字 → 会下意识省略信息
- 语音 → 自然带出上下文
我试了几次，确实成立。
打字时你脑子里的“默认信息”，agent 是完全拿不到的。
语音虽然更啰嗦，但信息密度反而更高。
这是个小点，但非常实用。
需求不清？让它来“采访”你
这是我觉得最有价值的一点。
以前遇到复杂需求，我的方式是：
想个大概 → 直接丢给 agent
结果就是：
永远差一点 → 来回改 → 很累
文档里的做法叫：
👉 反向采访（let the agent ask you questions）
你只需要说一句：
“先别做，先问我需要澄清的问题”
然后它会：
- 自动列出关键不确定点
- 帮你补齐思路
你回答完，需求自然清晰。
这个转变很关键：
不是你整理好再喂给它
而是让它帮你整理思路
配套工具：/plan 和 PLANS.md
这个流程可以进一步强化：
/plan：先收集信息、提问、再执行PLANS.md：管理多步骤长期任务
任务越复杂，这套越有价值。
AGENTS.md 是会“成长”的
以前我把 AGENTS.md 当成一次性配置。
现在理解是：
👉 它应该持续进化
核心用法：
当 agent 重复犯同一个错误时：
❌ 不要每次纠正
✅ 把规则写进 AGENTS.md
例如：
- “接口改动必须同步更新测试”
- “提交信息必须用英文”
这其实是在做一件事：
把“你在提醒它”，变成“它自己记住”
层级也很重要
- 全局：
~/.codex - 项目：
/AGENTS.md - 子目录：局部规则（优先生效）
团队项目里，这个层级非常有用。
一个判断标准
写规则前问自己一句：
这件事，agent 能靠常识推断出来吗？
能 → 不写
不能 → 才写
否则文件会越来越臃肿。
Skills 和 AGENTS.md，本质完全不同
这个我卡了很久才想明白。
一句话总结：
- AGENTS.md = 规则（必须遵守）
- Skills = 流程（按需调用）
例子：
-
AGENTS.md
- 提交必须英文
- 改接口必须更新测试
-
Skills
- 分析日志
- 生成 Release Notes
- 风险评估
👉 判断方法：
所有任务都必须遵守 → 规则
只在特定场景用 → 流程
两个容易踩的坑
1. 不要手写 Skills
用 $skill-creator 自动生成。
让 agent 写 agent 的流程，比你自己写更省事
2. 不要过早封装
只有当一个任务开始反复出现，才值得做成 Skill。
否则只是制造维护成本。
存放位置
- 个人：
~/.agents/skills - 团队：
.agents/skills
团队共享非常关键，新人可以直接用。
Automations：稳定之后再自动化
一句话理解：
- Skills → 做什么
- Automations → 什么时候做
适合自动化的场景：
- 每天 lint 扫描
- 每周代码总结
- TODO 汇总
一个重要原则
❗ 不稳定流程，不要自动化
否则：
- 出错你不容易发现
- 问题会长期积累
顺序必须是：
先跑稳 → 再自动化
一个更高级的用法
Automations 不只是执行流程，还可以：
👉 定期分析 prompt 和 Skill 表现
比如：
- 哪个 Skill 开始“漂移”
- 哪类 prompt 问题最多
这点很多人会忽略。
MCP 和 Skills：越少越好
很多人（包括我）容易犯的错：
👉 接太多 MCP / 建太多 Skills
问题：
- 上下文变重
- 核心指令被稀释
- 响应变慢
文档建议：
一个项目控制在 2–3 个核心能力
本质是：
克制也是一种配置策略
只让 AI 写代码，是最差用法
这个我想说得直接一点。
很多人的流程是：
生成代码 → 结束
这是不对的。
正确闭环是：
1. 静态检查
- lint
- format
- type check
2. /review 自检
让它从 reviewer 视角检查：
- 边界情况
- 潜在 bug
- 命名问题
3. 单元测试
确保代码有覆盖
👉 关键点：
这三步应该写进 AGENTS.md
不是靠你提醒，而是强制流程
Git Worktrees：避免污染你的工作区
这是我踩坑之后才重视的。
问题：
agent 直接改你当前文件 →
改错 → 状态混乱 → 回滚麻烦
解决方案：
👉 用 Git Worktrees
给 agent 单独一个目录：
- 出问题 → 直接删
- 不影响主工作区
任务越大，这个习惯越重要。
几个容易忽略的坑
简单列几个我自己踩过的：
1. 一个 thread 只做一件事
不要混任务，否则上下文会漂移。
2. 不要跳过规划
复杂任务必须：
- /plan
- 反向采访
- 对齐需求
否则后面成本更高。
3. 不要让 agent 改活跃文件
（Git Worktrees，前面说过）
几个实用命令
我自己常用的：
/fork：开新分支探索/resume：恢复任务/agent：切换 agent/status：查看状态/compact：压缩上下文/experimental：开启实验功能
最后
官方文档这种东西，大多数人不会认真看。
我之前也是。
但这次翻完之后，最大的收获不是“学了新功能”，而是：
发现自己一直在用次优方法
有点尴尬，但也很有用。
改完之后，明显顺手很多。
参考资料
OpenAI. (2025). Codex Best Practices.
developers.openai.com/codex/learn…
