用途：将需求草稿转换为简洁、符合 EARS（Easy Approach to Requirements Syntax）的语句，在保留原意的前提下降低歧义。
主要能力：从用户输入中提取需求意图；识别对应的 EARS 模式（普遍型、状态驱动、事件驱动、可选功能、不期望行为、复杂组合）；按严格子句顺序改写，每条需求只保留一个明确的系统响应；随后做质量检查，关注可度量性、可测试性和缺失条件。
返回内容：改写后的需求、每条的需求模式标签，以及当模式选择可能有争议时的简要理由。
编写规则：一条语句只写一个需求；只使用一个明确的系统主语（如“the ATM”）；强制行为使用 shall；优先描述可观察结果而非实现细节；条件必须显式，避免隐含触发或隐藏状态；避免“as appropriate”“if possible”“etc.”等模糊表述；若数值上限或时间未知，加入明确占位符（如 <MAX_LATENCY_MS>）。
EARS 子句顺序：仅使用所选模式需要的子句，且顺序固定为 While <state/precondition>, when <trigger>, the <system> shall <response>；不期望行为模式写作 If <undesired trigger>, then the <system> shall <response>。模式定义与示例见 references/ears-patterns.md。
脚本用法：用 scripts/validate_ears.py 快速分类模式并检查语法与质量问题。单条需求：python3 scripts/validate_ears.py --requirement "When mute is selected, the laptop shall suppress all audio output."；批量文件（每行一条需求）：python3 scripts/validate_ears.py --file requirements.txt；机器可读输出：python3 scripts/validate_ears.py --file requirements.txt --json。
质量门：定稿前逐条核对——是否有通过/失败的判定标准；角色、条件与响应是否无歧义；术语是否一致、无同义词漂移；是否避免把多个独立行为合并（除非明确属于复杂模式）；是否符合所选 EARS 模式。任一检查不通过时，给出修正版并说明最小改动。
适用场景与限制：适合系统与软件需求的起草、改写与评审，尤其需要可测试性时。技能本身仅处理文本层面对齐与质量问题，不验证需求是否真实可满足，也未提供具体收费、平台或效果信息（资料未提供）。