结构化多智能体代码审查

要解决什么问题

一次 diff 交到单个 reviewer 手里，视角往往不够完整。安全、性能、架构一致性、可维护性可能同时被略过，或者某一类问题被反复提及，另一些关键风险却没人关注。直接堆叠多个模型去 review，又容易变成各说各话，意见互相冲突，最后仍要人逐条翻看并判断。

技能如何工作

• 角色拆分：不同 reviewer persona 分别从安全、架构、性能、可读性等角度检查同一份变更，而不是让一个模型一次性包揽所有维度。
• 结构化讨论：各角色在回合制对话中提出发现、回应异议、修正判断，而不是各自输出后简单汇总。
• 合成输出：人工批准前，系统整理出一份结构化的 review 结论，区分共识、争议点和需要人来裁决的事项。

关键步骤通常包括：

1. 从当前 Git 工作分支准备 diff，进入待评审状态。
2. 通过 ocr dashboard 运行评审回合，浏览结果并管理流程。
3. 输出可人工审阅的 review 报告，而不自动提交或直接写回 PR。

适用边界

它适合处理结构较清晰的代码变更，例如重构模块、新增 API、修改跨模块逻辑。但它不替代人做业务权衡、交互细节或合规判断。reviewer persona 提供的是视角，不是权威；最终决策仍需人确认。

另外，环境要求包括 Node.js 20+、Git、受支持的 AI 编码助手，若要回写 PR 还需 GitHub CLI 认证。没有这些前置条件时，讨论回合无法正常运转。