用途：将需求简报或现有功能转化为可测试的需求，聚焦结果与可观察行为，保留用户的明确选择，不替用户决定产品方案。
主要能力：从简报或运行中的产品里提取用户目标、触发事件、允许的操作者、输入、结果和失败行为；为需求分配稳定 ID（仅在需要可追溯时）；针对每次写入识别服务端授权、校验、持久化、重复提交行为，以及超时后结果未知时的处理；为质量约束附加条件（目标设备、输入方式、内容大小、延迟测量、支持语言、隐私、可用性），拟议目标需标注为提案；列出依赖、未解决的契约问题与排除范围，不臆造 API。回访实现时报告哪些需求已满足、变更、缺失或未验证，并附证据。
使用方式：按“需求→验收示例→依赖/未知”输出。格式示例：FR-01：[操作者+行为]。验收：[可观察示例]。依赖/未知：[...]；NFR-01：[约束+条件]。验证：[限定范围的检查]。结尾列出范围外、假设、开放问题与下一步。为重要行为包含失败或边界案例；对“可访问”“快”“安全”需给出限定条件的验证标准。分支顺序未定时用 $flow，可复用交互需要契约时用 $component。
适用场景：功能行为定义、验收标准编写、质量约束与权限规则梳理。
限制：想法仍模糊（面向谁、达成什么结果）时不宜使用，改用 $intent；开放问题是导航或页面结构时改用 $sitemap；要梳理任务分步路径时改用 $flow。仅隐藏按钮的权限检查会放过可直接调用 API 的构建，须包含直接请求案例；写入的第三种失败是超时后服务端已保存，重要写入需重试需求；需求中写端点名会被当作已存在契约，未文档化 API 应列为未知。