loading image

别再伺候 AI 了:5 个方法狠狠压榨 Codex

这篇文章想解决一个很具体的问题: 你已经开始用 Codex 了,但每次还是要自己复制资料、补充背景、反复解释需求,最后感觉不是 AI 在帮你省时间,而是你在陪 AI 加班。 我自己也经历过这个阶段。 刚开始用 Codex 的时候,我最常做的事就是一句一句指挥它:看这个文件、改这里

Posted by Enovace on May 29, 2026

这篇文章想解决一个很具体的问题:

你已经开始用 Codex 了,但每次还是要自己复制资料、补充背景、反复解释需求,最后感觉不是 AI 在帮你省时间,而是你在陪 AI 加班。

我自己也经历过这个阶段。

刚开始用 Codex 的时候,我最常做的事就是一句一句指挥它:看这个文件、改这里、再检查一下、换个说法。它确实能帮忙,但人还是一直盯着,精神并没有轻松多少。

后来我发现,Codex 真正好用,不是因为我写出了多么神的 prompt,而是我开始把一些重复动作交给它自己跑:

让它读邮件、找资料、连 Obsidian、每天定时整理信息,再把常用流程沉淀成 Skills。

这篇就把我目前最常用的 5 个方法整理出来。你不需要一次全配完,先挑一个最适合自己的场景试起来就行。

如果你是 Codex 新手,看完至少能拿走:

  1. 插件怎么用:让 Codex 接上 Gmail、Google Drive、GitHub 这类工具
  2. Goal Mode 怎么用:别每一步都手动指挥,直接给它目标
  3. 自动化怎么用:让 Codex 到点自己跑重复任务
  4. MCP + Obsidian 怎么用:让 Codex 读取你的知识库
  5. Skills 怎么用:把常用流程固化成可复用能力

我越来越觉得,Codex 效率提升的关键,不是“多聊几句”,而是慢慢减少那些你每次都要重复说的话。

1.插件:先让 Codex 长出手脚

没有插件的 Codex,只能回答你。

接上插件以后,它才开始能做事。

OpenAI 官方教程里说得很直接:插件让 Codex 连接其他工具和信息来源,比如 Google Drive、邮箱、外部系统。翻译成人话就是:你不用再把一堆资料复制粘贴给它,它可以自己去工具里找。

我最直观的感受来自 Gmail。

以前处理邮件很烦:先扫标题,再点进去看,再判断要不要回,再想怎么回。尤其是合作、报价、客户跟进这种邮件,一天多几封就很耗精神。

现在我会直接让 Codex 用 Gmail 插件处理第一轮:哪些紧急、哪些要回、哪些只是通知,先筛出来。需要回复的,它先起草。我只负责看一眼,改两句。

这一步很关键。不要只让 AI “想”,要让它能“动手”。

Gmail、Slack、Figma、Notion、Google Drive、GitHub,这些插件接上以后,Codex 就不再只是一个聊天 AI,而是能进工具里帮你干活的助手。

小白怎么配:

  1. 打开 Codex app。
  2. 进左侧或设置里的 Plugins。
  3. 搜索 Gmail / Google Drive / GitHub 这类插件。
  4. 点安装或连接。
  5. 按提示登录授权。
  6. 回到对话里,明确告诉 Codex 用哪个插件。

图像

直接复制这个命令:

请使用 Gmail 插件帮我整理今天的邮件。

目标:
找出今天真正需要我处理的重要邮件,并帮我准备回复草稿。

成功标准:
1. 按“紧急处理 / 需要回复 / 仅需了解 / 可以忽略”分类
2. 每封重要邮件都要总结:发件人、主题、核心诉求、建议动作
3. 需要回复的邮件,请帮我起草一版简短、自然、不像 AI 的回复
4. 最后给我一份今日邮件处理优先级清单

边界条件:
1. 不要自动发送邮件
2. 不要删除、归档、移动任何邮件
3. 不要修改邮件标签
4. 如果需要代表我发送、转发或授权,请先问我

