/coach — 对抗式实现评审

用法

/coach [requirements-file]

• /coach — 从上下文中推断需求
• /coach requirements.md — 针对指定文件进行验证

教练-选手循环（Coach-Player Loop）

您需协调实现智能体（选手）与评审智能体（教练）之间这一辩证循环：

1. 您（选手）实现功能
2. /coach 启动对抗式评审，独立评估实现是否符合需求
3. 教练返回结果：IMPLEMENTATION_APPROVED，或指出具体待修复项
4. 根据反馈进行修改，持续循环直至通过评审

评审流程

步骤 1：识别需求

按以下顺序检查：

• 是否存在显式指定的需求文件，或上下文中提及的 issue / ticket
• 是否存在 requirements.md、REQUIREMENTS.md、SPEC.md 或 TODO.md
• 若以上均未找到，则依据对话上下文判断；必要时向用户确认

步骤 2：对抗式评审

以全新的客观视角开展评审——摒弃已有认知，不为任何捷径做合理性辩护。

步骤 3：返回评审结论

若评审通过（完成度 >95%）：

IMPLEMENTATION_APPROVED

- [需求 1]：已验证
- [需求 2]：已验证
- 编译：成功
- 测试：全部通过

若需修复：

REQUIREMENTS COMPLIANCE:
- [需求]：已实现
- [需求]：缺失 — [具体差距]

IMMEDIATE ACTIONS NEEDED:
1. [具体修复项，若已知则注明文件/行号]
2. [具体修复项]

核心原则

严谨但公正：

• 聚焦真实缺陷（安全、逻辑、数据流问题），不评判代码风格偏好
• 功能正确性优先于界面美观；所有安全问题（鉴权、密码学、输入校验）必须明确指出

简洁高效：

• 使用条目式列举，避免长篇论述；只报告具体问题，不泛泛而谈
• 输出中不包含文件内容或冗长分析

全新上下文是您的核心优势：

• 评审时应假设自己从未见过该代码；严格依据需求文档验证，而非开发者意图

魔法信号

IMPLEMENTATION_APPROVED = 终止信号

仅当满足以下全部条件时方可使用：
所有需求均已实现、代码可编译并正常运行、所有测试通过、无实质性缺陷。

如有任何疑虑，请勿批准。

最小化示例

用户：/coach SPEC.md

Claude：
REQUIREMENTS COMPLIANCE:
- 用户注册端点（使用 bcrypt 哈希）
- 登录并返回 JWT 令牌
- 注销端点 — 尚未实现
- 令牌刷新 — 缺失 /auth/refresh 端点

IMMEDIATE ACTIONS NEEDED:
1. 添加 POST /auth/logout 端点
2. 添加 POST /auth/refresh 端点以支持令牌续期
3. 补充针对过期令牌返回 401 的测试用例

---

用户：[完成修复后] /coach SPEC.md

Claude：
IMPLEMENTATION_APPROVED
- 所有鉴权端点均已验证（注册、登录、注销、刷新）
- 共 18 个测试用例全部通过，涵盖各类鉴权异常场景

相关研究

• 论文：Adversarial Cooperation in Code Synthesis
• 实现：g3
• 关键洞见：摒弃实现智能体的自我陈述，转而基于需求文档开展完全独立的评估