Codex Playbook 02：把 Codex 变成 AI 工程协作系统

摘要

很多人第一次使用 Codex，会把它当成一个更强的代码助手。

这个理解不算错，但还不够。

Codex 真正的价值，不只是让你写代码更快，而是让一个工程任务可以被清晰委派、自动执行、持续验证、接受审查，并沉淀为可复用的团队能力。

它不是简单的 autocomplete，也不只是聊天式 coding assistant。

更准确地说，Codex 是一个可以进入真实代码库、理解项目上下文、修改文件、运行命令、生成 diff、接受 review、并持续迭代的 AI Coding Agent。

如果说普通用户关心的是：

Codex 能不能帮我把想法变成交付物？

那么专业用户更应该关心的是：

如何把 Codex 纳入真实工程体系，让它可控、可验证、可复用、可审计？

这篇 Playbook 面向开发者、AI Builder、独立开发者和技术团队，目标不是教几个 Prompt，而是建立一套完整的 AI Engineering Workflow。

把目标、边界和验证交给 Codex，再由人类审查 diff。

把目标、边界和验证交给 Codex，再由人类审查 diff。

01. 重新理解 Codex：不是代码助手，而是工程协作层

传统代码助手的价值，是在你写代码时提供补全、建议和局部生成。

Codex 的价值，是把一个工程任务从“人手写代码”变成“人类定义目标和边界，Agent 执行和验证”。

这两者的差别很大。

代码助手解决的是局部效率。

Codex 解决的是任务交付。

一个成熟的 Codex 工作流应该包含：

Goal → Context → Plan → Implement → Validate → Review → Iterate → Document

这意味着你不只是让 Codex 写代码，而是在训练它参与完整工程生命周期：

理解需求；
阅读代码库；
制定修改计划；
执行局部变更；
运行测试；
解释 diff；
暴露风险；
接受 review；
更新文档；
沉淀规则。

所以，Codex 的本质不是“更聪明的编辑器插件”，而是一个可以被纳入工程系统的 AI 执行层。

一句话：

Codex 的最佳实践，不是让 AI 多写代码，而是建立一套可控、可验证、可复用的工程协作系统。

02. Codex 工程协作九要素

专业团队要把 Codex 看成一个系统，而不是一个聊天框。

可以用九个要素来理解：

Prompt：一次任务说明
Plan：复杂任务先分析
Goal：长任务持续推进
AGENTS.md：长期项目规则
Skills：可复用工作流
MCP / Plugins：外部工具和上下文
Subagents：并行探索与质量门控
Automations：成熟流程后台化
Review Loop：人类最终判断和风险控制

这九个要素解决的是不同问题。

Prompt 解决“这次要做什么”。

Plan 解决“先想清楚怎么做”。

Goal 解决“长任务如何持续推进直到完成”。

AGENTS.md 解决“这个项目长期怎么做”。

Skills 解决“重复工作如何复用”。

MCP / Plugins 解决“仓库之外的信息怎么接入”。

Subagents 解决“复杂任务如何多视角审查”。

Automations 解决“稳定流程如何定期执行”。

Review Loop 解决“谁对最终结果负责”。

这套系统的目标不是“全自动”，而是：

可控
可验证
可审查
可复用
可治理

03. Prompt、Plan、Goal、Automation 的区别

很多 Codex 翻车，不是因为模型不够强，而是人类把不同类型的任务混在一起。

Prompt、Plan、Goal、Automation 不是一回事。

能力	解决什么问题	适合场景
Prompt	一次性任务说明	小任务、短任务
Plan	复杂任务开始前先分析	边界清楚但影响面较大的任务
Goal	长时间持续推进一个目标	多步骤、长周期、有明确完成标准的任务
Automation	定时或重复执行成熟流程	周报、巡检、release notes、CI 总结

正确链路通常是：

Prompt → Plan → Goal → Skill → Automation

含义是：

Prompt 解决一次任务；
Plan 解决复杂任务的起步；
Goal 解决长任务持续推进；
Skill 把成功流程沉淀下来；
Automation 把成熟流程定期运行。

