Codex Apply Patch：让 Codex 改 Skill，但让 Axon 决定能否发布

Codex Apply Patch 是把 Codex 生成的文件修改变成结构化 diff，并由集成环境应用、回报结果、继续迭代的 Skill Builder 工作流。团队每天用 Agent 改脚本、补模板、重构 Skill 说明时，痛点不是“模型会不会写代码”，而是人工复制修改低效、重复出错、失败后没有补丁记录，最后很难判断这个改动能不能进入业务工作流。Axon 可以把 apply_patch 变成 Skill 构建的一段能力，但不能让它绕过验证器和发布评审。

OpenAI 的 Apply Patch 文档 说明模型可以提出结构化 diffs，由应用环境执行并把结果反馈给模型；Code generation 文档 也把 Codex 放在 IDE、CLI、web/mobile 和 SDK 等代码任务入口中。对 Axon 来说，这不是“让 Codex 随便改文件”的理由，而是把结构化补丁接进 User Skills、Agent Pipeline、Trust Mode 和 workspace 的机会。

Codex 负责提出补丁；Axon 负责判断补丁是否符合 Skill 契约、样例、权限和发布边界。

从补丁到 Skill，不是一步到位

一个 Codex patch 可能只是改了几行代码，也可能影响参数、输出字段、默认路径和失败处理。Axon 的 Skill Builder 不应该把 patch 成功等同于 Skill 可发布。

阶段	Codex 做什么	Axon 必须做什么
Intent	根据 brief 生成修改计划	限定 Skill 目标和不改范围
Patch	输出结构化 diff	记录 patch id、文件、状态
Apply	环境应用 patch	拦截危险路径和越权写入
Validate	解释失败并补修	运行 Skill validator 和样例
Release	生成变更摘要	进入 Codex Review Gates

这就是 Codex Apply Patch 在 Axon 里的定位：它是 Skill Builder 的变更机制，不是发布权限。

Patch lifecycle packet

codexApplyPatchWorkflow:
  skill: "invoice-field-normalizer"
  intent: "add missing tax-id normalization without changing output schema"
  patch:
    operation: "update_file"
    changedFiles:
      - "skills/invoice-field-normalizer/handler.ts"
      - "skills/invoice-field-normalizer/tests/sample.ts"
  applyResult:
    status: "completed"
    rejectedPaths: []
  axonValidation:
    sampleRun: "pass"
    schemaChanged: false
    permissionChanged: false
  releaseDecision: "hold-for-owner-review"

这份 packet 的关键是保留中间状态。Codex 不只是“改好了”，而是把 intent、patch、apply result、validation 和 release decision 留给 Axon workflow。

哪些 Skill 修改适合 apply_patch

模板和字段处理。
比如把发票字段、合同审阅字段或内容规范字段整理得更稳定。Codex 能快速改实现，Axon 需要确认输出 schema 没漂移。

测试和样例补充。
Codex 很适合补回归样例，尤其是失败样例和边界样例。Axon 要把这些样例接进 Workflow Version Pinning。

文档和使用说明。
Skill 的 SKILL.md 和业务说明可以由 Codex 辅助修订，但仍要由 owner 检查是否夸大能力。

Builder review 的三个问题

步骤 1：这个 patch 是否只改了 brief 允许的范围？步骤 2：Skill 输出 schema、权限和 workspace 规则是否保持稳定？步骤 3：如果 patch 失败，是否能回滚到上一个可用版本？

如果三个问题答不上来，Codex Apply Patch 不应该进入发布流程。

让结构化补丁服务 Axon 工作流

Apply patch 的价值不只是更快改文件。真正的价值是把“模型说要改什么”变成可记录、可拒绝、可复跑的变更对象。这样 Axon 可以把它放进 Developer Skill Workflows：Codex 产生补丁，Axon 验证补丁，业务 owner 决定是否发布。

当补丁涉及外部系统、文件路径或执行权限时，还要连到 Workspace-Scoped AI Workflows。结构化 diff 不等于安全 diff；安全来自 path guard、validator、样例和 Trust Mode。

常见问题

Q1：Codex Apply Patch 能直接发布 Skill 吗？
不应该。它可以完成结构化修改，但发布还要通过验证、样例、权限和人工 review。

Q2：为什么不用普通文本让 Codex 说明怎么改？
普通说明需要人工复制，容易漏改。结构化 patch 能留下变更记录和失败结果，更适合工作流复盘。

Q3：patch 失败时怎么办？
失败结果要回传给 Codex，同时进入 Axon fallback：重试、缩小范围、请求 Source Data 或交给开发者。

从一个小 Skill patch 开始

选择一个低风险 User Skill，不要先让 Codex 大规模重构。先用 Codex Apply Patch 修改一个字段处理或测试样例，再让 Axon 跑 validator、样例和 Review Gates。阅读更多 developer Skill workflow、review gates 和 workspace boundary，开始使用 Axon 把 Codex 的补丁能力变成可控的 Skill Builder 工作流。