AI编程第17讲:用EARS改写需求,让AI真正读懂你

AI Coding时代大家逐渐形成了一个共识：AI 编程，多数情况下就是在通过写提示词来完成需求开发。

这种说法只说对了一半。当你真正高频使用 Claude Code、Cursor、Copilot 之后，会发现瓶颈通常不在提示词写得精不精彩，而在于你输入的那份需求本身——它是一段模糊的描述，还是一条可验证的规格。

不少开发者过去一年反复踩进同一个坑：拿到一条 PM 需求，直接丢给 AI 编码，AI 看起来理解得很顺畅，写出来的代码也能运行。但一进入联调（多个模块拼合后协同测试的环节），就全面崩塌。不是 AI 不够聪明，而是你拿"模糊的意思"问它，它自然给你一个"大致能跑"的结果。

最近几个月，我们团队在开发实践中，把需求设计的环节向前推进了一步：在动手编码之前，先采用一种名为 EARS 的方法把原始 PM 需求整体重写一次，重写后再交给 AI。前后效果差异非常显著。

这篇文章面向两类读者：

一是刚开始认真使用 AI 编程几个月、被模糊需求困扰过多次的开发者；

二是日常输出需求、又时常被"这段究竟想表达什么"困住的 PM。

读完你将收获三样东西：

下面进入正文。遇到开发术语时我会尽量加括号说明，纯技术读者可以直接略过。

先看几条实际存在的需求：

"用户点击登录，系统需校验，体验应更好。""密码重置需及时。""支付失败时妥善处理。""高级用户上传文件时，速度应更快。"

这类话放进 PRD 人能看懂，AI 字面上也不"难理解"。真正的麻烦在于，其中埋藏着大量未表述的假设：

这些空白，人脑会在阅读需求时自动补全——依靠常识和领域经验，方向大致正确，所以我们觉得"这需求挺明白"。但 AI 的"补全"是另一回事：它来自统计层面的默认倾向，不是在填充业务常识，而是在没有约束的地方填入一个"看起来最合理"的默认实现。两者本质不同，结论差距极大。

因此 bug 几乎不会出现在主流程里，全部藏在这些表述不清的分支中。

传统开发中，需求模糊的代价是熬夜澄清、测试反复打回；AI 编程中，需求模糊的代价是 AI 一本正经地猜错，然后你把时间耗费在与一个"态度礼貌但确实错了"的对象进行多轮澄清上。

所以真正要做的是把投入的力气向前挪一步：不是要求 AI 学会理解模糊表达，而是先把模糊性消除掉，再让 AI 开展工作。需求阶段的一点点投入，会成倍地节省后续返工和沟通——许多项目根因分析报告把 30%～50% 的缺陷追溯到需求或设计阶段，这还未计入 AI 时代被"礼貌地猜测"进一步放大的部分。

EARS 是 Easy Approach to Requirements Syntax（需求语法简易方法）的缩写。由 Alistair Mavin 等人于 2009 年提出，最早用于 Rolls-Royce 飞行控制系统的需求编写，随后被广泛推广至汽车、轨道交通、软件工程等领域。

它的主张非常朴实：需求不能是散文，必须转化为有固定句式的陈述，让每种表达都拥有明确角色。工具仅包含六个句式（加几个大写关键字 WHEN、WHILE、IF、THEN、WHERE）和一个驱动词 shall（在中文语境里译为"应"）。

下面是 EARS 常见的几种编写格式语法：

普适型（Ubiquitous）· 无关键字：行为始终成立，没有触发事件、没有前置条件。

事件驱动型（Event-Driven）· WHEN：由一个明确、离散的事件触发。

状态驱动型（State-Driven）· WHILE：某个状态持续成立期间一直生效。

非期望行为型（Unwanted Behavior）· IF-THEN：处理出错、故障、边界情况。

可选功能型（Optional Feature）· WHERE：只在某个功能或配置启用时生效。

复合型（Complex）· 两个关键词组合：条件不止一个时组合使用，且一条最多两个关键词，顺序按"状态/功能 → 事件/异常 → 响应"排列。

日常使用时需遵守以下规则：

读者可能会问：这与验收标准、用户故事、Gherkin 的 Given/When/Then 有何区别？简单来说，用户故事表达"给谁带来什么价值"，Gherkin 讲究完整场景编排，而 EARS 是更轻量、更贴身、不含 UI 流程的规格写法——它的定位从一开始就明确了：作为工程和 AI 编码的输入。

它不是替代那些方法，而是把"哪一块环境里要做什么、不做什么"切分为可测试的粒度。

