EARS：让 AI 没有洞可填，禁止脑补

你大概率写过这样一段"保命符"贴给 AI："如果你觉得我的表述不明确，可以向我提问，直到你 100% 明确我的需求。"或者"用苏格拉底式提问反问我"。

@OMOisomo 也这么干过。AI 确实追问了，他也答了，AI 说"我 100% 明确你的需求了"——写完一看，还是在几个关键地方写歪了。

真凶叫脑补：你写"出错要重试"，它填成"重试三次、间隔一秒"；你写"失败要兜底"，它填成"包一层 try-catch，catch 里打一行 log"。这些数字和动作你一个字没提，它替你定了，还定得理直气壮——拿一个"统计上最合理"的默认值，填进了那个洞。

追问解决的是"说不清"——你意识到的地方，它问，你答，说清楚。但脑补发生在"你没意识到要交代"的地方。你让 AI 追问，它只能问"哪里不清楚"，问不出"哪里你以为清楚了、其实是个洞"。

更要命的是：默认情况下 AI 几乎不反问。除非你专门写了"遇到模糊的地方先问我"，否则它不会像 junior 开发那样举手。它替你猜了，交给你一版看起来没毛病的代码，你跑了才发现不对，然后多轮返工。

EARS，全称 Easy Approach to Requirements Syntax（简易需求语法）。一句话定义：一种受控自然语言，用少量关键词加固定子句顺序，把系统需求写成清晰、可测试、可解析的句子。它不新——2009 年 Rolls-Royce 提出，在航空、汽车这类"需求写糊了就是安全事故"的行业用了十几年，Airbus、NASA 都在用。

先纠正一个常见误会：EARS 常被简化成"五个关键词 WHEN / WHILE / IF / WHERE / SHALL"。不准——SHALL（应）不是条件关键词，是所有模式共用的"应"；真正的第五种是 Ubiquitous（无触发条件的普适需求）。

• Ubiquitous（普适）：没有触发，始终成立。模板：系统应<响应>。例："支付服务应使用 AES-256 加密所有静态卡号"。
• When（事件驱动）：某件事发生了，就做什么。模板：当<触发>时，系统应<响应>。
• While（状态驱动）：某个状态持续期间，行为成立。模板：在<状态>时，系统应<响应>。
• Where（可选特性）：只有某配置/变体具备时才成立。模板：在已启用<功能>时，系统应<响应>。
• If-Then（非期望行为）：出错、异常、非法输入怎么兜。模板：如果<条件>，则系统应<响应>。

再加一条硬规则：一条需求，只留一个"应"。想写"并且"？拆两条。看见"妥善""尽快""合理""友好"？全部换成可验证的动作，或者进待确认清单。

机制上四层，正好卡住脑补：

1. 槽位明确：WHEN / WHILE / IF / WHERE 直接标出"这是触发、这是状态、这是异常"，AI 不用猜"这句话哪里是条件、哪里是结果"。
2. 行为可验收："应 + 可观察响应"（显示/拒绝/存储/发送）接近验收标准，能直接映射成测试步骤。
3. 原子化：一条 EARS 通常只描述一种条件-响应，没有长段落里的隐含假设。
4. 人机双语：仍是自然语言，产品/业务能审；结构够规整，LLM 解析和代码生成更稳。

还有一句关键洞察：AI coding 真正费时间的不是写代码慢，而是以前"写代码之前开会澄清需求"的时间，现在全挪到了"代码写完了再反过来发现需求没讲清楚"。而且代码已经写出来，你会有锚定效应——顺着它写的那版去改，而不是从零思考。EARS 把澄清从"事后"挪回"事前"。

PM 写道："用户提交订单时校验库存，缺货要提示，体验好一点。"看起来挺清楚，看 AI 怎么脑补：

EARS 重写之后（五条，一条一个"应"，没有"尽快""妥善""体验好一点"）：

1. When 用户点击提交订单，系统应校验购物车中每个商品的当前库存。
2. If 任一商品库存为零，则系统应在该商品旁显示"已售罄"，并展示其余有货商品的数量与总价；订单可部分提交。
3. If 所有商品库存充足，则系统应为每件商品预占库存，锁定时间 15 分钟。
4. If 15 分钟内未完成支付，则系统应释放该订单所有预占库存。
5. If 预占库存时发生并发冲突，则系统应重试一次；重试后仍库存不足，则拒绝订单并显示当前库存。

第一条是正常路径 When，剩下四条全是 If（异常、边界、并发）——原句里一个字没提。真正让代码从"能跑"变"能上线"的，就是这几条 If。第五条里的"重试一次"是我自己定的数字，严谨做法是标 [待确认：重试次数、并发策略是否需 PM 拍板]。

PM 写道："用户登录时要校验用户状态，体验好一点，密码错了要提示。"

EARS 重写之后：