一句话：

Plan 让 Codex 想清楚怎么做，Goal 让 Codex 持续推进直到完成。

04. Goal Mode：把长任务变成任务合约

Prompt 适合一次性任务。

Plan 适合复杂任务开始前的分析。

Goal 适合长任务。

当一个任务需要很多步骤、很多文件、很多轮验证，或者你希望 Codex 在较长时间内持续推进一个明确目标时，就应该使用 Goal。

Goal 的关键不是“让 Codex 自由发挥”，而是给它一个清晰、可衡量、可验证的完成标准。

一个模糊 Goal 是：

优化这个项目。

一个好的 Goal 是：

目标：
把 billing 模块的测试覆盖补到核心路径完整。

完成标准：
1. 覆盖订阅创建、升级、取消、退款、webhook 同步五条核心路径
2. 所有新增测试可稳定通过
3. 不修改现有公共 API
4. 不引入新的生产依赖
5. 最后输出测试覆盖说明、风险点和未覆盖场景

一个成熟的 Goal 应该包含五个部分：

1. Objective：最终目标是什么
2. Scope：允许改哪里，不允许改哪里
3. Constraints：必须遵守哪些约束
4. Checkpoints：中间如何汇报进度
5. Done Criteria：什么叫完成

05. Codex 核心工作流：Plan → Goal → Implement → Validate → Review → Iterate

成熟团队使用 Codex，不应该是：

我说一句 → AI 改一堆 → 人类盲目接受

而应该是：

Plan → Goal → Implement → Validate → Review → Iterate

Plan：先理解，再计划

复杂任务不要直接让 Codex 改代码。

先让它读取相关文件，解释当前实现，找出风险点，给出修改计划。

Goal：长任务写成任务合约

如果任务需要多阶段推进，就不要只靠单次 Prompt。

把它写成 Goal：

目标：
把当前登录模块从散落逻辑整理为 service + hook + UI 三层结构。

范围：
- 可以修改 src/auth、src/hooks、src/components/login
- 不要修改数据库 schema
- 不要改公共 API contract

完成标准：
1. 登录、登出、刷新状态保持现有行为
2. 新增或更新相关测试
3. lint / test / typecheck 通过
4. 输出风险点和人工 review 清单

Implement：小步执行

不要一次性让 Codex 重构半个系统。

把任务拆成可审查的小块：

按照刚才的计划，只执行第一阶段：
- 修改 auth/session 相关逻辑
- 不要改 UI
- 不要改数据库 schema
- 保持现有 API contract 不变

Validate：强制验证

写完不是完成。

必须运行测试、lint、type check、build，或者明确说明无法运行的原因。

完成后请运行相关测试、lint 和 type check。
如果不能运行，请说明原因，并给出我本地应执行的命令。

Review：解释 diff 和风险

不要只看结果。

让 Codex 输出：

请总结本次修改：
1. 修改了哪些文件
2. 每个文件为什么要改
3. 运行了哪些验证命令
4. 哪些地方可能有风险
5. 哪些部分需要人类重点 review

Iterate：根据反馈继续修正

Codex 的正确使用方式不是期待一次完美，而是让它在明确反馈下持续迭代。

一个高质量工程工作流，通常是多轮小步修正，而不是一次性大改。

06. Prompt 要像 GitHub Issue，而不是聊天

专业使用 Codex 的第一条原则：

Prompt 不是咒语，而是任务说明书。

一个好的 Codex Prompt，应该像 GitHub Issue 或 PR 描述一样清楚。

推荐结构：

Task:
请完成什么任务。

Background:
为什么要做？当前问题是什么？用户或业务影响是什么？

Context:
相关文件、目录、错误日志、接口文档、参考实现。

Constraints:
哪些可以改，哪些不能改；不要引入什么依赖；不要改变什么 API。

Done When:
什么叫完成？需要通过哪些测试？最后要输出什么报告？

坏 Prompt：

帮我优化一下支付模块。

好 Prompt：

