把进阶能力串成一个真实工作流
前四块（子 Agent、计划模式、技能系统、权限安全）单看都不难，真正的难点是把它们组合成一个可用的工作流。这一节用一个完整任务把它们串起来。
而你要串的，就是贯穿全课的 codex-review——把前面所有能力收束成「一个端到端能跑通的评审工作流」。之前你分块学会了拆解、并行、规划、技能、权限，这一节把它们组合成 codex-review 的完整闭环。
codex-review 要长什么样
动手前，先把「端到端工作流」的目标定下来。一个能跑通的 codex-review，应该长这样：
输入：一次代码改动（分支 / PR / 一批文件）
↓
第1步：出评审计划（审哪些、派几路、怎么验收） ← 计划模式
第2步：确认计划
↓
第3步：派三路子 Agent 并行评审 ← 子 Agent
第4步：三档输出 + 冲突对账 ← 技能系统约定
第5步：权限边界全程约束（只读、危险必确认） ← 权限模型
↓
输出：一份可照着修的评审报告
目标清晰，再往下搭。
准备：先把评审技能和权限边界就位
codex-review 的骨架是「技能」+「权限」。动手前先确保这两样在：
- 评审技能（模块 03 已写）：
.claude/skills/codex-review/SKILL.md，包含三路并行、三档输出、冲突对账的约定。 - 权限边界（模块 04 已写）：SKILL.md 里的「权限边界」一节，默认只读、不直接改代码。
任务：端到端跑通 codex-review
已就位：
- 技能：.claude/skills/codex-review/SKILL.md
- 权限：默认只读 + 危险操作必确认
- 缺：一份真实待评审的改动
第 1 步：用「计划模式」规划评审流程
先别开审，用计划模式规划这次评审：
先别开审。给「评审 src/ 这次 30 个文件改动」出个评审计划：
准备派几路（逻辑/安全/风格）？每路审哪些文件、重点查什么？
结论怎么汇总、按什么验收？列出计划，等我确认再开审。
它给出的计划应当覆盖：目标（审出三档清单）、步骤（派三路）、范围（审 src/、不审什么）、风险与回滚（审漏了怎么补）。
你审这份计划：范围对不对？「不审什么」写清了吗？三问（能做吗 / 会碰错吗 / 有退路吗）通过后确认。
可以，按这个评审计划开审。
第 2 步：用「技能系统」固化评审规则
评审规则已经在 SKILL.md 里固化，所以这一步你只需要触发技能，而不是再手打一遍：
用 codex-review 技能，评审 src/ 本次改动。
技能会按约定自动执行：派三路 → 三档输出 → 冲突对账。这就是技能系统的意义——你不用每次重写评审规则，一句触发即到位。
如果你觉得评审规则有遗漏（比如想加一条检查点），现在改 SKILL.md 再触发，而不是在本次对话里临时补。规则沉淀进技能，下次才复用。
第 3 步：用「子 Agent」并行拆解评审
技能触发后，主会话按约定派三个子 Agent 并行评审。你应该看到：
并行三路：
- 逻辑子 Agent：业务正确性、边界情况、异常处理、数据一致性
- 安全子 Agent：注入、越权、硬编码密钥、敏感信息
- 风格子 Agent：命名、格式、重复代码、可读性
各自输出三档清单 → 汇总
三路各自独立上下文、同时推进，总时间 ≈ 最慢那路。这就是「多 Agent 协作评审工作台」的核心。
第 4 步：全程用「权限模型」约束边界
并行评审全程，权限边界要持续生效：
- 只读不写：三路子 Agent 只读代码、只出结论，不直接改文件
- 跑命令需单独授权：若需要跑
npm test验证某个问题，只放行那一条命令 - 危险操作必确认：任何删除、覆盖、高风险命令，必须停下问你
发现子 Agent 想直接改文件修「必须改」？→ 叫停。
本次是评审，只出报告。要修另开修正任务并单独授权。
权限边界（已写进技能）让三路并行评审既快又稳，不出安全圈。
第 5 步：整体验证
并行结果汇总后，做一次整体验证，对照验收标准：
- 三路结论都齐了吗？每路都按三档输出了吗？
- 「冲突对账」一节做了吗？被多路提到的位置，结论是否矛盾？
- 「必须改」每条都有「位置 + 问题 + 建议」吗？
- 权限边界全程遵守了吗（只读、没乱跑命令）？
全部通过，这份 codex-review 评审才算跑通。
一张图回顾这套工作流
计划模式（先规划评审流程）
→ 技能系统（固化评审规则，一句触发）
→ 子 Agent（并行拆解三路评审）
→ 权限模型（兜底：只读、危险必确认）
→ 整体验证（三档 + 对账 + 验收）
四个能力各司其职、缺一不可，组合成了 codex-review 的端到端闭环。
落地练习
.claude/skills/codex-review/SKILL.md）和权限边界；第 2 步，挑一个真实分支，完整走一遍五步（出计划 → 确认 → 触发技能 → 三路并行 → 权限约束 → 整体验证）；第 3 步，拿到一份「三档齐全 + 冲突对账完整」的评审报告。② 怎么判断做对了：全程你只需要「出计划 + 确认 + 触发技能」三个动作，其余由技能自动完成；报告里有完整三路结论、冲突对账、每条的「位置+问题+建议」；评审过程只读不写。
③ 卡住了怎么办：如果技能没自动并行，检查 SKILL.md 的「派三个独立子 Agent」写没写清；如果某路结论薄，回技能补充检查点再触发；如果它想改文件，提醒「本次只读」并收紧权限。
常见坑：把「触发技能」当成「这次对话里手打一遍」
端到端最容易翻车的，是技能建好了却不触发，反而在对话里重新手打整套评审指令。有人觉得「这次临时手打也一样」，结果评审规则又回到「每次自由发挥」，技能形同虚设——多 Agent 协作工作台又退回了单次对话。
正确做法：一旦技能就位，就坚持用它触发（用 codex-review 技能评审…），把评审规则的制定权交给技能。真觉得规则不对，去改 SKILL.md，而不是在对话里临时覆盖。这样 codex-review 才真正「一次定义、处处复用」。
小结
- 动手前先定权限边界
- 计划先行、标准沉淀（技能）、并行提速（子Agent）、安全兜底（权限）
- 收尾做整体验证（三档 + 对账 + 验收）
- 四个能力合体，端到端跑通 codex-review
下一节，复盘这套流程，并学会持续优化——让 codex-review 越用越稳。