工作方式:
1. 先搜索今天的邮件
2. 再筛选重要邮件
3. 再生成摘要和回复草稿
4. 完成后告诉我你筛选了多少封邮件,哪些需要我亲自处理

2.Goal Mode:不要给任务,给目标

很多人用 Codex,是这样用的:

“帮我看一下这个文件。”

“再改一下。”

“这里不对。”

“继续。”

这其实还是你在牵着它走。你累,它也容易跑偏。

Goal Mode 更像是你给它一个终点,然后让它自己拆步骤、执行、检查、修正。

OpenAI 在 2026 年 5 月 21 日的 release notes 里提到,Goal mode 已经在 Codex app、IDE extension 和 CLI 里可用。你可以定义结果和成功标准,让 Codex 持续朝目标推进。

比如排查 Bug,不要只说:

帮我看看哪里错了。

你要说:

/goal
目标:排查当前项目启动失败的原因,修复问题,并运行测试确认项目可以正常启动。

成功标准:
1. 找到明确原因
2. 完成代码修复
3. 项目可以成功启动
4. 给我总结你改了什么、为什么改

我以前让 Codex 改格式,也踩过坑。一开始我会一步步说:先改标题,再调引用,再检查格式。后来发现没必要。

更好的方式是直接告诉它:把这篇论文改到目标期刊格式,成功标准是标题、摘要、引用、图表编号、参考文献都符合要求,最后给我修改总结。

普通模式是你说一步,它走一步。

Goal Mode 是你定义终点,它自己找路。

小白怎么配:

  1. 打开 Codex app。
  2. 进入一个 Project。
  3. 在输入框输入 /goal。
  4. 写清楚目标、资料范围、成功标准。
  5. 让它开始执行。
  6. 中途只在必要时介入。

如果你看不到 /goal,可以在 CLI 里检查:

codex features list

如果 goals 没开,再运行:

codex features enable goals

然后重启 Codex。

直接复制这个命令:

请进入 Goal mode。

目标:
帮我排查当前项目无法正常启动的原因,修复问题,并确认项目可以正常运行。

背景资料:
1. 当前项目文件夹就是你可以读取和修改的范围
2. 如果项目里有 README、AGENTS.md、package.json、日志文件,请优先阅读
3. 如果需要运行命令,请先选择安全、常规的检查命令

成功标准:
1. 找到导致项目无法启动的明确原因
2. 完成必要修复
3. 成功运行启动命令或测试命令
4. 输出一份修复总结,说明你改了哪些文件、为什么改、如何验证成功

边界条件:
1. 不要删除原始文件
2. 不要重置 Git 历史
3. 不要擅自覆盖用户已有修改
4. 涉及安装依赖、联网下载、修改配置、删除文件时先说明原因
5. 如果遇到权限、账号、密钥问题,先停下来问我

工作方式:
1. 先拆解排查步骤
2. 再读取项目关键文件
3. 然后定位问题并提出修复方案
4. 执行修复后自测
5. 如果第一次修复失败,继续排查替代方案
6. 完成后给我简短总结和下一步建议

3.自动化:让 Codex 每天自己上班

真正省时间的东西,不是“我叫它,它很快”。

是“我不叫它,它也会按时出现”。

这就是 Automations。

OpenAI 官方 Automations 教程里有个判断标准:好的自动化任务,要具体、可重复、容易复查。官方也提醒,如果你在本地跑 Codex,电脑最好保持醒着,Codex 也要运行。

所以别一上来就让它“帮我赚钱”“帮我运营账号”。太虚了。

先从每天、每周重复的小流程开始。

比如:每天早上检查项目错误日志,整理新增问题。或者每天早上整理 AI / Codex / MCP 的重要更新。

我自己比较喜欢后者。醒来之后先看一份筛过的简报,而不是钻进信息流里捞半小时。

