在使用 Codex 进行日常开发时，有两类能力几乎每天都会用到：一是Git 操作与项目改动管理，用来安全、可控地处理代码变更；二是Skills 与插件，用来把 Codex 从「只会写代码的助手」扩展成能生成文档、操作浏览器、甚至接管电脑的多面手。

本文按这两条线展开，帮助你快速建立清晰的使用习惯。

一、Git 操作和项目改动管理

Codex 可以直接在你的项目仓库里执行 Git 相关操作。在桌面端 App 中，项目为 Git 仓库且已配置远程时，还可以 Commit、Push、创建 PR；在 CLI 或 IDE 扩展里，则通常通过终端命令完成同类操作。这意味着你不必在对话和终端之间来回切换——查看改了什么、整理提交、推进版本，都可以在同一个协作流程里完成。

1.1 可以查看变更

在动手改代码之前，先看清「当前工作区到底变了什么」，是避免误操作的第一步。

Codex 可以帮你：

• 在审查面板（Diff）中查看未暂存与已暂存的文件差异
• 列出新增、修改、删除的文件（如通过git status）
• 对比某个文件在改动前后的具体内容
• 了解当前分支状态、是否与远程同步
• 筛选「仅本轮改动」（Last turn changes），快速定位 AI 刚刚修改的部分

典型场景包括：你让 Codex 改了一轮代码，想确认它有没有动到不该动的文件；或者合并前想看看冲突区域长什么样。把「先看 diff，再决定下一步」当成固定动作，能显著降低返工成本。

实用建议：每次较大改动后，先让 Codex 展示变更摘要，或打开审查面板自行浏览，再决定是否继续修改、暂存或提交。

1.2 可以提交代码

确认变更无误后，Codex 可以协助完成从暂存到提交的完整流程：

• 将指定文件加入暂存区（git add）
• 撰写符合项目风格的commit message
• 执行提交（git commit）
• 在需要时推送到远程仓库（git push）

提交信息不必你逐字撰写。你可以用自然语言描述「这次改了什么、为什么改」，Codex 会帮你整理成简洁、可读的 commit message。若项目有约定格式（如 Conventional Commits），也可以一并说明。

注意两点：

1. Codex通常不会主动提交，除非你明确要求；说「帮我 commit」或「确认后再 push」能避免意外写入历史。
2. 涉及敏感文件（如.env、密钥配置）时，应明确告知不要纳入提交；养成自查习惯比依赖提醒更稳妥。

1.3 建议先审查再提交

「能提交」不等于「应该立刻提交」。更推荐的工作流是：

查看变更 → 人工或 AI 审查 → 确认无误 → 提交

审查环节可以检查：

把审查嵌入流程，比事后从混乱的历史记录里找问题要轻松得多。你也可以直接对 Codex 说：「先展示 diff，我确认后再提交」——这是实践中非常高效的一句话。桌面端还可使用/review进入代码审查模式，或在 diff 行上添加行内评论，让 Codex 定点修改后再提交。

二、Skills 和插件：Codex 最常用的能力扩展

Codex 的基础能力已经很强，但遇到特定场景——生成图片、写 Office 文档、操控浏览器——往往需要Skills和插件来补足。理解二者的区别与用法，是进阶使用的关键。

2.1 Skills 是什么？

（1）Skills 是一套写好的执行步骤

Skill 不是抽象概念，而是可重复执行的操作规程。当某个任务有固定套路（例如：按模板创建 PR、按规范写 commit、按步骤配置 MCP），就可以封装成 Skill，让 Codex 每次按同一套步骤走，减少遗漏和风格漂移。

你可以把 Skill 理解为：把资深同事的工作 checklist 写进系统里。

（2）Skill 本质上是 Markdown 说明书

每个 Skill 对应一个文件夹，其中必须包含SKILL.md，还可附带参考文档、脚本等辅助文件。SKILL.md里写清楚了：

• 适用场景（description字段也供 Codex 自动匹配时使用）
• 前置条件
• 逐步操作说明
• 注意事项与边界

Codex 在需要时会读取完整说明并按文档指引执行，而不是临场即兴发挥。因此 Skill 的质量，直接取决于文档是否清晰、步骤是否完整。

（3）手动调用 Skill 用$

在对话输入框中输入$可以唤起 Skill 选择器，从中挑选要使用的技能；已启用的 Skill 也会出现在/斜杠命令列表中。例如：

