EARS 需求句法是什么：六种验收标准写法

3.1 「要好用」为什么无法验收

自然语言的默认状态是模糊的，而模糊的需求有一个共同特征：你无法在实现完成后判断它是否被满足。

「导出要快」——多快？
「处理好异常情况」——哪些异常？处理成什么样？
「界面要友好」——什么算友好？
「兼容主流阅读器」——哪几个？

这类句子对 agent 是灾难，因为它必须替你定义标准，然后按自己定的标准交付。你事后说「这不叫好用」，它也没做错——你从没说过什么叫好用。

3.2 EARS 的六个模板

需求工程领域早就有现成解法。EARS（Easy Approach to Requirements Syntax，简明需求句法） 由 Alistair Mavin 等人在 Rolls-Royce 分析航空发动机控制系统适航条例时提出，2009 年发表于 IEEE 需求工程会议。它的思路不是发明一种形式化语言，而是用极少的关键词和固定的子句顺序，温和地约束自然语言，从而压制歧义、含糊和不完整。

正因为足够简单，它被 AI 编码工具直接搬了过来——AWS 的 Kiro 就用 EARS 句法来生成验收标准。

通用句式：

While <前置条件>, when <触发>, the <系统> shall <响应>

六个模板：

第3章：从模糊到可验证 — 图 3.1：右侧每一句都能直接变成一条测试用例；左侧每一句都不能。

模板	英文原型	中文写法	用在哪
普遍性 Ubiquitous	The system shall …	系统应……	任何时候都成立的性质
状态驱动 State-Driven	While …, the system shall …	当处于……状态时，系统应……	只在某种模式下成立
事件驱动 Event-Driven	When …, the system shall …	当……发生时，系统应……	由用户动作或外部事件触发
可选特性 Optional	Where …, the system shall …	若系统包含……特性，则应……	只在启用某能力时成立
非期望行为 Unwanted	If …, then the system shall …	若发生……，则系统应……	错误、失败、异常输入
复合 Complex	While …, when …, the system shall …	当处于……状态且……发生时，系统应……	前两者叠加

关键在于主语必须是系统，谓语必须是一个可观察的行为。「用户可以导出订阅」不合格（主语是用户，行为不可观察）；「当用户点击导出按钮时，系统应生成 OPML 文件并触发下载」合格。

3.3 一张改写对照表

把第2章那份规格里的验收标准，和它的模糊版本并排看：

模糊写法	EARS 改写	用了哪个模板
要能导出	当用户点击「导出订阅」按钮时，系统应生成 OPML 文件并触发浏览器下载	事件驱动
支持分组	当订阅列表包含分组时，系统应在 OPML 中生成对应的嵌套 outline 结构	事件驱动
处理好异常情况	若订阅列表为空，则系统应提示「暂无订阅可导出」并且不触发下载	非期望行为
处理好异常情况	若订阅标题包含 XML 特殊字符，则系统应对其转义，使导出文件可被 XML 解析器解析	非期望行为
导出要快	当订阅数量不超过 1000 条时，系统应在 1 秒内完成文件生成	事件驱动
兼容主流阅读器	系统导出的文件应符合 OPML 2.0 规范	普遍性

注意第三行和第四行：一句「处理好异常情况」展开成了两条。这正是 EARS 最大的价值——它逼你把「异常」这个抽象词拆成具体的触发条件。写不出触发条件，说明你还没想过这个异常到底长什么样；而没想过的异常，agent 也不会替你想。

3.4 裁剪：应用软件不需要全套

EARS 出身于安全关键系统，那种场景下每一条需求都要能追溯到适航条例。你写一个 RSS 阅读器不需要这种严格度。实用的裁剪：

只用三个模板就够：事件驱动（When）、非期望行为（If…then）、普遍性。状态驱动和复合留给确实有模式切换的场景。
不必强求「shall」的对应词。中文写「系统应」即可，重点是保持「触发—系统—行为」三段结构，不是关键词考试。
一条验收标准对应一条测试。如果一条标准需要三个测试才能覆盖，把它拆成三条。

3.5 回顾：一句话能不能变成一个会失败的测试

「导出的文件名要有日期」
「网络断了要有提示」
「深色模式下按钮也要能看清」