需求协议的开源实现：加载
AGENTS.md后，AI 变身为「需求 Scout」——通过对话一点一点帮您把模糊想法挖成可落地、可验证、可直接开工的需求文档。产出接口对准 Anchorlaw（编程执行协议）的 stage-0 输入契约——需求确认后直接喂给 Anchorlaw 实施，零重新诠释。
三协议闭环中的「需求协议」一环：
需求协议（本项目）→ Anchorlaw（编程执行）→ RE 框架（逆向探索）
模糊意图 → 已确认需求 需求 → 代码+验证 目标程序 → 逆向结论
- Anchorlaw 解决「拿到确定需求后怎么实施并验证」
- req-scout 解决「模糊想法怎么变成确定需求」——Anchorlaw 的上游
- 需求发掘是探索型工作，不是构建型工作——探索人类的意图要靠对话，不能用判据驱动的流水线硬套（Anchorlaw v0.10 结构反转的教训）。
- AI 角色的注意力机制：发散（倾听/共情/提问）和收敛（判定/挑剔/矛盾检测）是两种互相干扰的认知模式。单角色既发散又收敛，必然互相污染——所以本协议用 Scout（发散）+ Judge（收敛）双角色闭环。
- 模糊是需求的逃逸通道：「差不多」「到时候再说」到实现期就变成甩锅空间——必须当场锁定。
把本仓库（至少 AGENTS.md + skills/ + templates/）交给任何支持 AGENTS.md 的 AI（Claude / OpenClaw / 其他 agent），AI 启动后即扮演需求 Scout。
Scout 按层提问：意图 → 功能 → 约束 → 边界。每轮对话后：
- Scout 整理草稿（
scout-notes.md：客户原话 S: / 推测 I: / 未决问题 ?） - 召唤 Judge（加载
skills/judge-review/SKILL.md的隔离 subagent）审核 - Judge 返回五段式技术报告：可实现 / 不可实现 / 模糊点 / 矛盾 / 缺失
- Scout 把报告翻译成您能懂的问题，继续下一轮对话
循环直到：Judge 说「模糊点清零、技术层可落地」+ 您逐条确认 → 产出需求文档。
按 templates/requirements-doc.md 输出已确认需求文档 + 技术约束规范，交给 Anchorlaw 实施。您的确认 = Anchorlaw 的实施授权。
req-scout/
├── AGENTS.md ← Scout 角色定义（灵魂文件：发散者铁律/工作流程）
├── docs/
│ └── requirements-protocol.md ← 需求协议全文（判据体系/产出契约/Anchorlaw 映射）
├── skills/
│ └── judge-review/SKILL.md ← Judge 角色定义（收敛者铁律/五段式报告）
├── templates/
│ ├── scout-notes.md ← Scout 草稿格式（交 Judge 的输入）
│ ├── judge-report.md ← Judge 五段式技术报告格式
│ └── requirements-doc.md ← 最终需求文档（Anchorlaw stage-0 输入契约）
├── examples/ ← 示例（进行中）
├── LICENSE
└── README.md
| req-scout 产出 | Anchorlaw 消费 |
|---|---|
| 声称清单（条件+行为） | Judge 推导验收判据（§15.4 criteria-first） |
| 验证方案草案 | 将来绑定 @anchor.test（§5.1） |
| 边界清单（what+source） | @anchor.idk 认知边界锚（§5.2） |
| source（需求来源） | 锚的溯源起点（§5.5） |
| 客户确认 | host handover = 实施授权（§16.1） |
对接原则：Anchorlaw 的 Judge 拿到需求文档时，推导验收判据是机械翻译，不是重新诠释。
本协议在工程设计之上，融合了唯物实践论的认识论判据：
- 第一律（实践锚定剃刀）：声称必可检验——不可翻译成验证断言的声称不许进清单
- 模糊空间 = 逃逸通道：逐条识别、逐条锁定
- Δ 自指一致性：术语操作化 + 需求间矛盾检测
- 诚实性纪律：半操作化标注 / 全称附范围 / 假设≠需求 / 接口标注
- 负反馈认识论：需求确认 = 「暂无未解决反例」，不是「需求完美」
MIT