说实话，我们hen容易陷入一种“Prompt焦虑”。总觉得只要我那句咒语念得够准，AI就Neng像哆啦A梦一样掏出完美的代码。但经过这段时间的反复折腾，我算是彻底想明白了一件事：老祖宗说“磨刀不误砍柴工”，这话放在AI编程时代简直太应景了。只不过这里的“刀”，根本不是你写的那个Prompt，而是你手里的一整套工作流。

我现在理解的“利其器”，早就超越了怎么把指令写得geng漂亮。真正决定你效率高低的，往往是那些kan起来枯燥乏味的东西：规则怎么定？边界在哪里？怎么验证？怎么审查？Zui后怎么收口？Ru果这些结构没搭好，你给Codex下再高级的Prompt，Zui后大概率也是一场灾难。

认知的觉醒：从“聊天”到“工作流”

一开始，我也犯了一个大多数人dou会犯的错误：把Codex当成一个Ke以无限聊天的窗口。遇到问题，我就把代码贴进去，然后跟它一来一回地对话。结果呢？聊着聊着，上下文就乱了任务边界开始模糊，原本只想改一个小功Neng，Zui后恨不得把整个模块重构了。

后来我才猛然惊醒，问题根本不在Codex，而在我自己。我一直把它当聊天框用，而不是当工作流用。这个认知的转变，比换多少个“神级Prompt”dou管用。真正的高手，不是那个会问问题的人，而是那个懂得如何把AI放进一个稳定闭环里的人。

这套东西一点dou不性感，不像那些“惊为天人”的Prompt技巧让人兴奋，也不像“多Agent并行”那样听起来hen猛。但真正让我效率稳定下来的，恰恰是这些不花哨的动作。一旦这些结构搭住了Codex才是生产力；缺位了它就只是一个“偶尔hen好用、偶尔把你带偏”的聊天框。

Plan阶段：别急着动手，先kan清路

以前我总是急着让AI“直接试试kan”，好像只要代码跑出来问题就解决了一半。但现实狠狠地打了我的脸。Ru果执行路径还不清楚、改动可Neng跨模块、或者任务明显还没拆小，这时候Zui该Zuo的绝对不是“直接试试kan”，而是先ZuoPlan。

在Plan阶段，Zui重要的输出根本不是代码，而是三样东西：执行路径、Zui小改动面、主要风险。它解决的是“别开错工”的问题。你想想，Ru果方向dou错了跑得越快，死得越惨。

hen多人觉得任务一大，开几个Agent并行就快了。真实情况通常相反——主问题没想清楚时多Agent只会把混乱复制好几份。只有主任务明确、子任务边界清楚且彼此独立时并行才真的有意义。否则，你得到的只是几份不同的混乱而Yi。

环境隔离：给AI一个“沙盒”

这点以前我没太认真想过总觉得默认让工具在当前工作区跑build和测试kan起来省事。但你只要多Zuo几次副作用就开始出现：缓存留下来了、临时文件留下来了、本来干净的工作区悄悄变脏了。

这些问题有个共同点：它们不会在第一时间炸掉你，但会一点点吞掉你的注意力。等你反应过来不是“代码写不出来”，而是“这轮协作Yi经不干净了”。那种感觉真的hen糟糕，就像在一个堆满杂物的桌子上找东西，越找越烦。

所以我现在的原则是：代码修改在当前工作区Zuo，build和实验性命令放到临时worktree或者`/tmp`副本里跑。只有当隔离成本明显过高时才例外。一旦验证不再总是伴随“把现场弄乱”的代价，你会发现自己敢geng频繁地验证——工作流整体也稳得多。

AGENTS.md：kan不见的契约

以前我对`AGENTS.md`的理解停留在“写点规则、显得规范”这种表面功夫。现在我完全不这么kan了。它真正的价值，是把你每轮dou要重新提醒一遍的东西，变成默认契约。

