用ChatGPT管项目，让Codex只做Ticket
今儿Claude发布了最新的大模型，但是老金不想讲，因为它对咱来讲太贵了，而且还是仅限于之前的Max用户才可见。
我现在看到最危险的提示词，就是让它直接Build my app，就是那种许愿式的，我要个XXXX，结束了。
不是因为Codex不会做。恰恰相反，因为它太会往前做了。它会补结构、加依赖、顺手重构、猜未来功能，最后给你一个看起来很完整、但你自己也解释不清的项目。
Reddit上有个帖子讨论ChatGPT加Codex怎么搭项目，核心观点很简单：ChatGPT当架构师和项目经理，Codex当一个小节点一个小节点的实现工人。
当然这套理论用在其他同类产品上都可以，不过老金作为GPT的死忠，还是要吹一波，如果只论推理能力，我认为还是没有能比得上他的，因为对我这种策划出身的人来讲，正确性是最被关注的。
图片加载中…
这个方法我觉得很实用。因为它讲的是AI编程里最容易被忽略的一件事：真正决定项目能不能活下来的，不是第一版生成得多快，而是你能不能控制范围。
先做文档包，再让Codex动手
帖子里提到的做法是，Codex动手前先准备一组项目文档。
README.md负责项目基本信息。AGENTS.md负责告诉Codex项目规则。Tickets.md把整个项目拆成小任务。Manual_Verification_Guide.md写清每个任务怎么验收。Repo_Current_State.md记录当前真实状态。Prompt_Playbook.md保存常用Codex提示词。
你想一下，一个人类新人加入项目，也不能只听一句帮我把App做了。你要告诉他项目目标、技术栈、目录结构、哪些东西不能碰、这次只做哪一步、做完怎么验收。
AI也一样。
AGENTS.md在这里尤其关键。它不是装饰，它是给Codex看的项目规则规范。
比如只实现当前ticket，不做未来功能，不重构无关系统，不随便加依赖，能跑测试就跑测试，最后报告改了哪些文件、跑了哪些命令、怎么手动验证。
这类规则写在一次提示词里，很容易被后面上下文冲掉。写进仓库，才更稳定。
最小可治理化才是核心
这套工作流最重要的一句话，是每次只给Codex一个小ticket，这里我就按照原文翻译了，票，虽然我觉得有点绕嘴。。。
小到什么程度？
帖子里建议，一个好ticket应该能在5到10分钟内人工验收。比如只创建项目骨架，不加播放，不加保存，不加生成，不加未来功能。跑完build，报告改了哪些文件。
这可能让你觉得很慢，但是实际操作下来，它往往要比一次性做快很多。
因为它做的都是你确认过的，你想要的。
大任务的失败成本太高。你让Codex同时做生成、播放、保存、导出、UI，它很可能每一块都做一点，最后哪里都像半成品。你再想改，就得先理解它到底做了什么。
小ticket的好处是，错了也好退。
你能看懂。你能验收。你能把问题丢回去。你也知道下一票该做什么。
这就是AI项目的节奏感。
ChatGPT和Codex要分工
我很喜欢这个分工，尤其最近GPT5x翻倍活动过后，我是一股脑的冲进了20x。
ChatGPT的PRO推理是真的很牛逼。。我说的不是Codex内，Codex内调用Pro需要付费API。
我指的就是在网页上，调用Pro的Thinking模型。
你就这么选，一选一个不吱声，虽然很慢，特慢，但是你看他的思考路径，就非常的详细且认真。
当然它可能有点儿小贵，最低也要5xPro，也就是100刀的价格才能使用，但物超所值，前提是你有明确的目标，他能极大的压缩你的思考时间。
图片加载中…
ChatGPT负责规划、架构、路线、拆票、复盘。Codex负责本地实现、改文件、跑命令、测试和报告。
不是因为ChatGPT一定比Codex聪明，也不是因为Codex不能规划。而是项目里规划和执行最好分开。一个负责想下一步，一个负责把当前这一步做好。
如果你让Codex一边设计路线，一边写代码，一边验收自己，很容易出现一种问题：它会为了让当前实现合理，顺手改变项目方向。
这在碳基团队里也是同理，项目经理、架构师、工程师、测试不是同一个角色。AI可以帮你扮演这些角色，但你要把边界讲清楚。
每次结束都要报告
帖子里还有一个细节，我觉得很实用：每次Codex跑完，都要给完成报告。
报告里至少有这些东西。
改动摘要。改了哪些文件。跑了哪些命令。build或test结果。手动验证步骤。风险。后续ticket。需要更新的文档。
这里最大的作用是你要把Codex的执行结果带回ChatGPT，让ChatGPT判断下一步。如果没有报告，下一轮规划就会凭感觉。项目慢慢就飘了。
图片加载中…
Reddit另一篇Codex CLI技巧里也提到，AGENTS.md应该先设置好，让Codex知道你的项目、约定、哪些能自动做、哪些要你批准。这和小ticket工作流是同一件事。
先立规矩，再让AI动手。
普通人可以直接照这个模板
如果你现在想做一个小项目，不要第一句话就让Codex全做。
先让ChatGPT帮你生成这些东西，通常最核心的大概如下结构。
项目一句话目标。
MVP范围，只写第一版必须有的功能。
技术栈和目录结构。
AGENTS.md项目规则。
前10个ticket，每个ticket都有目标、允许改动范围、禁止事项、验收标准。
然后把第一个ticket给Codex。
Codex提示词可以这么写：
只实现T0001，不实现未来ticket。
请先阅读AGENTS.md、README.md和Tickets.md里T0001部分。
只修改本ticket允许的文件。不要新增未要求的架构和依赖。
完成后运行可用的build或test，并报告文件改动、命令结果、手动验证步骤、风险和后续建议。
它能让AI少猜。少猜，项目就稳。
什么时候不适合这么重
当然，不是所有任务都要这么做。
你只是改一个按钮文案，没必要搞十个文档。你只是写一段脚本，也不用拆成五张票。
这套方法适合的是中等以上项目：会持续多天，有多个功能，会反复迭代，后面还要维护。尤其适合那些平时不算资深开发，但想用AI把项目做出来的人。
它帮你防的主要是项目失控。
我的结论
这篇Reddit帖子让我更确定一个判断：AI编程的核心能力，不是提示词越长越好，而是项目控制越清楚越好。
ChatGPT可以帮你想清楚方向。Codex可以帮你把一张小票做完。AGENTS.md、Tickets、Repo_Current_State这些东西，负责把记忆和规则放进仓库。
它可能不会让你躺平执行那么爽，但真要把项目做完，它更靠谱。
AI不是不能开快车。问题是你得有方向盘、刹车和验收点。
让ChatGPT管项目，让Codex只做当前小票。
这可能是咱普通人，尤其像我这样不懂代码的人，用AI做项目，最少走弯路的一条路。
先用一个小项目练节奏
下面用一个很普通的例子：做一个个人读书记录小工具。你可以把它替换成课程页、内部表单、小游戏、数据看板。
先别打开Codex。先让ChatGPT帮你把项目缩小：
我想做一个个人读书记录小工具。
请你先作为项目经理，不写代码。
输出：
1、一句话产品目标。
2、第一版MVP只包含哪些功能。
3、明确不做哪些功能。
4、推荐技术栈。
5、目录结构草案。
6、前10个ticket，每个ticket都要能在5到10分钟内人工验收。
你应该拿到一个小项目计划。
重点看非目标，注意，非目标不是约束，约束指的是原则性的，是必须遵守的限制。
而非目标是不用做的。比如它第一版就想做登录、云同步、社交分享、AI推荐，那么删掉。
图片加载中…
第一版只做MVP，也就是最小可验证版本就够，比如本地增删改查，和简单统计就够。
图片加载中…
然后继续让ChatGPT写项目规则：
请为这个项目生成AGENTS.md。
要求：
1、Codex每次只实现一个ticket。
2、不能实现未来功能。
3、不能重构无关文件。
4、新增依赖必须说明理由。
5、完成后必须报告文件改动、命令结果、手动验证步骤和风险。
6、如果需求不清楚，先提问，不要猜。
把这个文件放进项目根目录。它的作用是让Codex每次进项目都先读规则。
你就看Pro写的这个Agent，反正我一个十几年策划经验的人，要想打磨到这个细节，大框架要满足可能就得花费2-3天才能补齐，如果说是细节，可能需要1-2周。
不是因为不会，是因为人的记忆无法能瞬时反应记录的很完美，它这几分钟就出了小400行的严谨的规则规范。
这才是老金说的，最省时间的地方，避免之后来回擦屁股。
图片加载中…
以下我只讲咋做，就不实操了，感兴趣的小伙伴可以做完，老金可以保证你能直接出个小产品。
第一个ticket最好只做项目骨架：
请阅读AGENTS.md和Tickets.md。
只实现T0001：项目骨架。
目标：
创建一个Vite + React + TypeScript项目骨架，能本地启动，显示一个空白读书记录页面标题。
允许修改：
package.json
src目录
基础配置文件
禁止：
不要实现新增书籍。
不要实现列表。
不要实现编辑删除。
不要接数据库。
不要新增未来ticket功能。
验收：
1、能安装依赖。
2、能运行开发服务器。
3、页面能看到读书记录标题。
4、报告改动文件和运行命令。
这一票做完，你应该拿到项目骨架、启动命令和文件清单。不要嫌它小。小就是为了能收。
你本地跑它给的命令。页面打开了，就让ChatGPT更新Repo_Current_State.md，然后生成T0002提示词。
T0002可以做新增书籍表单。T0003做列表展示。T0004做编辑。T0005做删除。每一票都保持小。
如果某一票失败，你不要让Codex顺手修整个项目。只让它修当前ticket。
每票结束都要产出交接报告。这个格式可以写死：
请按这个格式结束：
完成内容：
修改文件：
新增文件：
运行命令：
测试或构建结果：
手动验证步骤：
风险：
没有完成的部分：
建议下一张ticket：
这个报告就是给ChatGPT继续管理项目用的。没有报告，下一轮就会失去项目状态。
跑完前5张小票，你应该拿到一个能本地启动的MVP，而不是一堆半成品文件。它应该有可运行项目、清楚的目录结构、AGENTS.md项目规则、Tickets.md任务清单、Repo_Current_State.md当前状态，还有每张ticket的完成报告。
如果你只有代码，没有这些状态文件，后面迭代会越来越难。
这个工作流不是看Codex写得快不快，而是看项目有没有失控。每张ticket能不能在10分钟内看完，Codex有没有做未来功能，每次改动能不能说清原因，每次结束有没有命令结果和手动验证步骤，ChatGPT能不能基于Repo_Current_State继续生成下一张票。
这些都能做到，你就有了一个能持续推进的AI项目节奏，以及更重要的，信心。
翻车也基本就几类。
1、票太大，就拆成只改一个页面、一个组件或一个状态流。
2、AGENTS.md太空，就别写请保持高质量，要写不能做什么、必须报告什么、哪些目录不能碰。
3、Codex开始自作主张，就把禁止事项提前，并要求它发现范围外问题时只报告，不修。
4、ChatGPT和Codex状态不一致，就每票结束更新Repo_Current_State.md，不要相信聊天记忆能永远准确。
最关键的还是手动验收。
AI跑过测试不等于用户体验正常。每张票都要有你能亲手点的检查动作。否则你不是在管项目，你是在等AI给你一个看起来完整的惊喜。
惊喜这个东西，写代码时最好少一点。