adversarial-coach

核心用法

adversarial-coach 是一款对抗式实现审查工具，灵感源自 Block 的 g3 方言编码研究。用户通过 /coach [requirements-file] 触发，系统会启动「教练-选手循环」：先识别需求来源（指定文件、常见规范文件或对话上下文），再由「教练」角色以完全新鲜的客观视角审查实现——刻意丢弃对代码的既有认知，不自圆其说、不合理化捷径。

审查覆盖五大维度：需求逐项核验、编译与测试状态、常见缺口（认证端点、Token 刷新、HTTPS、bcrypt、错误处理、输入校验）、功能性真实流程测试、以及边界测试覆盖。最终以结构化 verdict 输出：IMPLEMENTATION_APPROVED 表示通过（>95% 完成度且安全无虞），或列出具体缺口与修复清单。

显著优点

• 对抗性客观性：核心创新在于「fresh objectivity」——强制审查者像从未见过代码一样评估，有效克服实现者的确认偏误与自我合理化倾向
• 安全优先设计：明确将认证、加密、输入验证列为必查项，强制 flag 安全问题而非风格问题
• 结构化输出： verdict 模板清晰，修复指令具体到文件/行，减少沟通成本
• 研究背书：基于 Block 公开发表的对抗式合作编码论文及 g3 开源实现，方法论经过学术验证

潜在局限与风险

• 依赖需求文档质量：若需求文件本身模糊或缺失，审查基准即失效
• 无法替代人工渗透测试：虽覆盖常见安全缺口，但非专业安全审计工具，复杂漏洞（如业务逻辑绕过、竞争条件）仍需专门检测
• 「新鲜视角」的实现依赖：实际由同一模型扮演教练与选手，理论上存在上下文泄露风险，虽通过 prompt 工程缓解但非绝对隔离
• >95% 完成度阈值：量化标准较模糊，大型项目可能因边缘需求未实现而被反复打回

适合人群

• 独立开发者自检代码完整性
• 敏捷团队快速门禁审查（gatekeeping）
• 教学场景演示「红队思维」与需求验证方法论

常规风险

• 过度依赖风险：开发者可能将「APPROVED」视为质量保证的终点，忽视持续集成与真实用户测试
• 安全误报/漏报：bcrypt、JWT 等模式化检查可能放过实现层面的细微错误（如弱随机数源）

核心用法

/coach 是一个对抗式代码审查指导工具，借鉴了 Block 公司的 g3 辩证自编码研究成果。用户通过 /coach [requirements-file] 命令启动审查流程，系统会扮演"教练"角色，与实施代码的"玩家"形成对立统一的辩证循环：玩家实现功能后，教练以独立客观的视角评估代码与需求的符合度，返回 IMPLEMENTATION_APPROVED 或具体的修复建议，直至通过验收。

显著优点

方法论先进：引入"新鲜客观性"原则，强制审查者抛弃既有认知，不从意图出发而从需求文档出发验证，有效避免开发者自我合理化的盲区。

安全导向明确：将安全检查嵌入标准流程，强制覆盖认证端点、Token 刷新、HTTPS、bcrypt 密码加密、错误处理、输入验证等常见缺口，显著提升代码安全性。

反馈精准高效：采用结构化输出格式，区分"需求合规性"与"立即行动项"，给出文件/行号级别的具体修复建议，避免泛泛而谈的风格偏好批评。

零依赖零风险：纯 Markdown 文档型设计，无可执行代码、无第三方依赖、无网络请求，部署和使用均无额外安全负担。

潜在缺点与局限性

人工介入依赖：本质上仍是指导框架，实际审查质量高度依赖模型执行时的上下文理解能力，复杂场景下可能需要多轮迭代。

覆盖率阈值刚性：设定 95% 完成度才批准通过，在快速原型或 MVP 阶段可能显得过于严格，需结合项目阶段灵活调整预期。

文档前提假设：假设用户已具备结构化的需求文档（如 requirements.md/SPEC.md），对文档驱动不成熟的团队存在 adoption 门槛。

适合的目标群体

• 安全关键型系统开发者：金融、医疗、政务等领域对代码安全性有硬性要求的团队
• 代码审查制度化的技术团队：希望建立标准化、可重复的审查流程
• 独立开发者与开源贡献者：缺乏专职 reviewer 时自我把关的工具
• 技术负责人与架构师：需要客观第三方视角验证实现完整性的场景

使用风险

性能方面：无运行时代码，对系统资源零消耗；但多轮辩证循环可能增加交互次数，大型项目审查需预留充足时间。

依赖项方面：零外部依赖，无供应链攻击风险；但依赖模型对 Block g3 研究方法论的理解深度，建议团队结合官方论文深化认知。

合规提示：当前版本未明确声明开源许可证，商业使用前建议确认许可条款。