---
title: 代码审查 – Agent Teams 文档
description: 检查任务范围内的差异（diff），接受或拒绝代码块（hunk），留下行内评论，并管理从 none 到 approved 的审查状态。
lang: zh-Hans
---

# 代码审查

Agent Teams 中的代码审查以任务为中心。你检查的是某个特定任务发生了哪些变更，而不是在一大堆无结构的差异中翻找。

## 审查界面

对于每个触及文件的已完成任务，审查 UI 让你能够：

- 在带有变更前/后上下文的情况下检查变更的文件
- 接受或拒绝单个代码块（hunk）
- 留下行内评论
- 将差异关联回任务描述和智能体日志

## 代码块（hunk）级别的决策

接受细小且正确的变更，并拒绝个别的错误，而无需丢弃整个任务。当某个智能体基本上解决了任务，但在某个文件上做得过头时，这种方式很有用。

::: tip 增量接受
如果一份差异大体正确，先接受好的代码块，只对需要修复的部分请求修改。这样可以让看板持续向前推进。
:::

在以下情形使用代码块（hunk）级别的决策：

| 情形 | 操作 |
| --- | --- |
| 范围正确的变更 | 接受该代码块 |
| 思路正确，但文件错误或重构范围过宽 | 拒绝该代码块并请求一个更窄的修复 |
| 行为变更不明确 | 评论并要求验证 |
| 生成的格式噪音 | 拒绝，除非格式调整本就是任务的一部分 |

## 发起审查

1. 打开一个已完成的任务
2. 查看 **Changes** 标签页
3. 如果差异看起来合理，点击 **Request Review** 将任务移入审查（review）列

在审查期间，任务尚未被视为完成，因此其他队友或 lead 仍可以对其发表评论。

## 审查循环

一个健康的审查循环看起来是这样的：

1. 任务负责人发表一条结果评论，说明变更范围和验证情况
2. 审查者打开任务差异，并对照任务描述检查各个代码块
3. 审查者接受好的代码块、拒绝差的代码块，或请求修改
4. 负责人只修复所请求的范围，并发表一条后续评论
5. 当任务结果与差异相匹配时，审查者予以批准

请求修改评论的示例：

```text
Please keep the copy improvements, but revert the unrelated runtime wording in the provider table. Add the `pnpm --dir landing docs:build` result before resubmitting.
```

## 审查状态

| 状态 | 含义 |
| --- | --- |
| `none` | 任务为新建、进行中，或已完成但尚未进入审查 |
| `review` | 任务正在被积极审查 |
| `needsFix` | 已请求修改；负责人必须先更新才能再次批准 |
| `approved` | 审查已被接受，任务已最终确定 |

## 智能体审查工作流

在你做出最终决定之前，团队之间可以相互审查彼此的工作。这能捕捉到明显的回归，并让看板保持真实，但你仍应亲自审查有风险的区域。

当审查者拥有清晰的评分标准（rubric）时，智能体审查最为有用。例如，让一个审查者只检查文档的清晰度、只检查 IPC 安全性，或只检查测试覆盖率。宽泛的“审查所有内容”请求往往会产生较弱的反馈。

### MCP 驱动的审查状态

审查状态的变更（请求审查、请求修改、批准）是由工具驱动的。在任务上留下一条“请求修改”的评论**并不会**将看板列移动到 `needsFix` —— 必须由 lead 或智能体调用相应的 MCP 工具：

- `review_request_changes` —— 将任务移动到 `needsFix` 并通知负责人
- `review_approve` —— 将任务移动到 `approved` 并最终确定审查

仅凭评论不足以触发状态转换。有关审查类 MCP 工具及其参数的完整列表，请参阅 [MCP 集成](/zh/guide/mcp-integration)。

## 审查参与者

团队 lead 是默认的审查者。如果你希望同伴之间相互审查工作，可以在 Kanban 设置中配置额外的审查者。

## 需要手动检查的内容

审查时优先关注以下区域：

- **提供方认证与运行时检测** —— 智能体是否以会破坏其他路径的方式更改了运行时设置？
- **IPC、preload 与文件系统边界** —— 保持 Electron 各项职责相互分离
- **Git 与 worktree 行为** - 验证分支命名、提交和推送；隔离模式请参阅 [Git 与 worktree 策略](/zh/guide/git-worktree-strategy)。
- **解析与任务生命周期逻辑** —— 对任务引用、分块（chunking）或过滤的更改可能破坏消息投递
- **持久化与代码审查流程** —— 对任务存储或审查状态的更改必须在各 IPC 层之间保持一致

有关规范的功能布局和硬性护栏（guardrail）链接，请使用 [贡献者架构](/zh/reference/contributor-architecture)。

## 验证

优先使用聚焦的验证命令。除非任务明确打算进行大范围的格式整理，否则不应使用宽泛的格式化或 lint-fix 命令。

好的验证评论包含命令及其结果：

```text
Verified with `pnpm --dir landing docs:build`. Build passed.
```

当跳过验证时，任务评论应说明原因：

```text
Docs-only wording change. Build not run because the existing dev server was busy; checked Markdown links manually.
```

::: warning 不要在整个项目范围内自动格式化
除非任务专门关于格式化，否则避免对无关文件运行 `pnpm lint:fix`。它会在审查界面中制造噪音。
:::
