你用的 Codex，可能只发挥了 3% 的能力
打开 Codex，第一眼看到的是一个聊天框。很多人就停在这里了——问问题、复制代码、关掉。
这么用，你大概只用到了它 3% 的能力。
我花了两周把 Codex 从头到尾跑了一遍，踩了不少坑，也摸清了它真正有用的地方。下面是我整理出来的 14 个步骤，从建文件夹开始，到自动化跑起来，基本上把核心流程都覆盖了。
14 个步骤。3 个层次。一个文件夹搞定所有工作流。
第一部分：基础设置
01. 项目文件夹就是一切
Codex 没有自己的数据库或工作区。一个项目，就是你电脑上的一个普通文件夹。新建项目时选好文件夹，里面的文件 Codex 都可以读、写、编辑、移动。
这个设计有个实际好处：同一个文件夹可以在 Codex CLI、桌面应用、VS Code/Cursor/Windsurf 插件里打开，甚至拿去给 Claude Code 用也没问题。工具换了，项目内容不动。Git、GitHub、Vercel 都是标准工具，不需要任何特殊集成。备份、分享、迁移，和操作普通文件夹没区别。
Codex 默认以 Agent 模式运行，可以自动读写工作目录内的文件。文件夹外的内容和网络访问需要你手动批准。文件夹就是信任边界，记住这一点。
02. AGENTS.md：最被忽视的文件
这是 Codex 里最容易被跳过、但影响最大的东西。
AGENTS.md 放在项目根目录，每次开新对话时 Codex 都会读它。它告诉 AI：这个项目是干什么的、有哪些硬性规则、你希望它怎么工作。
不要从头写。直接告诉 Codex 你的项目目标，让它帮你起草一份，然后再改。我第一次自己写花了半小时，后来让 Codex 生成再修改，10 分钟搞定，质量还更好。
一份有用的 AGENTS.md 大概包含这几块：
背景：一段话，说清楚你是谁、做什么项目。省去每次对话都重新解释的麻烦。
目标：描述最终想要什么，不是具体步骤。步骤留给计划模式（步骤 03）去生成。
约束条件：硬性规则列表。比如用哪个 API、不能用什么语言、输出格式是什么。越短越好。
工作习惯：比如"失败的方法写进项目记忆"、"写代码前先确认计划"。这些会慢慢积累成稳定的工作模式。
# 项目：B站评论智能分析
## 背景
我运营一个关于 AI 工具的 B 站频道。我想了解
观众在问什么、他们想看什么、他们在比较什么工具——
而不用手动阅读每条评论。
## 目标
构建一个工作流，提取最近的评论、对其分类、
发现模式，并在实时仪表板上可视化结果。
## 约束条件
- 使用 B 站 API 和 API 密钥
- 将凭证保存在 .env.local 中，永远不要提交到代码仓库
- 输出目标：用于分析的 Excel 工作簿 + Web 仪表板
- 将仪表板部署到 Vercel
- 通过自动化每周刷新数据
## 工作习惯
- 将失败的方法保存到项目记忆中，避免重复犯错
- 在编写代码之前始终确认计划
OpenAI 官方文档里有一句话我觉得说得很准：把 Codex 当成可以持续配置的队友，而不是一次性工具，效果会好很多。
03. 计划模式：每次都先过这一关
计划模式下 Codex 不会直接动手。它先提问、列方案、给出权衡，然后生成一个编号计划，等你确认后再执行。
跳过这一步是项目出问题最常见的原因。我自己就吃过亏——直接让它写代码，结果改了 30 个文件才发现方向不对，回头重来比走计划模式慢多了。
几个用好计划模式的方法：描述目标而不是步骤，比如"提取最近 200 条评论生成 Excel 报告"，而不是"用 Python 调 API 然后写入 xlsx"。让它提问，通常会有 3-5 个澄清问题，认真回答，每个问题背后都是一个潜在的 bug。拿到计划后仔细看，发现问题在这里改，比写完代码再改省事得多。
计划模式和 AGENTS.md 配合效果最好：配置文件里的约束条件会直接影响 Codex 给出的方案，两者结合能少走很多弯路。
04. .env.local 管密钥
所有 API 密钥放在项目根目录的 .env.local 文件里。文件名前面的点不是随便加的，这告诉 Codex 和 git 不要把这个文件提交出去。
两条必须遵守的规则：不要把密钥粘贴到 secrets.txt 里，更不要直接粘贴到聊天消息里——这两种做法迟早会进版本控制，一旦推送就公开了。加完密钥立刻让 Codex 做一个最小的 API 调用验证，别等到整个项目跑起来才发现认证报错。
如果密钥不小心提交了，去服务商那里轮换密钥。光从文件里删掉再推送没用——旧的提交记录里密钥还在，扫描脚本几分钟内就能找到。唯一安全的做法是轮换凭证。
第二部分：连接与构建
05. MCP 服务器：让 Codex 直接操作你的数据
Codex 用的是模型上下文协议（MCP），和 Claude Code 用的是同一个开放标准。现有的大多数 MCP 服务器都能直接用：GitHub、Slack、Notion、Linear、Drive、Figma，还有几十个社区维护的服务器。
接上 MCP 之后，你不再是向 Codex 描述数据，而是让它直接读。不再是说"帮我创建一个 PR"，而是它真的去创建。对话从"这是我代码仓库里的内容"变成了"用这个修复创建一个 PR 并通知负责人"。
最值得先接的三个：GitHub MCP（读仓库、建分支、发 PR，对开发者来说收益最直接）、Vercel MCP（部署、检查状态、回滚，和 GitHub 配合就是完整的构建到上线流程）、Notion 或 Drive MCP（把内部文档拉进来作为上下文，把决策记录写回知识库，Codex 不再是黑盒，而是团队记忆的一部分）。
06. 没有 MCP 时，让 Codex 帮你搞定 API
不是每个服务都有 MCP 服务器。B 站 API 没有，公司内部系统也没有，很多小众 SaaS 工具也没有。
这种情况不用找第三方封装库，直接在计划模式里告诉 Codex 目标。它会给出几个方案（比如 API 密钥 vs OAuth），推荐一个，然后生成分步计划来设置连接和测试。
有一个习惯值得养成：失败的方案要记下来。比如"PowerShell 有 TLS 问题，Python 可以，把这个写进项目记忆"。Codex 的 Agent 只有短期记忆，对话结束就忘了，除非你主动写下来。每次遇到值得记的教训，告诉它更新 AGENTS.md 或项目记忆，系统会越用越顺。
07. 提示词要具体
工具的价值在于交付物。第一次构建质量好不好，基本上取决于提示词有多具体。
"分析我的评论"会给你一个只有"积极/消极/中性"三列的 Excel，没什么用。"分析评论并按工具对比、内容建议、技术问题、一般反馈分类，然后按回复优先级排序"才会给你一个真正能用的工作簿。
两个快速提升质量的方法：说明输出的用途（"给我自己看"、"给团队汇报用"），受众决定结构；列出你关心的分类维度，不要让模型自己猜。
第一版不够好，不要推倒重来。加更多细节重新跑，用清晰的提示词迭代三轮，比从头来五次效率高。
08. 先生成概念图，再写 UI 代码
Codex 内置图像生成，用的是 gpt-image-2。在提示词里用 $imagegen 显式调用，或者直接描述需要什么，它会自动识别。
生成的图像会存进项目资源，后续构建可以引用。实际用下来，先生成一两张概念图再让它写 UI 代码，最终效果比直接凭文字描述设计要好不少。视觉上更有参照，生成的界面也更接近你想要的。
09. 把工作流存成 Skill
Skill 是可重用的配方。一旦某个工作流跑通了，把它存成 Skill，下次一条命令就能触发，不用重新解释。
Codex 里的 Skill 就是文件夹里的一个 markdown 文件，包含前置元数据和指令正文：
---
name: bilibili-comment-insights
description: 提取最近 B 站视频评论，按工具对比、内容建议、
技术问题、一般反馈分类，按回复优先级排序，输出带图表的
Excel 工作簿。当我说"评论分析"或"本周报告"时触发。
---
# B 站评论分析
## 设置
- 从 .env.local 读取 BILIBILI_API_KEY
- 获取最近 10 个视频的约 200 条评论
## 分类
- 类别：工具对比、内容建议、技术问题、
一般反馈、无关内容
- 优先级信号：问题 > 高互动评论 > 其他
## 输出
- 工作簿选项卡：摘要、分类、优先回复、内容创意、原始数据
- 摘要页图表：类别分布存储有两个级别：全局（~/.agents/skills/，所有项目可用）和项目级（项目文件夹内，只在该项目用，适合客户专属配方）。
描述写得好不好决定了 Skill 能不能被自动触发。把关键触发词放在描述前面，模糊的描述不会被匹配到。调用方式有两种：显式调用（CLI/IDE 里的 /skills 或 $skillname）和隐式调用（提示词和描述匹配时 Codex 自动选择）。
另外，Skill 格式已经是跨平台标准，Codex、Claude Code、Gemini CLI、Cursor 都支持。写一次，哪里都能用。
10. 部署：GitHub → Vercel → 上线
本地跑通之后要上线。接两个服务：GitHub 管代码，Vercel 管托管。
> 把项目连接到 GitHub，创建名为 "comment-dashboard" 的私有仓库并推送。
▲ Codex 认证中…
- 创建了 github.com/you/comment-dashboard（私有）
- 初始提交已推送
✓ 仓库就绪
> 把 Vercel 连接到同一个 GitHub 账户，导入这个仓库，部署。
▲ Codex 连接 Vercel…
- 已创建 vercel 项目
- 构建在 38 秒内成功
✓ 已上线：https://comment-dashboard.vercel.app
初始连接之后，每次推送到 main 分支 Vercel 会自动部署，不需要再手动登录。你在 Codex 里改代码，Codex 推到 GitHub，Vercel 自动跟上。三个工具，一个工作流。
第三部分：自动化与进阶
11. 自动化任务要手动指定模型
Codex 的自动化选项卡支持 cron 表达式定时任务。和 Skill 结合，就是让仪表板"自己更新"的方法——周日晚上自动跑：提取新评论、运行分析 Skill、更新 Excel、推送、Vercel 自动部署。周一早上打开，数据已经是最新的。
有一个坑要注意：自动化面板的模型选择器不继承你对话的设置，新建任务会用面板默认值，可能比你想要的慢很多。我有一次忘了设置，原本 7 分钟的任务跑了 40 分钟。每个自动化任务都要手动指定模型。另外，如果 Codex 需要覆盖某个文件，但你本地正好打开着它，任务会出问题，先关掉再跑。
12. 三种线程模式按情况选
Local（本地）：直接在项目目录里改文件，最快，但改动立刻生效。小修小补用这个。
Worktree（工作树）：在独立分支里工作，不影响主分支。任何重要的构建都应该用这个。跑坏了直接删 worktree，没有损失。
Cloud（云端）：在云端运行，你的电脑可以关机。配合自动化任务用，适合长时间跑的任务。
简单记法：重要工作用 Worktree，小改动用 Local，长任务用 Cloud。
13. 内置浏览器做 QA
仪表板做好后，让 Codex 在内置浏览器里打开它，点一遍，找问题，然后报告。
它会发现你盯着代码看不出来的东西：失效链接、空状态没有提示、搜索太死板、小的 UI 错位。我第一次用这个功能，找出了三个自己没注意到的问题。
更好的做法是把 QA 测试写进 Skill 或项目记忆，每次发布新功能都自动跑一遍。你不用再当测试员，看报告就行。
浏览器还有另一个用途：当某个工具没有 API 时，用浏览器自动化代替。登录传统管理后台、从只有 UI 的仪表板里导出报告、自动化多步点击流程，用自然语言描述步骤，Codex 执行。
14. 几个容易忽略的 UX 功能
侧边对话：从主对话开一个侧边线程，相同项目上下文，独立对话。快速问问题不污染主线程，用完关掉。
斜杠命令：输入 / 可以看到所有功能，/skills 显式调用 Skill，/clear 清空对话。
@ 提及文件：在提示词里用 @filename.tsx 引用特定文件，比粘贴路径干净。
模型切换器 + 推理强度：输入框下方可以按对话切换模型。推理强度越高，复杂任务表现越好，但消耗 token 更多，也更容易触发速率限制。简单任务不用拉满。
可以内联提及技能，和 @ 用于文件的语法相同，可以在一个提示词里组合多个技能。
IDE 扩展自动上下文同步：安装了 Codex IDE 扩展后，应用和编辑器在同一项目里会自动同步。编辑器内能看到应用里跑的线程，反之亦然。开启"自动上下文"让 Codex 跟踪你正在看的文件。
完全访问模式：设置里可以关掉批准提示，更快但也更危险。先用默认，熟悉项目边界之后再考虑开。
用 Codex 只发挥 3% 的常见习惯
没有 AGENTS.md，每次对话重新解释项目，每次得到不同的答案。跳过计划模式，为了修一句话的误解改了几十个文件。密钥放在聊天消息里，推送之后就公开了。从不记录教训，同样的坑踩了三遍。提示词太模糊，结果通用，然后觉得工具没用。工作流跑通了不存 Skill，每周从头重建。所有事情都用 Local 模式，AI 一次运行出错把工作文件清空了。自动化任务忘了指定模型，跑了六倍的时间。发布之前没做 QA，上线的仪表板有坏链接。工具站队，根据习惯而不是任务本身选 Codex 还是 Claude Code，两者各有优势。
最后说几句
Codex 的外壳是聊天窗口，但它不是聊天工具。它是一个文件夹，加上一个读懂这个文件夹的 AI Agent，再加上 Skills、MCP、自动化和内置浏览器，全部通过 markdown 文件配置。
这个文件夹可以在 Codex、Claude Code、Cursor 里随便切换，工具换了内容不变。
大多数人会继续在聊天框里问问题，复制代码，关掉。真正把它用起来的，是那些花时间配置好文件夹的人。
如果你现在只想做一件事，先把 AGENTS.md 写好。其他的慢慢来。
