Digital--PRD-SKILL

KO | EN

gitlite — search

#javascript #python #hacktoberfest #react #ai #typescript #llm #go #golang #android #machine-learning #rust #deep-learning #linux

Digital--PRD-SKILL

★ 14 Open GitHub ↗

把模糊点子变成可落地 PRD 的 Claude Code skill：两阶段流程 + 技术落点 + 交付契约

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# /prd — 把模糊点子变成可落地的 PRD

一个给 [Claude Code](https://claude.com/claude-code) 用的 skill。通过对话，把一个模糊的产品想法一步步变成**可以直接拿去 coding 的需求文档**——不止对齐产品方向，还包含技术落点和给执行者的约束。

适合没有产品背景、准备用 vibecoding 把点子做出来的人。

---

## 出处与致谢

**这个 skill 不是从零发明的，方法论骨架来自别人，我做的是改造和迭代。**

- **两阶段流程、三视角诊断、五个盲区、MVP 冻结** —— 源自 B 站 UP主 **Panix潘尼** 的 PRD Writer 方法
  （[BV1Ba5g6wEwU](https://www.bilibili.com/video/BV1Ba5g6wEwU/)、[BV16MQjBkEJ3](https://www.bilibili.com/video/BV16MQjBkEJ3)）
- **第五节「交付契约」的思路** —— 源自 **数字生命卡兹克** 开源的 [Leader.skill](https://github.com/KKKKhazix/khazix-skills/tree/main/leader) 中提出的「目标七问」

本仓库是在此基础上，按个人工作流改造并三次迭代出来的版本。

---

## 它解决什么问题

AI 写需求文档有三个通病：

1. **幻觉迎合** —— 你说什么它都说好，从不挑战你
2. **细节模糊** —— 看着专业，但没有状态、没有字段、没有异常、没有文案
3. **返工成本高** —— 等你发现不对已经在 coding 阶段，改一处全盘重来

解法是不让 AI 一上来就写完整 PRD，而是拆成两步：**先出精简版对齐方向，冻结范围之后再出落地版补细节。**

---

## 工作流

### 阶段一：概念版（约 10 分钟）

从**用户 / 商业 / 技术**三个视角连续提问，诊断这个想法是不是伪需求、范围是不是过大、技术上现不现实。这一阶段会**主动挑战你**，而不是一味迎合。

聊透后输出一份约 300 字的概念版，核心是圈定 MVP——**明确哪些本期做、哪些本期明确不做**，然后逐条确认并冻结，才进入阶段二。

### 阶段二：落地版（约 30 分钟）

五节结构：

| 节 | 内容 |
|---|---|
| 一、概述 | 背景、目标、范围、技术约束、文案人设、视觉方向 |
| 二、功能列表 | 本期功能 + P0/P1/P2 优先级 |
| 三、功能详细说明 | 每个功能逐项覆盖**五个盲区** |
| 四、技术方案与数据模型 | 技术栈建议表 + 全局数据实体表 + 关键接口与读写时机 |
| 五、交付契约 | 验收证据 + 禁止路径 + 取舍优先级 + 未知处置 |

**AI 最容易跳过的五个盲区**（逐功能必填）：用户流程（正常 + 异常）、状态机、字段规范、文案规范、异常状态处理。

---

## 我在原方法上加的三层

这三层没有一层是装上它的第一天能想到的，全是用出来的。

**第一层：技术落点。** 原方法能产出很漂亮的产品级 PRD，但丢给模型 coding，同一份文档跑两次会出来两套完全不同的数据结构——因为数据存哪儿、建几张表、字段叫什么、用什么栈，文档里一个字没提。补了第四节，文档才真正能作为开发输入。

**第二层：堵摩擦。** 用了一个多月后的体检：修掉模板外层代码围栏被内层提前闭合的 bug；把开放式提问改成选择题 + 默认值（每视角 2~3 轮封顶）；功能多时改成每批 2~3 个分批交付，防细节质量衰减；补上视觉方向约束——不写风格关键词和主色调，coding 模型每次都会给你一套自己的审美，这是返工重灾区。

**第三层：交付契约。** 前四节描述**要做什么**，第五节约束**不许怎么做**。需求写得再清楚，也挡不住执行者走捷径——尤其当 AI 从"你盯着它写"变成"它自己跑几个小时"之后。

其中最实用的是**禁止路径清单**：

- 不许用 mock 或 hardcode 返回值让流程"看起来通了"
- 不许删改或跳过测试用例来让测试通过；跑不过就改实现，不改测试
- 不许交付 UI 骨架加占位数据就报告完成
- 不许绕过技术约束偷偷引入新依赖
- 不许改动本期范围之外的文件和功能
- 不许把"本期明确不做"的功能顺手做了

> 定义目标时，排除比设定更重要。肯尼迪登月宣言的关键不在"把人送上月球"，而在"并安全带回地球"——多出的这句话，删掉了"单程票"这个最省钱的解法。

---

## 安装

把仓库内容放进 Claude Code 的 skills 目录：

```bash
git clone https://github.com/liuzhaowei1/Digital--PRD-SKILL.git
mkdir -p ~/.claude/skills/prd
cp -r Digital--PRD-SKILL/SKILL.md Digital--PRD-SKILL/references ~/.claude/skills/prd/
```

目录结构：

```
~/.claude/skills/prd/
├── SKILL.md
└── references/
    └── prd-template.md
```

## 用法

```
/prd
```

或者直接说「我有个点子想做出来」「帮我写个产品需求」「帮我把这份需求改得能落地」。

支持三种模式，开场会先确认是哪种：

| 模式 | 场景 |
|---|---|
| 从零生成 | 我有个点子想做 |
| 优化已有 | 帮我把这份需求改得能落地 |
| 新增需求 | 给这个产品加个 X 功能 |

### 一个使用建议

第五节交付契约要写多细，取决于你打算怎么用这份 PRD：

- 拿了就开目标模式 / `/goal` 让它自己跑几小时 → **五个小节必须填满**，这是唯一的防跑偏手段
- 自己边看边改、随时能纠偏 → 留一条禁止路径清单就够了

---

## 不适用的场景

企业级需求规格说明书（SRS）、甲方验收文档——那是另一套范式（乙方设计、甲方验收、功能指标化），不要用这个 skill。

---

## 最后

**别人的 skill 装上就能用，但用不了多久。**

因为方法论是对方从自己的工作流里长出来的，而摩擦点长在你自己的工作流里。

这个 skill 可以直接装上就用，但更希望你把它当成一个起点——按自己的需求继续优化，做适配性改造，让它更贴合你的使用习惯。

毕竟这个 skill 本身，就是这么来的。

---

## License

[MIT](LICENSE)

Digital--PRD-SKILL

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README