1. 从一条写崩的需求开始为什么我要把EARS搬进提示词里聊需求这件事实在太反人类了。你跟业务方聊的时候他脑子里有一幅完整的画面说出来的却是“系统要能自动处理异常情况”你点头记下了回去细想发现这句话怎么解读都有问题——“异常情况”是什么“自动处理”是提示、跳过、还是直接修复等你拿着这句话去问开发开发又问回来“异常情况的判定标准是什么”一个需求来回磨三四个会议最后拍板靠的还是默契。真正逼我去找方法论是有一次我负责给一个中台系统写需求池同时压着六个模块的需求每个需求的描述风格全凭当天状态状态好就写得细一点状态差就写“用户能正常完成操作”这种废话。评审会上产品、开发、测试各解各的读需求文档活生生变成了阅读理解题。那之后我开始大量试各种需求描述规范最后发现最适合跟AI提示词结合、也最能被大模型稳定执行的是EARS语法。EARS全称是Easy Approach to Requirements Syntax最早是航空领域搞出来的一套需求句式模板后来在系统工程和软件需求工程里被广泛使用。它的核心思想非常朴素把需求描述固定成几个结构化的句式模板每种模板对应一类场景写出来的需求自带主语、条件、触发机制和预期结果不会再有“系统要能”这种无主语的模糊表达。更关键的是EARS语法的结构化特性天然匹配大模型的提示词工程。大模型本质上是一个“联想机器”你给它一个清晰框架它输出就稳定你给它开放式提问它就给你开放式发挥。把EARS五个句式模板直接写进提示词等于给模型装了一套需求描述的标准坐标系——坐标一旦定死产出的需求条目就不会偏。这篇文章我要写的东西很明确一是把EARS的五类句式讲透二是把它翻译成一套可以直接复制粘贴的提示词模板三是用一个完整案例带你走完5步需求拆解流程。适合正在做产品需求文档、写技术方案、或者想用AI辅助提升需求管理效率的人参考。我踩过的坑、调过的参数、实测过没用的写法都会一并写出来。2. EARS语法到底在做什么五类句式一次讲清楚2.1 需求写不清楚的根源先做个实验。你现在写一条需求“系统要能支持多用户使用。” 这句话听起来没毛病但拆开看全是问题系统是什么系统用户有几类每类用户的权限差异是什么“支持”指的是并发、登录人数上限、还是数据隔离EARS的观点是需求描述最怕的两种病一是主语缺失二是约束缺失。主语缺失导致需求不知道发生在谁身上约束缺失导致需求不知道在什么条件下成立。这两种病一旦存在AI帮你写的代码、测试帮你写的用例、开发帮你做的设计都会建立在一个松动的地基上。EARS的解决思路是用固定句式把一句话的主语、触发条件、系统响应全部框死。比如上一条需求用EARS改写就变成了“当已注册用户尝试登录系统时系统应校验其账号和密码若校验通过则进入个人工作台若校验失败则显示错误提示并允许重新输入。”这一下子就把场景、条件和行为全部讲清楚了。2.2 EARS五类句式详解EARS把需求分成五大类每一类对应一个句式模板覆盖系统行为的绝大多数场景。第一类是普遍性需求句式是“系统应[做什么]”。这类需求没有任何前置条件系统任何时候都必须满足。举个例子“系统应记录所有用户的操作日志”这就是一条普遍性需求没有“如果”“当”这种条件词。第二类是状态驱动型需求句式是“当[系统处于某状态]时系统应[做什么]”。这类需求描述的是系统在某种持续状态下应该表现出来的行为。比如“当系统处于离线模式时系统应缓存用户提交的数据”这里的“离线模式”是一个持续存在的系统状态不是一次性事件。第三类是事件驱动型需求句式是“当[某个事件发生]时系统应[做什么]”。这个容易和状态驱动混淆我一开始也绕了很久后来总结了一个区分方法事件是一次性发生的瞬间动作状态是一段时间内持续的属性。还是拿离线来说“当用户点击离线下载按钮时系统应开始缓存该文件”是事件驱动点击按钮这件事就发生在那一瞬间“当系统处于离线状态时”就是状态驱动离线状态是持续的。第四类是非期望行为需求专门描述系统遇到异常、错误、非法输入时该怎么办。句式是“如果[某个非期望情况发生]系统应[做什么]”。比如“如果存储空间不足系统应停止写入并通知管理员”。这一类需求特别重要因为现实中很多系统的问题恰恰出在异常路径没有定义清楚。第五类是可选功能需求句式是“如果[特定条件被满足]系统应[提供某项能力]”。它表达的是一种条件性的能力开放跟事件驱动不同这类需求通常描述的是一个能力开关而不是一次响应动作。比如“如果用户是VIP会员系统应提供高清画质选项”这个能力在VIP条件满足时就可以一直使用。2.3 为什么这套句式对AI友好用EARS写提示词本质上是把“请帮我写需求”这种开放式指令变成“请用这五种固定句式生成需求条目”这种封闭式指令。大模型的输出空间被严格限制它不需要猜你想要什么风格也不需要发挥创造力去组织语言只需要把信息点填进模板里。我做过一个对照测试同一个产品需求题目用开放式提示词让AI生成需求列表得到的结果五花八门有的条目是用户故事格式有的是验收标准格式有的直接写成了功能描述混在一起根本没法直接用于研发排期。而用EARS句式模板约束之后AI输出的每条需求都是同一个骨架条件、触发、动作、响应结构整齐划一测试用例编写也好、开发任务拆分也好直接可以在条目级别对齐。这里有一个关键认知提示词工程的核心不是让AI变聪明而是让AI的输出方差变小。EARS语法正好提供了一套方差压缩机制。你与其每天研究那些玄学提示词技巧不如用一套结构性模板把AI的输出框起来。3. 提示词模板设计把EARS写进提示词的完整思路3.1 提示词的关键三要素我在设计这个提示词模板的时候反复调了好几版最终沉淀下来三个关键要素角色设定、任务路径、输出格式约束。角色设定决定AI站在什么角度思考。“你是一名资深产品经理”和“你是一名研发工程师”产出的需求风格肯定不一样。对于需求拆解这个场景最合适的角色是“兼具产品、研发、测试视角的需求分析师”既要懂业务逻辑又要能落到技术实现粒度。任务路径决定AI按照什么顺序思考。我设定的路径是先明确产品背景和目标再拆分核心用户与使用场景然后按EARS五类句式逐类生成需求最后检查需求是否有冲突、重叠和遗漏输出结构化需求清单。这个顺序不能乱因为它模仿的是人类需求分析师的正常思考流程先理解业务再梳理场景然后逐类枚举行为最后做质量检查。输出格式约束决定AI的输出长什么样。我要求AI严格按照一个表格或分组列表来输出每条需求带唯一的编号、对应的EARS句式类别、需求描述、优先级、验收要点。这样产出的结果是可管理的资产而不是一段好看的散文。3.2 可直接复制的提示词主模板下面这版提示词是我实测下来效果最稳定的你可以直接复制到一个新的对话窗口使用。你是一名资深产品需求分析师拥有10年以上中大型系统需求分析和需求管理经验擅长用结构化方法将模糊的业务想法转化为可落地的研发需求。 我接下来会给你一个产品需求描述请你帮我拆解成完整的需求清单。 【处理步骤】 第1步提炼产品的核心定义、目标用户和关键使用场景。 第2步识别并枚举该产品涉及的主要角色普通用户、管理员、系统后台等。 第3步针对每个角色按照EARS语法五大类句式生成需求 1. 普遍性需求Ubiquitous系统在任何情况下应满足的基本行为句式“系统应[行为]”。 2. 状态驱动型需求State-driven当系统处于某状态时句式“当[系统状态]时系统应[行为]”。 3. 事件驱动型需求Event-driven当某个事件发生时句式“当[事件]时系统应[行为]”。 4. 非期望行为需求Unwanted behavior遇到异常、错误、非法输入时句式“如果[异常情况]系统应[处理方式]”。 5. 可选功能需求Optional feature当特定条件满足时提供的能力句式“如果[条件成立]系统应[提供能力]”。 第4步检查生成的需求是否覆盖核心场景是否有冲突、重叠或遗漏。 第5步为每条需求标注优先级P0/P1/P2优先级标准P0为核心路径缺失将导致产品不可用P1为主要功能缺口但存在临时替代方案P2为增强体验或后续迭代项。 【输出格式】 按以下分组输出 一、需求概述包含产品定义、目标用户、核心场景 二、角色清单列出所有角色 三、需求清单 每条需求包含 需求编号REQ-xxx EARS类别属于五类中的哪一类 需求描述完整的EARS句式描述 优先级P0/P1/P2 验收要点简要描述怎么算完成 【需求描述】 在这里粘贴你的原始需求材料这版提示词有几个设计细节值得展开说。优先级标注这块我特意给了一个统一标准P0/P1/P2分别对应什么情况AI不会凭感觉乱打。很多模板直接让AI“标优先级”AI就真的随便标不同批次的输出标准还不一致。统一标准能大幅提高输出一致性。验收要点这个字段一开始我没有加后来发现需求条目描述再清晰验收的时候还是会有分歧。加上验收要点之后测试可以直接拿这个字段做测试点来源免去了需求到用例的翻译成本。处理步骤的顺序也是有讲究的。第1步先做背景提炼是为了建立上下文让AI后续生成的需求跟产品目标对齐第2步枚举角色是为了覆盖不同视角避免只围绕单一用户写需求第3步按五大类逐类生成确保需求不是只覆盖正常路径第4步做质量检查第5步定优先级。3.3 提示词的参数与边界设置为了让这版提示词的输出更稳定我还建议在正式提问之前做一些上下文隔离操作。比如新开一个对话、清空历史记录再粘贴模板避免之前聊过的内容干扰本次输出方向。如果原理解析足够复杂还可以先只让AI执行第1步和第2步你觉得读起来没问题再让它继续后面的步骤这样相当于对AI的产出做分阶段验收避免一步错步步错。另外一个我踩过坑的点AI对“应”这个字的敏感度很高。如果你写的句式是“系统可以……”它产出的需求就偏软像建议改成“系统应……”语气就变成了规范性要求输出的内容也更像正经需求条目。所以提示词里所有句式模板里的动作词我都坚持用“应”不用“可以”这个细微差别影响实际输出质量。4. 实操核心5步搞定产品需求拆解4.1 五步流程总览整个需求拆解流程我压缩成五步这五步对应上面提示词里AI的处理步骤也对应你人工操作的验收节点。Step 1定义上下文。把产品背景、目标、用户、使用场景用统一的结构提供给AI。Step 2枚举角色。先确认有哪些人/系统会跟当前产品产生交互。Step 3逐类生成需求。按EARS五类句式从普遍性需求到可选需求逐类写。Step 4冲突检查和优先级标注。检查需求之间是否有矛盾、重复、缺失给每条需求加上P0/P1/P2。Step 5输出并人工复核。把AI产出的内容当成初稿人工复审一遍再进入后续研发流程。很多人觉得让AI做需求拆解人就可以躺平了。我的经验恰恰相反AI负责的是把需求从零散想法扩展成结构化初稿而人的核心工作在后半段——审核、判断、取舍。这个协作关系一定要摆正。4.2 Step 3里最容易被低估的两个句式类别在实际跑生成的时候我发现AI对两个类别的产出质量直接影响最终需求清单的完整度一个是事件驱动型需求一个是非期望行为需求。事件驱动型需求描述的是“当用户做了某个动作系统会怎样响应”这是系统交互逻辑的核心体现。如果这类需求生成得不够细系统的主流程就跑不通。我常用的技巧是让AI专门针对每一个角色走一遍“用户旅程”把用户的核心操作路径一项一项列出来再为路径上每一步生成事件驱动需求。这样得到的需求不是孤立的功能点而是一条完整的旅程链。非期望行为需求则决定了系统在真实世界的生存能力。开发最喜欢的需求就是只写正常路径因为异常分支实现起来又费时又不好展示。但真实用户的操作千奇百怪传了超大文件、点了十次提交按钮、网络突然中断、输入了非法字符。如果这些异常路径在需求阶段没有被枚举出来开发就默认不处理测试也不会测用户就是那个买单的人。我要求AI在生成非期望行为需求的时候专门站在用户的“破坏性操作”视角来想用户会做哪些操作来试图搞坏这个系统4.3 AI生成结果的人工复核清单无论AI的输出看起来多漂亮我在正式采用之前一定会过一遍复核清单每一条都检查过才进入下一步。覆盖性检查五类需求是否都存在如果某类一个需求都没有是业务真的不需要还是AI漏了冲突性检查有没有两条需求互相矛盾比如一条说“系统应自动保存所有草稿”另一条说“如果用户未点击保存按钮系统应丢弃所有未保存数据”这就是冲突。可测试性检查每条需求是否能推导出至少一个明确的测试场景“系统应提供良好的用户体验”这种模糊表述不能出现在最终清单里。技术可行性扫描把工作量和复杂度最高的P0需求列出来让研发提前给一个初步评估避免规划了一个研发周期内根本做不完的方案。5. 完整案例团队周报汇总助手的需求拆解实战5.1 案例背景与目标为了把上面的方法完整走一遍我准备了一个虚拟但非常贴近实际工作场景的产品团队周报汇总助手。背景是某个20多人的技术团队每周五大家都要发周报目前大家用各种格式发在群里负责人需要手动收集、整理、统计费时费力且经常漏人。目标是做一个小工具或者内部系统让周报提交、汇总、统计自动化。我把这段描述作为原始输入直接粘贴到上面设计的提示词模板中让AI跑一遍完整流程。下面就是我实测得到的产出过程。5.2 实际生成过程还原AI先执行了第1步产出了需求概述产品定义为一个面向团队的周报收集与汇总工具目标用户包括普通员工、团队负责人和系统管理员。核心使用场景有三个员工填写并提交周报、负责人查看汇总和统计、管理员维护系统配置。第2步识别出三个核心角色团队成员周报提交者、团队负责人周报查看与统计者、系统管理员系统配置与权限维护者。第3步开始按EARS五类句式逐类生成。这里我截取几个非常有代表性的输出。普遍性需求REQ-001系统应支持团队成员在线填写并提交周报。REQ-002系统应保存所有已提交周报的历史记录供后续查询和追溯。事件驱动型需求REQ-010当团队成员点击“提交周报”按钮时系统应校验必填字段是否完整若完整则将周报保存为“已提交”状态。REQ-012当团队成员在截止时间后尝试提交周报时系统应允许提交但标记为“逾期提交”。状态驱动型需求REQ-020当系统处于“周报统计周期结束”状态时系统应自动生成团队成员的提交率统计报表。REQ-022当系统处于“成员未提交周五周报”的状态时系统应在周五18点向该成员发送提醒通知。非期望行为需求REQ-031如果团队成员提交周报时网络连接中断系统应保留本地输入内容并在网络恢复后自动重试提交。REQ-032如果团队负责人在统计页面选择的时间范围内没有周报数据系统应显示空状态提示而不是报错。可选功能需求REQ-040如果团队负责人开通了自动汇总功能系统应每周一自动向负责人发送上周周报汇总邮件。REQ-042如果系统管理员开启了外部同步模式系统应将周报数据同步到指定的项目管理工具。第4步检查之后AI标出两个潜在冲突并给出建议REQ-010要求必填字段完整才能提交但REQ-012允许逾期提交两者本身不冲突但需要补充逾期提交时的必填校验是否放宽另外REQ-022的提醒时间和REQ-020的报告生成时间可能重叠建议在系统日历配置中做时间优先级设定。第5步按统一标准给全部需求标了优先级。我把其中几条摘出来看标的是合理且克制的P0集中在“提交周报”“查看汇总”“保存记录”这类主链路P1集中在“逾期提醒”“统计报表”P2集中在“外部同步”“自动邮件”这类增强能力。5.3 我对这个案例输出的判断我观察了一下AI产出中最有价值的部分非期望行为需求里“本地保留输入内容并在网络恢复后自动重试”这件事说明AI在五类句式的约束下确实会站在用户体验的异常分支上思考。这种覆盖度是靠人临时头脑风暴很难做到的因为人在写需求的时候天然偏向正常流程。同时我要提醒一点AI产出的优先级只是参考。比如REQ-042外部同步AI标了P2但如果你们的团队正好在用某个项目管理工具同步就是刚需那这个优先级就应该人工调高。AI给的是基于通用业务逻辑的判断不是基于你们团队的实际资源状况。6. 常见问题与排查技巧实录6.1 高频问题速查表我整理了这段时间使用这个提示词模板频繁遇到的几个问题做成一个速查表。问题现象可能原因处理方式需求描述太笼统出现“系统应提供良好体验”“系统应支持高效操作”这类描述没有严格要求句式AI把非EARS内容混入给AI强调“所有需求必须严格使用EARS句式模板”并给一个反例和正例做对照五类需求分布严重失衡普遍性需求一屏都放不完非期望行为需求只有两三条AI在偷懒优先走正常路径单独发起一轮对话仅让AI枚举异常场景问题描述换成“只从用户破坏性操作视角输出非期望行为需求”部分需求之间存在明显互相矛盾输入信息本身存在冲突AI选择全部保留让AI执行“冲突检测”专项步骤列出所有冲突对并给出你可能需要拍板的取舍建议输出格式乱掉不加编号不分组别输出格式约束不够强硬在提示词里加一句“严格按给定格式输出不要添加任何解释性文字”不按格式就连续追问让它重出最有效的兜底方案是分步骤执行不要一次把五步全压给AI。把提示词拆开每跑完一步你和AI确认一次确认对了再继续。输出质量差的时候优先检查是不是这一阶段的问题而不是反复让AI重新生成全部内容。6.2 三个我觉得值得分享的实操技巧第一个技巧在标题和场景不明确时先让AI补充业务背景。很多需求描述是一句话需求比如“做一个二手书交易平台”。这种情况下直接拆需求AI产出的东西会非常飘逸因为它脑子里没有行业上下文。先让它扩充“产品愿景、市场规模、核心用户画像、竞品分析摘要”把上下文养厚了再去走EARS流程需求质量会提升一个维度。第二个技巧善用“反问模式”。我发现AI在生成需求时如果碰到一个它理解不清的词它往往会猜一个合理的意思然后继续。比如“系统应支持合理的权限管理”它就直接写“系统应支持基于角色的访问控制”。但你想要的可能是“按部门多层审批”的权限结构。所以我现在都会在提示词尾部加一句“如果在描述中存在语义不清的内容先向我提问不要自行假设。”这一句能显著降低需求理解偏差。第三个技巧AI产出的需求清单一定要导入需求管理工具做版本管理。很多人把对话记录当成需求文档的终点过两周改了两版需求之后就再也追溯不回来了。我的习惯是把AI产出整理成Markdown或CSV文件导入到polarion、jama或简单的表格工具里每条需求带编号后续变更直接在工具里追踪。这是把AI辅助需求拆解真正工程化的关键一步不做这一步AI产出得再好也是孤岛数据。最后再分享一个我个人的使用体会EARS语法和提示词的组合真正帮到我的不是让AI替代我做需求分析而是让我从“一张白纸写需求”变成了“带着结构化提纲去做需求验证”。一开始用这套方法AI生成的需求清单可能只有六成能直接用剩余四成要靠你修正和补充。但哪怕只有六成你也省掉了大量从零到一的起草成本而且那些被AI覆盖到的异常分支和边界情况往往是人工写作时最容易遗漏的。用顺手之后再跑一个中大型系统的需求拆解我通常会先让AI走一遍完整流程我把精力集中在冲突仲裁、优先级调整和可行性判断这些真正需要人来决策的事情上。这就是我觉得这套提示词方案目前最值得投入时间的理由。