四个AI角色互盲评审GitHub issue再合成修复方案

原文要点

该工作流用表单收集GitHub仓库、issue号、固定commit SHA和1到6个指定文件，通过GitHub API只读拉取issue与文件作为证据；架构师、开发者、评审、测试四个角色用同一自选模型互盲独立审阅，可选BVC机制在分歧时追加一轮交叉批评；总预算为5次或9次计数的模型调用（含失败调用），留1次给合成；拒答、截断或格式异常时输出失败报告而非方案。支持OpenAI、Claude、Gemini、DeepSeek、Yandex及OpenAI兼容端点，需n8n 2.37.10且启用JavaScript Code节点，从作者GitHub release下载workflow.json、README和测试。工作流不改GitHub、不提PR、不评论。作者标注n8n Cloud及多数服务商实测未验证。

这次做成什么

搭一个"四角色盲审+合成"的issue会诊台：输入一个真实issue和固定版本的代码文件，产出一份供人工复核的修复计划或失败报告，并保留每次调用与停止原因的审计记录。

准备什么

• n8n 2.37.10且启用JavaScript Code节点（Code、HTTP Request、Form节点可用）
• 一个GitHub只读token，仅授contents、issues、metadata读权限
• 自选模型服务商的API账号与密钥，费用由你的账号承担
• 从作者GitHub release下载的workflow.json及README
• 至少一个有真实issue的测试仓库

具体怎么做

1. 下载并导入工作流

   打开作者的release页（github.com/jabrailkhalil/xynapse/releases/tag/n8n-bvc-v0.1.0），下载workflow.json、README和测试文件。在n8n 2.37.10中导入workflow.json；若导入报错先确认实例版本和JavaScript Code节点已启用。

2. 创建GitHub只读凭据

   在GitHub生成fine-grained token，只勾选目标仓库的contents、issues、metadata读取权限。在n8n建Header Auth凭据，值填Authorization: Bearer 你的token，并绑定到全部8个GitHub HTTP节点。

3. 配置模型与预算

   在Configure approved input节点选择服务商、填精确模型ID、把maxCalls设为5或9（9含一轮交叉批评的余地）。按README为所选服务商建Header Auth凭据，绑定到全部9个Model HTTP节点；换服务商必须重新绑定。

4. 跑表单测试

   手动执行工作流打开表单，填仓库owner/name、一个真实issue号、该仓库当前完整commit SHA（git rev-parse HEAD获取，勿用分支名），并明确列出1到6个相关文件路径。先不勾Use BVC跑一次，观察四份独立评审与合成计划。

5. 核对审计并发布

   检查Final report中的attempts、分歧点与停止原因；再勾选Use BVC对比是否追加了批评轮。确认无误后发布工作流获得可复用表单URL，使用者需有授权的n8n登录。

可直接复制的材料

你是{架构师|开发者|代码评审|测试工程师}。以下是一个GitHub issue描述和固定版本的若干源文件，它们是唯一证据，你看不到其他角色的结论。任务：1) 用证据推断缺陷根因，引用具体文件与行；2) 给出你角色视角下的修复建议，说明影响的模块；3) 列出你不确定、需要其他角色确认的点。若证据不足以定位，明确说"证据不足"而不是猜测。输出为三个小节的纯文本。

{
  "repository": "yourname/demo-shop",
  "issue_number": 42,
  "commit_sha": "9f02c1d4e5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0",
  "files": ["src/cart/calc.js", "src/cart/calc.test.js"],
  "use_bvc": false,
  "maxCalls": 5
}

复核顺序：1. 四角色是否都完成且互不相同（排除模型复读）；2. 根因是否引用了具体文件行号；3. 修复建议是否触及issue未提到的文件（警惕臆测）；4. 审计中attempts是否超限、stop reason为何；5. 若为失败报告，确认是拒答、截断还是格式异常，再决定换模型重跑。

输入与输出示例

本站虚构演示，非作者运行结果，未实际调用任何模型

输入

表单填：仓库yourname/demo-shop，issue #42"购物车满200减30未生效"，commit SHA为9f02c1d4…（40位），文件选src/cart/calc.js和calc.test.js，不勾BVC，maxCalls=5。

对应输出

合成计划要点：架构师指出calc.js第38行满减判断在折扣前执行导致门槛计算错误；开发者给出把满减移到小计之后的改法；评审提醒该改动影响优惠券叠加分支；测试要求补三条边界用例（199.99、200、200.01）。审计显示5次调用全部成功、无追加批评轮、stop reason为budget_exhausted_after_synthesis。

做完检查这些

• 四份角色评审内容互不雷同，且合成计划引用了具体文件名与行号
• 审计记录中模型调用次数不超过设定的5或9，且含失败调用的计数
• 表单使用完整commit SHA时两次运行读到的文件内容完全一致
• 工作流全程未对GitHub产生任何写入（无PR、无评论、无提交）

容易卡住的地方

• 用分支名或短SHA代替完整commit SHA会破坏可复现性，表单要求完整SHA
• GitHub token若给了写权限违背只读设计，应仅授contents/issues/metadata读权限
• 5次预算勾BVC可能不够追加批评轮，想体验BVC建议设9
• 作者明确n8n Cloud及对多数服务商的实测未验证（verification=not_run），先在自托管实例小步测试
• 模型被拒答或输出截断时得到的是失败报告，属正常设计而非工作流故障