第 5 篇:插件、Skills、MCP、Computer Use 和自动化:把 Codex 变成长期工作流

本篇目录

1. 1. 为什么要学习扩展能力
2. 2. 插件是什么
3. 3. 插件使用案例：用 GitHub 插件整理电商项目 Issue
4. 4. Skills 是什么
5. 5. 方法一：使用内置 Skills
6. 6. 方法二：自己创建 Skill
7. 7. 方法三：使用第三方分享的 Skill
8. 8. MCP 是什么
9. 9. 用 Context7 MCP 查询最新开发文档
10. 10. Computer Use 是什么
11. 11. 自动化是什么
12. 12. 如何设计一个简单安全的自动化任务
13. 13. Codex 推荐工作流
14. 14. 避坑清单
15. 15. 最终总结

1. 为什么要学习扩展能力

前面几篇主要讲的是 Codex 如何在本地项目里工作。

但 Codex 的价值不只是在项目文件夹里写代码。

通过扩展能力，它还可以连接更多外部系统，例如：

• • GitHub
• • Gmail
• • 浏览器
• • 文档工具
• • 项目管理工具
• • 自动化流程
• • 自定义 Skills
• • MCP 服务

当你经常做同一类任务时，就应该考虑把它流程化。

例如：

• • 每次都要整理 GitHub Issue。
• • 每次发版前都要检查 README、截图和构建命令。
• • 每次开发新页面都要按同一套 UI 规范生成代码。
• • 每天都要查看项目清单并整理当天要做的任务。
• • 每次使用新框架或新版本 API 前，都要先查询最新开发文档。

这些都适合沉淀成更固定的工作流。

2. 插件是什么

插件可以理解为给 Codex 增加外部服务能力的软件包。

例如安装 GitHub 插件后，Codex 可能可以更方便地处理：

• • GitHub 仓库
• • Issue
• • Pull Request
• • 项目看板

安装 Gmail 插件后，Codex 可能可以：

• • 读取邮件
• • 总结邮件
• • 草拟回复
• • 发送邮件

插件的核心作用是连接外部工具。

插件适合什么场景？

适合：

• • 你需要 Codex 操作某个第三方服务。
• • 你经常在某个平台重复执行任务。
• • 你想减少手动切换窗口。

不适合：

• • 只是问一个普通问题。
• • 只是修改本地代码。
• • 不希望 Codex 访问外部账户。

使用插件时的安全原则

1. 1. 只安装你真正需要的插件。
2. 2. 看清楚插件申请的权限。
3. 3. 涉及发送、删除、发布、合并的操作，要求 Codex 先确认。
4. 4. 不要把敏感账户随便授权给不熟悉的插件。
5. 5. 不要让插件默认拥有过大的写入权限。

3. 插件使用案例：用 GitHub 插件整理电商项目 Issue

假设你已经把前面做好的电商网站项目推送到了 GitHub。

项目里有几个 Issue：

• • 首页商品卡片在移动端太挤。
• • 购物车按钮点击后没有明显反馈。
• • 商品筛选区域需要增加价格区间。
• • README 需要补充本地运行方式。

如果安装了 GitHub 插件，就可以让 Codex 帮你读取这些 Issue，并整理成开发任务。

使用前准备

1. 1. 安装 GitHub 插件。
2. 2. 授权访问你的 GitHub 账号。
3. 3. 确认插件只访问你允许的仓库。
4. 4. 打开当前电商项目。

示例提示词

请使用 GitHub 插件读取当前电商项目仓库中的 Open Issues。

要求：
1. 只读取 Issue，不要修改、关闭或删除任何 Issue。
2. 按优先级整理成一个任务列表。
3. 把和页面 Bug 相关的任务排在前面。
4. 把文档类任务排在后面。
5. 输出每个任务的建议处理方式。
6. 先不要改代码。

Codex 可能会输出类似结果：

优先级 P1：修复移动端商品卡片拥挤问题
原因：影响手机用户浏览商品。
建议：先检查商品网格布局和断点设置，只做移动端样式修复。

