你是否曾在 Vibe Coding 开发过程中，发现 AI 产出的代码逻辑漏洞百出，改到怀疑人生？
在传统开发里， Spec 就是正义。但在与 AI 协作时，我们更像是「导演」。
想要让那个很有才华但偶尔会「发疯」的 AI 演员演出一场好戏，你需要的是两套强大的工具：EARS（剧本逻辑） 与 BDD（验收剧照）。
EARS：把需求变成「逻辑积木」
你一定遇过这种 PM，需求写着：「系统要好用一点」、「处理速度要快」。这在写代码时根本是灾难。
EARS (Easy Approach to Requirements Syntax) 说白了，就是要把这些「模糊的形容词」转化为「精准的指令」。
EARS 就像是顶级的 Prompt Engineering，它强迫你把话讲得逻辑封闭。主要的 5 种句型，让你随时都能「锁死」需求边界：
| 类型 | 说明 |
|---|---|
| Ubiquitous (通用型) | 系统必须...（就像呼吸一样，随时都要遵守）。 |
| Event-driven (事件驱动型) | 当 [事件发生] 时，系统必须...。 |
| Unwanted Behavior (异常处理型) | 如果 [坏事发生] 了，系统必须...（这就是 Error Handling 的灵魂）。 |
| State-driven (状态驱动型) | 当处于 [某种状态] 时，系统必须...。 |
| Optional Feature (选配型) | 当有 [特殊功能] 时，系统必须...。 |
EARS 帮你立下严谨的规矩
让 AI 没办法在逻辑上「一本正经地胡说八道」。
BDD：把测试变成「电影剧本」
如果 EARS 是严谨的合约，那 BDD (Behavior Driven Development) 就是「有血有肉的故事」。它不测 a == b，它测的是「使用者觉得发生了什么事」。
BDD 用的语法叫 Gherkin（小黄瓜，就是要清脆爽口！），核心三部曲如下：
| 语法 | 说明 |
|---|---|
| 🎬 Given (背景) | 设定开拍前的场景（例如：口袋里有 100 块）。 |
| ⚡ When (动作) | 导演喊 Action 的那一刻（例如：点了一份大辣鱿鱼）。 |
| ✅ Then (结果) | 观众看到的结局（例如：拿到香喷喷的鱿鱼，钱包少了 60 块）。 |
透过这种「说故事」的方式，即便不是工程师也能跟我们沟通，而 AI 也能透过这些「实例」理解你的真正意图。
EARS vs BDD 的差异是什么？
这两者各司其职，结合起来才是真正的「无敌」。
| 特性 | EARS (需求语法) | BDD (行为驱动) |
|---|---|---|
| 核心精神 | 精准定义 (消除歧义) | 共识与验证 (说故事) |
| 像是在写… | 法律条文 | 电影剧本 |
| 主要听众 | PM、架构师、规则制定者 | 工程师、QA、AI 助手 |
| 解决痛点 | 「你做的跟我想的不一样！」 | 「这功能逻辑对了，但没法用！」 |
简单来说：EARS 帮你定规矩，BDD 帮你确认结果。
EARS 高阶运用：Vibe Coding 实战
我们在 Prompt 里直接塞进 EARS 的规则和 BDD 的剧本让 AI 开发。
你可以试试看开发「电子钱包扣款」时这样下指令：
# 任务：请帮我实作扣款 API
## EARS 逻辑 (请严格遵守)：
- [Event-driven]: 当收到请求，必须验证余额。
- [Unwanted]: 如果余额不足，回传 400 错误码 'INSUFFICIENT_FUNDS'。
- [State-driven]: 当钱包处于 'Frozen' 状态，拒绝所有扣款。
## BDD 验收剧本 (作为 Jest 测试用)：
Scenario: 余额不足扣款失败
Given 用户余额为 50 元
When 收到扣款 100 元的请求
Then API 应回传 HTTP 400
And 错误代码应为 'INSUFFICIENT_FUNDS'
你试试看丢给 AI，产出来的 Code 不会偏离目标太多！
总结
不管是在日常开发还是 Vibe Coding，EARS 与 BDD 都是提升效率的神器。
EARS 帮你立下严谨的规矩，BDD 帮你确认演出的结果。