• $imagegen— 调用图片生成
• $skill-creator— 按引导创建新 Skill
• 需要按团队规范创建 PR → 选择对应的 PR Skill

除手动调用外，Codex 还可能根据任务内容与 Skill 的description自动选用匹配的技能（隐式调用）。$适合你明确知道要用哪套流程的场景：目标清晰，直接指定规程即可。

2.2 插件是什么？

（1）插件 = 技能 + 外部应用连接能力

如果说 Skill 是「单份操作手册」，插件（Plugin）更像是「可安装的能力包」。官方定义中，插件可以打包：

• 一个或多个 Skill
• 外部应用连接（Apps，如 GitHub、Slack、Google Drive）
• MCP 服务器（接入更多工具或共享信息）

插件让 Codex 从「只在编辑器里干活」延伸到「与外部世界交互」。

（2）调用插件用@

在对话中输入@可以引用插件或其内置 Skill。例如@Browser指向内置浏览器能力，@Computer指向桌面操控能力；安装 Google Drive 等插件后，也可@对应插件名，让 Codex 从云端文档、表格中读取或写入内容。

与$指向固定流程不同，@更像是指定通过哪条通道干活——启用某类能力后，Codex 会在任务进行中调用插件绑定的工具与子技能。

你也可以不手动@，直接用自然语言描述需求（如「总结今天未读的 Gmail」），Codex 会从已安装的插件中自动选择合适的工具。

（3）插件和 Skill 可以混合使用

二者并不互斥。常见组合方式：

• 先用@启用插件（如 Google Drive），再用$调用某个 Skill 约束输出格式
• 在插件完成的任务后，直接让 Codex 整理并提交产物到 Git

混合使用的原则是：插件解决「能连什么、能读什么」，Skill 解决「怎么做才规范」。

2.3 常用插件和技能总结

以下能力在日常协作中出现频率较高。注意：有些是Skill（用$），有些是插件（用@或自然语言），还有些是App 内置能力（在设置中开启）。

（1）Image Gen：最常用的图片生成能力

类型：Skill· 调用方式：$imagegen

需要配图、图标草图、UI 概念图时，Image Gen 可以直接根据文字描述生成图像，省去打开设计工具的中间步骤。适合：

• 产品原型示意
• 文档配图
• 简单视觉素材

生成结果通常作为项目文件保存，可纳入后续 Git 管理。

（2）Documents、Spreadsheets、Presentations

类型：插件能力· 常见来源：Google Drive 等办公类插件

这一组能力覆盖Word 文档、Excel 表格、PPT 演示文稿的创建与编辑。安装相应插件并完成授权后，Codex 可跨 Drive、Docs、Sheets、Slides 读写内容。典型用途：

• 输出技术方案、README 以外的正式文档
• 整理数据表格、导出统计结果
• 制作汇报用的演示幻灯片

当你希望 Codex 的产出直接是可交付的办公文件，而不是纯 Markdown 或代码时，这些插件非常实用。

（3）Browser Use：操作浏览器

类型：App 内置能力· 调用方式：@Browser，或在设置 → Browser 中配置

Browser Use 让 Codex 能够在App 内置浏览器中执行操作：打开页面、点击、填表、抓取信息等；也支持 Browser comments（页面标注反馈）。适用于：

• 验证前端页面实际表现（如 localhost 预览）
• 查阅动态加载的网页内容
• 自动化重复的网页操作

限制：内置浏览器通常不支持登录态、Cookie 及浏览器扩展，涉及账号登录的页面需另作安排。

（4）Computer Use：直接接管电脑

类型：App 内置能力· 调用方式：@Computer，权限在设置 → Computer Use 中管理

Computer Use 让 Codex 可以操作桌面应用与系统界面——不限于浏览器，还包括其他 GUI 程序。适合高度依赖图形界面、难以用命令行完成的场景。由于权限较高，使用时建议：

• 明确任务范围
• 避免在含敏感信息的界面无人监督地运行
• 关键步骤前要求 Codex 说明即将执行的操作

小结

建议养成的日常习惯：

1. 改代码先看 diff，提交前先审查
2. 固定流程用 Skill（$），跨系统任务用插件（@）
3. Image Gen 走 Skill，Office 文档走插件，Browser / Computer Use 按场景开启

掌握 Git 协作与 Skills/插件的分工，Codex 就能既守得住代码仓库的纪律，又够得着编辑器以外的真实工作流。