概述

EARS （简易需求语法）是英国罗尔斯・罗伊斯公司于 2009 年创造的简易需求语法： 英文全称为 Easy Approach to Requirements Syntax。其起源是该公司工程师在分析各种系统需求表述时，为了明确和简化需求，设定了一组初始的需求表述 “规则”。为了将我们的PRD更量化，逻辑性更强，从而达到可核验的目的。将需求分解为实体、动作、关系、范围四个要素，通过强制使用：“系统应...”“当... 时” 等结构化句式，把自然语言的 “表述行为” 转化为 “指令行为”，使需求从 “描述性” 转变为 “规范性”。这套表述方法非常适合原子化拆解。当符合条件A时，触发B动作，就满足C功能，产生D响应。

为什么要改写成符合EARS语法的PRD

如果一个PRD写的模棱两可，将极大影响AI生成的代码质量，而且生成的代码无法有效核验每个功能项，会让生成的AI代码遗留功能点，EARS减少或甚至消除了文本自然语言需求中的常见错误，让每个需求点更可量化和可检验，极大利于AI编写测试用例和mock数据，EARS语法描述简单，行为上一致，消除PRD中的功能分歧。使用EARS，你可以以更系统和一致的方式处理复杂需求，这让产品的需求更明确，更易于AI编写实现代码。简单来说，让AI生成代码时解决（前后矛盾，丢三落四；大量功能被悄悄遗留，似是而非；越改越乱；利于拆解需求，解决上下文丢失问题）。

五种句式

每条功能需求必须使用以下五种句式之一：

复杂需求可组合关键词，例如 While , when , the  shall .

举个示例

我们将以上封装为skill，可以将自己的PRD需求文档交给AI，让AI完成PRD的支持EARS框架的精准改写。AI会给出【待澄清项】，针对PRD文档里未明确或不清晰的点等待你的进一步确认。比如我提供了一个明显存在重大缺陷的需求描述如下（缺少提醒量化指标，提醒方式，缺少交互描述，检验标准等各种问题）：

实现todo待办任务的增删改查，需要有任务的计划完成时间，并在任务快到期的时候提醒我

给出的几条需求拆解如下：EARS 句式：Event-driven需求语句：When 用户提交一条标题非空的新任务创建请求，the 待办应用 shall 创建一条待办任务并展示在任务列表中。验收标准（Given/When/Then）：

• • Given: 用户处于待办任务页面，且任务标题输入框已填写有效内容
• • When: 用户点击「添加」或提交创建请求
• • Then: 列表中新增该任务，且任务默认处于「未完成」状态

EARS 句式：Unwanted behavior需求语句：If 用户提交的新任务标题为空或仅含空白字符，then the 待办应用 shall 拒绝创建并提示「标题不能为空」。验收标准（Given/When/Then）：

• • Given: 用户处于待办任务创建状态
• • When: 用户提交标题为空或纯空白的任务
• • Then: 任务未被创建，界面提示标题校验错误，焦点回到标题输入框

EARS 句式：State-driven需求语句：While 任务列表为空，the 待办应用 shall 展示「暂无待办任务」的空状态提示。验收标准（Given/When/Then）：

• • Given: 当前无任何待办任务
• • When: 用户打开待办任务页面
• • Then: 页面展示空状态提示，引导用户创建首个任务

EARS 句式：Ubiquitous需求语句：The 待办应用 shall 在任务创建、更新、删除后持久化任务数据，使用户重新打开时数据不丢失。验收标准（Given/When/Then）：

• • Given: 用户已完成若干增删改操作
• • When: 用户关闭并重新打开待办应用
• • Then: 任务数据与关闭前一致，未发生丢失

......

通过技能输出的待澄清项如下：

• •REQ-TODO-006「任务快到期」的提醒提前量（lead time）具体是多少？例如到期前 1 天 / 1 小时 / 可配置？ — 缺少：提醒触发阈值
• •提醒通过什么渠道送达？应用内通知 / 系统推送 / 邮件 / 短信？ — 缺少：通知渠道
• •如果用户创建任务时未填写计划完成时间，系统应如何处理？拒绝创建并提示必填，还是允许为空（则不进行到期提醒）？ — 缺少：REQ-TODO-005 的必填性约束
• •是否允许为单条任务设置多次/多级提醒（如提前 1 天与提前 1 小时各提醒一次）？ — 缺少：提醒策略
• •"查"是否包含筛选/搜索/按状态或到期排序等子能力？ — 缺少：查询的粒度与范围
• •待办任务包含哪些字段（是否含截止日期、优先级、备注、分类等）— 缺少：字段定义
• •数据持久化方式（本地存储 / 服务端数据库 / 多端同步）— 缺少：存储架构
• •是否需要批量删除、批量标记完成 — 缺少：批量操作需求
• •是否需要搜索 / 关键字查找功能 — 缺少：搜索需求
• •删除是否需要二次确认或软删除（回收站）— 缺少：删除策略

个人觉得，特别AI给出的【待澄清项】，可以很方便的检查的PRD文档缺陷，以便让你写出更完善，边界更清晰的PRD文档，要重点关注。我们会在下一篇中讲解在使用EARS需求拆解和原始PRD两种情况下，使用我们【全栈AI开发应用】技能生成和实现项目上的重大差异。

阅读原文，直达skill。