小白怎么配:

  1. 先在普通对话里手动跑一次。
  2. 确认输出格式满意。
  3. 对 Codex 说:把刚才这个任务创建成自动化。
  4. 去左侧 Automations 检查任务。
  5. 确认频率、提示词、状态。
  6. 先跑 2-3 次,再改 prompt。

如果你不想依赖本地电脑常开,就要考虑云端值守或远程机器。本地用户最稳的做法,还是让电脑和 Codex 保持醒着。

直接复制这个命令:

请创建一个自动化任务。

目标:
每天早上 8 点,帮我整理一份 AI / Codex / MCP 相关的重要更新速递。

成功标准:
1. 只保留真正值得关注的信息,不要堆砌新闻
2. 每条信息都要包含:标题、来源、为什么重要、我可以怎么用
3. 最后给出 3 个可以写成 X 长文的选题
4. 输出内容要简短、清晰,适合早上快速阅读

边界条件:
1. 不要自动发布到 X
2. 不要自动发送邮件
3. 不要编造来源
4. 如果没有重要更新,就告诉我“今天没有值得单独关注的更新”
5. 如果需要访问付费内容、登录账号或授权工具,先问我

工作方式:
1. 每天按时间自动运行
2. 先搜索或读取可用信息源
3. 再筛选重要信息
4. 再整理成固定格式
5. 完成后给我一份可直接阅读的简报

4.MCP + Obsidian:把 Codex 接进你的知识库

互联网给 Codex 外部信息。

Obsidian 给 Codex 你的个人上下文。

这俩不一样。

很多人说 AI 不懂自己。其实也正常。你的笔记、经验、素材、项目复盘都在 Obsidian 里,Codex 没看见,当然只能泛泛地写。

MCP 解决的就是这个问题。

通过 MCP,你可以让 Codex 连接 Obsidian、文档库、内部工具。OpenAI 官方 Docs MCP 教程也提到,MCP 可以把文档内容拉进 agent 的上下文里。

如果你的 Obsidian 装了 Local REST API with MCP,Codex 就可以读取 vault 里的 md 文件。比如这篇文章,就是从 Obsidian 的 Codex 素材库里读素材,再结合官方教程整理出来的。

小白怎么配:

  1. 在 Obsidian 安装 Local REST API with MCP。
  2. 打开插件,确认 REST API 服务已启动。
  3. 记录插件里的 API Key。
  4. 在 Codex 的 MCP 配置里添加 Obsidian server。
  5. 重启 Codex。
  6. 让 Codex 测试读取一篇笔记。

图像

配置大概长这样:

[mcp_servers.obsidian]
url = "https://127.0.0.1:27124/mcp/"
bearer_token_env_var = "OBSIDIAN_API_KEY"

这一步打通的不是一个工具,而是你的长期积累。

直接复制这个命令:

请通过 Obsidian MCP 读取我的知识库。

目标:
读取 Obsidian「Codex素材库」里的相关 md 文件,帮我整理一篇 X 长文大纲。

背景资料:
1. 重点参考和 Codex、插件、Goal Mode、自动化、MCP、Skills 相关的笔记
2. 文章面向 Codex 新手
3. 主题是:如何让 Codex 使用效率翻倍

成功标准:
1. 找出最有价值的素材点
2. 整理成一篇 X 长文结构
3. 开头必须有强钩子
4. 正文必须包含 5 个方法:插件、Goal Mode、自动化、MCP + Obsidian、Skills
5. 每个方法都要包含:核心观点、实操步骤、可复制 prompt
6. 最后给出适合 X 的结尾和互动引导

边界条件:
1. 不要修改 Obsidian 原始笔记
2. 不要删除、移动、重命名任何文件
3. 不要编造不存在的笔记内容
4. 如果某个文件读不到,请告诉我文件名和原因
5. 如果需要 API key、授权或登录操作,先问我

工作方式:
1. 先列出你准备读取哪些笔记
2. 再提取核心素材
3. 再整理文章结构
4. 等我确认结构后,再继续写正文
5. 完成后说明你参考了哪些笔记

