★ FEATURED ARTICLE 我给自己定了个小规矩凡是要进开发排期的需求必须用“主谓宾加条件”的句式写清楚否则不签字。这个规矩来源于一次印象深刻的线上事故——需求文档里写着“用户打开页面后应看到内容”开发按用户未登录状态做测试按登录状态验产品觉得“内容”指推荐列表最后上线后一片混乱。后来我接触到EARS语法又赶上了AI提示词工程爆发把两样一结合需求拆解这件事的效率和严谨度直接翻了几倍。这篇文章分享的是一套我已经稳定跑了半年的5步拆解法附提示词模板和完整案例适合产品经理、需求分析师、技术负责人也适合想规范需求表达的朋友参考。1. 为什么需求拆解总翻车先搞清楚病根1.1 需求文档里最常见的三类坑先说说最常见的三种问题你要是都见过那下面的方法论对你一定有直接用处。第一类坑是描述模糊。需求文档里写“响应要快”“体验要好”“数据要准”这类话看着没毛病实际上没法落地。“响应要快”是100毫秒还是2秒“体验要好”是指页面不白屏还是按钮要大一点“数据要准”是强一致还是最终一致每一个模糊的词背后都是一次开发和产品之间的来回拉扯。第二类坑是逻辑跳跃。很多需求从“用户进入页面”直接跳到“展示数据列表”中间省掉了一整条链路。数据从哪来接口挂了怎么办用户没权限怎么办缓存数据要不要展示这些中间环节一旦没写清楚测试只能靠猜开发只能靠自由发挥。第三类坑是需求边界不清。文档里永远只写系统“要做什么”从不写“不做什么”“异常时做什么”。结果就是正常路径开发得漂漂亮亮出问题时没有任何兜底方案。1.2 EARS语法为什么能治这种病EARS全称是Easy Approach to Requirements Syntax最早是用在航空航天、汽车这类安全关键系统的需求工程里。它的核心套路特别简单给每个需求句子加上“触发条件”和“系统状态”把一句抽象的愿望变成“当……时系统应……”这种可以验证的句子。举个例子。传统写法是“系统应确保用户安全”。EARS会把它改成“当检测到用户连续输错密码5次时系统应锁定该账户并在30分钟内拒绝该账户的登录请求”。后一句话有触发条件、有执行动作、有验证指标测试人员拿到这种需求直接就能写用例。我自己的体会是EARS最大的价值不是词法好看而是强制你思考四个问题这件事什么时候发生发生后系统要做什么在什么状态下才生效如果出错了怎么办这四问几乎覆盖了需求分析中80%的常见漏洞。1.3 为什么这时候要拉上AI大模型最擅长的事就是从一段含糊描述里联想到完整的业务场景。你给一句话它能给你补全出用户、设备、异常、边界条件。但这里有个麻烦AI太能“脑补”了。你要是只丢一句话给它不给任何框架它能给你编出十几种风格迥异的需求描述听着都对但没法统一使用。所以我的打法一直是用EARS语法做骨架用AI提示词做生成器。AI负责批量扩展场景、补全异常分支我负责审核、纠偏、拍板。这样既发挥了大模型快速产出的优势又通过EARS的固定句式让输出保持在一个专业、可用的轨道里。试过几次以后你会发现AI写的需求条目比很多实习生写得还要规范。2. EARS语法五类句型一次搞懂2.1 通用型需求Ubiquitous通用型需求描述的是系统“始终如此”的行为不依赖任何触发事件格式是“系统应……”。这类句子总结全局约束比如“系统应记录所有用户操作日志”“系统应保证所有密码以加密形式存储”。它既是功能要求也往往是合规要求所以写的时候要用词精准不能出现“尽量”“尽可能”这类修饰词。通用型需求是五类句型里的“背景板”数量不会太多但每一条都是硬要求。我在实际项目中习惯把它放在需求集的最前面作为整个模块的全局约束提醒开发和测试这些都是默认要满足的。2.2 事件驱动型Event-driven事件驱动型是使用频率最高的一类格式是“当[触发事件]时系统应[响应动作]”。几乎所有交互功能用户点按钮、设备上报数据、接口返回结果都可以用这个句式。比如“当用户点击保存按钮时系统应将当前表单数据写入数据库”“当天猫精灵返回设备状态时App应刷新对应设备的控制面板”。写这类需求时事件必须具体到可观察的程度不能写“当条件满足时”要写清楚到底是什么条件、由谁发出、怎么被系统感知。事件驱动型的难点在于事件的完整度。一个用户操作往往包含多个串联事件漏掉任何一个流程就会断。这也是后面我要讲第二步提示词重点解决的环节。2.3 状态驱动型State-driven状态驱动型描述的是系统在某种持续状态下的行为格式是“当系统处于[某状态]时系统应[保持/切换/执行某动作]”。它和事件驱动的区别在于事件驱动强调“瞬间发生的动作”状态驱动强调“某个时间段内的持续表现”。比如“当系统处于离线模式时应缓存所有用户操作并在网络恢复后自动同步”“当设备处于休眠状态时系统应保持蓝牙连接但不主动唤醒设备”。写状态驱动需求时要把状态定义清楚。什么叫在线什么叫离线什么叫激活状态这些名词不一致后面所有涉及状态的句子都会产生歧义。2.4 非期望行为型Unwanted behavior这一类的格式是“如果[异常情况]系统应[采取保护措施]”。专门用来写异常处理、容错机制、安全防护。比如“如果支付接口响应超时系统应提示用户支付结果未知并在后台自动发起订单状态查询”“如果设备上报数据超过合理阈值系统应丢弃该数据并标记设备异常”。非期望行为型需求是区分新手和老手的地方。新手写需求正常路径写30条异常路径写2条老手至少会保证正常和异常的比例不低于2比1。2.5 可选功能型Optional feature可选功能型用于描述“有更好没有也能用”的扩展点格式是“在满足[前提条件]的基础上系统可[提供某功能]”。比如“在用户完成实名认证的基础上系统可提供人脸快捷登录能力”“在网络状态良好的情况下系统可自动下载离线地图包”。这类需求在排期里通常是P1之后的优先级用EARS的可选句型写出来既保留需求又给研发侧一个明确的优先级信号。为了直观对比我整理了一张表格方便你在写提示词时做设定句型类型固定格式关键字典型场景通用型系统应……始终/所有/任何全局规则、安全合规事件驱动型当[事件]时系统应[动作]当/在……时点击、回调、设备上报状态驱动型当处于[状态]时系统应[动作]当处于/期间在线、离线、休眠、开启非期望行为型如果[异常]系统应[保护]如果/当异常超时、失败、非法输入可选功能型在[前提]基础上系统可[提供]可/支持扩展点、灰度功能3. 5步实操流程从一句话需求到完整的EARS需求集3.1 第一步用提示词锁定系统边界和干系人很多人拿到一个需求就急着让AI写条目这样写出来的东西十有八九是空中楼阁。我建议先花两分钟做“系统边界分析”把这个需求对应的系统模块、用户角色、外部依赖理清楚。我用的提示词是这样的可以直接复制你是一名资深需求分析师。请帮我拆解以下产品需求 [把原始需求文字粘贴到这里] 先不要写任何需求条目。请先完成以下任务 1. 列出这个需求涉及的核心系统或模块 2. 列出主要用户角色以及外部依赖系统 3. 用一句话概括该需求的核心目标 4. 指出该需求中可能存在的边界模糊点。我给AI设定了一个“资深需求分析师”的角色并要求它先列系统边界再谈功能。为什么这么设计因为大模型是概率输出如果你不给它一个分析顺序它会跳过边界直接给出看似完整的答案。用提示词锁住“先分析后输出”AI的表现会稳定很多。这一步的输出大概长这样核心系统App客户端、云端服务、智能设备端 主要角色普通用户、家庭成员、设备管理员 外部依赖设备云、消息推送服务、设备固件 核心目标用户一键触发离家模式系统自动执行预设的设备关闭策略 边界模糊点“该关的设备”具体指哪些家庭成员权限是否与普通用户一致把这一屏东西发给AI相当于先画了一幅作战地图。后面生成的每一条需求都不会跑出地图范围。3.2 第二步让AI按事件流拆解触发条件边界定了之后把需求从一句话扩展成一条完整的时间线用户做了什么系统回应什么设备又返回什么每个节点都是一个潜在的需求点。提示词模板基于你刚才识别出的系统边界请以事件流的方式列出该需求从开始到结束的完整操作路径。路径上的每个节点用“谁执行了什么动作”来描述。事件要求具体、可观察比如“用户点击按钮”“云端收到请求”“设备返回结果”。这一步是5步法中最花时间的也是AI最能帮忙的。你只需要把正常路径上的五六个节点想清楚AI能帮你扩展出十几条分支事件比如“用户再次点击”“设备重复上报结果”“App进入后台再恢复”等。但AI不是万能的它会漏掉低频事件。我个人的经验是人工必须补三类事件冷启动事件App刚打开时、设备刚上电时、中断恢复事件网络从无到有、页面从后台切回前台、重复触发事件连点两次、重复提交。这三类漏网之鱼往往是线上问题的大头。3.3 第三步补全状态与前置条件防止逻辑漏洞事件流理完之后得给每个节点加上“生效范围”。如果不加就会出现“用户没有登录也可以点保存”“设备离线了还下发指令”这种逻辑漏洞。提示词模板请对上述事件流中的每个节点补充该需求生效的前置条件和系统状态。 要求 - 前置条件用“当[条件]时该需求才生效”描述 - 系统状态用“当系统处于[状态]时系统应……”描述 - 列出所有可能影响流程的状态变量如登录状态、网络状态、设备状态、权限状态。这一步本质上是把正常流程变成“有条件触发的流程”。我自己常用一个笨但有效的检查方法把事件流里的每个动词都列出来再看每个动词前面是不是都能找到对应的“当……时”。如果哪个动词没有条件那它大概率是个隐藏需求未来一定会有人问“这里要不要判断一下”。3.4 第四步主动构造异常路径和非期望行为AI默认生成的路径都是happy path你得逼它写“坏路径”。这个“逼”的动作我用了一个针对性很强的提示词请针对上面生成的每一条正常路径沿路径逐个节点列出可能发生的异常情况。 异常类型包括但不限于网络超时、接口返回错误、数据格式非法、设备离线、权限不足、第三方服务不可用。 对每个异常请用EARS非期望行为句型写出系统的降级或保护措施“如果[异常]系统应[动作]。”这一步最能体现需求分析师的功力。正常路径只要跟着业务走一遍就能写出来异常路径靠的是对技术架构、第三方接口、历史事故的积累。举一个案例。以前我最常写的需求是“用户点击支付按钮系统调起收银台”后来被线上事故教育过支付回调丢失、支付超时但用户已扣款、用户重复支付。现在写任何支付类需求我都会在需求集里加上至少三条非期望行为型需求“如果支付回调超过30秒未返回系统应主动查询订单状态”就是其中典型的一条。3.5 第五步用AI验收清单做覆盖率检查最后一步用提示词让AI生成验收清单把需求从“描述”变成“可测试的内容”。提示词模板请基于上面生成的全部需求生成一份需求验收清单。 对每一条需求请回答我可以用什么方法验证它已经被正确实现了 若该需求中含有“良好”“快速”“合理”等不可测量的词请用EARS语法改写为可验证的表述。 最终输出格式需求编号 | 需求原文 | 验收方法 | 是否可自动化测试 。这一步的隐藏价值是“二次纠错”。当AI试图写出验收方法时如果发现某条需求根本没法验证就说明这条需求描述得太虚。这个反馈是闭环的——这一轮发现的模糊需求回去修改EARS句子再重新生成验收清单。4. 完整案例智能家居“离家模式”需求拆解全过程4.1 原始需求与目标为了让你看得更明白我拿一个完整的例子从头到尾走一遍。假设你是某个智能家居App的产品经理老板丢给你一句话“App上要加一个离家模式用户一键就能把家里该关的都关了。”先走第一步。系统边界App客户端、云端服务、智能设备灯光、空调、智能门锁、摄像头。主要角色普通用户、家庭成员、设备管理员。外部依赖设备云、消息推送、设备固件。核心目标用户一键触发系统自动执行预设的设备关闭策略。边界模糊点哪些设备算“该关的”家人权限如何处理一键执行失败怎么处理4.2 逐步演示5步如何落地第二步事件流我直接在提示词里补充了“离家模式”的预设信息之后AI给出了这样一条主链路用户打开App点击“离家模式”按钮 → App发送开启请求到云端 → 云端解析用户预设的设备策略 → 云端向灯光、空调、门锁、摄像头下发关闭指令 → 各设备返回执行结果 → 云端汇总状态并通知App → App展示“已完成/部分失败”结果页这个链路准确因为AI基本不会跳过“云端下发指令”这个关键节点。但第二步结束时我会手动补一条“App在冷启动后首次进入智能场景页”的事件这是Hard Path测试里容易被漏掉的部分。第三步状态与前置条件提示词让AI补全后得到的关键内容有用户必须已经完成App登录且设备已绑定系统必须处于“离家布防生效中”的状态此时门锁应自动切至布防模式如果设备处于离线状态则应跳过该设备并上报异常。第四步异常路径AI给出的典型输出如果云端下发指令后30秒内未收到设备回执系统应将该设备标记为失败并允许用户点击“重试”。 如果网络中断导致App无法连接云端系统应在App本地暂存操作意图并在网络恢复后提示用户确认是否补发。 如果智能门锁返回“布防失败”系统应阻止离家模式被标记为完成并弹出安全提示。第三步和第四步之间是天然衔接的“前置条件”里写了设备离线第四步就自然要写离线后怎么办。这也是我为什么把这两步排在一起的原因它们互相对照逻辑才完整。第五步验收清单AI生成的节选需求编号需求原文验收方法是否可自动化测试REQ-05当用户点击“离家模式”按钮时系统应在2秒内返回操作结果模拟100次点击统计平均响应时间是REQ-12如果任一设备执行失败系统应标记该设备并在结果页展示构造设备离线场景检查结果页文案和状态是REQ-18当系统处于布防状态时摄像头应持续记录并保存7天录像连续运行7天检查录像存储记录否凡是“验收方法”写不出来的需求基本都有问题。比如那句“系统应保证用户体验良好”到了这一步就会被揪出来。4.3 最终需求集与验收标准走完5步之后我得到了大约24条需求远远不止老板那一句话。这里节选几条典型的EARS格式需求作为参考REQ-01 通用型系统应仅允许已登录且完成设备绑定的用户开启离家模式。REQ-05 事件驱动型当用户点击“离家模式”按钮时系统应在2秒内向云端发起开启请求。REQ-09 状态驱动型当系统处于离家布防状态时系统应关闭所有预设灯具并保持门锁布防。REQ-12 非期望行为型如果任一设备执行失败系统应将该设备状态标记为失败并在结果页显著提示。REQ-18 可选功能型在家庭成员的权限等级为“管理员”的基础上系统可允许其修改离家模式下各设备的执行策略。这套诉求集可以直接给开发做排期测试拿到手就可以写脚本。你可能会问AI一次性输出24条会不会跑偏会所以我的习惯是每条都人工过一眼把不符合EARS格式或当前版本原则的句子删掉或改写。这24条里最后实际保留下来的大约有18条其余6条有过度设计的嫌疑在当前迭代里不该做。5. 提示词设计核心原则与常见问题排查5.1 提示词设计时的4个关键原则第一给AI一个角色不要让它自由发挥。开头的“你是一名资深需求分析师”不是废话它能把整个输出的风格、术语、结构往专业方向拉。我试过不加角色直接问AI输出的东西内容可能差不多但表达方式偏口语没内味儿。第二一次只让AI干一件事。不要在一个提示词里同时要求“列出边界生成需求写验收清单”。拆成多个提示词逐步调用每一步的上下文都由上一步结果提供AI的表现稳定得多出错也容易定位。为了省事把任务堆在一起经常得到一个要啥啥不行的四不像。第三透明输出流程。在提示词里明确要求“先列步骤再输出内容”比如“先识别系统边界再写出事件流”。这能有效减少AI跳步和“先给结论再补理由”的情况。第四关键约束重复强调。EARS句式、禁止模糊词、必须可验证这三条我会在每一步的提示词里都带上一次。AI对长文本里的约束记忆有限放在不同步骤里强调等于加强约束信号。从结果看这种重复很值得。5.2 高频错误when、if、while混用EARS语法里三类条件句式是有严格区分的AI经常搞混。最常见的是AI把状态驱动型写成事件驱动型。比如它写“当用户登录时系统应展示首页”这其实是事件驱动型又写“当系统处于登录态时系统应展示用户头像”这是状态驱动型。AI不会自动区分这两者它会根据“像螺栓一样风格的句子”来拼装所以你需要人工分辨。我个人的标记方法是凡是条件里出现“处于”“在……期间”这种描述持续状态的词就归为状态驱动型凡是条件里出现“点击、收到、返回”这类瞬时动作词就归为事件驱动型。如果一句话里两者都有就拆成两句。5.3 高频错误AI输出“伪需求”EARS最核心的检验标准是可验证性。AI被喂了大量互联网文本时不时会输出一些像“系统应提供良好的用户体验”“系统应确保数据安全”这样的“伪需求”。怎么揪出来靠第五步验收清单。当AI自己都写不出验收方法时这条需求必然有问题。比如“系统应确保数据安全”验收方法是“找安全专家评估一下”吗显然不行。改写思路是把模糊的目标动词换成可检测的指标系统应对所有密码使用SHA-256加盐哈希存储系统应在未授权访问时返回403状态码。5.4 实操排查技巧覆盖率打分法最后分享一个我自创的小技巧用来检查需求集有没有把原始需求“拆全”。把原始需求里的每个动词都摘出来画一张表对照找需求集原始动词对应需求条目覆盖情况点击REQ-05、REQ-06已覆盖关闭REQ-09、REQ-10已覆盖通知REQ-19待补充恢复REQ-13已覆盖如果发现某个动词没有任何需求条目对应说明这一步逻辑漏了。比如原始需求里提到“通知家人”但需求集里没写“当离家模式执行完毕后系统应自动向已绑定的家庭成员发送通知”那就是漏了补上即可。这套覆盖率检查法很简单但每次都能抓到一两条漏网需求。我个人的实际体会是EARS加AI这套组合拳最大的价值不是让AI替你写需求而是逼你在写之前把逻辑漏洞暴露出来。过去我写需求靠经验和脑补现在靠流程和提示词产出质量稳定很多。如果你所在的团队还没有用过EARS建议不要一次性推翻原有模板先挑一个低频功能试点跑一遍把生成的EARS需求集给开发和测试看一眼用实际效果说服大家比直接做一场培训有效得多。最后分享一个可以立即试做的小练习随便找一条你手头正在写的需求用“当……时系统应……”改写成三条事件驱动型需求你就会理解这种格式给人带来的秩序感。
阅读完成 · 觉得有帮助？
