别再为模糊需求扯皮了！引入 EARS：像写代码一样写 PRD

01 程序员的噩梦：PRD 里的“文学创作”

作为一名写了十多年代码的老兵，我最怕的不是复杂的算法，而是产品经理（PM）发来的“散文式”需求：

• “当用户操作不当时，系统要给出友好的提示。”
• “如果可能的话，尽量在页面加载时多展示一些数据。”

看到这种话，我脑子里只有一连串的问号：

• “操作不当”的判定条件是什么？（if里面写啥？）
• “友好提示”是弹窗、吐司（Toast）还是红字？
• “页面加载时”是在OnMount还是SSR阶段？

这就是典型的沟通熵增。为了解决这个问题，我最近研究了一套需求句法规范——EARS。

02 什么是 EARS？

EARS全称是Easy Approach to Requirements Syntax（需求句式简易法）。

简单来说，它不是一个软件，而是一套写作模板。它要求 PM 在写需求时，必须像我们写逻辑代码一样，遵循固定的触发条件和响应结果。

EARS 的核心公式：

触发场景/前提条件 + 系统名称 + 应当（SHALL） + 反应动作

03 EARS 的五种“逻辑模式”

EARS 把复杂的人类语言拆解为 5 种逻辑模式，这简直就是为程序员量身定制的：

1. 事件型 (Event-driven) —— “当…时候”

• 适用：用户点击、消息到达等瞬间触发。
• 语法：WHEN<触发事件>, <系统名称>SHALL<动作>。
• 例子：WHEN用户点击“导出”按钮，系统SHALL生成并下载 CSV 报表。

2. 状态型 (State-driven) —— “在…期间”

• 适用：系统处于某种持续状态（如：登录状态、欠费状态）。
• 语法：WHILE<系统处于某种状态>, <系统名称>SHALL<动作>。
• 例子：WHILE用户处于“未实名”状态，系统SHALL隐藏提现按钮。

3. 环境型 (Unwanted Behavior) —— “异常处理”

• 适用：网络断开、内存溢出等非预期情况。
• 语法：IF<异常/非法触发>,THEN<系统名称>SHALL<动作>。
• 例子：IF数据库连接超时，THEN系统SHALL返回 504 错误码并记录日志。

4. 可选型 (Optional) —— “如果具备某种能力”

• 适用：针对特定硬件或版本。
• 语法：WHERE<具备某功能/硬件>, <系统名称>SHALL<动作>。
• 例子：WHERE手机支持指纹识别，系统SHALL显示指纹支付选项。

5. 普适型 (Ubiquitous) —— “始终如此”

• 适用：基础全局功能。
• 语法：<系统名称>SHALL<动作>。
• 例子：后台系统SHALL在所有列表页展示“创建时间”字段。

04 为什么要推广 EARS？（对比实验）

看一个真实的 PRD 转化案例：

05 结语：让 PRD 变成“伪代码”

EARS 的核心价值在于：它强制 PM 在动笔写需求之前，先进行逻辑建模。

对于我们程序员来说，看到符合 EARS 规范的文档，就像是在读一份高层的伪代码。我们不需要猜测 PM 的意图，只需要关注具体的函数实现和数据流转。

如果你也深受“垃圾需求”之苦，不妨把这篇文章转发给你的 PM，告诉他：“按这个格式写，我写代码的速度能快一倍！”