Skill 介绍
背景
作为 UI 设计师、前端开发或测试工程师，你是否遇到过这些痛点？
- 需求文档太简略：产品经理只写了功能清单，没写业务规则、异常情况
- 原型图有了，但细节缺失：设计稿给了，但字段校验、交互逻辑没说明
- 需求变来变去：口头沟通的需求，开发和测试理解不一致
- 时间紧，来不及写详细文档：需求紧急时，大家凭感觉开工，后期返工多
generate-prd 就是为解决这些问题而生的——不是帮产品经理写文档，而是帮 UI、开发、测试补全需求细节，产出一份三方都能用的协作基准文档。
使用场景
| 场景 | 示例 |
|---|---|
| 会议纪要转 PRD | 开完需求评审会，把口头需求转成结构化文档，方便后续查阅 |
| UI 原型图识别 | 设计师给了原型图，AI 自动识别字段、按钮、交互逻辑，补全细节 |
| 功能清单完善 | 产品经理只列了功能点，AI 帮你补全业务规则、数据定义、异常情况 |
| 需求迭代确认 | 初版文档生成后，通过多轮对话逐步完善，减少返工 |
目标用户： UI 设计师、前端开发工程师、测试工程师
核心价值： 把"缺斤少两"的需求来源，补全成一份信息完整、结构清晰、三方认可的协作基准文档。
具体使用方法
1. 基本调用
支持多种输入方式：
把这份会议纪要转成 PRD：meeting-notes.txt
把这个需求文档完善一下：requirements.docx
帮我生成 PRD：
[粘贴你的需求草稿]
2. 工作流程
Phase 1: 文档转换
- 自动将 .docx/.txt 转为 Markdown
- 提取并保存图片
Phase 2: 图片识别（如有图片）
- 使用 Vision 能力详细识别 UI 截图
- 按行列出字段、按钮、交互元素
注意：图片识别需要带视觉能力的大模型，实测 Kimi 2.5 效果不错
Phase 3: 需求提取
- 保持用户原文一字不改
- 按功能模块组织内容
Phase 4: 双角色审查
- 产品策略师：检查 CRUD 完整性、流程闭环、数据一致性
- 体验专家：检查异常状态、空状态、二次确认、输入校验
Phase 5: 生成输出
- 输出
[OriginalStem]-v1.md（主文档） - 输出
[OriginalStem]-待确认-v1.md（待确认问题清单）
3. 迭代完善
查看待确认清单后，直接回复：
问题1需要补充，登录方式包括手机号+验证码、微信扫码两种方式。
问题2不需要，产品已明确物理删除策略。
问题3待讨论，下周和财务确认后再定。
AI 会自动解析并生成 v2 版本。
Skill 编写思路
1. 角色分离：双专家机制
不要让一个 AI 做所有事。我把审查拆成两个角色：
- 产品策略师：关注"功能对不对"（业务逻辑）
- 体验专家：关注"用起来顺不顺"（交互细节）
每个角色有独立的规则库，互不干扰，输出更专业。
2. 原始内容保护
用户写的原文一字不改，AI 补充的内容用 【补充】 标记：
## 1. 用户登录
[用户原文，保持原样]
---
**【补充】业务规则：**
- 手机号格式校验：1[3-9]\d{9}
- 密码错误 5 次锁定 30 分钟
这样既尊重用户表达，又明确了 AI 的贡献边界。
3. 强制模板：图片识别
图片识别最容易"偷懒"，所以我设计了强制模板：
> **图片内容识别：** [页面名称]
> - **整体布局**：[X]列布局
> - **字段明细**（按行列出）：
> - **第1行**：字段1 [标签][类型][必填？][提示][状态]
> - **交互元素**：...
> - **特殊说明**：...
AI 必须按这个格式输出，确保识别结果详细且结构化。
4. 门控检查：流程严谨性
关键节点设置强制检查：
- Phase 1.5：检查图片引用 vs 图片文件数量，不匹配就停止
- Phase 2 完成门控：确认所有图片都有识别结果
避免"差不多就行"，用规则保证质量。
5. 迭代机制：持续改进
PRD 不是一次写完的。我设计了版本号机制：
v1：初版，带待确认清单v2：用户确认后，补充内容移入正文v3：继续迭代…
每次迭代都保留历史记录，便于追溯。
文件结构
generate-prd/
├── SKILL.md # 主技能文件
├── references/
│ ├── strategy-rules.md # 产品策略师规则库
│ ├── ux-rules.md # 体验专家规则库
│ ├── image-analysis-template.md # 图片识别模板
│ └── document-templates.md # 输出文档模板
└── scripts/
└── convert_docx.py # docx 转换脚本
核心设计原则
- 人机协作：AI 负责发现遗漏，人类负责决策确认
- 渐进明细：从粗到细，多轮迭代，避免一次性追求完美
- 可追溯：保留原始内容、标记 AI 补充、记录迭代历史
- 专业分工：不同角色关注不同维度，输出更专业
适用与不适用
适合用：
- 需求来源是会议纪要、草稿、口头描述，缺少细节
- 有 UI 设计稿需要转成文字需求，补全交互逻辑
- 产品经理给的功能清单太简略，需要补全业务规则
- 时间紧，需要快速产出可协作的基准文档
不适合用：
- 需求已经非常明确详细（直接写代码更快）
- 需要高度创意的产品设计（AI 只能补漏，不能创新）
用户反馈
“以前需求评审会开完，纪要里只有功能点，开发经常问’这个字段要不要必填’‘异常怎么处理’。现在用这个 skill，会议纪要直接转成带业务规则、异常情况的 PRD，开发和测试都能看明白，返工少了很多。”
—— 某互联网公司前端开发
效果展示
原始文档
PRD文档
待确认清单
欢迎试用和反馈！如果有改进建议，欢迎交流讨论。