优先级 P2：增强购物车按钮反馈
原因：用户点击后不知道是否加入成功。
建议：添加 toast 提示或按钮状态变化。

优先级 P3：增加价格区间筛选
原因：属于功能增强。
建议：先实现前端筛选，不接后端。

优先级 P4：补充 README 本地运行方式
原因：文档完善，不影响页面功能。
建议：在功能稳定后补充。

继续执行开发

整理完后，你可以选择其中一个任务继续让 Codex 处理：

请先处理 P1：移动端商品卡片拥挤问题。

要求：
1. 只修改移动端布局。
2. 不改变桌面端视觉效果。
3. 修复后启动本地预览。
4. 总结修改了哪些文件。
5. 不要关闭 GitHub Issue。

这里故意加上“不要关闭 GitHub Issue”，是为了防止 Codex 在没有人工验收前直接改变远程项目状态。

4. Skills 是什么

Skills 可以理解为给 Codex 安装“专业技能包”。

插件通常负责连接外部服务，例如 GitHub、Gmail、Netlify。

Skills 更像是一种“带目录的说明书”。你可以把某个工作流、专业能力、项目规范或输出格式封装成 Skill，让 Codex 在执行特定任务时更稳定、更高效，输出也更可靠。

例如你正在长期维护一个电商网站，每次都希望 Codex 按同一套规则写代码：

• • 页面风格保持简洁、现代、适合电商。
• • 商品卡片必须包含图片、标题、价格、评分和按钮。
• • 移动端优先检查商品网格是否溢出。
• • 修改后必须运行构建检查。
• • Git 提交前必须检查 .env、node_modules 和构建产物。

如果每次都手写这些规则，会很麻烦。

这时就可以把规则沉淀成 Skill。

Skills 能解决什么问题？

适合：

• • 固定代码规范。
• • 固定文档格式。
• • 固定检查流程。
• • 固定项目交付流程。
• • 固定内容生成流程。
• • 固定工具最佳实践。

不适合：

• • 一次性的临时问题。
• • 还没想清楚的模糊任务。
• • 高风险操作的自动放行。
• • 来源不明、内容不可读的第三方规则。

本篇按三个方法介绍 Skills：

方法一：使用内置或官方 Skills
方法二：自己创建 Skill
方法三：使用第三方分享的 Skill

5. 方法一：使用内置 Skills

内置 Skills 或官方 Skills，可以理解为 Codex 已经提供好的常用能力。

你不需要自己编写 Skill，只需要安装或调用它。

在 Codex 的插件与技能页面里，有些能力会被归在“技能”下面，有些看起来在“插件”下面，但实际里面只包含一个 Skill。

示例：使用 Image Gen 官方 Skill 生成图片

假设你想测试一个官方 Skill，可以先创建一个临时项目文件夹，例如：

demo

然后在 Codex 中添加这个项目，并用斜线 / 唤起已安装的 Image Gen。

可以输入：

生成一张猫咪图片。

Codex 会先读取这个 Skill 里的说明，理解 Image Gen 项目的创建方式、文件结构和运行方式，然后再开始生成项目。

新手使用内置 Skills 的建议

第一次使用某个 Skill 时，不要直接放到真实项目里。

更推荐：

1. 新建一个临时文件夹。
2. 用 Codex 打开这个文件夹。
3. 调用 Skill 做一个小演示。
4. 看清楚它会创建哪些文件、运行哪些命令。
5. 确认安全后，再考虑用于正式项目。

6. 方法二：自己创建汇报 PPT Skill

当你发现某个流程会反复出现，就可以考虑自己创建 Skill。

这一节可以换成一个更适合教程演示的场景：论文或学习材料汇报 PPT 生成。

很多人做论文汇报时，会把论文笔记、摘要、方法图、实验结果和自己的理解交给 Codex，让它基于 Marp 生成 PPT。问题是，第一次生成的 PPT 通常很难完全满意：

• • 标题太长，不适合放在幻灯片上。
• • 每页内容太满，像论文摘抄。
• • 方法和实验结果没有讲清楚层次。
• • 图表位置不合理。
• • 结论页不够有汇报感。
• • Marp 主题、分页和演讲备注不稳定。