5. Skills:把常用流程固化

如果一个流程你重复做了 3 次,就应该把它变成 Skill。

OpenAI 官方对 Skills 的说法是:它像一本 Codex 可以照着执行的 playbook。我的理解更简单:Skill 就是你写给 Codex 的 SOP。

插件解决“去哪里拿资料”。

Skills 解决“按什么流程做”。

比如你经常让 Codex 写 X 长文。不要每次都重新说:开头要有钩子、不要 AI 味、先讲痛点、再给方法、每个方法要有例子、最后要有行动号召。

这些东西,应该沉淀成一个 Skill。

小白怎么配:

  1. 先让 Codex 跑通一次完整任务。
  2. 结果满意后,让 Codex 把流程整理成 Skill。
  3. 检查 Skill 是否包含适用场景、输入要求、流程、质量标准。
  4. 下次直接调用。

更高级一点,可以做父子 Skill。

父 Skill 负责判断任务类型:这次是写长文、做表格、查资料,还是生成报告。

子 Skill 负责具体执行:资料提炼、开头钩子、案例改写、格式检查。

这样 Codex 不只是会做事,而是会按你的方式做事。

直接复制这个命令:

请帮我创建一个 Codex Skill。

目标:
把“X 长文写作”这个常用流程沉淀成一个可复用 Skill。以后我给你素材,你就能按固定流程写出适合 X 发布的长文。

背景资料:
1. 我的文章通常面向 AI 工具、Codex、效率工作流的新手用户
2. 我喜欢开头先打痛点,再给认知反差
3. 正文要有方法、有例子、有可复制 prompt
4. 语言要像真实经验分享,不要像官方说明书

成功标准:
1. Skill 要包含适用场景
2. Skill 要包含输入材料要求
3. Skill 要包含写作流程
4. Skill 要包含开头钩子规则
5. Skill 要包含正文结构规则
6. Skill 要包含质量检查标准
7. Skill 要告诉 Codex 最终应该输出什么

边界条件:
1. 不要覆盖我已有的 Skill,除非我明确同意
2. 不要删除任何原始素材
3. 不要自动发布文章
4. 不要编造案例和数据
5. 如果需要创建文件,请先告诉我文件名和保存位置

工作方式:
1. 先根据我的需求设计 Skill 结构
2. 再问我是否需要调整
3. 我确认后再创建 Skill 文件
4. 创建后,用一个小例子测试这个 Skill 是否好用
5. 最后告诉我以后应该怎么调用它

最后

如果你现在用 Codex 还觉得累,这很正常。

很多时候不是你不会用 AI,而是我们还停留在“每次都重新解释一遍”的阶段。只要任务一多,人就会被这些重复沟通慢慢消耗掉。

我更推荐的方式是:先从一个最小场景开始。

比如先装一个 Gmail 插件,让它帮你整理邮件;或者先把每天都要看的信息做成自动化;再或者先把你最常写的一类文章做成 Skill。

不用一下子把 5 个方法全部配齐。

你只要先跑通一个,就会明显感觉到:Codex 不再只是回答你,而是开始替你分担一小段流程。

等插件、Goal Mode、自动化、MCP、Skills 慢慢连起来,它就会越来越像一个熟悉你工作方式的助手。

你说过一次的规则,它下次可以复用。

你设过一次的任务,它可以按时执行。

你整理过一次的流程,它可以变成 Skill 留下来。

这篇你可以先收藏。下次准备配置 Codex 的时候,按这 5 个部分一项一项试,不用急。

如果你身边也有人明明用了 AI,却还是每天复制粘贴、反复解释需求,可以把这篇转给他。也许他缺的不是更多 prompt,而是一套能慢慢搭起来的工作流。

参考资料

  • OpenAI Academy: Plugins and skills
  • OpenAI Academy: Automations
  • OpenAI Academy: What is Codex
  • OpenAI Help Center: 2026-05-21 Codex updates / Goal mode release notes