基于 EARS 规范，将模糊的业务想法转化为清晰、结构化、AI 易读的需求文档
写需求文档是产品开发中最头疼的环节之一——业务方说不清楚，开发理解有偏差，最后做出来的东西和预期差距很大。
Write EARS PRD 是一个智能助手技能，它引导你按照 EARS（Easy Approach to Requirements Syntax） 规范，一步步将业务需求转化为标准化的 PRD 文档。
EARS 是一种被广泛应用的需求描述语法，它通过固定的句式（When/While/If/Where）让需求变得清晰无歧义，既方便人类阅读，也便于 AI 理解和后续处理。
自动判断你的需求是否适合用 EARS 描述：
- ✅ 适合：复杂业务逻辑、状态流转、异常处理、后台系统交互
- ❌ 不适合：纯 UI/UX 设计、商业策略、头脑风暴
按照固定流程，一步步产出完整 PRD：
| 步骤 | 内容 |
|---|---|
| Step 0 | 需求评估与澄清 —— 信息不足时会主动提问 |
| Step 1 | 需求分析 —— 确认业务领域和核心实体 |
| Step 2 | 提取全局名词 —— 统一术语定义 |
| Step 3 | 识别非功能性需求 —— 安全、性能、可用性等 |
| Step 4 | 构建 EARS 需求表格 —— 核心功能需求 |
| Step 5 | 完整性检查 —— 黑名单词汇检测、逻辑验证 |
| Step 6 | 组合覆盖度验证 —— 确保状态 × 事件 100% 覆盖 |
- 技术细节屏蔽：自动检测并阻止数据库、代码、架构等实现细节混入需求
- If 句式校验：确保 If 只用于异常场景，正常流程用 When
- 覆盖度矩阵：自动生成状态-事件矩阵，检查是否有遗漏场景
内置电商订单、医院挂号、物流追踪等多个行业的完整示例，供参考学习。
直接告诉 AI 你的业务需求即可，例如：
"帮我写一个电商订单系统的 PRD，需要包含订单创建、支付、发货、退货等流程"
AI 会按照以下流程与你交互：
- 确认理解 —— 先向你确认对需求的理解是否正确
- 逐步完善 —— 分阶段产出 PRD 内容，每阶段都需你确认
- 质量把关 —— 自动检查需求完整性和规范性
- 输出文档 —— 最终生成标准格式的 Markdown PRD
为了获得最佳效果，建议你在描述需求时包含以下信息：
- 业务实体：涉及哪些核心对象？（如订单、用户、商品）
- 系统状态：有哪些关键状态？如何流转？
- 触发事件：用户操作或系统事件如何触发业务逻辑？
- 异常场景：网络超时、库存不足等情况如何处理？
- 约束规则：时间限制、数量限制等业务规则
生成的 PRD 文档包含以下部分：
📄 PRD 文档
├── 1. 文档信息（版本、作者、日期）
├── 2. 背景与目标
├── 3. 全局名词定义（术语表）
├── 4. 非功能性需求（NFRs）
├── 5. 功能性需求（EARS 需求表格）
├── 6. 组合覆盖度矩阵（验证用）
├── 7. 业务流程图（可选）
└── 8. 需求追溯矩阵（可选）
| 关键字 | 句式 | 使用场景 |
|---|---|---|
| When | When [事件], the [系统] shall [响应] | 正常业务流程 |
| While | While [状态], the [系统] shall [响应] | 特定状态下的行为 |
| If | If [异常], then the [系统] shall [响应] | 异常/错误处理 |
| Where | Where [特性], the [系统] shall [响应] | 可选功能开关 |
| Complex | While [状态], When [事件], the [系统] shall [响应] | 复杂组合场景 |
When 用户提交订单时，系统应当验证购物车非空且用户已登录
While 订单处于"待支付"状态期间，系统应当保留库存且允许用户取消订单
If 订单创建后 30 分钟内未支付，则系统应当自动取消订单并释放库存
write-ears-prd/
├── SKILL.md # 技能核心定义文档（AI 使用）
├── README.md # 本文件（人类阅读）
├── evals/
│ └── evals.json # 技能评估测试配置
├── reference/ # 参考资料
│ ├── ears.md # EARS 规范原文
│ ├── *.md # 相关学习文章
│ └── assets/ # 图片资源
└── test-output/ # 测试输出示例
├── 01-education-system-prd.md
├── 02-logistics-system-prd.md
├── 03-hospital-appointment-prd.md
└── ... # 更多场景测试用例
| 场景 | 推荐程度 | 说明 |
|---|---|---|
| 全新功能/系统设计 | ⭐⭐⭐⭐⭐ | 最适合，可建立完整的质量基线 |
| 现有功能重大改版 | ⭐⭐⭐⭐☆ | 适合，但需评估历史债务 |
| 简单字段/规则调整 | ⭐⭐☆☆☆ | 过于简单，不建议使用 |
| 纯 UI/UX 设计 | ❌ 不适用 | 请使用设计稿或原型工具 |
- 运行环境：Claude / CodeBuddy / 支持 Skill 机制的 AI 编程助手
- 输入格式：自然语言描述的业务需求
- 输出格式：Markdown 文档
- 无需安装：本技能为声明式配置，无需额外依赖
- 📚 EARS 规范详解
- 📖 SDD 来了，产品经理怎么写出 AI 易读的 SPEC-一起看下EARS给出的答案
- 使用花叔的 达尔文技能 进行迭代
- 🧪 测试用例示例
如有建议或问题，欢迎通过 Issue 或 PR 反馈。
让需求文档不再难写，让沟通更加高效。