AI提示词+EARS语法：5步法高效拆解需求与验收标准-北京尧图网络

写需求文档最让人崩溃的是什么不是没想法而是想法太多写出来之后被研发追着问这个及时到底是几秒、正常用户怎么定义、如果手机号已经被注册了怎么办。一问一个不吱声回头还得自己补。我最近用AI辅助做了几轮需求拆解发现一个特别有效的组合打法AI提示词 EARS语法。EARS不是什么新东西在需求工程圈子里存在很多年了全称是Easy Approach to Requirements Syntax简单需求语法它本质上是一套把自然语言需求格式化的规范让每一条需求都长成一个固定的句式结构。而把EARS的语法规则写进AI提示词里等于给大语言模型装了一套需求约束框架让AI不再写散文而是直接产出结构严谨、可测试、可追踪的需求条目。这篇文章我就把这套方法完整拆开从一个真实案例入手手把手演示如何用5个步骤完成产品需求拆解同时把每一步用到的提示词模板直接给出来你可以直接复制拿去用。1. 为什么AI写的需求像散文先搞清楚需求拆解到底在拆什么很多同学用AI写需求文档写完后自己都觉得不对劲——通篇都通顺但好像哪条都没用。这不是AI的问题是需求拆解本身就做错了。1.1 需求文档最常见的三个病我在评审会上被问到最多的问题翻来覆去其实就这么三个第一模糊词扎堆。及时发送、友好提示、流畅体验、合理时间内。这些词单独看没错放在需求文档里就是灾难因为每个研发对及时的理解都不一样。有人觉得5分钟算及时有人觉得5秒才算一条需求两个理解做出来的东西就要返工。EARS语法对这类模糊词是零容忍的它要求每一处描述都能被验证、被测量。第二触发条件残缺。很多需求只写了系统应该做什么但没说清楚在什么情况下做。比如用户点击获取验证码后系统发送短信验证码那用户手机号格式不正确算不算这个场景60秒内重复点击又怎么处理触发条件不完整开发只能靠猜猜错就只能改。第三异常路径几乎空白。正常路径大家都会写但异常路径——第三方短信接口超时怎么办、用户输入验证码错误5次怎么办、服务端幂等等——经常是在联调阶段才被发现的。等到发现才补需求开发成本和沟通成本都是成倍增加。1.2 AI会放大这些问题而不是解决这里我要说句大实话如果你自己脑子里都没有一套需求拆解的逻辑那让AI帮你写它只会写得更流畅、更完整、更像一篇漂亮的散文然后在同样模糊的地方模糊得更优雅。大语言模型的强项是生成通顺的文本它并不知道你的业务边界在哪里不知道哪些条件是真实存在的哪些字段在系统里根本没有。所以问题不在AI在于你用什么框架去约束AI。把EARS语法塞进提示词里等于在大模型输出之前先给它戴上一副结构眼镜——别再自由发挥了给我按模板来。1.3 EARS语法解决的是一句话需求背后的问题EARS语法的核心价值是把一条需求拆成触发条件和系统响应两个边界清晰的部分。触发条件回答什么时候和在什么状态下系统响应回答系统要做什么和做到什么程度。当每一个条件都被精确描述需求的歧义空间就被压缩到接近零。再加上它天生支持条件组合——普通条件、状态条件、事件条件、非期望行为条件——需求文档就从一段描述性文字变成了一套可测试的行为规范。所以这篇文章要讲的5步法本质上是两件事第一步到第三步是把业务语言翻译成EARS格式第四步是用EARS条目反推验收标准第五步是把整个方法论沉淀成AI提示词资产。下面我会用一个用户登录验证码案例完整演示这条链路。2. EARS语法到底长什么样五种模式一次讲透在进入实操之前我先把EARS语法的五种基本模式用最直白的方式讲清楚。很多人一看到EARS就以为是某种高深方法论其实它的名字是五种模式首字母的合称理解起来并不难。2.1 从一条完整需求拆出五个基本句式EARS把需求分成了五种类型每种对应一个标准句式模板模式英文名句式模板一句话解释普遍型Ubiquitous系统应始终/总是/在一切情况下...无条件的、任何时候都成立的需求可选型Optional在...的情况下系统应...在某类特定条件下触发的需求状态驱动型State-driven当处于...状态时系统应...系统进入某个状态后才生效的需求事件驱动型Event-driven当...事件发生时系统应...用户或外部系统做出动作后触发的需求非期望行为型Unwanted behaviour如果...异常情况系统应...对错误、异常输入的防御性需求我用一个生活化的例子来说明。假设你在开发一个智能门锁系统需要写一条开门的需求普遍型系统应始终记录每一次开门事件的时间戳并与开门者身份ID关联存储。可选型在用户指纹信息已录入的前提下系统应允许通过指纹识别开门。状态驱动型当门锁处于反锁状态时系统应拒绝所有密码开锁请求并提示已反锁。事件驱动型当用户连续输入错误密码3次时系统应自动锁闭键盘30秒并发送告警短信。非期望行为型如果门锁电量低于5%系统应至少提前2天在手机App推送低电量提醒并拒绝远程开锁指令避免因中途断电导致锁体卡死。注意看同样是开门这条需求五种模式各管一块合在一起才构成完整的行为闭环。正常逻辑、条件逻辑、状态逻辑、事件逻辑、异常逻辑全部覆盖没有任何一条需要研发去脑补。2.2 为什么EARS对AI格外友好我用了很多种提示词框架最后发现EARS跟大模型的能力边界特别匹配原因有三个第一EARS句式是填空式结构。当____时系统应____这种模板信息位置高度固定。大模型天生擅长做完形填空把触发条件和系统响应填进去比让它自由发挥写一条需求要稳定得多。这有点像给AI出了填空题而不是作文题答案质量自然会高很多。第二EARS强调可测试性。因为每条需求都有明确的触发条件和响应行为AI在生成验收标准时就很容易对齐不需要再猜这个词到底是什么意思。需求可测试后续的测试用例生成、开发排期估算都会变得容易。第三EARS支持多轮追问。它的五种模式可以看作五个审查视角当你让AI逐条检查现有需求有没有五种模式之外的遗漏时AI很容易挑出来——这条需求缺少非期望行为分支如果手机号已被注册怎么办这种追问能力恰好补上了人类写需求时最薄弱的异常路径覆盖问题。2.3 用EARS写需求时容易踩的第一个坑有一点必须先提醒EARS不是让所有需求都写成同一句话而是让每一条需求的条件边界都清楚可辨。所以同一个业务行为可以出现在多个条目里比如禁止重复提交既可以用非期望行为表达如果用户60秒内重复点击...也可以用状态驱动表达当按钮处于倒计时状态时...。不要怕重复怕的是表述混乱、条件纠缠。3. 5步法完整实战从一句碎需求到38条可测试的EARS条目理论讲完直接上案例。我选了一个几乎所有产品都会遇到的功能——用户注册时的手机号验证码登录。整个过程完全按照5步法走每一步都给出初始输入、AI输出以及我在每一轮做的手工修正。3.1 Step 1场景穷举——把边界逼出来第一步的输入可能只有一句话用户输入手机号点击获取验证码输入验证码后登录成功。这是典型的碎片化需求什么细节都没有。但如果你直接让AI根据这句话生成EARS需求它可能只生成三四条正常情况的条目异常分支完全靠它脑补。这样不够EARS的价值恰恰在覆盖。所以第一步的正确做法不是让AI直接写需求而是让AI先做场景穷举我直接让它列场景不急着写需求。提示词大概是请针对手机号验证码登录功能穷举所有可能出现的业务场景包括正常流程、异常流程、极端边界条件每个场景用一句话描述。要求覆盖输入校验、接口异常、重复操作、状态变化、安全防护等方面。这轮AI输出了大概25个场景从手机号格式正确且点击获取验证码到短信通道超时无响应到手机号被列入黑名单全列出来了——AI在这一步的价值是提供穷举速度25个场景肉眼看不全。但AI也会漏比如它漏掉了服务端验证码校验接口校验次数超限后账号锁定这种偏安全类的场景是我手动补进去的。这一步结束后你会得到一份场景清单它们是后续EARS条目的原料。如果你自己的业务知识不够扎实这就是你的补课地图——AI列出来的场景可以帮你理清这个功能涉及的边界。3.2 Step 2EARS改写——把场景变成需求条约拿到场景清单后第二步是把每个场景改写成EARS句式。我会给AI设定好五种类别的输出框架要求它按类别分组输出场景示例1用户输入合法的手机号点击获取验证码按钮。EARS改写事件驱动型当用户输入格式合法的手机号并点击获取验证码按钮时系统应在3秒内向该手机号发送一条包含6位数字验证码的短信同时生成验证码记录并进入60秒倒计时发送间隔状态。场景示例2用户点击获取验证码后发现收不到短信。EARS改写非期望行为型如果验证码短信发送接口返回超时或失败系统应触发重试机制最多重试2次重试仍失败时系统应向用户显示发送失败请稍后重试的提示文案并允许用户等待60秒后再次点击获取验证码。注意到没有3秒内、6位数字、60秒这些数字是怎么来的不是EARS凭空生成的而是在改写之前就存在的业务规则或者是你在出需求时必须拍板的参数。AI能做的是把这些散落的参数放进正确的句式里并识别出缺失的参数然后向你提问这里的倒计时是几秒短信验证码有效期是几分钟——这是EARS提示词很有价值的附带产出规则缺口清单。3.3 Step 3异常分支补全——用如果...则...挖出隐藏雷区做完Step 2你已经有了覆盖正常流程的EARS条目。但EARS最狠的一招是非期望行为型条目的强制补全。我通常会让AI做一次漏洞自检提示词是请检查以上所有EARS需求条目针对每一个系统应...语句思考对应的如果...时会怎样的非期望行为条目并补充进去。重点检查输入非法、权限不足、外部接口故障、并发冲突、数据不存在、时间过期等异常情况。这一步AI会生成大量你平时写需求时根本想不到的条目比如如果用户输入的手机号已注册系统应在对应登录场景下直接进入输入密码流程而不是重新发送验证码。如果同一手机号在24小时内获取验证码次数超过5次系统应锁定该手机号的验证码发送功能至次日0点并提示用户联系客服。如果客户端时间与服务端时间偏差超过5分钟系统应在用户登录时提示请校准系统时间后重试避免因时间偏差导致验证码校验失败。这些条目加进去之后需求文档的覆盖率会有一个质的飞跃。你再看原来的那句用户输入手机号点击获取验证码输入验证码后登录成功已经从一个句子变成了一张密密麻麻的需求网。3.4 Step 4验收标准重构——让每一条EARS都能变成测试用例需求写完了还得能验收。第四步是把EARS条目转化为验收标准这一步同样可以交给AI但关键在于提示词要让AI对齐而不是自由发挥。我给AI的提示词是针对上述每一条EARS需求生成对应的验收标准每条标准必须包含具体输入、触发条件、预期结果三个要素。验收标准的表述必须可以直接转化为测试用例。AI输出的验收标准长这样条目当用户输入格式合法的手机号并点击获取验证码按钮时系统应在3秒内发送包含6位数字验证码的短信。验收标准1输入手机号13800138000点击获取验证码在3秒内查询短信发送记录确认该手机号收到一条短信短信正文含6位数字验证码。验收标准2输入手机号12345格式非法点击获取验证码界面应提示请输入正确的手机号不产生短信发送记录。用验收标准反向验证需求你会发现一个有意思的现象如果需求条目能产生清晰可执行的验收标准它一定是合格的需求如果生成验收标准时你觉得别扭、需要额外补充条件说明需求条目本身有歧义或条件缺失。所以第四步不仅是写验收也是对前三步的一次质检。3.5 Step 5提示词资产化——让方法论可复用前面四步跑的是单个需求但如果每次新功能都重新来一遍效率还是不够。第五步是把整套流程变成一份提示词模板资产存入你自己的提示词库里。下次拿到新需求只需要改业务描述其他全部复用。我沉淀下来的模板长这样下文第4节会给完整版先让AI做场景穷举再要求它按EARS五种类别分别输出然后做异常分支补全最后生成验收标准清单。四个环节、四段提示词一次会话完成。这一步等于给团队留下了方法资产。哪怕以后不用我新人拿到这套提示词模板也能按照同样的质量产出结构化的需求——这就是把个人经验转化为组织能力的过程我觉得这比需求文档本身更有价值。4. 三套可直接复制的AI提示词模板从入门到完整工作流下面给出我在实战中沉淀出的三段核心提示词。这三段基本覆盖了整个5步法的工作流。你可以直接复制到任何一个主流大模型里跑一遍。4.1 模板一场景穷举引擎对应Step 1你是一位资深产品需求分析师。现在需要为一个功能模块做全面的场景穷举。功能描述{在这里粘贴功能描述} 请你从以下维度穷举所有可能的业务场景每个场景用一句话描述不要遗漏 1. 正常流程用户按预期完成整个操作链路的场景 2. 输入异常用户输入内容格式错误、为空、超长、重复等 3. 接口异常依赖的外部系统或服务无响应、超时、返回错误 4. 状态冲突用户在某个状态下执行了不允许的操作 5. 时间条件数据过期、超时、未来时间、并发时序交错 6. 频率限制用户高频操作、重复提交、批量请求 7. 权限边界不同角色、不同用户身份的差异化行为输出要求 - 用无序列表输出场景清单 - 每个场景前标注编号 - 场景描述必须具体禁止使用某些情况等等这类模糊表述 - 如果某个维度存在信息缺口用[待确认]标注并说明需要确认什么信息4.2 模板二EARS合规改写器对应Step 2和Step 3你是一位需求工程专家擅长使用EARSEasy Approach to Requirements Syntax语法改写需求。背景下面是一个业务功能的场景清单和原始需求描述。请将每个场景改写成符合EARS语法的正式需求条目。 EARS语法的五种标准模式 1. Ubiquitous普遍型系统应始终/总是/在一切情况下... 2. Optional可选型在{条件}的情况下系统应... 3. State-driven状态驱动型当系统处于{状态}状态时系统应... 4. Event-driven事件驱动型当{事件}发生时系统应... 5. Unwanted behaviour非期望行为型如果{异常情况}系统应... 原始需求与场景清单 {在这里粘贴场景清单} 改写要求 1. 每条需求只能包含一个触发条件和一个系统响应禁止出现当A时系统应B并C这种多响应句式如果触发后有多个子动作请拆成多条独立需求 2. 系统应后面只能跟具体的、可观察的行为禁止使用友好及时合理等模糊形容词 3. 如果场景中的参数如时间、数量、次数不明确不要在AI这边擅自编造用[待确认]标注 4. 输出时按五种模式分类每类单独一个子标题 5. 每条需求条目编号格式为[U-01][O-01][S-01][E-01][Uw-01]4.3 模板三验收标准对齐器对应Step 4请针对以下EARS需求条目逐条生成对应的验收标准。 EARS需求条目 {在这里粘贴需求条目} 验收标准生成要求 1. 每条EARS需求至少生成2条验收标准覆盖正常路径和至少一条异常/边界路径 2. 每条验收标准必须包含三个部分前置条件、操作步骤、预期结果 3. 验收标准中出现的具体数据时间、次数、长度等必须与需求条目中的参数严格一致不得自己改数字 4. 如果某条EARS需求无法生成清晰的验收标准请指出需求本身存在的歧义并给出修改建议 5. 输出格式用表格输出列为需求编号 | 前置条件 | 操作步骤 | 预期结果额外要求请最后检查一遍哪些需求条目之间可能存在冲突或重复如有请列出并说明冲突原因。4.4 使用这三套模板的三个小建议第一上下文要喂够。大模型本身没有记忆你给的上文越完整输出越稳定。建议第一步、第二步、第三步在同一个对话会话里连续进行每轮都保留上一轮的完整输出。因为EARS改写和验收标准对齐都依赖前序信息如果你分成了三个独立的对话AI对需求上下文的理解会大打折扣输出质量也会明显下降。第二AI给的数字不要直接用。这句话我在第3节已经提过这里再强调一次EARS句式里的参数——3秒内、60秒倒计时、5次上限——这些数值必须来自真实的业务规则或产品决策而不是AI的合理猜测。AI最大的问题在于它会把一个它自己编的50次/小时说得跟真的一样。所以提示词里我已经加了[待确认]的标记要求但这只是防御手段关键还是你自己要对业务有判断。第三模板要持续迭代。我第一次跑的时候模板二经常把一条需求拆得太碎一条当用户注册时能拆出5条后面发现部分条目完全没必要拆分。后来我在模板里加了多响应句式拆分的要求又加了合并同类项的后处理提示输出质量才稳定下来。提示词模板是需要根据你的实际使用反馈反复迭代的不要指望一次成型。5. 落地EARS时会踩的坑以及我的应对方式模板给了案例也跑了最后说几个我在实际项目中落地这套方法时踩过的坑和应对方式。5.1 需求爆炸EARS条目太多怎么管理EARS会把一条简单需求拆成很多条这是它的优势也是它的副作用。我第一次用EARS跑一个中型的订单模块生成了200多条需求条目产品经理直接看傻了——每条都正确但每条都会增加评审、测试和排期成本。我的应对方式引入优先级标记。在Step 3结束后加一轮MoSCoW优先级标注——把每条需求标记为Must必须有、Should应该有、Could可以有、Wont这期不做。AI做不了这个判断但可以辅助分类最终由人来确认。有了优先级200条需求可以快速收敛到80条Must加40条Should其余进入Backlog。EARS解决的是完整性问题优先级解决的是交付边界问题两者搭配才完整。5.2 团队抗拒研发觉得文档味太冲有次我把EARS格式的需求文档发给研发对方的反馈是这写得太教条了累。这个反馈我很理解EARS的确不适合做日常沟通文档但非常适合做正式的需求规格说明和验收基准。我的应对方式不要把EARS文档当成唯一的沟通载体。日常讨论、方案评审时用白话文档或原型图来沟通正式进入排期前再用EARS文档作为最终事实来源。可以把它理解为一份合同的条款合同语言和日常聊天语言本来就不一样。只要提前跟研发说明这份文档的用途是验收不通过时扯皮用的大家反而会欢迎这种确定性。5.3 AI幻觉EARS也会编造需求前面说过EARS的五种模式对AI的引导性很强但这也带来一个新问题AI为了满足非期望行为型的输出要求可能凭空编造出一些你系统里根本不存在的异常场景。比如如果用户输入的手机号属于物联网卡号段你的系统压根没这个判断逻辑AI也会编一条出来。应对方式所有AI生成的需求条目在合入正式文档之前的最后审核里必须逐条确认需求来源。来源可以是原始需求描述、业务方确认的规则、或者你在提示词里明确输入的场景。凡是没有来源支撑的条目一律标记为AI建议项人工确认后再转正。这条铁律能挡住90%的AI幻觉问题。5.4 什么场景不适合用EARS最后说个反向经验不是所有项目都适合用EARS。如果你在做探索性的、创新型的、需求每天都在变的项目比如0到1的MVP验证EARS的高结构化反而会成为束缚。EARS更适合以下场景需求边界已经清晰的存量功能优化有一定规模和合规要求的正式项目多方协作、需要明确责任边界的系统与外部系统对接需求必须精确描述的接口规格场景我自己在跑新产品的验证阶段更愿意用轻量的用户故事加验收标准来推进等验证通过、进入正式排期之后再把这套EARS拆解流程跑一遍。什么时候用重武器什么时候用轻武器取决于项目处于什么阶段。有一点我是体会越来越深AI的能力再强也只是帮你把写好需求这件事从3天压缩到半天它不会替你长出业务判断力。EARS语法给AI划定了写需求的跑道但往哪个方向飞、飞多远方向盘始终得握在自己手里。如果你正准备推进一个新需求建议先用第4节的模板跑一遍哪怕只是试一个很小的模块跑完你就会发现原本模糊的需求边界已经在你脑子里变得清清楚楚了。

AI提示词+EARS语法：5步法高效拆解需求与验收标准

相关推荐

交通标志检测与分类实战：从数据清洗到YOLO模型训练全流程

零基础Python调用豆包大模型API实战教程

S7-200与组态王实现单容液位控制系统：从PLC程序到画面组态全解析

更多资讯

系统提示词泄露全解析：从原理到四层防护实战

MQ消息积压四层穿透式排查与消费速度优化实战

大模型直觉重建：从信号、流形到动力系统的深度学习认知升级

AutoDock Vina大批量对接实操：从脚本设计到并行调度全流程

具身智能人机交互数据采集平台选型与实操要点

Awesome-Dify-Workflow：40+ 个 Dify 工作流模板，分钟级跑通

今日更新

基于MATLAB的CRI显色指数计算：从SPD光谱到Ra的完整流程

JSP+Servlet+MySQL博客系统源码部署与优化全攻略

蜂窝调度算法 MATLAB 实现：比例公平、轮询与最大 C/I 对比

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？