大家Zui容易优化的，通常是模型选择、slash command用法、Prompt怎么写得geng“高级”。这些dou值得Zuo，但它们不是Zui先该动的地方。真正决定协作质量的，不是那句话怎么写，而是你有没有给它一个靠谱的结构。

不过要注意，这个契约不该越写越长。根规则保持短，展开说明放进对应文档，需要时再加载。这条规则hen朴素，但真的帮我省掉了大量无效对话。这些规则没有一条kan起来“高级”，但只要缺其中两三条，整个协作体验马上往下掉。

贴一份我目前探索的全局AGENTS.md

Ru果你也在折腾Codex，我把这套还在持续打磨的playbook放到了GitHub：HuiDBK/codex-playbook。下面是核心内容，大家Ke以参考，毕竟hen多东西是和AI探讨出来的，geng偏个人观点，也有hen多需要改进与探索的地方，搭让自己用起来顺畅、懂你的Agent工具才是正经事。

## 范围控制
- 默认一轮会话只Zuo一个小闭环。
- 先完成当前任务，不把“顺手优化”混入本轮。
- 不Zuo未明确要求的重构，不改无关文件。
- Ru果任务明显膨胀，先停下来说明原因，再继续。
## 执行方式
- 中等及以上任务，先复述目标、边界、方案和风险，再执行。
- 先找执行路径、相关文件和Zui小改动面再开始修改。
- 优先复用现有模式，避免为了当前任务引入额外抽象。
- 需求不清且错误假设会造成明显返工时先对齐，不硬Zuo。
- 涉及较大行为变geng、较大重构或高风险假设时先对齐再改，不擅自推进。
- 不要只机械执行表面要求，要主动理解真正目标。
- Ru果我给出的方案存在明显风险、局限或geng优替代路径，要明确指出，并将“按要求执行”和“geng优建议”分开表达。
## 输出方式
- 改完后优先给出：改动摘要、修改文件、验证结果、剩余风险。
- 默认简洁输出，不写长篇解释。
- Ru果没法验证，直接说明，不模糊带过。
## Review
- Zuo review 时先kan范围是否失控，再kan行为、失败路径和测试缺口。

三件事，彻底分开

以前我会把hen多动作混在一起：边分析边改、边review边继续实现。表面kan起来hen流畅，一气呵成，实际特别容易失控。现在我把三件事硬拆开，虽然感觉上没那么“丝滑”，但结果靠谱多了。

1. 只Review，不继续实现

我现在比较舒服的一轮，通常是这样的：只review，不继续实现。重点kan几件事：有没有改动越界、行为是否符合验收标准、失败路径有没有漏、测试是否只测了表面。它解决的是“别带病交付”的问题。

一个简单的判断：Ru果你在review的时候忍不住想去改代码，说明你还没把这两个角色分开。这时候Zui该Zuo的是停下来深呼吸，切换心态。

2. 实现与修改的边界

任务边界没收住一轮会话越聊越大，这是常态。一开始我也觉得是模型的问题——为什么又理解偏了为什么任务越Zuo越大，为什么代码越来越难改动。后来发现，这是因为我没有在一开始就划定严格的界限。

没有收口点，小需求Zui终变成长对话。那种无休止的拉锯战，Zui消耗心力。所以明确什么时候该停，和明确什么时候该开始一样重要。

3. 验证的独立性

不要把验证当成是顺手Zuo的事。验证必须是一个独立的环节，有独立的输入和输出。只有这样，你才Neng相信验证的结果。

朴素的真理

折腾到Zui后我Zui认同的东西反而hen朴素。不要指望AINeng替你思考所有事情，也不要指望一个Prompt就Neng解决所有问题。用Codex越久，越发现：真正决定协作质量的，是你有没有给它一个靠谱的结构。

这套方法论可Neng听起来不够“极客”，也没有什么黑科技的味道。但它Neng让你在深夜面对屏幕时少一点焦虑，多一点掌控感。毕竟我们是要用工具来解决问题，而不是制造新的问题。希望这些踩坑经验Neng帮到还在探索路上的你，Ru果大家有geng好的玩法，也欢迎一起来交流。

---