这类任务很适合做成 Skill。你可以先通过多次对话，把“满意的 PPT 结构、风格、分页规则、图表处理方式、演讲备注格式”调出来；等流程稳定后，再让 Codex 基于这段对话创建一个 Skill。下次再做论文汇报，就不需要重新磨提示词，可以直接调用这个 Skill。

第一步：准备项目文件夹

先新建一个项目文件夹，例如：

paper-ppt-skill-demo

然后在 Codex 中添加这个项目。

建议把下面这些材料放进项目文件夹：

paper-ppt-skill-demo
├── paper-notes.md
├── paper-summary.md
├── figures/
│   ├── method.png
│   └── result.png
└── references/
    └── paper.pdf

如果你暂时没有完整论文，也可以先用一份论文笔记或课程材料测试。

第二步：先用普通对话迭代出满意流程

不要一上来就创建 Skill。

更推荐先让 Codex 用普通方式帮你做一版 PPT，然后不断修改，直到你找到满意的规则。

例如先输入：

请根据 paper-notes.md，帮我生成一份 10 页左右的论文汇报 PPT。

要求：
1. 使用 Marp Markdown 格式。
2. 适合课堂汇报或组会汇报。
3. 不要逐段复制论文原文，要改写成适合演讲的表达。
4. 每页只讲一个重点。
5. 方法页要突出研究流程。
6. 实验结果页要突出指标、对比和结论。
7. 最后输出 slides.md，并告诉我如何预览。

第一版出来后，你可以继续要求它调整：

现在这一版不太美观，需要更改的美观一些

经过几轮迭代后，如果你觉得它终于能稳定生成满意 PPT，就可以把这套规则固化成 Skill。补充说明，marp文档配合VS Code插件可以实现markdown写PPT操作，这里不详细展开，感兴趣的读者请自行查找相关教程。

第三步：调用 Skill Creator

在对话框里输入 /，找到 Codex 的内置技能：

Skill Creator

它可以理解为“帮助你创建 Skill 的 Skill”。

第四步：描述你要固化的汇报 PPT 流程

可以输入：

基于当前对话内容，请使用 Skill Creator 创建一个 Skill，名称为：论文汇报 PPT 生成器。 

这个 Skill 用于把论文笔记、课程材料、调研文档或研究总结，转换成适合课堂汇报、组会汇报讲解的 Marp PPT。

使用场景：
- 我提供 paper-notes.md、paper-summary.md、论文 PDF、图片或实验结果表格。
- 你根据材料生成 slides.md。
- slides.md 必须符合 Marp Markdown 格式。

生成流程：
1. 先阅读我提供的材料，提取研究背景、问题、方法、实验、结论和可讲解亮点。
2. 不要逐段复制原文，要改写成适合口头汇报的表达。
3. 先规划 PPT 大纲，再生成 slides.md。
4. PPT 默认控制在 8 到 12 页，除非我另有要求。
5. 每一页只讲一个重点。
6. 每页标题尽量使用结论式标题，而不是普通小标题。
7. 每页正文控制在 3 到 5 个短要点。
8. 方法页优先使用流程图、步骤图或 Mermaid 图表达。
9. 实验页要突出指标、对比对象、结果变化和一句话结论。
10. 结论页要总结贡献、局限和后续方向。
11. 如果材料里有图片或图表，要优先复用本地图片路径，不要编造不存在的图片。
12. 给关键页面添加 speaker notes，帮助我讲解。
13. 输出文件命名为 slides.md。
14. 不要删除原始论文、笔记、图片和数据文件。
15. 如果材料不足，要先列出缺失信息，再给出可生成的最小版本。

注意，如果你在 Codex 输入多行提示词，想换行时可以使用：

Shift + Enter

不要直接按 Enter，否则可能会提前发送。

第五步：检查 Skill 产物

Codex 可能会生成：

.codex/
└── skills/
    └── research-presentation-ppt/
        ├── SKILL.md
        └── examples/
            └── sample-slides.md

其中最重要的是 SKILL.md。

