夜雨聆风前段时间公司要求部门所有人不分岗位都要自己用AI工具在9天内做出3个APP，我差点以为完不成。但做完之后，我发现最值钱的不是APP，是这套和AI协作的方法。
我对整个过程做了一次回顾，回顾完发现，就是很多现在看来“挺自然”的用法，其实一开始并不会有人专门告诉你。在过程中遇到的一些问题，我觉得其他人也许也会遇到：
一上来就让它从 0 开始搭项目，结果越做越乱
开了几个新对话之后，上下文断掉了，不知道怎么接
项目一复杂，Codex 开始“失忆”
同一个项目越聊越长，token 越烧越快，效果却越来越差
所以我想把自己踩过坑之后，觉得确实有帮助的一些方法分享出来，希望这里面有那么一两条，能帮到一些也同样在使用Codex的伙伴。
1. 专业工作打地基
不要一上来就让 Codex 从 0 生成整个 APP 骨架，而是用专业工具先把地基打好，Codex 再来做扩展和实现
这是我自己很深的一个体会。
如果是安卓项目，我现在更推荐的做法是：先用 Android Studio 把标准工程骨架建出来，再让 Codex 接手。
原因很现实。像安卓这种工程，本身就有一堆基础文件、目录结构、构建配置、SDK 相关的东西。如果让Codex 从空文件夹硬生生给 “造”一套，很多时候不是不能做，而是很容易在环境、版本、构建细节上不断踩坑。
但 Android Studio 本来就是专业干这个的。它先把一个标准、能跑的骨架给你搭出来，Codex 再在这个基础上继续开发，会稳很多。
这件事看起来很小，但它能减少很多“项目为什么跑不起来”的低级折腾。
2. AGENTS.md的定位
把 AGENTS.md 当成“项目约定书”，而不是神奇文件
第一次接触AGENTS.md，容易以为它是什么“自动生成的高级机制”。
但我的实际感受是：它真正有价值，不在于它神不神，而在于你有没有认真把项目约定写进去。
AGENTS.md分全局级和项目级，这里先说项目级。对我来说，项目级AGENTS.md 更像是我和 Codex 之间的一份“项目约定书”。
比如我会在里面告诉它：
这个项目的工作区在哪里
项目里有哪些关键文档
构建要看哪个说明
做长期任务时要怎么理解当前进度
有哪些规则是每次新对话都应该先知道的
这样做最大的好处是：每次新开对话，Codex 不是从零开始猜。
它先读这份约定，再进入项目，整个状态会稳定很多。
这里我还想强调一点：AGENTS.md不是 Codex 替我想出来的，而是我和Codex共同讨论出来的。 比如当时我做的过程中，考虑到一个实际问题：怎样能在做一个长项目的过程中，即使做到一半，上下文全部清空，也能让AI工具快速了解当前项目情况，并能从中断处继续往下推进。我就向Codex提出了这个想法，然后让Codex配合我一起把机制设计出来。机制也很简单，在后面【长期项目机制】中会讲到。
3. AGENTS.md的内容
AGENTS.md 里不要塞一大堆内容，最好放“导航”
这一点我自己后来越来越重视。
刚开始很容易有一种冲动：既然AGENTS.md 这么重要，那我把所有东西都塞进去好了。 但后来我发现，这样反而不太好。因为这个文件如果每次对话都会读，那它太臃肿，就会一直占用上下文。你等于每次开工前都先背一大本说明书，成本很高。
所以我现在更推荐一种做法：
在 AGENTS.md 里放“文档地图”或者“导航”，而不是把所有内容全文贴进去。
比如可以告诉它：
需求看哪里进度看哪里
决策记录看哪里
构建说明看哪里
当前待办看哪里
这样它需要什么，再去读对应文档。不需要的时候，就不要让它把所有东西都扛在身上。
这个思路我觉得非常实用，本质上就是一句话：让 Codex 按需读取，而不是默认全背。
4. 长期项目机制
长期项目一定要准备几份“能恢复上下文”的文档
这一点对我来说，几乎是从“能用”到“好用”的分水岭。如果你只是临时写个脚本，当然无所谓。但只要做的是一个会持续几天、几周，甚至更久的项目，那最好默认一件事：上下文一定会中断。
中断的方式太多了：
开新对话
切换模型
换工作区
上下文自动压缩造成关键信息丢失
过几天再回来，自己都忘了当时做到哪了
所以我现在会尽量把长期项目拆成几类文档，比如：
plan：项目目标、阶段、范围、里程碑
progress：当前做到哪一步
todo：眼下还要做什么
decision：有哪些关键决策，为什么这么定
这些文档的意义不是“显得专业”，而是真的能救命。
尤其是你新开一个对话，或者想把任务接着往下做的时候，只要这几份文档在，Codex 就能很快重新进入状态。 甚至不只是 Codex，换一个模型，照样能接上。
总结就是，长期项目不是靠聊天记录维护的，而是靠项目文档维护的。这里的价值其实不是一个“写文档”的问题，而是一个“降低协作脆弱性”的问题。
5. 对话管理
不要把所有活都塞进同一个对话里
这个也很重要，而且非常接地气。
如果你一直在主对话里做所有事，那上下文一定会越来越大。 前面一个功能的细节、后面一个功能的细节，全部堆在一起，最后就会出现两个问题：
效率变差
token 消耗明显变高
因为很多细节，其实做完那个小功能之后，就不再重要了。 但它还在上下文里占空间。
所以我现在更倾向于把一些细节实现、局部问题、独立子任务，尽量放到子对话、子 agent 或者新的小会话里处理。主对话更像是“总控台”，只保留高层信息和关键状态。
我的理解是：
主对话负责方向，子对话负责细节。
这样上下文会干净很多，Codex的表现通常也会更稳定。
通过Codex插件能自动实现这个过程，如果不使用插件，也可以直接向Codex提要求，把大任务分成几个互不影响的小任务，分别由Sub Agent来处理，主会话做总控。
6. 重视需求梳理
先让 Codex 和我梳理需求，再让它开工
这一点我特别推荐使用Superpowers这个插件。
很多时候项目做着做着乱，不是因为 Codex 不会写，而是因为一开始需求就没梳理清楚。
一开始我只有很简单很朴素的想法：想做一个简单的安卓APP， 用来给需要学习AI的人更方便地学习AI相关知识。然后简单描述了一下整个APP的主要使用流程。
我用Superpowers，把想法给到会话，Superpowers会进一步和我讨论各种需求细节。
比如：
这个功能是纯本地实现，还是要服务端配合？
内容来源到底是什么？
MVP 先做到哪一步就够了？
哪些是当前必须做的，哪些可以后面再加？
只要前面这一步聊清楚，后面会顺很多。
我自己的经验是，Codex 真正好用的地方，不只是“写代码”，而是让它和你一起把需求、问题定义清楚。这些定义清楚了，代码只是后续动作。
7. 工作区和目录结构
工作区和目录结构，真的值得早点想清楚
我自己早期也踩过这个坑。
一开始图快，随便找个文件夹就开做。做到一半，才发现不够规范，后面又要搬、又要改、又要重新整理，反而更费劲。最好是在项目开始之前，先把这些想清楚：
工作区放哪
项目目录怎么分
共享文档放哪
当前活跃版本和归档版本怎么区分
哪些是协作说明，哪些是产出内容
这件事的价值在前期不明显，但中后期会越来越明显。 因为项目一复杂，目录结构本身就是上下文的一部分。
8. 把Codex当搭档
不要把 Codex 当“全自动工具”，把它当“能一起商量的搭档”
这是最后一个我特别想说的。
刚开始用 Codex，容易在两个极端之间来回摇摆：
要么期待它全自动，一句提示词搞定一切
要么一旦它没按预期来，就觉得“这工具不行”
但我自己的感受是，Codex最适合的位置，其实更像一个可以一起商量的搭档。
很多好用的方法，不是它自动冒出来的，而是先说出你的想法，再和它一轮轮讨论出来的。
比如我后来形成的一些文档结构、长期项目协作方式、恢复上下文的设计，本质上都不是“官方直接给我的答案”，而是我提出诉求，它再根据这个诉求帮我整理、调整、优化，最后才慢慢变成一套适合自己的方法。
所以在使用 Codex方面，我建议多试一种这样的思路：
除了给它任务，也和它共同讨论一些想法。
任务是“帮我做这个功能”。 想法是“我希望这个长期项目即使换对话也能继续推进”。 后者往往能引出更有价值的协作方式。
如果你刚开始想把 Codex用得更顺一点，我最建议先做这4 件事
看到这里，如果觉得上面内容太多记不住，那我建议先从下面 4 件事开始：
安卓项目先用 Android Studio 建好标准骨架，再让 Codex 接手
在项目根目录认真写一份 AGENTS.md，把关键约定放进去
不要把所有说明都塞进 AGENTS.md，只放导航和文档地图
给长期项目准备 plan / progress / todo / decision / build 这类恢复上下文文档（如果有小伙伴想要这几份文档的模板，也欢迎找我拿）
光是把这 4 件事做好，用 Codex 做项目的体验，大概率就会明显不一样。
最后
我现在越来越觉得，想把Codex用好，不只是“它会写代码”，而是能不能和它慢慢形成一套适合自己的协作方法。
有些技巧看起来不炫，甚至不高级，但它们真的很实用。 尤其是当项目开始变长、变复杂、变成长期协作之后，这些东西的价值会越来越明显。
希望这篇文章里提到的这些经验，能帮同样在用Codex的伙伴少走一点弯路。 不用一下子全照搬，可以先试那么一两条，感受一下是否能在日常项目中做得更顺。
有任何使用反馈，也欢迎在评论区和我一起交流，大家共同进步。
