PostLog inSign upPost唐华斑竹🦅@uniswap1230 分钟吃透 Codex 97% 的能力（完整教程）
大多数人打开 Codex，看到一个聊天窗口，就把它当成“侧边栏更花哨一点的 ChatGPT”。结果十个人里有九个，都会错过它真正能力的 97%。
他们不做 Skills，不把项目部署成线上 URL，也不会让自动化在自己睡觉的时候跑起来。下面这套 14 起来的 AI 工作流。整个过程按 30 分钟设计
Codex 是 OpenAI 的智能体式编程平台，不是 2021 年那个已经废弃的代码补全 API，而是新的 Codex。它最早在 2025 年 4 月以 CLI 形式发布，后来一路扩展成桌面 App、VS Code/Cursor/Windsurf 的 IDE 插件，以及云端 Agent。
Sam Altman 在 2026 年 4 月确认过，Codex 当时大约有 400 万周活用户。现在它是 Claude Code 最直接的竞争对手。
如果你用过 Claude Code，可以用一句话理解 Codex：你电脑上的一个项目文件夹，一个 Markdown 配置文件，一个会读取文件夹里所有内容的 Agent，再加上一层 Skills、MCP 服务器、自动化和内置浏览器。
外壳不同，模型不同，但底层玩法很像。
14 步。3 个层级。一个文件夹，跑起你的工作流。
第一部分：准备工作
01. 先选电脑上的项目文件夹
Codex 没有自己的数据库，没有自己的文件系统，也没有自己的“工作区”。一个 Codex 项目，本质上就是你电脑上任意位置的一个普通文件夹。你新建项目时，Codex 会打开文件选择器。
你选中一个文件夹。从那一刻起，文件夹里的所有文件都进入 Codex 的工作范围：它可以读、写、编辑、整理、移动。
这个设计看起来简单，但后面所有体验都会被它改变：
项目可迁移。 同一个文件夹可以用 Codex CLI 打开，也可以用 Codex App、VS Code/Cursor/Windsurf 的 IDE 插件打开，甚至也可以交给 Claude Code 或 Cursor。工具壳会变，工作本身不变。
像普通代码一样做版本控制。 Git、GitHub、Vercel 都是标准工具，不需要什么特殊集成。
备份、分享、迁移也很普通。 你怎么处理磁盘上的其他文件夹，就怎么处理这个项目。
默认情况下，Codex 运行在 Agent 模式：它可以在当前工作目录里自动读取文件、编辑文件、执行命令。但只要涉及文件夹外部的内容，或者要联网，仍然需要你的批准。这个文件夹，就是信任边界。
02. 写一份 AGENTS.md：Codex 第一个会读的入门文档
AGENTS.md 是 Codex 里最被低估的文件。它放在项目根目录。你每次在这个文件夹里打开一个新聊天，Codex 都会先读它。
它告诉 Agent：你是谁，这个项目是什么，目标长什么样，哪些约束很重要。
诀窍是：别从零开始写。你可以直接用自然语言告诉 Codex 项目目标，然后让它起草一份 AGENTS.md。它会先给你一个结构化版本，你再改。这样更快、更完整，也更不容易漏掉关键约束。
一份好的 AGENTS.md 通常包含这些内容：
Context： 一段话说明你是谁、为什么做这个项目。以后就不用每次重新解释背景。
Goal： 一段话描述最终状态，而不是具体步骤。步骤应该放在 Plan 模式里，也就是第 3 步。
Constraints： 用列表写硬规则。比如 API 选择、不能用的语言、安全边界、输出格式。越短、越具体越好。
Conventions： 用列表写工作习惯。比如“把失败经验保存到记忆里”“先确认计划再写代码”“永远不要运行 X”。这些约定会慢慢叠加成更稳定的行为。
OpenAI 自己的最佳实践指南也说得很直接：使用 Codex 时，最好别把它当成一次性的助手，而是当成一个可以配置、可以持续改进的队友。先给对任务上下文，用 AGENTS.md 留下长期指导，再按你的工作流配置 Codex。
03. 每次构建都先从 Plan 模式开始
Plan 模式的意思是：Codex 先不执行任何操作。它会头脑风暴、问澄清问题、列出取舍，然后给你一份编号计划，等你批准之后才开始写代码。跳过 Plan 模式，是构建跑偏的最大原因。
真正好用的模式是这样：
描述目标，不要规定步骤。 说“抓取我 YouTube 频道最近的评论，并整理成 Excel 报告”，不要一上来就说“用 Python 调 YouTube API，再写入 xlsx”。
让它问问题。 Codex 在 Plan 模式下一般会问 3 到 5 个澄清问题。认真回答。每一个问题，都是提前消掉的一个未来 bug。
批准计划之后再执行。 读一遍步骤。如果有哪里不对，比如漏了边界情况、工具选得奇怪、复杂度没必要，就直接指出来。在计划阶段改，比代码写完之后再返工便宜得多。
Plan 模式和 AGENTS.md 特别搭。配置文件里的约束，会直接影响 Codex 能提出什么样的计划。两者配在一起，可以大幅减少错误方向。
04. 用 .env.local 放 API Key
所有 API key、所有 secret、所有凭证，都应该放进项目根目录下的 .env.local。文件名前面的那个点不是装饰，它表示这是隐藏文件，也提醒 Codex 和 git 不要把它提交到公开仓库。
两个规则可以帮你少踩很多坑：
不要把 key 粘到随便一个secrets.txt里，更不要直接粘进聊天。 这两种做法最后都很容易进版本控制。一旦你 push，它们就可能公开。
加完 key 之后立刻测试。 让 Codex 做一次最小 API 调用，确认这个 key 能用。认证错误越早暴露，越不会拖垮后面的构建。
如果 key 真的被提交进 git 了，立刻去服务商那里轮换这个 key，比如 Google Cloud、OpenAI 等。不要只是从文件里删掉再提交一次删除记录。旧 commit 里仍然有这个 key，而且抓 GitHub 泄露密钥的机器人几分钟内就能扫到。唯一安全的修复方式，是轮换凭证。
第二部分：连接和构建
05. 连接 MCP 服务器和插件
Codex 支持 MCP（Model Context Protocol，模型上下文协议），也就是 Claude Code 使用的同一个开放标准。所以很多现有 MCP 服务器也能在 Codex 里用：GitHub、Slack、Notion、Linear、Drive、Figma，还有大量社区做的 MCP。
这会带来一个很关键的变化：你不用再口头描述数据给 Codex，它可以自己读取数据。你也不用只让 Codex 提建议，它可以直接执行动作。对话会从“我仓库里大概有这些东西”，变成“修这个问题，开一个 PR，并 tag 负责人”。
最快能见效的三个组合：
GitHub MCP： 读仓库、建分支、开 PR、评论 issue。对开发者来说，这是第一天就能产生价值的东西。
Vercel MCP： 部署、查状态、回滚。配合 GitHub，就能形成完整的“构建 → 提交 → 部署”闭环。
Notion 或 Drive MCP： 把内部文档拉进上下文，再把决策写回统一日志。Codex 就不再是一个黑箱，而会变成团队记忆的一部分。
06. 如果没有插件，就让 Codex 帮你接 API
不是每个服务都有 MCP 服务器。YouTube Data API 没有。公司内部 API 没有。很多小众 SaaS 工具也没有。
遇到这种情况，不用到处找第三方封装库。直接问 Codex。在 Plan 模式里告诉它集成目标，比如“抓取我 YouTube 频道最近的评论”。
它会给你几个选项，比如 API key 还是 OAuth，然后推荐一个方案，并输出一步步计划：怎么设置凭证，怎么启用相关 API，怎么测试连接。
这个模式用久了会越来越值钱：
先试第一条路。 Codex 会基于取舍选一个方案。先让它试。
失败了就保存经验。 比如“PowerShell 遇到 TLS 错误，Python 能跑通。把这个写进项目记忆里，以后别再走坏掉的路径。”下一次会继承这个经验。
把跑通的模式锁下来。 一旦某个集成稳定了，就把它做成 Skill，也就是第 9 步。以后不用重复搭一遍。
这是 Agent 工作里最重要的习惯之一：尝试，失败，保存失败经验，然后不要在同一个坑里摔第二次。Codex Agent 默认记忆很短，这次会话里学到的东西，如果不写下来，明天就没了。
只要某件事真的教会了它一个经验，就让 Codex 更新 AGENTS.md 或项目记忆。这个系统会越用越锋利。
07. 用具体提示词做一个真正可交付的东西
任何工具最终都要落到可交付成果上。对多数人来说，第一个成果应该是很具体的东西：一份 Excel 报告、一个自动化脚本、一个仪表盘、一份生成文档。它要能证明这个工具值得用。
决定你的第一次构建是好用还是普通，核心只有一条：提示词要具体。你说“分析我的 YouTube 评论”，它大概率会给你一个 Excel，里面是“正面、负面、中性”这种分类。没什么用。你说“分析我的 YouTube 评论，并按工具对比、内容请求、技术问题、一般反馈来分类，再按我作为创作者的回复优先级排序”，它就更可能产出一份你真的会用的工作簿。
两个能快速提升输出质量的习惯：
说清楚这个输出给谁用。 比如“给我这个创作者用”“给董事会更新用”“给我的工程团队用”。受众会影响结构。
列出你关心的分类桶。 不要把分类完全交给默认判断。直接告诉 Codex 你的分类体系。
如果第一版还行但不够好，不要直接推倒重来。把提示词补得更具体，再跑一轮。三轮更精准的迭代，通常比从头来五次更有效。
08. 写 UI 代码前，先用 gpt-image-2 出概念图
Codex 内置了基于 gpt-image-2 的图片生成能力。你可以在提示词里明确写 $imagegen 调用它，也可以直接描述你需要什么，Codex 会识别出来。
生成的图片会变成项目资产，后面的构建都可以引用。
真正打开这个能力的方式是：先生成概念图，再写 UI 代码。你可以先让 Codex 用一两张图模拟仪表盘的视觉方向，把图片保存到项目里。
然后再让它参考这些概念图来构建仪表盘。这样出来的视觉结果，通常比只给文字规格让模型自由发挥要更稳、更清楚。
09. 把工作流变成 Skills
Skill 是 Codex 可以按需加载的可复用配方。只要你已经跑通了一套工作流，比如拉评论、生成报告、部署仪表盘，就可以把它变成一个 Skill。下一次只需要一条命令。
Codex 里的 Skills 本质上是文件夹里的 Markdown 文件。目录里有一个带 frontmatter 的 SKILL.md，里面写名称、描述和操作说明。你也可以把脚本和参考文件一起放进去。
有两个存放层级值得知道：
全局 Skills： 放在 ~/.agents/skills/。你电脑上的所有 Codex 项目都能用。
项目级 Skills： 放在项目文件夹内部。只有这个项目能用。适合客户专属或项目专属的流程。
一个 Skill 能不能在需要的时候被触发，主要看三件事：
description 最关键。 Codex 做隐式调用时，只会拿任务和 description 文本匹配。把核心使用场景和触发词写在前面。描述太虚，基本就不会触发。
两种调用方式。 一种是显式调用，比如 CLI/IDE 里用 /skills，或者在提示词里点名 $skillname。另一种是隐式调用，也就是你的请求刚好匹配，Codex 自动选择这个 Skill。
开放标准。 Skills 在 2025 年 12 月进入 Codex，现在已经是跨平台 Agent Skills 标准的一部分。同一套格式可以在 Codex、Claude Code、Gemini CLI、Cursor 里用。写一次，到处跑。
10. 把 localhost 部署成线上 URL：GitHub → Vercel → production
Excel 表格算是后端结果。仪表盘才是前端。localhost 只是开发地址。它们都还不算真正交付。
要从 localhost 走到线上，需要接两个服务：GitHub 放代码仓库，Vercel 做托管。Codex 可以把整个流程串起来。
关键细节在于：GitHub 和 Vercel 初次连接之后，会一直保持联动。每次 push 到 main，都会自动触发一次 Vercel 部署。你不用再登录 Vercel。你在 Codex 里工作，Codex push 到 GitHub，Vercel 自动部署。三个工具，合成一个工作流。
11. 设置 Automations，并且明确指定模型
Codex App 里有一个 Automations 标签页。它可以设置按 cron 定时运行的提示词。把 Automations 和 Skills 结合起来，一个仪表盘就会从“我手动更新的东西”，变成“我睡觉时自己更新的东西”。
一个真实的周日晚自动化可以是：拉取最新评论，运行洞察 Skill，更新 Excel 文件，推送新数据，让 Vercel 自动部署。端到端刷新，全程不用碰。到周一早上，仪表盘就是最新的。
Automations 面板里的模型选择器，不会继承你当前聊天使用的模型。新建自动化时，它会默认用面板自己的默认模型；这个模型可能比你实际想用的生产模型更慢、更便宜。
所以每个自动化都要明确指定模型。不然你会疑惑：为什么一个本来 7 分钟能跑完的任务，突然要跑 40 分钟。另一个类似问题是：如果你本地正打开一个 Codex 需要覆盖的文件，先把它关掉。
12. 选对线程模式：Local、Worktree 或 Cloud
Codex App 里的每个线程，都运行在三种模式之一。选对模式，区别就是安全迭代和合并崩溃之间的区别。
Local： 直接在当前项目目录里工作。最快、最简单，但每一次改动都会碰到你真实的工作树。适合小范围、很确定的修改，而且你信任这个 Agent。
Worktree： 把改动隔离到一个 Git worktree 里，也就是同一个仓库旁边的一个兄弟工作目录。Agent 在单独分支上工作，不会影响你的主 checkout。任何有点分量的构建，都应该默认用它。如果这次运行跑偏了，把 worktree 扔掉就行。主目录零损伤。
Cloud： 在配置好的云端环境里远程运行。你的电脑可以关机。把它和第 11 步的 Automations 搭配，就能做真正异步的工作流，不依赖你的机器是否开着。
一个简单经验：有野心的任务用 Worktree，小而准的修改用 Local，长时间自动化任务用 Cloud。三种信任等级，每个任务单独选。
13. 把内置 Browser Use 当成 QA 循环
仪表盘做好之后，让 Codex 用内置浏览器打开它，点一遍，试着把它搞坏，然后回来报告。它真的可以这么做。
它能抓到你只看代码时容易漏掉的问题：外链坏了、空状态太空、搜索逻辑太死板、可访问性缺口、细小的 UI 不一致。
把这件事从一次性操作变成习惯的方法是：把 QA pass 写进项目记忆或 Skill。
以后每次发布新功能，Agent 在回到你面前之前，都会先跑一遍浏览器检查。你不再亲自当 QA 测试员。Agent 负责跑，你负责看报告。
Browser Use 不只是 QA 工具。只要某个服务没有 API，它就会变成通用操作工具：
登录没有 API 的工具，比如老后台、供应商门户、内部仪表盘。
从不提供程序化数据出口的仪表盘里拉报告，比如分析页面、账单工具、状态页。
自动执行你原本要手点的多步骤 UI 流程。你用自然语言描述步骤，Codex 去完成。
14. 用上大多数人忽略的 UX 功能
Codex App 里有一组 UI 功能，会把它从“我偶尔用的工具”，变成“我长期待在里面的工作区”。单独看都很小，但组合起来很有用。
Side chat： 从主对话旁边开一个侧边线程。同一个项目上下文，不同的对话。你可以临时问一个小问题，不污染主会话。问完就关。
Slash commands： 输入 / 浏览命令，比如 /skills 显式调用 Skill、/clear、/help 等。Slash 菜单会把 Codex 能做的事直接露出来。
@-mentions： 在提示词里点名某个文件，例如“参考 @example.tsx，新增一个页面，列出 @resources.ts 里的 items”。比手动粘路径干净得多。
模型切换器 + reasoning effort： 聊天输入框下面的切换器，可以给当前对话换模型。reasoning effort 控制 Codex 在回答前思考多久。更高 effort 复杂任务效果更好，但会消耗更多 token，也更快吃掉限额。按任务匹配就好。
$imagegen + Skills mentions： 输入 $ 可以在提示词里直接提到某个 Skill。语法和 @ 文件引用类似。这样你可以在一个提示词里组合多个 Skill。
IDE 插件自动同步上下文： 如果你在编辑器里装了 Codex IDE Extension，并且 App 和编辑器打开的是同一个项目，它们会自动同步。你能在编辑器里看到 App 里的线程，反过来也一样。打开 “Auto context” 后，Codex 还会跟踪你正在看的文件。
Full access mode： 在 Settings 里打开，可以跳过审批提示。更快，也更危险。建议先用默认模式。只有在你信任项目边界之后，再切到 full access。
让 Codex 一直停留在 3% 潜力的坏习惯
没有 AGENTS.md。每个会话都重新解释项目，每个会话都得到不一样的答案。
跳过 Plan 模式。一个一句话误解，最后变成四十个文件的 diff。
把 key 放进聊天或 secrets.txt。一 push 就可能公开。
从不保存经验。因为什么都没写下来，所以同一个错误一遍遍重来。
提示词太泛。拿到通用产出之后，又惊讶它怎么这么通用。
只做一次性构建。每周都从零重做同一套流程，而不是把它变成 Skill。
什么都用 Local 模式。一次跑偏的 Agent 运行，直接把你的工作树弄乱，因为你没用 worktree。
让 Automations 默认选择模型。明明 7 分钟能跑完的任务，拖成 40 分钟。
不做 QA pass。仪表盘外链坏了，空状态很丑，还是直接发出去。
工具阵营化。用身份认同来选 Codex 还是 Claude Code，而不是看眼前任务适合哪个。两者都有赢的时候。
结论
Codex 看起来像一个聊天窗口。但它不是聊天窗口。它是一个文件夹，里面有一个知道文件夹内容的 Agent，再加上一层 Skills、MCP、自动化和浏览器。这些东西都通过放在项目文件夹里的 Markdown 文件来配置。
这个文件夹是可迁移的。你可以用 Codex 打开它，也可以用 Claude Code、Cursor，或者任何支持 Agent Skills 标准的工具打开它。外壳会变，工作不会变。
大多数用户会继续只在聊天框里打问题，然后到此为止。他们会拿到答案，复制代码，然后离开。真正用 Codex ship 的那 400 万周活用户，是那些把文件夹配置起来的人。
挑一个你还没做的步骤，可能是 AGENTS.md，也可能是你的第一个真正 Skill，明天就加上。然后再加下一个。Codex 的输出质量，跟你对 Codex 的配置质量强相关。
空文件夹。工作流引擎。中间隔着这 14 步。
#AI #AIAgent @grok1:40 PM · Jun 12, 202615.7KViews10106464211211230230Read 10 repliesNew to X?Sign up now to get your own personalized timeline!
Sign up with GoogleSign up with AppleCreate accountBy signing up, you agree to the Terms of Service and Privacy Policy, including Cookie Use.
Relevant people唐华斑竹🦅@uniswap12FollowTrending nowTerms of Service|Privacy Policy|Cookie Policy|Accessibility|Ads info|More© 2026 X Corp.Don't miss what's happeningPeople on X are the first to know.Log inSign up