请先不要修改代码。阅读 src/billing/ 和 tests/billing/，分析当前订阅升级流程。

目标：
修复用户从 standard 升级到 premium 后 webhook 状态偶发不同步的问题。

背景：
当前客服反馈部分用户付款成功后，后台仍显示 standard，导致高级功能无法使用。

约束：
- 不要修改数据库 schema
- 不要改变现有 API contract
- 不要引入新的生产依赖
- 保持现有 billing event 处理方式

完成标准：
- 找到问题原因
- 给出修改计划
- 等我确认后执行
- 新增回归测试
- 运行 billing 相关测试
- 输出风险点和人工 review 清单

这就是专业 Codex 使用者和普通使用者的区别：

普通使用者问问题。

专业使用者交付任务。

07. AGENTS.md：把团队制度写进 Agent

如果 Prompt 是一次性指令，那么 AGENTS.md 就是团队制度。

Codex 会在开始工作前读取 AGENTS.md，用它作为项目的长期指导。

AGENTS.md 应该告诉 Codex：

项目是什么；
目录结构是什么；
如何安装依赖；
如何运行测试；
如何 lint / build；
代码风格是什么；
哪些文件不能改；
哪些依赖不能加；
什么叫完成；
如何做 review；
哪些风险必须上报。

一个专业版 AGENTS.md 可以这样写：

# AGENTS.md

## Project Overview

This repository is a [project type] built with [stack].
The main goal is [short product goal].

## Core Doctrine

- Prefer small, reversible changes over large rewrites.
- Optimize for reviewability, not cleverness.
- Preserve existing behavior unless the task explicitly changes it.
- When uncertain, explain the tradeoff before editing.
- Tests are evidence, not decoration.
- Security and data integrity override speed.

## Repository Structure

- `src/`: application code
- `tests/`: automated tests
- `docs/`: documentation
- `scripts/`: operational scripts

## Commands

- Install: `pnpm install`
- Dev: `pnpm dev`
- Lint: `pnpm lint`
- Test: `pnpm test`
- Build: `pnpm build`
- Typecheck: `pnpm typecheck`

## Engineering Rules

- Prefer small, focused diffs.
- Follow existing code style.
- Do not introduce new production dependencies without approval.
- Do not change public APIs unless explicitly requested.
- Add or update tests when behavior changes.
- Never hardcode secrets, tokens, credentials, or private URLs.
- Do not modify production configuration unless explicitly requested.

## Planning Rules

For complex tasks:
1. Read relevant files first.
2. Explain current behavior.
3. Identify risks and assumptions.
4. Propose a plan.
5. Wait for confirmation before editing.

## Goal Rules

For long-running tasks:
1. Restate the objective.
2. Confirm scope and constraints.
3. Create checkpoints.
4. Validate progress against Done Criteria.
5. Stop and ask when scope changes.

## Review Guidelines

- Check authentication and authorization boundaries.
- Check error handling and edge cases.
- Check logging for PII or secrets.
- Check whether tests cover changed behavior.
- Check backward compatibility.
- Treat security regressions as high priority.

## Done Means

Before finishing, Codex must:
1. Summarize what changed.
2. List files changed.
3. Run relevant tests or explain why tests could not run.
4. Provide evidence that behavior changed as expected.
5. Report risks and follow-up work.
6. Identify what a human should review carefully.

这里最关键的是 Core Doctrine 和 Goal Rules。

不要只把 AGENTS.md 写成规则清单。

复杂任务中，Codex 经常会遇到规则没有覆盖的场景。它需要的不只是命令，而是判断框架。

规则告诉 Codex 怎么做。

原则告诉 Codex 怎么判断。

Goal Rules 则告诉 Codex：长任务如何持续推进，而不是跑偏。

当 Codex 第二次犯同样错误时，不要只在对话里纠正它。你应该把这条规则写进 AGENTS.md。

这就是团队经验的复利。

把零散工程经验沉淀进 AGENTS.md、Skills、MCP 和 Review Loop。

