# Soia Dev Design Draft Prd

> 起草互联网通用 PRD、产品需求文档与用户故事；适用于一句话需求补全、功能范围和验收标准梳理。

- Skill: `soia-team/soia-dev-design-draft-prd` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add soia-team/soia-dev-design-draft-prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/soia-team/soia-dev-design-draft-prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: soia-team (https://skillmd.com/u/soia-team)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/soia-team/soia-dev-design-draft-prd

---


# soia-dev-design-draft-prd

将模糊的互联网产品想法转化为可评审的产品需求文档（PRD）。输入可以是一句话需求或已有材料；输出是明确标注假设、范围和待决事项的 PRD 草稿，而非未经验证的实现承诺。

## 客户可读说明

### 这个技能可以做什么

| 客户想要 | 技能会做 | 客户能看到 |
|---|---|---|
| 把一句话想法变成 PRD | 用最少的追问引导补全关键上下文，并显式记录未知项 | 一份带假设和开放项的 PRD 草稿 |
| 整理已有需求材料 | 归纳问题、目标、用户故事、范围和验收条件 | 可评审的结构化需求清单 |
| 为需求评审做准备 | 检查范围边界、可验证性、依赖和风险 | 评审问题、里程碑建议与风险表 |

### 客户如何使用

直接描述产品机会、目标用户、要解决的问题或预期结果；也可提供已有访谈摘要、需求笔记或约束。示例：`为 ExampleCorp 的示例产品起草一个 PRD：让新用户在移动端完成首次任务。`

若输入只有一句话，先提出不超过五个、按影响排序的问题，优先确认目标用户、问题证据、成功指标、约束和上线窗口。客户暂时无法回答时，使用清晰的“假设”占位继续起草，不把假设写成事实。

### 依赖与安装

这是纯方法论技能，无强依赖、可选工具依赖或私有配置；不读取公司知识库，不执行代码、数据或远端系统操作。

```bash
claude plugin marketplace add soia-team/soia-open-skills
```

```bash
claude plugin install soia-dev-design@soia
```

只要这一个技能时，可用 npx 路线。注意技能会落进共享真源 `~/.agents/skills`；若同时装了插件，同一技能会出现两份索引且各自漂移，建议二选一：

```bash
npx skills add soia-team/soia-open-dev-design-skills -g -a '*' -s soia-dev-design-draft-prd -y
```

配置约定采用 schema v2：`~/.config/soia-skills/soia-dev-design-draft-prd/config.yml`。本技能默认无需创建该文件；如客户希望长期复用文档模板、术语表或默认交付格式，可在其自有配置中定义，且不得放入凭据或私密业务资料。

## 工作流程

**WorkBuddy** 的装载单位是角色化专家而不是插件，`npx skills add -a '*'` 覆盖不到它，需要单独安装，见 [docs/install/workbuddy.md](https://github.com/soia-team/soia-open-skills/blob/main/docs/install/workbuddy.md)。

### 1. 建立需求边界

复述已知需求，并区分看到的事实、合理推断和未验证假设。确认交付的是草稿而不是立项、排期或研发承诺；没有客户授权时，不代表客户作出商业、合规或发布决定。

### 2. 补全最关键的信息

从以下维度选择信息缺口最大的项目提问：目标用户与使用场景、当前问题及证据、业务目标与成功指标、时间/平台/合规约束、已有能力和明确排除项。避免为填满模板而提问；已能合理假设的低风险细节放入开放项。

### 3. 起草问题、目标和边界

以用户问题而非预设功能开篇。目标应包含可观察的结果或衡量方式；非目标应排除相邻但容易被误解为本次范围的事项。若没有基线数据，写明待采集的指标和采集方式，不虚构数值。

### 4. 定义用户故事和功能范围

为每个核心场景写出“作为 <用户>，我想要 <动作>，以便 <结果>”。按必须、应该、可选或明确不做分层功能范围；说明关键流程、异常路径、权限/状态边界和跨团队依赖。功能描述聚焦可观察行为，避免预先锁定技术实现。

### 5. 编写可验收的条件

为每项必须范围定义可独立核验的验收标准，覆盖正常路径、关键失败路径和边界条件。使用可观察的前置条件、动作和结果；“体验良好”或“性能快”之类表述必须改成可验证的指标，或列为待定。

### 6. 规划里程碑、风险与开放项

里程碑按可验证结果组织，例如“需求确认”“原型验证”“可用版本”“上线复盘”，不编造日期、资源或承诺。将风险写成“触发条件—影响—缓解/验证动作”；把未决问题单列，标明建议负责人或所需证据。

### 7. 自检与交付

从反面检查：目标是否能被功能范围支持、非目标是否防止范围蔓延、每个必须功能是否有验收标准、每个事实是否有来源或被标为假设。交付前删除重复描述和未经证实的断言，并说明需要客户确认的内容。

## 输出契约

默认以 Markdown 输出，包含以下章节；客户要求的内部模板可改变排版，但不得省略不确定性标识：

```markdown
# <产品/功能名称> PRD

## 背景与问题
## 目标与非目标
## 目标用户与场景
## 用户故事
## 功能范围
## 验收标准
## 里程碑
## 风险与缓解
## 开放项与假设
```

- 背景与问题：只陈述客户提供的事实或标注为假设的判断。
- 目标与非目标：目标含成功信号；非目标明确本次不处理的范围。
- 用户故事、功能范围和验收标准：相互可追溯；必须范围均有至少一个验收条件。
- 里程碑：以成果和确认点描述，不在缺乏依据时承诺具体日期或人力。
- 风险开放项：每项包含影响、下一步验证或决策信息；未知项不伪装成结论。

## 私密信息与中间数据

- 仅使用客户在当前对话或明确授权材料中提供的需求信息；不读取、推测或复述任何未授权的公司知识库、账号资料或个人数据。
- 默认仅在对话中生成草稿，不写入本地磁盘。客户要求保存时，写入客户指定的位置；草稿中的联系人、真实业务数据和附件链接须按客户要求脱敏。
- 本技能不需要凭据，也不记录运行状态、缓存或临时数据。若客户自建配置，配置中仅保存非敏感格式偏好，保留期由客户控制。

## 日志与完成回执

最终回复应简要说明：已使用的输入范围、提出或采用的假设、生成的 PRD 章节、未解决的开放项，以及建议的下一步（例如确认指标或评审范围）。不得声称完成用户研究、技术评估、合规评审或上线决策，除非客户另行提供了相应证据。

## 质量与安全边界

- 使用通用互联网产品实践和虚构示例；不依赖任何组织专属术语、系统、流程或数据。
- 不虚构用户研究、市场数据、指标基线、客户承诺、排期或法律结论。
- 涉及隐私、安全、支付、医疗、金融或监管要求时，标为待专业评审的风险，不提供替代专业意见。
- 输出是需求沟通材料；实施方案、技术架构、项目排期和发布授权须由相应负责人另行确认。

## Agent Metadata

`agents/openai.yaml` 仅提供界面展示和示例提示；所有可移植的执行要求以本文件为准。

## 验证

- 静态：确认 frontmatter、目录结构和 Markdown 链接通过仓库审计。
- 内容：用一句虚构需求检查能生成八个必需章节，并将未知信息标为假设或开放项。
- 安全：提交前扫描私有路径、凭据和不应出现的专属术语。