研发协作
在合并大型或高风险 PR 前,用四个并行只读子代理从安全…
当你需要在大 diff、重构或安全/性能敏感改动合并前做多维度代码审查时,用四个并行只读子代理各审一个维度,再由主代理合并成一份优先级报告。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 38/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15
适用场景
在合并大型或高风险 PR 前,用四个并行特定
解决思路
- 用 git diff --name-only origin/main...HEAD 获取具体变更文件列表,或粘贴 PR 链接让主代理从分支列出变更文件。
- 在一条消息中同时发起四个 Task 调用,每个都设置 subagent_type: "explore" 且 readonly: true,分别负责安全、性能、正确性、可读性四个维度。
- 安全子代理的提示词:只读审查 SECURITY,聚焦注入(SQL、shell、XSS)、授权/认证缺口、代码中的密钥、不安全反序列化、路径遍历、SSRF、IDOR、diff 中提到的依赖 CVE;输出 Critical/High/Medium/Low 分级发现、File:line 和简短修复建议,无实质问题则输出 "No issues"。
- 性能子代理的提示词:只读审查 PERFORMANCE,聚焦 N+1 查询、缺失索引、意外的 O(n²) 循环、bundle 体积影响、不必要的重渲染、热路径上的同步 I/O、无界缓存;输出同样的严重级别与位置格式。
- 正确性子代理的提示词:只读审查 CORRECTNESS,聚焦逻辑 bug、off-by-one、错误边界情况、竞态条件、错误处理缺口、破坏性 API 变更、新行为的测试缺口;输出同样格式。
- 可读性/可维护性子代理的提示词:只读审查 READABILITY,聚焦命名、重复、抽象边界、文件大小、不清晰的控制流、能防止 bug 的缺失类型/文档;输出同样格式,优先给建议而非吹毛求疵。
- 主代理合并时:对出现在多个维度中的发现去重(只计一次,取最严重级别),先按严重级别再按修复成本排序,产出最多 5 条要点的执行摘要和可执行事项的表格或列表。
- 可选:在主代理中修复,或仅对已批准的事项发起针对性的非只读后续任务。
- 保持提示词为只读,避免并行运行在写入上冲突。
- 如果 diff 很大,按目录拆分,第二轮对每个目录运行四个审查者,不要把不相关的大型 diff 塞进一次审查。
- 该流程补充人工审查,不替代受监管环境中的合规或安全签核。
- 适用场景:单次审查容易遗漏类别的大型 diff 或重构;安全敏感改动(认证、支付、解析不可信输入);性能敏感路径(热循环、N+1 查询、bundle 入口点)。
适用边界 · 注意事项
- diff 极大时不要把所有不相关改动塞进一次审查,应按目录拆分分轮运行。
- 不能替代受监管环境中的合规或安全签核,也不能替代人工审查。