90% 的人，把 Codex 用反了

记录时间：2026-08-05 14:30:42

这篇笔记是个人观点，来自一条我最近在用的 Codex 使用方式。

大多数人用 Codex 的方式，是一上来就扔一句话：

帮我写一个 App。

然后 Codex 立刻开始生成文件、写代码。问题不在于它写不出东西，而在于它写的东西没经过验证。

架构是拍脑袋想的，坑是别人早就踩过的，需求也未必对得上。结果就是：一大堆代码生成了，然后你一句句推翻重来。token 烧在最没价值的地方。

先把 Codex 连上 GitHub

真正的省 token 技巧只有一句话：先调研，后动手。

第一步，给 Codex 连上 GitHub 插件。这一步是关键，它让 Codex 有能力去翻真实的开源项目，而不是凭空编。

然后，不要让它写代码。先发这样一段提示词：

我要开发一个 XXX。

暂时不要创建文件，也不要输出代码。

先在 GitHub 调研同类开源项目，筛选出最有参考价值的方案。分析它们解决了什么问题、采用什么架构、依赖哪些技术、目前是否活跃，以及有哪些设计值得复用或避开。

最后结合我的需求，给出技术选型、系统架构、MVP 范围和开发顺序。得到我的确认后，再进入实现阶段。

它会帮你做三件事

方向确定之前，Codex 会先做三件事：

1. 找到经过真实项目验证的方案——别人已经跑通过的架构，比它现场编的靠谱得多。
2. 研究别人已经踩过的坑——issue、PR、弃坑原因，提前帮你避开。
3. 根据你的需求做技术取舍——选型、架构、MVP 范围，全部对齐你的实际情况。

等这三件事做完，你拿到的是一份有依据的方案，而不是一堆待推翻的代码。

确认之后，再让它写

Codex 给出方案后，你只需要确认或微调。比如：

MVP 砍掉后台管理，先做核心流程。

然后发一句「开始实现」，它才真正动手。

这时候生成的代码，命中率高、返工少。前面省下的调研 token，远小于你反复推翻重写浪费的 token——据说整体能省下大约 90%。

没有 GitHub 插件也行

如果你的 Codex 没有 GitHub 插件，把调研环节换成 web 搜索 + 读文档 一样有效。核心不是工具，而是顺序：先研究，再实现。

把顺序调对，Codex 才真正从「代码生成器」变成「能帮你做技术决策的搭档」。