它应该写清楚：

• • 这个 Skill 什么时候使用。
• • 输入材料可以是什么。
• • Marp PPT 的输出格式是什么。
• • 默认页数和页面结构是什么。
• • 标题、正文、图表和 speaker notes 的规则是什么。
• • 如何处理本地图片、论文 PDF 和实验表格。
• • 哪些文件不能删除。
• • 材料不足时应该怎么提示用户。

第六步：测试自己创建的 Skill

创建完成后，新开一个对话，再用 / 唤起刚才创建的 Skill。

新建一个项目，把论文笔记或汇报材料放进项目文件夹，然后输入：

我已经在当前项目文件夹里准备好了论文笔记。
请使用“论文汇报 PPT 生成器”这个 Skill，帮我生成一份 Marp 汇报 PPT。

如果一切正常，Codex 会读取 Skill 的流程要求，识别工作区里的论文笔记、图片和结果材料，生成一份结构更稳定的 Marp PPT。

7. 方法三：把自制 Skill 作为第三方 Skill 分享使用

除了使用内置和自己创建的 Skill，你也可以使用别人分享的 skill。

第一步：整理要分享的 Skill 文件夹

假设上一节生成的 Skill 位于：

paper-ppt-skill-demo
└── .codex/
    └── skills/
        └── research-presentation-ppt/
            ├── SKILL.md
            └── examples/
                └── sample-slides.md

你可以把 research-presentation-ppt 这个文件夹单独复制出来，作为别人分享的 skill。

如果要上传到 GitHub，可以整理成这样的仓库结构：

research-presentation-ppt-skill
├── README.md
└── research-presentation-ppt/
    ├── SKILL.md
    └── examples/
        └── sample-slides.md

README.md 可以简单说明：

• • 这个 Skill 是做什么的。
• • 适合哪些材料。
• • 如何安装到 .codex/skills/。
• • 如何在 Codex 中用 / 调用。
• • 是否会运行命令、联网或修改文件。

第二步：在另一个项目中安装这个 Skill

新建一个项目文件夹，例如：

demo

然后创建目录：

.codex/skills/

把你分享出来的 research-presentation-ppt 文件夹放进去。

最终结构类似：

demo
└── .codex/
    └── skills/
        └── research-presentation-ppt/
            ├── SKILL.md
            └── examples/
                └── sample-slides.md

这时，这个 Skill 对 demo 来说，就是一个“第三方分享的 Skill”。
之后就像调用内置或自己创建的skill一样使用 / 来调用。

使用别人分享的 Skill 前要检查什么？

即使这个案例用的是你自己创建的 Skill，也建议在文章里提醒读者：真正使用网上下载的第三方 Skill 时，一定要先检查。

建议至少检查：

1. 1. 来源是否可信。
2. 2. SKILL.md 内容是否能看懂。
3. 3. 是否要求过大的权限。
4. 4. 是否包含联网、删除、上传、发送等高风险动作。
5. 5. 是否会读取敏感文件，例如 .env。
6. 6. 是否会自动提交 Git、发布内容或修改远程仓库。
7. 7. 是否会执行你看不懂的脚本或命令。

新手推荐做法

不要直接把第三方 Skill 用在真实项目里。

更安全的方式是先让 Codex 审查：

请先阅读这个第三方 Skill 的内容。

要求：
1. 总结它会做什么。
2. 标出可能有风险的步骤。
3. 告诉我它是否会读取敏感文件、联网、删除文件、执行脚本或自动提交。
4. 在我确认前，不要执行这个 Skill。

如果你只是想测试，可以先在一个临时项目里试用。

8. MCP 是什么

MCP 全称是 Model Context Protocol。

可以把它理解为“大模型连接外部系统的标准协议”。

如果插件像一个个专用工具，MCP 更像一种标准接口。

通过 MCP，Codex 可以连接一些外部能力，例如：

• • 查询最新技术文档。
• • 读取公开资料。
• • 访问项目管理系统。
• • 连接数据库。
• • 调用内部工具。

MCP 适合什么场景？

适合：