光说"EARS 能消除歧义"，程序员未必觉得有分量。

讲讲它在 AI 实战中的三个关键位置：

第一，AI 不会追问，它会替你猜测。人类开发者拿到模糊需求，会开会、拉群、争论三轮才动工（多数开源模型都默认直接开工，不会先反问）。AI 却在几乎每个模糊处悄悄填入一个它认为"最合理"的答案。你感觉没有冒险，其实全被代偿。EARS 把需求补到"无需猜测"的程度，就是把这个坑填平。

第二，需求歧义本就是 bug 的最大源头，而 AI 会将放大乘数。人写代码一次一版，发现不对会刹车；AI 一瞬间生成整个函数、整个模块，歧义会被丝滑地包装成"看似没错"的生产代码。歧义不消除，测试、验收、回归的代价会成倍叠加。

第三，规格稳定，提示词才能稳定。每次都从同一份 EARS 规格出发，无论你换哪种 AI、换哪个版本，对同一逻辑的理解都是一致的。这是可复现工程的核心：需求输入稳定，AI 输出才有机会稳定。

一句话总结：提示工程的上游，是需求工程。需求越结构化，提示越省力，测试越有把握。

我们的流程中，编码之前会先过一遍需求的"规范化改写"，并且把它固化为一个固定技能（Skill），让 AI 按同一套流程执行、输出统一结构。

大致五步：

最终按固定结构输出：每条的模式判断 + 改写前后对照 + 待确认问题，让改写者、PM、测试三方在同一张文档上对齐。下面直接展示真实样例，看它具体是如何转换的。

我个人也针对 EARS 这种做成一个 Skills，感兴趣的可以安装下载使用：

这个技能可以帮助大家实现一些原始需求描述的重写。将模糊、口语化或有歧义的需求改写为清晰、无歧义、可测试、可评审的规格陈述，并在需要时给出句式选择、拆分建议和校验意见

下面是日常的几个案例：

原始需求：用户登录的时候要校验用户状态，体验要好一点。

问题拆解："登录时"是点击按钮还是提交成功？"体验好"具体指什么？"用户状态"没有给出定义和异常分支。

重写拆成四条，每条标注模式：

看，原来说"体验好"，落到底其实是"错误时把报错说清楚"+"防暴力破解"。一条需求拆成四条，每条都对应一个测试角度——这正是 EARS 最直接的价值：把"我觉得可以"变成"我真能去验证"。

同时注意，第 3、4 条明明都发生在"密码错了"的那一刻，却依然是两条，分写了"提示错误"和"锁定账号"，各自独立验证。这正是规则第 1 条：一条规格只装一个动作，哪怕它们都发生在"密码错了"的那一刻。

改写完成后还要提交一份作业——待确认问题，把原句未给出、改写时也不该替 PM 拍板的内容挑出来：

这些就是重写之后你需要回头询问 PM 的问题。

EARS 的价值，就是把它们一个个从代码里揪出来——它们本就不该由 AI 默默决定。例如我的使用截图：

原始需求：系统支持双因素认证。

"支持"这类词在业务口语中司空见惯，但一到规格层面就是地雷。重写：

一句话"支持"，被展开为三个分支：什么时候要验证码、验证错如何处理、未开启开关怎么办。每一条都是一个测试设计，AI 拿到后可直接实现前后端逻辑。

待确认问题：

原始需求：网络错误要妥善处理。

"处理"和"妥善"是两道门槛。重写：

讲两点作为说明。第一，重试次数、间隔、兜底结果都已明确，AI 才能一次次改对。第二，第 3 条"用户主动取消支付"在句子语义中根本不存在——它不是从"网络错误"推导出来的，而是我们新增的业务场景。如果确有需要补充，也凭职业判断写上，然后在待确认中明说"这条属于我补充的，请你拍板"，而不是悄悄塞进实现。

原始需求：离线状态情况下也能正常使用功能，之后进行同步。

一个"离线"的场景，拆成了"存哪""何时同步"两条。那 30 秒的同步时限仍需确认：业务能否接受 30 秒内全量同步，还是优先同步、不重要的后台慢慢补？

EARS 不是替代 AI 编码，而是编码的入口关卡。我们目前的完整链路是这样的：

最后，几个值得带回去的实操技巧：

1. 把 EARS 做成一个技能（Skill），而不是每次手写。六种模式、五步流程全部用脚本固化，AI 每次收到原始需求自动跑完识别→拆→套模式→输出对照→给待确认。你只需要当"裁判"，把关哪些问题需要回到 PM。

