很多人用上 Codex 之后，总是感觉沟通得很累。
以下这些话你肯定也对 Codex 说过：
“再改一下这里”
“这个背景我补充一下”
“继续”
“同意，进行下一步”
表面上看，是 AI 在帮你干活。
实际上，是你一直在给 AI 喂资料、补上下文、拆步骤、盯进度。
你买的是一个助手，最后却变成了它的项目经理。
这篇就讲 5 个用法：插件、Goal Mode、自动化、MCP + Obsidian、Skills。
它们不是五个孤立功能，而是一套从“聊天 AI”升级到“流程助手”的路线。
让你把 Codex 的性能一次性榨干，让你越用越轻松。
榨干 Codex 性能的 5 个用法
一、插件：先让 Codex 长出手脚
没有插件的 Codex，本质上还是一个很聪明的对话框。
你问，它答。
你给材料，它处理。
你不给，它就只能靠当前上下文猜。
但接上插件之后，事情就变了。
插件让 Codex 有机会连接外部工具，比如 Gmail、Google Drive、GitHub、Figma、Slack、Notion 等。换成人话说，就是你不用每次都把资料复制粘贴给它，它可以在你授权的范围内自己去找、自己去读、自己去整理。
这一步的意义很大。
因为很多工作真正耗人的地方，不是写提示词，而是前面的信息搬运。
比如处理邮件：
传统做法是，你先扫标题，再点开正文，再判断要不要回，再想怎么回。合作邮件、报价邮件、客户跟进邮件，一天多几封就很烦。
有了Codex后，让 Codex 先做第一轮筛选：
哪些紧急；
哪些需要回复；
哪些只是通知；
哪些可以暂时忽略。
需要回复的，它先起草一版。你只负责看一眼，改两句，再决定是否发送。
这里有一个关键转变：不要只让 AI “想”，要让它能“动手”。
适合先接的插件，不一定越多越好。新手可以先从三个方向开始：
- 邮件类：Gmail，用来处理收件箱和回复草稿。
- 文件类：Google Drive / Notion，用来读取资料和文档。
- 代码类：GitHub，用来读 issue、PR、代码变更和项目上下文。
插件越多，权限越多，也越需要边界。
我的建议是：只给它接你真的会用的工具，先跑通一个高频场景，再慢慢扩展。
插件：让 Codex 长出手脚
二、Goal Mode：不要给任务，要给终点
很多人用 Codex 的方式，还是“Yes模式”。
你按一下“同意”，它走一步。
你再按一下“同意”，它再走一步。
这种方式当然能用，但并不省心。
因为任务拆解、过程检查、失败重试，其实都还在你脑子里。
Goal Mode 的思路更像是：你告诉它终点在哪里、成功标准是什么、哪些边界不能碰，然后让它自己拆步骤推进。
比如你排查项目启动失败，不要只说：
帮我看看哪里错了。这句话太虚了。
Codex 不知道你希望它看到哪一步，不知道什么叫“修好”，也不知道哪些动作不能做。
更好的说法是：
目标：排查当前项目无法启动的原因，修复问题，并确认项目可以正常运行。成功标准：1. 找到明确原因2. 完成必要修复3. 成功运行启动命令或测试命令4. 输出修复总结，说明改了哪些文件、为什么改、如何验证边界条件：1. 不删除原始文件2. 不重置 Git 历史3. 不擅自覆盖用户已有修改4. 涉及安装依赖、联网下载、删除文件时先说明原因这类提示词的关键不是长，而是清楚。
你要给它三样东西：
- 目标：最后要达成什么结果。
- 成功标准：做到什么程度才算完成。
- 边界条件：哪些事情不能擅自做。
Goal Mode 的正确写法
普通模式是“我说一步，你走一步”。
Goal Mode 是“我定义终点，你自己找路”。
如果你经常让 Codex 做排查、整理、重构、迁移、批量修改，这个思路会明显减少来回沟通。
三、自动化：让 Codex 到点自己上班
真正省时间的东西，不是“操作时，它很快”；而是“它会按时出现”。
这就是自动化的价值。
但这里很容易走偏。
很多人一上来就想让 AI 自动赚钱、自动运营账号、自动做用户增长。这种目标太大、太虚，也很难约束和迭代。
更适合自动化的任务，通常有三个特点：
- 具体：知道每次要处理什么。
- 重复：每天、每周都会发生。
- 可检查：结果好不好，人能快速判断。
什么任务适合交给 Codex 自动化
比如：
每天早上整理 AI / Codex / MCP 重要更新。
每周五汇总项目 issue 和错误日志。
每天检查收件箱，把重要邮件分级。
每周把 Obsidian 里新增资料做一次摘要。
这些任务不性感，但真的省心。
我更建议新手这样做：
先在普通对话里手动跑一次。
确认输出格式满意。
再让 Codex 把这个任务创建成自动化。
跑 2-3 次之后，再根据结果调整提示词。
不要一开始就追求全自动。
先把一个小流程跑稳，你才能知道哪里应该交给 AI，哪里必须留给人判断。
四、MCP + Obsidian：把你的知识库接进 Codex
互联网给 Codex 外部信息。
Obsidian 给 Codex 你的个人上下文。
这两件事不是一回事。
很多人抱怨 AI 不懂自己，其实很正常。
你的笔记、经验、项目复盘、踩坑记录、素材库，都躺在本地文件夹或 Obsidian 里。Codex 没看见，自然只能说一些通用建议。
MCP 要解决的，就是这个问题。
通过 MCP，你可以把 Obsidian、文档库、内部工具这类信息源接进 Codex，让它在需要时读取你的长期积累。
这一步打通之后，Codex 的回答会发生一个很明显的变化：
它不再只是根据网上常识回答你。
它可以开始结合你过去写过什么、做过什么、踩过什么坑，给出更贴近你的方案。
比如你要写一篇关于 Codex 工作流的文章。
没有知识库时，它可能给你一篇普通科普。
接入 Obsidian 后，你可以让它先读取你的素材库、项目复盘、选题笔记，再整理成大纲。这样写出来的东西，才更像你的内容，而不是一篇标准 AI 作文。
新手可以先跑一个最小闭环：
- 在 Obsidian 里建一个 Codex 素材库。
- 把文章素材、项目记录、复盘笔记放进去。
- 用 MCP 或其他可用方式让 Codex 读取这些 md 文件。
- 让它先列出准备读取哪些笔记。
- 再让它提炼素材、整理大纲。
- 最后再进入写作或输出。
注意，不要一上来就让它改你的整个知识库。
先读，不要改。
先整理，不要删除。
先跑通一个小目录，再扩大范围。
个人经验变成可复用数字资产
五、Skills：把重复流程固化成 SOP
如果一个流程你已经重复做了 3 次以上，就应该考虑把它变成 Skill。
我对 Skill 的理解很简单：它就是写给 Codex 的 SOP。
插件解决“去哪里拿资料”。
MCP 解决“能不能读到你的上下文”。
Goal Mode 解决“这次任务的终点是什么”。
Skills 解决“以后遇到同类任务，按什么流程做”。
比如你经常让 Codex 写 X 长文。
你不应该每次都重新说：
开头要有痛点。
不要 AI 味。
先讲问题，再讲方法。
每个方法要有例子。
最后要有行动号召。
这些都应该沉淀成一个 Skill。
一个好用的 Skill，至少要写清楚 5 件事：
- 适用场景：什么时候调用它。
- 输入材料：需要用户给什么。
- 执行流程：先做什么，再做什么。
- 质量标准：怎样算输出合格。
- 边界条件：哪些事不能做。
你说过一次的规则，下次不用重复说。
你调好一次的流程，下次可以直接复用。
你跑通过一次的经验，可以慢慢变成自己的工作系统。
这样一来，Codex 不只是会做事，而是开始按你的方式做事。
如果你现在用 Codex 还觉得累，不一定是你不会用 AI。
更可能是你还停留在“每次都重新解释一遍”的阶段。
每次复制资料。
每次补背景。
每次拆步骤。
每次提醒它不要越界。
这些重复沟通，会一点点吃掉你的注意力。
真正值得追求的，不是写出一条神级 prompt，而是让 Codex 逐渐记住你的流程、接入你的工具、读取你的知识库，并在合适的时候自己跑起来。
先从一个最小场景开始。
比如整理邮件。
比如排查项目问题。
比如每天做一份更新简报。
比如把你最常写的一类文章沉淀成 Skill。
只要先跑通一个，你就会感觉到变化：
Codex 不再只是回答你。
它开始替你分担一小段流程。
而当插件、Goal Mode、自动化、MCP 和 Skills 慢慢连起来，它才会真正从“聊天工具”变成“工作系统”。
热门跟贴