用途：在动手实现之前，把“要构建什么”结构化地记录下来，适用于需求文档、验收标准、用户故事、EARS 格式、规格说明、功能规格与产品需求等场景。核心原则是只规定 WHAT（结果与行为），不规定 HOW（实现细节）。
主要能力：提供 EARS（Easy Approach to Requirements Syntax）结构化验收标准模板，包括事件驱动 WHEN [event] THEN [system] SHALL [response]、条件 IF [condition] THEN [system] SHALL [response]、状态 WHILE [state] [system] SHALL [response]、普遍 WHERE [feature] [system] SHALL [response]、无条件 [system] SHALL [response]。提供用户故事格式：As a [role] I want [capability] So that [benefit]，其中 so that 子句用于揭示真实需求。提供需求文档结构：问题陈述、用户故事、验收标准、非功能需求、范围外内容、成功指标。对复杂项目可先建立“宪法”（治理原则），含核心价值观、技术原则、决策框架与质量标准，以防范围蔓延。还提供澄清技巧（问 what if、给出选项、挑战假设、界定边界）与非功能需求清单（性能、安全、可访问性、可扩展性、可靠性）。
使用方式：按上述模板与结构逐项填写需求，用可测试的标准替代模糊表述，例如把“响应快”写成“响应低于 200ms”，把“安全”写成“密码用 bcrypt 哈希”。
限制与注意：资料未提供具体安装命令、平台支持或收费信息。需避免的常见反模式包括规定实现、假设需求、跳过边界情况、混淆需求与设计、写模糊标准。若无法为其编写测试，则它不是需求而是愿望。