• • 需要连接外部数据源。
• • 需要读取外部系统数据。
• • 需要调用外部 API。
• • 希望通过标准方式给 Codex 增加工具。
• • 希望同一个 MCP 配置能在 Codex CLI、IDE 扩展或 App 中复用。

新手注意

MCP 比普通插件更偏技术。

使用 MCP 时要特别注意：

• • 不要把密钥写到前端代码。
• • 不要把 API Key 提交到 GitHub。
• • 不要随便给生产系统授权。
• • 先在测试项目里练习。
• • 优先选择只读、低风险、配置简单的 MCP 做入门演示。

9. 用 Context7 MCP 查询最新开发文档

Context7 的用途很简单：让 Codex 在写代码时可以查询更新的开发文档，而不是只依赖模型记忆。例如在电商项目里使用 Next.js、Tailwind CSS 或某个 UI 库时，可以让 Codex 先查文档，再给出实现方案。

第一步：安装前准备

你需要本机已经安装 Node.js 和 npm。

可以在终端里检查：

node -v
npm -v

如果这两个命令都能输出版本号，说明基本环境可用。

第二步：添加 Context7 MCP

在 Codex App 里进入：

设置 → MCP Servers → Add Server

然后按界面提示根据官方文档添加服务器。

第三步：确认配置

添加后，可以在终端执行：

codex mcp list

或者在 Codex 的 MCP 设置页面里查看 context7 是否已经出现。

如果你使用的是 Codex CLI 或 IDE 扩展，也可以查看配置文件。

常见位置是：

~/.codex/config.toml

它可能包含类似配置：

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
enabled = true

如果你的网络环境、组织设置或 Context7 账户要求 API Key，就不要把 Key 写进前端项目代码，也不要提交到 GitHub。应该放在本机配置或环境变量里。

第四步：在电商项目中使用 Context7

假设你正在把 ecommerce-site 从普通 HTML 项目升级成 Next.js 项目。

可以对 Codex 说：

请使用 Context7 MCP 查询 Next.js App Router 的最新文档，然后为当前 ecommerce-site 项目制定迁移计划。

要求：
1. 先查询文档，再输出计划。
2. 使用 App Router。
3. 使用 TypeScript。
4. 保留当前页面结构和视觉风格。
5. 不要直接修改文件。
6. 不要引入不必要的依赖。

如果你要使用 Tailwind CSS，也可以说：

请使用 Context7 MCP 查询 Tailwind CSS 当前版本的安装和配置方式。

然后检查当前 ecommerce-site 项目是否适合接入 Tailwind。
先输出分析和计划，不要修改文件。

第五步：根据文档结果再执行

拿到计划后，不要马上让 Codex 大改。

你应该先检查：

• • 它查到的文档是否和你的技术栈匹配。
• • 它是否准备覆盖已有文件。
• • 它是否要安装大量不必要依赖。
• • 它是否会修改 .env、Git 配置或项目外文件。

确认没问题后，再让它执行：

这个计划可以执行。

请按计划迁移，但每一步都要保持可验证。
修改后运行构建检查，并总结你改了哪些文件。

10. Computer Use 是什么

Computer Use 可以理解为让 Codex 操作电脑界面。

它可能打开浏览器、网页系统或其他桌面应用。

需要特别注意：Computer Use 对电脑环境有要求。目前教程里建议明确告诉读者：只有 Mac 电脑能使用这一能力。Windows 用户可以先学习插件、Skills、MCP 和普通项目开发流程，不要把 Computer Use 作为必学步骤。

Computer Use 能做什么？

例如：

请打开浏览器，进入这个公开电商页面，观察首页结构，并整理成一份模块分析。不要登录账号，不要提交任何表单。

或者：

请打开浏览器，进入我的 GitHub 项目页面，查看 README 显示是否正常。只查看，不要点击删除、合并或发布按钮。

使用 Computer Use 的安全原则

1. 1. 明确告诉 Codex 可以打开什么页面。
2. 2. 明确告诉 Codex 不要登录陌生网站。
3. 3. 涉及发送、删除、购买、发布、合并的动作，必须人工确认。
4. 4. 不要让 Codex 在你看不懂的情况下操作账号后台。
5. 5. 不要让 Codex 接触支付、真实客户资料或敏感后台。

