简诗 AI 需求拆解

痛点：当 Epic 落到代码前缺一份可执行的 PRD

在中大型 SaaS 迭代中，团队常把一个 Epic 拆到 Feature 层时，只留下一句目标或几张草图。结果是谁该负责、边界到哪里、成功指标是什么，都在会议里口头消化；到写技术方案时再回头确认，返工成本高，验收也容易只凭印象。

技能如何工作

该技能扮演大平台资深 PM，围绕一个 Feature / Enabler 生成完整 PRD，并写到 /docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md，给工程团队当需求基线。

核心能力分三步：

• 上下文补全：读取用户请求与父 Epic 资料；若目标用户、场景或约束不足，先提出澄清问题，不靠猜测硬写。
• 结构化输出：按固定骨架成稿，包含 Feature Name、Epic 链接、Goal（Problem/Solution/Impact）、User Personas、User Stories、Functional Requirements、Non-Functional Requirements、Acceptance Criteria、Out of Scope。
• 工程对齐：用户故事覆盖主路径与边界；验收标准用 checklist 或 Given/When/Then 表达，方便测试与联调时逐条勾选。

典型输入是 Epic 链接或上下文，加上对新功能的一句话想法；可再补充 Target Users，帮助收窄画像。

适用边界与注意点

• 适合需求仍需 PM 明确化、要形成团队共识的 Feature 级工作；不适合拿一句话需求直接替代完整调研。
• PRD 是需求与验收的单一来源，但不等同于架构设计或任务拆分；技术选型与里程碑仍需工程侧另行产出。
• Impact 应写成可观测指标，如转化率、留存或效率基线；团队没有埋点或基线时，应先把度量方案写清楚。
• Out of Scope 要具体到避免范围蔓延，例如明确哪些集成、端、数据迁移本期不做。