EP09. “第三方整合与自制 Skill”

首页 › AI 工具 › ChatGPT · Codex · EP09

约 10 分钟· #EP09#ChatGPT#Codex

🔒 登录后可标记已读

讲 Codex 怎么直接接进 GitHub、Slack 这些你本来就在用的工具，不用特地切换到 Codex 界面
讲 Hooks——在 Codex 工作流程的各个阶段自动插入你自己的脚本/检查
讲怎么自己动手做一个 Skill（EP04 讲的是怎么「用」现成的 Skill，这篇讲怎么「做」一个）
前置知识：先看过 EP02（权限概念）、EP04（Skills 是什么）

重点内容

GitHub 整合

Codex 能直接在 GitHub 上审查 Pull Request，不用把代码另外贴到别处：

代码审查：照仓库的规范审查 PR 差异，发一份标准审查意见，标出比较严重的问题
安全审查（研究预览阶段）：更深入地分析潜在安全问题
自动审查：可以设成每个新开的 PR 都自动跑一次
自订审查规则：写进 AGENTS.md（见 EP02），指导 Codex 审查时该注意什么

设置步骤：先把 Codex 云环境接上要审查的仓库 → 到 Codex 的代码审查设置页面 → 给这个仓库启用代码审查功能 → 可选启用自动审查。

怎么用：在 PR 评论里提及：

@codex review——手动叫它审查
@codex security review——要求安全向的审查
@codex fix the P1 issue——直接叫它修掉某个已经找出来的问题

💡 写审查规则时要「针对这个仓库、会真正影响后果的行为」，把安全路径和例外都讲清楚，规则范围明确才经得起时间考验，不要写太笼统的规则。

Slack 整合

在 Slack 频道/线程里提 @Codex 加上你的需求，它会开一个云端对话去处理，处理完回来贴结果——能读到同一个线程之前的讯息当上下文，通常不用重新讲一次背景。

前置要求：ChatGPT Plus / Pro / Business / Enterprise / Edu 方案、已连接 GitHub 账户、至少配置一个云环境。

安装：Codex 设置里装工作区的 Slack App（可能需要管理员批准）→ 把 @Codex 加进相关频道。

用法：@Codex fix the above in openai/codex 这种句式，可以指名要用哪个环境/仓库；没指名的话它会自己判断最匹配的环境，或者退回用最近用过的那个。

📌 企业管理员可以在工作区设置里关掉「Codex Slack App 任务完成后直接公开贴答案」——关掉之后它只会回一个聊天链接，不会把具体内容贴在频道里。

Hooks：在流程各阶段插入自己的脚本

Hooks 是一套扩展框架，让你在 Codex 跑任务的各个阶段自动执行脚本或 MCP 工具，例如：把对话记录送进自己的日志系统、扫描提示词防止密钥外泄、自动帮对话生成记忆、跑自订验证检查、依所在目录切换不同的提示语。

触发点（常用的几个）：

阶段	触发点
工具调用前后	`PreToolUse`、`PostToolUse`
请求权限时	`PermissionRequest`
会话开始/结束	`SessionStart`、`SessionEnd`
用户送出提示词	`UserPromptSubmit`
上下文压缩前后	`PreCompact`、`PostCompact`
子 agent 相关	`SubagentStart`、`SubagentStop`（子 agent 不触发 `SessionEnd`/`Interrupt`）
中断当前操作	`Interrupt`

配置位置：~/.codex/hooks.json（或写进 config.toml）、<项目>/.codex/hooks.json、或某个 Plugin 内的 hooks/hooks.json。

配置结构：事件 → 匹配器（用正则表达式过滤要触发的条件）→ 处理程序。处理程序两种类型：type: "command"（跑脚本）或 type: "mcp_tool"（叫用 MCP 工具）。可以设 "async": true 让它在背景跑，不卡住主流程；大部分 hook 预设 600 秒超时（SessionEnd/Interrupt 只有 1 秒）。

⚠️ 非管理员配置的 hooks 要经过你自己审查并「信任」才会生效（用 /hooks 指令查看/管理），不是写好配置就自动执行——这是防止恶意配置偷偷跑脚本的把关机制。

自己动手做一个 Skill

EP04 讲的是怎么「用」别人打包好的 Skill，这里讲怎么自己做一个。

文件结构：

my-skill/
├── SKILL.md 必需：说明文档 + 元数据
├── scripts/ 可选：可执行代码
├── references/ 可选：参考文档
├── assets/ 可选：模板、资源
└── agents/
└── openai.yaml 可选：外观和依赖配置

SKILL.md 基本格式（name、description 是必需字段）：

---
name: skill-name
description: 说明这个 Skill 的具体触发条件和适用范围
---

Skill 具体的操作说明，给 ChatGPT/Codex 照着执行。

💡 description 要写得简洁、范围界定清楚，把关键用例和触发词放前面——系统靠这段文字判断什么时候该套用这个 Skill，写得模糊系统会判断不准。

三种做法：

Record & Replay（最快）：如果这个工作流程本来就容易演示一遍，用内建的录制工具直接把操作过程转成 Skill
用 Skill Creator（互动式）：ChatGPT Work 里叫 @skill-creator，Codex 里跑 $skill-creator，系统会问你这个 Skill 要做什么、什么时候该触发、要不要带脚本
手动写：自己建文件夹、手写 SKILL.md

可选的 agents/openai.yaml（控制外观和调用策略）：

interface:
  display_name: "显示名称"
  short_description: "简短说明"
  brand_color: "#3B82F6"

policy:
  allow_implicit_invocation: false   # 设 false 就只能手动叫用，不会被系统自动套用

dependencies:
  tools:
    - type: "mcp"
      value: "serverName"

最佳实践：一个 Skill 只专注做一件事；优先用文字指令而不是脚本，除非真的需要「每次结果都一样」的确定性行为；步骤写成命令式（做这个、再做那个），讲清楚输入输出；改完 description 记得实测触发效果对不对。

💡 Codex 会自动侦测 Skill 有没有更动；如果改了没生效，重启一下应用就好。

常见错误

❌ 审查规则写得太笼统（例如「代码要写好」）——规则要针对这个仓库、讲清楚会真正影响后果的具体行为
❌ 把敏感操作的 Hooks 设成自动信任、不检查——非管理配置的 hooks 该经过 /hooks 审查，看清楚脚本内容再放行
❌ description 写得又长又模糊，指望系统自己会懂——触发条件和关键用例要写在前面，写完记得实际测试触发效果
❌ 什么工作流程都想写脚本才觉得「够专业」——能用文字指令说清楚的，不需要额外写脚本，除非真的要求每次结果一致
💡 Skill 改了没反应，先重启应用，不用怀疑是不是写错了

Sources

官方文档：

GitHub integration — https://learn.chatgpt.com/codex/third-party/github
Slack integration — https://learn.chatgpt.com/codex/third-party/slack
Hooks — https://learn.chatgpt.com/codex/hooks
Build skills — https://learn.chatgpt.com/codex/build-skills