把零散工程经验沉淀进 AGENTS.md、Skills、MCP 和 Review Loop。

08. Skills：把重复工程流程产品化

AGENTS.md 解决的是长期规则。

Skills 解决的是重复工作流。

如果你经常让 Codex 做同一类任务，就应该把它沉淀成 Skill。

适合做成 Skills 的工程任务包括：

PR Risk Review；
Test Generator；
Security Audit；
SDK Migration；
API Contract Review；
Release Notes；
Frontend Polish；
Log Triage；
Docs Generator；
Refactor Plan。

一个好的 Skill 应该满足三个条件：

1. 触发场景清晰
2. 输入输出明确
3. 工作流可复用

示例：PR Risk Review Skill

---
name: pr-risk-review
description: Review code changes for security, correctness, regression risk, missing tests, and maintainability. Use when reviewing a PR, diff, or uncommitted changes.
---

# PR Risk Review

## Workflow

1. Read the relevant AGENTS.md guidance.
2. Inspect the diff and changed files.
3. Identify high-priority risks first.
4. Check tests and validation coverage.
5. Output findings by severity.
6. Suggest minimal fixes when possible.

## Review Categories

- Security
- Correctness
- Regression risk
- Missing tests
- Performance
- Maintainability
- Documentation

## Output Format

- Summary
- P0 / Critical findings
- P1 / High-priority findings
- P2 / Medium-priority findings
- Test gaps
- Suggested fixes
- Human review checklist

## Rules

- Focus on material issues.
- Do not nitpick unless asked.
- Do not change code unless explicitly requested.
- Every finding must include file location and reasoning.

注意：Skills 不是越多越好。

不要把“写代码、修 bug、做前端、写文档、跑测试、部署上线”塞进一个超级 Skill。

更好的做法是：

一个 Skill 解决一类重复任务。
一个任务只启用少数相关 Skills。
复杂任务由主 Agent 判断何时调用哪个 Skill。

这就是 Skill Routing。

当 Codex 完成一次高质量任务后，你可以反向让它沉淀 Skill：

这次流程效果很好。

请把这套流程整理成一个可复用 Skill：
1. 提炼触发场景
2. 写清输入要求
3. 定义工作步骤
4. 规定输出格式
5. 给出失败处理方式
6. 标注不适用场景

成熟团队不是让 Codex 每次从零开始，而是不断把工程经验变成可复用能力。

09. MCP / Plugins：连接代码库之外的真实上下文

很多 Codex 任务失败，不是因为模型不够强，而是上下文不完整。

MCP 和 Plugins 把 Issue、设计稿、日志、数据库和文档接进真实工作现场。

MCP 和 Plugins 把 Issue、设计稿、日志、数据库和文档接进真实工作现场。

真实工程任务需要的不只是代码库，还包括：

GitHub Issue；
Linear / Jira ticket；
Figma 设计稿；
Sentry 错误日志；
数据库 schema；
API 文档；
内部 Wiki；
浏览器页面状态；
产品指标；
客户反馈；
线上运行日志。

如果每次都靠复制粘贴，Codex 很容易缺少关键信息。

MCP 和 Plugins 的价值，就是让 Codex 接入真实工作环境。

你可以这样理解：

Prompt：当前任务
AGENTS.md：长期规则
Skills：可复用流程
MCP / Plugins：外部上下文和工具

工程团队使用 Codex 的关键，不是写更长的 Prompt，而是让 Codex 访问正确的上下文。

例如：

请根据 Linear ticket、相关代码文件和 Sentry 错误日志，分析这个 crash 的根因。
先不要修改代码，先输出：
1. 错误路径
2. 相关文件
3. 复现假设
4. 修复方案
5. 测试计划

或者：

请结合 Figma 页面和当前组件实现，检查页面差异。
输出：
1. 视觉差异
2. 交互差异
3. 组件复用建议
4. 实现计划

这才是 AI 工程协作系统的核心：

Agent 不只是更聪明，而是更接近真实工作现场。

10. Subagents：多视角质量门控

