让ChatGPT管项目，Codex只做Ticket：AI编程防失控实战

今儿 Claude 发了最新大模型，但我不想讲——太贵了，还只限之前的 Max 用户可见。

我现在看到最危险的提示词，就是那种许愿式的一句“帮我做个 App”。倒不是因为 Codex 不会做，恰恰相反，它太会往前冲了：补结构、加依赖、顺手重构、猜未来功能，最后甩给你一个看起来完整、自己却解释不清的项目。

Reddit 上有个帖子讨论 ChatGPT + Codex 怎么搭项目，核心观点很直白：ChatGPT 当架构师和项目经理，Codex 当那个一小票一小票干活儿的小工。

这个方法我觉得特别实用，因为它讲的是 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（票），小到能在 5 到 10 分钟内人工验收。比如只创建项目骨架，不加播放、不加保存、不加生成，跑完 build，报告改了哪些文件。这听起来好像很慢，但实际跑下来，往往比一次性全丢给它要快得多——因为它做的每一点都是你确认过、你想要的。

大任务的失败成本太高了。你让 Codex 同时处理生成、播放、保存、导出、UI，它很可能每一块都搞一点，最后哪儿都像半成品。等你再想改，得先搞明白它到底做了什么。小 ticket 的好处是：错了也好退，你能看懂，能验收，能把问题丢回去，也知道下一张票该做什么。

这就是 AI 项目该有的节奏感。

ChatGPT 和 Codex 要分工

我特别吃这套分工，尤其是最近 GPT-5 翻倍活动过后，我一头扎进了 20x。

ChatGPT 的 Pro 推理是真的牛，我说的不是在 Codex 里调用（那要付费 API），是在网页上选 Pro 的 Thinking 模型。你这么选，一用一个不吱声，虽然慢，极慢，但你看它的思考路径，详细又认真。

当然它有点小贵，最低也要 5x Pro，也就是 100 刀价格才能用，但物超所值，前提是你有明确的目标——它能极大压缩你的思考时间。

分工上，ChatGPT 负责规划、架构、路线、拆票、复盘；Codex 负责本地实现、改文件、跑命令、测试和报告。这不是因为 ChatGPT 一定比 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，提示词可以这么写：

只实现 T0001，不实现未来 ticket。
请先阅读 AGENTS.md、README.md 和 Tickets.md 里 T0001 部分。
只修改本 ticket 允许的文件。不要新增未要求的架构和依赖。
完成后运行可用的 build 或 test，并报告文件改动、命令结果、手动验证步骤、风险和后续建议。

它能让 AI 少猜。少猜，项目就稳。

什么时候不适合这么重

当然，不是所有任务都要这么搞。改个按钮文案，没必要整十个文档；写一小段脚本，也别拆成五张票。这套方法适合的是中等以上项目——会持续多天，有多个功能，会反复迭代，后面还要维护。尤其适合那些平时不算资深开发，但想用 AI 把项目做出来的人。它帮你防的主要是项目失控。

我的结论

这篇 Reddit 帖子让我更确定一个判断：AI 编程的核心能力，不是提示词越长越好，而是项目控制越清晰越好。ChatGPT 帮你想清楚方向；Codex 帮你把一张小票做完；AGENTS.md、Tickets.md、Repo_Current_State.md 这些东西，负责把记忆和规则放进仓库。它可能不会让你爽到“躺平就能执行”，但真要踏踏实实把项目做完，这个办法更靠谱。

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 写出来的 AGENTS.md，我一个十几年策划经验的人，要打磨到这种细节，大框架想满足可能都得花 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 继续管项目用的。没有报告，下一轮就会丢失项目状态。

跑完前五张小票，你应该拿到一个能本地启动的 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 给你一个看起来完整的“惊喜”——写代码这事儿，惊喜还是少点好。

每次我都想提醒一下：这不是凡尔赛，是希望有想法的人勇敢冲。我不会代码，英语也不好，但我做出来了不少东西。真心希望能影响更多的人去尝试新的技巧，去迎接这个新的时代。如果你也在琢磨怎么把 AI 编程的流程跑顺，云栈社区 上有不少开发者在聊这些实战节奏，不妨来看看。

谢谢你读我的文章。