> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myrmagent.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 代码审查纪律

> Myrm 的 code-review 技能审查而不越权——只报告问题而不是悄悄改代码，拒绝臆想出来的风险，把每个问题归因到正确的变更，并把跨范围的阻塞项交给你拍板。

# 代码审查纪律

大多数 AI 代码审查员的失败不在于「审得不够细」，而在于**越权**：Agent 把只要求审查的代码顺手改掉、把陈年 bug 算到你的新变更头上、编造臆想风险来显得很认真、或者悄悄修一个跨模块的问题——而那个问题本该由人来决策。

Myrm 的 **code-review** 技能让审查员像一个自律的资深工程师：

* **只审查，不修改。** 应用修复是独立的步骤，由你或专门的修复管道完成。
* **每个问题都有归因。** 每条 finding 都标注 `Introduced-in-change`（本次变更引入）/ `Pre-existing`（之前就存在）/ `Unknown`（无法判定），以 `git diff` / `git blame` 为依据，绝不猜测。
* **臆想风险被拒绝。** Finding 必须落在真实 diff 上；不现实的边缘场景和假设性失败会被剔除，而不是凑数。
* **跨范围阻塞项升级给你。** 真正跨越模块边界或所有权线的风险会被上报并标记为 **Needs user decision**（需要用户决策），而不是被悄悄并入本次变更。

## 四层纪律

| 纪律         | 防什么              | 如何落地                                         |
| ---------- | ---------------- | -------------------------------------------- |
| **只报告不修改** | Agent 审查时顺手改代码   | 技能正文显式声明「仅产出报告」契约                            |
| **归因**     | 陈年 bug 被算到你的变更头上 | `git diff`/`git blame` 证据 + 保守的 `Unknown` 兜底 |
| **反臆想**    | 假 bug 凑数撑报告      | Finding 必须引用真实 diff 与周边代码                    |
| **停手并升级**  | 审查员擅自修跨模块问题      | 标记 **Needs user decision**，绝不自动应用            |

## 多智能体流水线闭环

当审查以 **code-review-pipeline** 形式运行（分析员 → 安全审查员 → 逻辑审查员 → 验证员）时，闭环在最后一公里显式落地：

* **验证员**角色确认修复并运行回归测试，**但不会自动修复标记为 `Needs user decision` 的项**——这些项交还给你。
* 流水线的成功标准要求 **out-of-scope blockers escalated to user decision**（跨范围阻塞项必须升级为用户决策），让真正的风险不会消失在 Agent 的修复清单里。

这很重要，因为 Myrm 的流水线是端到端 agent 自动化的。在竞品产品里，人类始终在 PR 界面上参与，所以它们从不需要教验证 Agent「何时该停手」。Myrm 必须补上这一环——而且做到了。

## 需求追溯

除了发现问题，技能还把任务/PR 描述里的每个需求映射为验证结果：

| 需求                                 | 状态              |
| ---------------------------------- | --------------- |
| 例如「通过 Google 和 GitHub 实现 OAuth 登录」 | 满足 / 部分满足 / 未满足 |

如果没有明确需求，它会陈述推断出的目的并确认代码是否达成——这样审查回答的是「**这次变更兑现承诺了吗**」，而不只是「代码干不干净」。

## 如何使用

**零配置。** 该技能以预置技能形式出现在 **设置 → 技能** 中。

* **直接审查变更：** 启用 `code-review` 技能，让 Agent 审查 PR、文件或模块。
* **运行完整审查流水线：** 使用 `code-review-pipeline` 技能（看板 → 流水线 → 代码审查），并行展开安全 + 逻辑审查，最后进行修复验证与回归测试。

## 验证与契约测试

技能的契约由契约测试守护（断言每条纪律条款都在、frontmatter 版本合法），并由集成测试覆盖完整流水线（实例化 → 任务 DAG → 验证员任务描述），关键路径无 mock。审查流水线解析与 `Needs user decision` 闭环均端到端覆盖。

## 相关

* [证据纪律](/docs/zh/guides/evidence-discipline) — 每个回答的表达层诚实
* [分层验证手册](/docs/zh/guides/layered-verification-playbook) — 审查纪律之上的架构级验证
* [技能发现与注册中心](/docs/zh/guides/skill-discovery) — 安装与管理预置技能