Subagents 不应该被理解为“开更多 AI 干活”。

它真正的价值，是并行审查和降低盲区。

Subagents 的价值不是多开几个 AI，而是用多视角降低审查盲区。

Subagents 的价值不是多开几个 AI，而是用多视角降低审查盲区。

适合使用 Subagents 的场景：

大型代码库探索；
多模块影响分析；
PR 多维审查；
安全 / 性能 / 测试并行检查；
架构迁移方案评审；
复杂功能上线前风险扫描。

不适合使用 Subagents 的场景：

简单 bug fix；
单文件样式调整；
小范围文案修改；
边界不清的模糊任务；
没有明确输出标准的讨论。

11. Automations：只自动化成熟流程

Automations 很强，但也容易被滥用。

专业团队要记住一个原则：

没有手动跑通的流程，不要自动化。

自动化应该从手动跑通的低风险流程开始，并保留人工审批闸门。

自动化应该从手动跑通的低风险流程开始，并保留人工审批闸门。

适合自动化的任务：

每日扫描 CI 失败；
每周生成 release notes；
定期检查依赖升级；
PR 自动 review；
每日总结 commits；
Bug triage；
文档过期检查；
测试覆盖报告；
安全 checklist 扫描。

不适合自动化的任务：

需求还不稳定；
缺少测试；
会修改生产配置；
涉及密钥、支付、权限；
失败代价很高；
结果必须强一致；
需要大量业务判断。

推荐流程：

Manual workflow
→ Prompt refinement
→ AGENTS.md / Skill standardization
→ Several successful dry runs
→ Low-risk automation
→ Human approval gate
→ Gradual expansion

Automations 不是让 AI 自由行动，而是把已经成熟、低风险、可验证的流程放进后台。

12. Sites：从原型到可部署产物

Codex 的一个重要趋势，是从“生成代码”走向“交付产物”。

Sites 让用户可以创建、保存、部署和检查网站、dashboard、内部工具、web app 等产物。

这意味着 Codex 工作流正在从：

Prompt → Code → Local Preview

变成：

Prompt → Code → Deploy → Share → Feedback → Iterate

这对 AI Builder 和一人公司尤其重要。

过去 vibe coding 的主要问题是：生成容易，交付困难。

你可以很快让 AI 写出一个页面，但要稳定部署、配置环境变量、管理版本、分享给团队或用户，仍然需要很多工程步骤。

Sites 把 Codex 往“可交付工作台”方向推了一步。

专业团队可以把它用于：

内部工具原型；
数据 dashboard；
产品 landing page；
demo app；
需求验证页面；
运营工具；
管理后台草图；
客户演示页面。

核心循环是：

Idea → Prototype → Deploy → Share → Feedback → Iterate

未来的软件开发，不只是 AI 写代码，而是 AI 帮团队更快形成可验证的产品表面。

13. Annotations：精准反馈与局部修正

AI 工程协作的关键，不是一次生成完美结果。

而是建立高质量反馈循环。

过去我们常常这样反馈：

这里不太对，帮我改一下。

问题是，“这里”是哪？“不太对”具体是什么？

Annotations 的价值，是让人类可以对具体位置、具体文件、具体页面、具体结果提出 targeted feedback。

这对以下场景特别重要：

PR diff review；
页面局部修改；
文档段落修改；
数据报告校正；
UI 细节调整；
需求说明修订。

一个成熟团队需要培养的不是“AI 一次做对”的幻想，而是：

Precise feedback → Targeted edit → Validation → Review

精准反馈，是人类在 AI 工作流中的核心能力。

14. 证据驱动测试：不要只接受“我完成了”

Codex 最容易出现的问题之一，是输出“已完成”，但证据不足。

专业团队不能只接受结论。

要要求 evidence。

不要只说：

请补测试。

要说：

请补充能证明这个行为变化的测试。

测试需要说明：
1. 修改前用户会看到什么问题
2. 修改后用户会看到什么变化
3. 哪个断言证明问题已经被修复
4. 运行了哪些命令
5. 测试结果是什么

