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 转化案例：
| 维度 | 传统 PRD 描述 (模糊) | EARS 规范描述 (清晰) |
|---|---|---|
| 场景 | 成功案例搜索 | 搜索过滤逻辑 |
| 描述 | 用户在搜索框输入关键词，如果没搜到就提示一下，搜到了就展示。 | WHEN用户提交搜索请求，IF结果集为空，THEN系统SHALL显示“未找到相关案例”；ELSE系统SHALL渲染结果列表。 |
| 开发感受 | 还需要去对 UI、对边界值 | 直接写if...else...，零沟通成本 |
05 结语：让 PRD 变成“伪代码”
EARS 的核心价值在于：它强制 PM 在动笔写需求之前，先进行逻辑建模。
对于我们程序员来说，看到符合 EARS 规范的文档，就像是在读一份高层的伪代码。我们不需要猜测 PM 的意图，只需要关注具体的函数实现和数据流转。
如果你也深受“垃圾需求”之苦，不妨把这篇文章转发给你的 PM，告诉他：“按这个格式写，我写代码的速度能快一倍！”