2. 强制 AI 输出"待确认问题"。这是整个机制最关键的一环：允许 AI 说"这个我不能替你做主"。当信息不足、无法确定数值时，EARS 会生成一份待确认清单，把这些空白挑出来。把"谁、何时、哪里、多少"留给真正该做决定的人，而不是让 AI 脑补。

3. 一条需求一个"应"，没有例外。只要看到 AI 偷偷加了一个"并且"，就拆。多动作合并，是隐蔽歧义的大门。

4. 别怕"保留原意图"。改写的原则是还原业务意图，不是给业务加戏；你真打算增加的规则，要进"待确认"而不是进"实现"。

几个需要认清的坑：

AI 编程把"写代码"的门槛降低了，但越是这样，"把话说清楚"反而比写代码更昂贵。你没法让一个理解力极强的 AI 替你补全——它只会把你的模糊，转化为一种漂亮的、看似没问题的实现。

EARS 补上的正是这个缺口：在 AI 编码之前，把需求变成"何时、在何状态、若怎样，系统就做什么"这样一句句可追问、可验证的规格。PM、研发、测试、AI 读到的是同一份一致的理解。

把它固化成自己的技能，每次需求再多一步：先改写，再编码。这一步看似慢，实际是把模糊从自己手中剔除——你喂给 AI 的每一个字，都在替你把联调夜连熬的三个通宵，压缩成编码前那 10 分钟的待确认环节。

想动手练习，去需求里挑一句含"支持、尽快、友好、妥善、合理安排"这种"一听就是地雷"的话，用上面五步重写一遍。数一数为了这一次你不得不回问 PM 多少个问题——问题比你想象的多，而这恰是你的价值。

喜欢本文的，可以关注、收藏、点赞、转发、分享到朋友圈哦。

本专题系列文章：

VibeCoding实践第1节：字节Trae实现简历与简历生成器

AI编程实践第2节：Spec规范驱动开发(SDD)1024游戏

AI编程实践第3节：Trae实现Web管理后台界面，效果出奇好

AI编程实践第4节：基于GPT5+Trae实现MCP服务市场

AI编程实践第5节：Trae梳理解构项目业务与代码流程

AI编程实践第6节：秒哒开发微信表情包生成应用

AI编程实践第7节：Git WorkTree机制实现分支并行开发

AI编程实践第8节：使用Understand Anything理解项目关系图谱

AI编程实践第9节：阿里秒悟与谷歌Stitch平台实现需求界面原型设计

AI编程实践第10节：B端C化，使用GPT-Image-2.0设计重构系统UI界面

AI编程实践第11节：使用代码图谱codegraph降低模型Token消耗

AI编程实践第12节：使用Zread生成项目Wiki知识文档，让AI和人类理解

AI编程实践第13节：Github Copilot对接自定义模型，爽了

AI编程实践第14节：Headroom代理，帮我省下Token 的"隐形管家"

AI编程实践第15节：Orca 的多代理协同开发，专门为AI Coding 打造的 IDE

AI编程实践第16节：Git SubModule打造可复用AI Workspace聚合仓库

最近也看到有人问如何学习AI，这里分享几个资料如下：

1、通往AGI之路的知识库飞书云文档

https://waytoagi.feishu.cn/wiki/QPe5w5g7UisbEkkow8XcDmOpn8e

2、掘金的AI知识库的飞书云文档

https://agijuejin.feishu.cn/wiki/UvJPwhfkiitMzhkhEfycUnS9nAm?table=blk3RfZtR7Nh73tO

3、极客时间的AI知识库的飞书云文档

https://geek-agi.feishu.cn/wiki/B9rYwwg6xidZYJkbrlscxTQFnOc

4、LangGPT社区的飞书云文档（结构化提示词等等）

5、一站式AI产品经理飞书知识库

https://v11enp9ok1h.feishu.cn/wiki/KiIvwdFOciiqqNkwKzTcmn88ndL

6、微软网站分享的AI指南说明知识

https://learn.microsoft.com/zh-cn/azure/databricks/generative-ai/guide/introduction-generative-ai-apps

7、赋范空间的飞书AI知识库：

https://kq4b3vgg5b.feishu.cn/wiki/ETqzwH4THiTY8kkGqAucYbSonPt

8、Marked的AI产品经理知识库

https://qqs7y1hozd1.feishu.cn/wiki/KVLtwsHdsiCLBfkumZpclY8ansd

喜欢的可以加入我的免费知识星球：觉醒的新世界程序员

喜欢的也可以关注我的公众号：无处不在的技术，与我一起学习成长、共同进步，在技术的道路上越走越远。

喜欢就点个在看呗 👇1