前端或产品任务也可以要求完成证据：

请提供完成证据：
- 修改前后的行为差异
- 关键页面状态说明
- 相关测试或手动验证步骤
- 仍未覆盖的风险

Done Means 不应该是“代码已写完”。

Done Means 应该是：

行为符合预期。
测试能证明。
风险被说明。
diff 可审查。
人类知道该看哪里。

测试不是装饰。

测试是证据。

15. 安全边界：给 Agent 一个受控施工现场

Codex 可以很强，但它不是责任主体。

AI 可以执行、验证、建议修复，但上线责任仍然在人类团队。

所以，专业团队使用 Codex，必须先建立安全边界。

基础安全清单：

1. 每个任务前确认 git status
2. 复杂任务新建分支或 worktree
3. 默认使用严格 sandbox
4. 高风险命令必须人工审批
5. 不允许硬编码密钥
6. 不让 Codex 直接修改生产配置
7. 所有 diff 必须 review
8. 所有重要修改必须测试
9. 依赖升级必须明确说明风险
10. 安全相关改动必须人工复核

企业使用 Codex 的核心关键词，不是“全自动”，而是：

Controlled
Verifiable
Auditable
Reversible

也就是：

可控、可验证、可审计、可回滚。

16. Token 与上下文管理：别让一个线程无限膨胀

Agentic workflow 的现实问题是：上下文和 token 消耗会快速增长。

尤其是：

大代码库；
长线程；
多轮调试；
多代理并行；
大量日志；
多文件 diff；
长期迁移任务。

专业用户必须学会任务拆分和上下文管理。

推荐策略：

1. 一任务一线程，避免无限上下文膨胀。
2. 大任务先 Plan，再拆成子任务。
3. 长任务写成 Goal，明确 checkpoints 和 Done Criteria。
4. 每个子任务有明确输入、输出和完成标准。
5. Subagents 只用于需要并行视角的任务。
6. 长任务定期 summarize / compact。
7. 稳定规则沉淀到 AGENTS.md。
8. 重复流程沉淀到 Skills。
9. 不要把重要结论只留在聊天记录里。

真正高效的 Codex 使用者，不是让 Codex 一直跑，而是善于拆任务、控上下文、沉淀经验。

17. Codex 工程十条铁律

第一，先建边界，再交任务。 Git、sandbox、approval、worktree 是基本安全线。

第二，Prompt 要像 Issue，不要像闲聊。背景、目标、范围、约束、验收标准必须清楚。

第三，复杂任务先 Plan，长任务用 Goal。 Plan 解决“怎么做”，Goal 解决“持续做到完成”。

第四，AGENTS.md 是团队制度。项目结构、命令、规范、禁区、完成标准都要写进去。

第五，重复工作沉淀成 Skills。不要反复 prompt，同类工作要产品化。

第六，仓库外上下文用 MCP / Plugins。设计稿、issue、日志、数据库、文档不要手动复制粘贴。

第七，写完必须验证。 lint、test、build、typecheck 至少执行相关项。

第八，所有变更必须 review。 Codex 可以生成代码，但人类承担最终责任。

第九，Subagents 用于多视角，不用于小任务。并行的目标是降低盲区，不是增加复杂度。

第十，只自动化成熟流程。没有手动跑通的流程，不要交给 Automations。

18. 团队上线前 Checklist

在团队正式推广 Codex 前，建议先完成这份清单：

基础环境：
- 已确认仓库权限边界
- 已确认 sandbox / approval 策略
- 已定义哪些仓库可以试点
- 已要求复杂任务使用分支或 worktree

项目规范：
- 已创建 AGENTS.md
- 已写清 install / test / lint / build 命令
- 已写清 Done Means
- 已写清 Review Guidelines
- 已写清 Goal Rules

质量控制：
- 已要求所有重要修改必须测试
- 已要求 Codex 输出验证结果
- 已要求人类 review 所有 diff
- 已定义 P0 / P1 / P2 风险等级