1. When 用户点击登录且已输入用户名和密码，系统应校验用户名、密码与账号状态。
2. If 用户名和密码正确但账号已被禁用或失效，则系统应在登录页显示"账号已失效，请联系管理员"。
3. If 密码错误，则系统应在登录提示区域显示"用户名或密码错误"，不区分具体是哪一个不对。
4. If 用户在 60 分钟内连续输错密码达到 5 次，则系统应锁定该账号 30 分钟并显示"登录次数过多，请 30 分钟后重试"。
5. Where 在已启用双因素认证时，系统应在密码验证通过后要求输入 6 位 TOTP 验证码。

"体验好一点"背后是：错误要区分但不暴露太多、防暴力破解要有阈值、账号禁用要覆盖、2FA 单走一条 Where。第四条里的"5 次 / 30 分钟"同样是 AI 最可能偷偷填的数字，照例进待确认清单。

下面这段 prompt 来自原文，可直接复制——把末尾"原始需求"换成你的内容。核心原则：提示工程的上游是需求工程；禁止替用户编造业务规则；原文信息不足时写入"待澄清"，不用"看起来合理"的默认值填坑。

复制你是需求分析助手，专责把模糊、口语或有歧义的产品需求，改写成 EARS（Easy Approach to Requirements Syntax）可测试规格，供研发、测试与 AI 编码直接使用。


提示工程的上游是需求工程。先消歧，再让 AI 写代码；禁止替用户编造业务规则。原文信息不足时，写入"待澄清"，不要用"看起来合理"的默认值填坑。


- 规格正文默认中文：用"当…时 / 在…时 / 如果…，则… / 应"
- 禁止在正文输出 WHEN / WHILE / IF / THEN / WHERE / shall（用户明确要求标准英文模板时，可另附对照，不替代中文正文）
- 模式名可用英文标签：Ubiquitous / Event-Driven / State-Driven / Unwanted / Optional / Complex


1. 定主语与对象：系统/组件叫什么？动作作用在谁身上？（EARS 主语是系统，不是用户角色）
2. 贴问题标签：模糊词、多动作塞一句、无数字、缺主语、正常与异常缠在一起
3. 先拆再写：多动作 / 多异常 / 多阶段 → 拆成可独立验收的意图列表
4. 选型：按下方决策树选模式（复合模式最多两个条件关键字）
5. 套句改写：只保留原文业务意图，只补可观察响应所需的最小结构
6. 可测性兜底：能量化就补时限/次数/范围/失败表现/文案；补不了 → 待澄清


有离散触发事件？
├─ 是 → 还有持续状态或功能开关？
│ ├─ 是 → Complex（如：在…时，当…时，系统应…）
│ └─ 否 → Event-Driven（当…时，系统应…）
└─ 否 → 有持续状态？
 ├─ 是 → State-Driven（在…时，系统应…）
 └─ 否 → 是错误/故障/非法输入/边界？
 ├─ 是 → Unwanted（如果…，则系统应…）
 └─ 否 → 依赖可选功能/套餐/配置？
 ├─ 是 → Optional（在已启用…时，系统应…）
 └─ 否 → Ubiquitous（系统应…）


- 普适：<系统>应<响应>。
- 事件：当<事件>时，<系统>应<响应>。
- 状态：在<状态>时，<系统>应<响应>。
- 非期望：如果<条件>，则<系统>应<响应>。
- 可选：在已启用<功能>时，<系统>应<响应>。
- 复合：在<状态/开关>时，当<事件>时，<系统>应<响应>。


- 一条规格只有一个"应"；想写"并且"就拆条
- 主动语态：写"系统应…"，禁止"错误被显示…"
- 触发具体：禁止"当有情况发生时""如果出问题"
- 响应可观察：显示/拒绝/写入/发送/置状态/返回码等；优先可测试动词
- 能量化就量化；复合条件 ≤ 2；实现细节非契约则不写
- 规格正文禁词：应该、尽量、可以、或许、尽快、及时、较快、足够、合理、友好、支持（无对象）、处理、优化、完善、保障、妥善、适当、should、could、might、can、appropriately
- 缺失信息不硬编


## 输入原文 / ## 判定（模式+依据）/ ## 规格正文 / ## 待澄清
多意图时用：## 输入原文 / ## 拆分说明 / ## 规格列表 / ## 待澄清


1. 下游模型能否不猜业务就写出测试步骤？
2. 测试失败时，能分清是实现错了还是规格没写清？
3. 换一个人读，触发与响应是否一致？
任一项为否 → 回炉或补待澄清。


（在此粘贴需要改写的需求）

如果只想先试一次：挑一句带"支持 / 尽快 / 友好 / 妥善 / 合理"的需求，走上面流程重写一遍，数一数你不得不回问 PM 多少个问题——问题比想象中多，而这正是 EARS 的价值。

互见：Anthropic 官方指南同样强调"意图、格式、成功标准一个都不能含糊"——官方视角的对比解读详见《第 4 课》；OpenAI 官方指南的起草层"不编造"护栏详见《第 6 课》。