和插件、MCP 的区别

可以简单这样理解：

11. 自动化是什么

自动化就是把一套流程固定下来，让 Codex 按时间或条件重复执行。

这一篇不使用“总结 GitHub 看板并发送给老板”这种复杂演示。

对新手来说，最好从简单、低风险、只读或只提醒的任务开始。

例如：每天上午提醒你检查电商项目今天要做什么。

简单演示任务：每天上午生成项目待办提醒

假设你的项目里有一个 TODO.md 文件，用来记录接下来要做的事情。

你可以设计一个自动化任务：

每天上午 9 点：
1. 提醒我打开 ecommerce-site 项目。
2. 让我查看 TODO.md。
3. 根据 TODO.md 总结今天最适合优先处理的 3 件事。
4. 只输出建议，不要自动修改文件。

这个任务很适合新手练习，因为它风险很低：

• • 不发邮件。
• • 不发消息。
• • 不删除文件。
• • 不推送 GitHub。
• • 不修改生产系统。

自动化适合什么任务？

适合：

• • 定时提醒。
• • 定时总结。
• • 定时检查清单。
• • 读取固定来源并生成草稿。

不适合：

• • 自动删除文件。
• • 自动发送消息。
• • 自动合并 PR。
• • 自动修改生产数据库。
• • 自动执行付款、发布、下单等高风险动作。

12. 如何设计一个简单安全的自动化任务

设计自动化时，要特别注意安全边界。

12.1 明确触发时间

不要只说：

每天提醒我看项目。

更好：

每天上午 9 点提醒我查看 ecommerce-site 项目的 TODO.md，并总结今天建议优先处理的 3 件事。

12.2 明确数据来源

例如：

只读取 ecommerce-site 项目里的 TODO.md，不要读取其他项目文件。

12.3 明确输出格式

例如：

输出三条建议，每条包含任务名称、原因和建议耗时。

12.4 明确禁止高风险动作

例如：

不要修改文件，不要提交 Git，不要推送 GitHub，不要发送消息。

简单自动化提示词示例

请创建一个简单自动化任务。

时间：每天上午 9 点。

任务：
1. 提醒我查看 ecommerce-site 项目的 TODO.md。
2. 根据 TODO.md 总结今天建议优先处理的 3 件事。
3. 每件事说明原因和建议耗时。

安全限制：
- 只读取 TODO.md。
- 不要修改任何文件。
- 不要执行 Git 操作。
- 不要发送邮件或消息。

这个示例的重点不是功能多强，而是让读者理解：自动化任务应该从低风险、可检查、边界清楚的流程开始。

13. Codex 推荐工作流

13.1 简单任务工作流

适合：

• • 修文案
• • 改颜色
• • 解释技术概念
• • 小 bug

流程：

1. 打开项目对话。
2. 输入明确需求。
3. 让 Codex 修改。
4. 浏览器验证。
5. 满意后 Git commit。

13.2 中等任务工作流

适合：

• • 新增页面
• • 优化样式
• • 添加商品筛选
• • 添加购物车交互

流程：

1. 新开对话。
2. 描述需求和验收标准。
3. 让 Codex 修改。
4. 使用内置浏览器批注。
5. 修复问题。
6. Git commit。

13.3 复杂任务工作流

适合：

• • 架构迁移
• • 大重构
• • 登录系统
• • 支付系统
• • 连接外部系统

流程：

1. 先 Git commit 保存当前状态。
2. 开启 Plan 模式。
3. 让 Codex 输出计划。
4. 修改和确认计划。
5. 执行。
6. 构建检查。
7. 浏览器验证。
8. 必要时用 Steer 中途纠偏。
9. 成功后 Git commit。
10. 不满意就回滚或分叉。

13.4 扩展能力工作流

适合：

• • 使用插件处理 GitHub Issue。
• • 使用 Skill 固定验收流程。
• • 使用 MCP 读取公开网页资料。
• • 使用自动化做每日提醒。