长任务管理：
- 已定义哪些任务适合 Goal
- Goal 必须包含 Objective / Scope / Constraints / Checkpoints / Done Criteria
- 长任务必须有阶段性汇报
- 任务范围变化时必须重新确认

复用机制：
- 已沉淀至少 1 个高频 Skill
- 已定义 Skill 触发场景
- 已避免创建过多泛化 Skill

自动化：
- 只自动化已手动跑通的流程
- 自动化任务有人工审批或 review gate
- 不自动化高风险生产操作

团队培训：
- 已提供 Prompt 模板
- 已提供 Goal 模板
- 已提供 AGENTS.md 模板
- 已提供 PR Review 模板
- 已明确 Codex 不是责任主体

这份 Checklist 的价值，是把“会用 Codex”变成“团队可治理地使用 Codex”。

19. 团队落地路线：从个人试点到组织系统

Week 1：选择低风险仓库试点

不要从核心生产系统开始。

选一个内部工具、文档站、测试仓库或低风险业务模块。

目标是建立基本工作流：

Prompt → Plan → Code → Test → Review

Week 2：建立 AGENTS.md

写清楚：

项目结构；
运行命令；
测试命令；
编码规范；
禁止事项；
Done Means；
Review Guidelines；
Goal Rules。

Week 3：让 Codex 参与 PR Review

先不要急着让 Codex 大范围改代码。

让它先做 review，更容易建立信任。

推荐从以下检查开始：

测试缺失；
安全风险；
错误处理；
边界条件；
向后兼容；
日志和隐私风险。

Week 4：用 Goal 推进一个长任务

选择一个边界清楚、风险可控的长任务。

比如：

给某个模块补测试；
清理一批 lint / type errors；
迁移一个 SDK；
重构一个低风险内部工具；
更新文档站结构。

要求：

- 写清 Objective
- 写清 Scope
- 写清 Constraints
- 写清 Checkpoints
- 写清 Done Criteria
- 每个阶段必须输出进度和风险

Week 5：沉淀 2–3 个 Skills

优先沉淀：

PR Risk Review；
Test Generator；
Release Notes；
Log Triage。

不要一开始创建太多 Skills。

先把高频任务做扎实。

Week 6：接入 MCP / Plugins

把 Codex 连接到真实上下文：

GitHub Issue；
Linear / Jira；
文档系统；
日志系统；
设计稿；
内部 API 文档。

目标是减少手动复制粘贴，提高任务准确性。

Week 7：尝试低风险 Automations

选择已经手动跑通过的流程自动化。

比如：

每周 release notes；
每日 CI failure summary；
PR risk scan；
文档过期提醒。

保留人工审批和 review gate。

20. 一人公司 / AI Builder 的最佳路径

如果你是独立开发者、AI Builder 或一人公司，Codex 的价值更大。

你可以把它当成一个工程工作台：

Idea → Spec → Goal → Prototype → Test → Page → Deploy → Feedback → Iterate

AI Builder 的复利来自把想法推进成原型、反馈，再沉淀为下次可复用的 Skill。

AI Builder 的复利来自把想法推进成原型、反馈，再沉淀为下次可复用的 Skill。

推荐路径：

第一步：用 Codex 写清规格

请把这个产品想法整理成 MVP spec：
1. 用户问题
2. 核心场景
3. 首版功能
4. 非目标范围
5. 验证指标
6. 7 天行动计划

第二步：把 MVP 写成 Goal

/goal

Objective:
把这个 MVP spec 推进成一个最小可运行原型。

Scope:
- 可以创建必要的前端页面和基础逻辑
- 可以使用现有项目依赖
- 不要引入复杂后端
- 不要做登录、支付等非首版核心功能

Constraints:
- 功能尽量少
- 代码结构清晰
- 可本地运行
- 重要逻辑有基本测试
- 每个阶段输出进度摘要

Done Criteria:
1. 原型可本地运行
2. 首页能说明产品价值
3. 核心流程可点击或可演示
4. 输出测试和运行命令
5. 输出下一步迭代建议

