oh-my-pi /review 代码审查完整指南：P0 到 P3 优先级排序，一键裁决代码能否发布
oh-my-pi /review 代码审查完整指南：P0 到 P3 优先级排序，一键裁决代码能否发布
【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi
oh-my-pi是一款把 IDE 深度接入的编程智能体（Coding agent），其中的/review代码审查命令可以把你的改动交给专门的审查智能体：先按P0 到 P3 四级优先级给问题排序，再输出一个明确的"能否发布"裁决——是correct（可合并）还是incorrect（存在阻断性缺陷），全程只需一个斜杠命令。
3 步启动 /review 代码审查
/review是一个内置的交互式命令，输入后会出现"审查模式"选择菜单。核心流程只有 3 步：
- 输入
/review（可直接跟在命令后附加自定义要求，如"重点关注并发安全"） - 选择审查范围：选一个模式并确认
- 等待裁决：审查智能体逐文件分析后，输出带优先级的 findings 和最终 verdict
内置的 5 种审查模式
| 模式 | 适用场景 | 说明 |
|---|---|---|
| 🎯 检测到的 PR | 对话中提到过 PR 链接 | 从会话上下文自动识别，无需手动输入 |
| 🌿 对比基线分支 | PR 风格审查 | 选择 base 分支，自动 diff 当前分支 |
| 📝 未提交改动 | 本地开发中 | 审查 staged + unstaged 全部改动 |
| 📌 指定 commit | 追溯历史提交 | 从最近 20 条提交中选一条 |
| ✍️ 自定义指令 | 专项检查 | 自己写审查要求，如"只看性能问题" |
命令的完整实现在 review/index.ts，斜杠命令的发现与调度机制可参考 docs/slash-command-internals.md。
P0 到 P3：AI 代码审查的四级严重程度
每条 finding 都必须标注 0–3 的优先级，这是/review给出可执行结论的关键。官方定义的分级标准如下（源自 reviewer.md）：
| 级别 | 判定标准 | 典型例子 | 处理时机 |
|---|---|---|---|
| 🔴P0 | 阻断发布/线上运维；与输入无关必然触发 | 数据损坏、鉴权绕过 | 立即修复，否则不发布 |
| 🟠P1 | 高风险 | 高负载下的竞态条件 | 下一迭代必须修复 |
| 🟡P2 | 中风险 | 边缘场景处理不当 | 计划内修复 |
| ⚪P3 | 信息级 | 次优但正确 | 锦上添花 |
发布裁决：由 3 个字段组成的"能否发布"结论
审查结束前，审查智能体必须交出一个结构化裁决，而不是含糊的"看起来还行"：
- overall_correctness（整体正确性）：
correct= 无 bug/无阻断项，可以合并；incorrect= 存在必须处理的问题 - explanation（裁决说明）：1–3 句纯文本总结，直接回答"能不能发"
- confidence（置信度）：0.0–1.0，告诉你这个裁决有多可靠
注意一个容易忽略的细节：风格、文档、命名等 nit 类问题不计入正确性裁决。也就是说，只要没有 P0/P1 级缺陷，即使有一堆 P3 建议，结论依然是"可发布"——这正是"裁决"与"唠叨"的区别。
严格过滤准则：为什么 AI 审查不钻牛角尖
很多 AI 审查工具最大的问题是误报泛滥。oh-my-pi 的审查智能体要求每条 finding 必须同时满足 6 条准则：
- 影响可证明——能指出具体受影响的代码路径，拒绝猜测
- 可执行——有明确的修复动作，而非"建议优化 X"
- 非故意——明显不是作者刻意的设计选择
- 补丁引入——不标记存量旧 bug，只查本次改动
- 无隐藏假设——不对代码库或作者意图做未声明假设
- 严格度对等——不提出代码库其他地方都不具备的严苛要求
此外还有专门的跨边界检查：任何穿过函数/模块边界的新类型、消息、枚举值，都必须去消费端确认存在匹配的分发分支，防止"生产者发了消息、消费者静默丢弃"这类集成 bug 漏审。
大型改动审查：并行审查员与自动噪音过滤
当 diff 变大时，/review会自动做两件事：
- 并行分派：按改动行数和文件数计算审查员数量（小改动 1 个，超大改动最多 16 个），并按"同目录同智能体、测试跟随实现"的原则分组，通过
task工具并行派发 - 噪音过滤：lock 文件、构建产物、图片字体、
node_modules等自动排除，且会在结果中列出排除清单，审查不跑偏
这套"分发 + 过滤"逻辑让几千行的巨型 PR 也能被审查得条理清晰。相关机制可阅读 docs/task-agent-discovery.md 与 docs/tools/task.md。
关键文件与延伸阅读
| 资料 | 路径 |
|---|---|
| /review 命令实现 | review/index.ts |
| 审查员智能体定义（含 P0-P3 标准） | reviewer.md |
| 审查请求提示词模板 | review-request.md |
| 无头（headless）审查模板 | review-headless-request.md |
| 斜杠命令内部机制 | docs/slash-command-internals.md |
| CLI 完整参考 | docs/cli-reference.md |
常见问题
Q：审查会修改我的代码吗？不会。审查智能体的 Bash 工具是只读的，只允许git diff、git log、gh pr diff等命令，明确禁止编辑文件或触发构建。
Q：和 /security 安全扫描有什么区别？/review关注"本次改动是否正确、能否合并"，/security是独立的安全扫描流水线（计划、扫描、导入 SARIF、对比 lineage），两者互补。
Q：审查结论能当最终把关吗？建议把incorrect裁决和 P0/P1 发现当作硬性阻断项处理，P2/P3 按排期跟进——这样既能拦住真正的事故，又不会被低级别建议拖慢发布节奏。
💡 小结：oh-my-pi 的
/review把"AI 代码审查"从一堆零散评论升级成了分级 + 裁决的工程流程——P0 到 P3 排序告诉你要先修什么，correct/incorrect裁决直接回答你能不能发布。
【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考