流程：

1. 先判断任务是否真的需要扩展能力。
2. 优先选择只读、低风险工具。
3. 明确告诉 Codex 可以访问什么、不能访问什么。
4. 涉及写入、发送、删除、发布时必须人工确认。
5. 执行后检查结果。
6. 把可复用流程沉淀成 Skill 或自动化任务。

14. 避坑清单

14.1 环境相关

[ ] Node.js、Git、VS Code 先装好
[ ] Windows 上注意 PowerShell 脚本执行权限
[ ] 国内网络访问 GitHub 可能不稳定
[ ] Python 项目建议使用虚拟环境
[ ] WSL 适合运行 Windows 原生支持不好的 Agent 工具
[ ] Computer Use 目前只建议 Mac 用户学习和使用

14.2 Codex 使用相关

[ ] 复杂任务先开 Plan
[ ] 一个任务完成后尽量新开对话
[ ] 不要在超长对话里持续追加需求
[ ] 看到方向错了及时 Steer
[ ] 不要随便开完全访问权限
[ ] 上传图片时要说明你希望 Codex 看什么
[ ] 对 AI 生成图片要检查是否符合业务
[ ] 对登录、支付、订单、客户数据类任务要特别审查安全性

14.3 插件、Skills 和 MCP 相关

[ ] 插件只安装真正需要的
[ ] 插件授权前先看清楚权限范围
[ ] 第三方 Skill 使用前先审查内容
[ ] 自己创建 Skill 时写清楚禁止动作
[ ] MCP 入门优先选择只读、配置简单的工具
[ ] 不要把 API Key、数据库连接串写进前端代码
[ ] 不要把密钥提交到 GitHub

14.4 Git 相关

[ ] 每完成一个稳定功能就 commit
[ ] 大改前先 commit
[ ] 不满意就回滚，不要硬修到越来越乱
[ ] 多方案实验用 Git Worktree
[ ] 推 GitHub 前检查 .gitignore
[ ] 不要提交 .env 和密钥

14.5 安全相关

[ ] API Key 不要发到前端
[ ] 数据库连接串不要提交到 GitHub
[ ] 完全访问权限只在可信项目中使用
[ ] 涉及发送消息、邮件、提交 PR、删除文件时，最好要求 Codex 先确认
[ ] 自动化任务要设置人工确认节点
[ ] 发送、删除、付款、发布类操作不要全自动
[ ] 真实订单、真实支付、真实客户数据不要作为新手演示项目

15. 最终总结

Codex App 的核心价值不是“帮你写几行代码”，而是把 AI 变成一个可控的项目执行者。

它可以：

• • 读项目
• • 改文件
• • 跑命令
• • 开浏览器
• • 看截图
• • 写 Git
• • 连插件
• • 用 Skills
• • 用 MCP
• • 执行自动化流程

但 Codex 不是完全自动驾驶。

最好的使用方式是：

Codex 负责执行，用户负责目标、边界、验收和方向盘。

你需要做的不是每一行代码都自己写，而是学会：

1. 1. 给清楚目标。
2. 2. 设置安全边界。
3. 3. 拆分任务。
4. 4. 检查结果。
5. 5. 用 Git 保存稳定节点。
6. 6. 用 Plan 控制复杂任务。
7. 7. 用 Steer 及时纠偏。
8. 8. 用插件连接外部平台。
9. 9. 用 Skills 沉淀重复流程。
10. 10. 用 MCP 扩展外部信息来源。
11. 11. 用自动化处理低风险重复任务。

这 5 篇文章可以组成一个完整的新手教程合集：

第 1 篇：认识 Codex 与环境准备
第 2 篇：项目、对话、沙箱和权限
第 3 篇：从 0 开发第一个网页项目
第 4 篇：Git、GitHub、回滚、图片输入和 Steer
第 5 篇：插件、Skills、MCP、Computer Use 和自动化

读者跟完这套教程后，应该不只是“知道 Codex 是什么”，而是能真正用 Codex 开始完成自己的第一个项目，并且知道如何安全、可控、可回退地持续使用它。