第三步：让 Codex 做自检

请 review 当前原型：
1. 是否符合 MVP spec
2. 是否有明显 bug
3. 是否有安全或数据风险
4. 是否需要补测试
5. 哪些地方不适合现在做

第四步：做页面和反馈入口

请生成一个 landing page：
1. 主标题
2. 一句话介绍
3. 用户痛点
4. 解决方案
5. 核心功能
6. FAQ
7. 邮箱收集入口

第五步：把成功流程沉淀为 Skill

请把这次 MVP 构建流程整理成一个 Skill：
- 触发场景
- 输入要求
- 工作步骤
- 输出格式
- 验证方式
- 不适用场景

这就是 AI Native Builder 的复利：

每完成一次任务，就沉淀一条可复用能力。

21. 最终判断：Codex 的专业价值是工程系统化

Codex 最重要的专业价值，不是“写代码更快”。

而是让工程团队第一次可以把很多隐性的工程经验，变成 Agent 可执行、可验证、可复用的系统。

过去，团队经验散落在：

README；
Slack；
代码审查评论；
老员工习惯；
会议记录；
临时脚本；
个人经验。

现在，这些经验可以被写进：

Goal；
AGENTS.md；
Skills；
Review Guidelines；
MCP Context；
Automations；
Subagent Workflows。

这就是 AI Native Engineering 的核心变化：

Human judgment → Agent instructions
Team workflow → Reusable skills
Long task → Goal contract
Review habits → Quality gates
Tribal knowledge → Executable context
Manual routines → Safe automations

人类负责目标、判断、边界和责任。

Agent 负责执行、验证、审查和迭代。

所以，Codex 最佳实践的本质，不是提示词技巧，而是把人类工程经验变成 Agent 可执行、可验证、可复用的工作系统。

最后一句话：

普通人用 Codex，是为了把想法变成交付物。专业团队用 Codex，是为了把工程经验变成可复用系统。

参考资料

OpenAI Codex Best Practices https://developers.openai.com/codex/learn/best-practices
OpenAI Codex Prompting https://developers.openai.com/codex/prompting
OpenAI Codex Workflows https://developers.openai.com/codex/workflows
OpenAI Codex CLI https://developers.openai.com/codex/cli
OpenAI Codex App Features https://developers.openai.com/codex/app/features
OpenAI Codex App Commands https://developers.openai.com/codex/app/commands
OpenAI: Introducing Codex https://openai.com/index/introducing-codex/
OpenAI: Introducing the Codex app https://openai.com/index/introducing-the-codex-app/
OpenAI: Codex for every role, tool, and workflow https://openai.com/index/codex-for-every-role-tool-workflow/
OpenAI: Codex is now generally available https://openai.com/index/codex-now-generally-available/
OpenAI: Unrolling the Codex agent loop https://openai.com/index/unrolling-the-codex-agent-loop/
OpenAI: Building more with GPT-5.1-Codex-Max https://openai.com/index/gpt-5-1-codex-max/
OpenAI Codex Use Cases https://developers.openai.com/codex/use-cases
OpenAI Codex Goal Use Case https://developers.openai.com/codex/use-cases/follow-goals
OpenAI Codex AGENTS.md Guide https://developers.openai.com/codex/guides/agents-md
OpenAI Codex Customization https://developers.openai.com/codex/concepts/customization
OpenAI Codex Agent Skills https://developers.openai.com/codex/skills
OpenAI Academy: Using Skills https://openai.com/academy/skills/
OpenAI Codex Plugins https://developers.openai.com/codex/plugins
OpenAI Codex Subagents https://developers.openai.com/codex/subagents
OpenAI Codex Subagents Concepts https://developers.openai.com/codex/concepts/subagents
OpenAI Codex Automations https://developers.openai.com/codex/app/automations
OpenAI Codex Changelog https://developers.openai.com/codex/changelog
OpenAI: OpenAI frontier models and Codex are now available on AWS https://openai.com/index/openai-frontier-models-and-codex-are-now-available-on-aws/

摘要