95e0f34d31
Localize the VitePress docs into Simplified Chinese, Spanish, Japanese, French and German (18 pages each), mirroring the existing en/ru structure. - generate the 5 new locales in config.ts from a single strings table (nav, sidebar, search, footer, docFooter, outline, editLink) with locale-prefixed links - rework DocsCardGrid from the binary isRu check to a per-locale map so the home cards render translated copy and prefixed links for every locale
119 lines
5.3 KiB
Markdown
119 lines
5.3 KiB
Markdown
---
|
||
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`。它会在审查界面中制造噪音。
|
||
:::
|