777genius 95e0f34d31 docs(product-docs): add zh, es, ja, fr, de doc translations

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

2026-05-31 17:50:54 +03:00

5.3 KiB

Raw Blame History

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

代码审查

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

审查界面

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

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

代码块（hunk）级别的决策

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

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

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

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

发起审查

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

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

审查循环

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

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

请求修改评论的示例：

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 集成。

审查参与者

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

需要手动检查的内容

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

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

有关规范的功能布局和硬性护栏（guardrail）链接，请使用贡献者架构。

验证

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

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

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

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

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

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

5.3 KiB Raw Blame History Unescape Escape