product-playbook 1.0.0

package/i18n/zh-CN/references/04c-mvp.md

@@ -0,0 +1,21 @@
+# 阶段三：Develop — MVP 范围定义
+
+## 3.7 MVP 范围定义
+
+MVP 判断标准：**能否验证核心假设？能否让目标用户完整体验 Primary JTBD？**
+
+```
+| 类别 | MVP 必须有 | V2 再加入 | 未来考虑 |
+|---|---|---|---|
+| 核心功能 | | | |
+| 用户体验 | | | |
+| 技术需求 | | | |
+```
+
+**Not Doing List（同等重要）：**
+
+```
+| 不做的事 | 不做的理由 |
+|---------|-----------|
+| | |
+```

package/i18n/zh-CN/references/05a-northstar-aha.md

@@ -0,0 +1,93 @@
+# 阶段四：Deliver — North Star + Aha Moment
+
+## 4.1 Marty Cagan 的赋能型团队原则（Empowered Teams）
+
+**适用于：高完整性 / 产出对象为老板/跨部门**
+
+> 4.1 Empowered Teams 在产出对象为老板/跨部门时才展示，否则跳过。
+
+```
+| 面向 | 功能型团队（避免） | 赋能型团队（目标） |
+|------|-----------------|-----------------|
+| 被分配到的 | 功能清单（Output） | 需要解决的问题（Outcome） |
+| 成功定义 | 按时交付功能 | 达成用户和商业指标 |
+| PM 的角色 | 需求收集者和项目管理者 | 问题探索者和解法验证者 |
+| 工程师的角色 | 执行规格 | 参与问题探索和解法设计 |
+```
+
+> 「真正的产品发现是与工程师和设计师**一起**做的，而不是 PM 一个人做完再交给他们。」— Marty Cagan
+
+**Lenny 的 PM 三职责：**
+- **Shape（塑形）**：整合用户洞见、数据和市场资讯，决定做什么
+- **Ship（交付）**：确保高品质产品按时上线，没有意外
+- **Synchronize（同步）**：让所有利害关系人对愿景、策略、目标和路线图保持一致
+
+## 4.2 成功指标框架（North Star + 三层讯号）
+
+北极星指标必须满足：
+- 能反映用户获得的真实价值（不是虚荣指标）
+- 可以持续增长（不会天然达到上限）
+- 能让整个团队在同一个目标下对齐
+
+```
+| 公司 | 北极星指标 | 为什么这个指标 |
+|------|----------|---------------|
+| Airbnb | 订出的住宿晚数 | 代表主客双方都获得了价值 |
+| Spotify | 每月聆听时长 | 代表用户真正在使用和享受音乐 |
+| Facebook | DAU / MAU 比率 | 代表用户习惯性回访 |
+| Slack | 每周发送的消息数 | 代表团队真正在协作 |
+| Salesforce | 活跃客户合约年度价值（ACV） | 代表客户持续从产品获得商业价值（B2B） |
+```
+
+**你的北极星指标：**
+```
+北极星指标：[一个数字，代表用户和产品创造的核心价值]
+定义：[精确的计算方式]
+为什么这个指标：[说明它为什么代表真实用户价值，而不只是商业结果]
+```
+
+### 📝 North Star 品质自检清单
+- ✅ 是否反映用户获得的价值？（不是营收、不是 DAU）
+- ✅ 是否能持续增长？（不会天然到达上限）
+- ✅ 团队每个人看到这个指标是否都知道自己该做什么？
+- ✅ 是否可以被操弄？（如果可以，需要护栏指标）
+- ✅ B2B 产品：是否反映客户组织层级的价值，而非只有个人使用者？
+- ❌ 常见问题：用营收当 North Star（营收是结果不是驱动因素）、指标太复合无法移动
+
+**三层讯号体系（必须依序达标）：**
+
+```
+| 层级 | 指标类型 | 定义 | B2C 目标值 | B2B 目标值 |
+|---|---|---|---|---|
+| 层级一（前提） | 核心动作成功率 | 用户是否完成了产品的核心动作？ | 30-40%+ | 60-80%+（因为用户更有动机） |
+| 层级二（价值代理） | D14 / D28 留存率 | 用户是否持续回来使用？ | 消费产品 15-20%+ | Logo 留存 90%+；Net Revenue Retention 100%+ |
+| 层级三（热情讯号） | Sean Ellis Score | 「如果失去这个产品，你会多难过？」 | 40%+ 回答「非常难过」 | 40%+ 回答「非常难过」 |
+| 护栏指标 | 防止过度优化 | 确保不伤害其他重要面向 | 视情况而定 | 视情况而定 |
+```
+
+说明：层级一是层级二的前提。如果核心动作成功率很低，留存率数据就没有意义，因为用户根本没有机会体验到产品价值。
+
+## 4.4 Aha Moment 设计
+
+```
+Aha Moment 定义：
+当用户完成 [具体行为]，他们就体验到了这个产品的核心价值。
+目标：在用户进入产品的 [X 分钟 / X 步骤] 内让他们到达这个时刻。
+
+Aha Moment 到达率：[目标 %]
+当前障碍：[什么阻止了用户更快到达 Aha Moment？]
+改善计划：[如何移除障碍？]
+```
+
+**范例：**
+| 产品 | Aha Moment | 时间目标 |
+|------|-----------|---------|
+| Slack | 团队发送第 2,000 条消息 | 前两周 |
+| Dropbox | 第一个文件同步到第二台装置 | 首次使用 10 分钟内 |
+| Zoom | 第一次一键加入会议且画面流畅 | 第一次使用 |
+
+### 📝 Aha Moment 品质自检清单
+- ✅ 是否是一个具体的、可追踪的行为？（不是「感觉产品好用」）
+- ✅ 是否与 JTBD 的功能性工作直接相关？
+- ✅ 到达时间目标是否合理？（B2C 应在首次使用内；B2B 可能在试用期内）
+- ✅ 是否可以设计 Onboarding 来引导用户更快到达？

package/i18n/zh-CN/references/05b-pmf-gtm.md

@@ -0,0 +1,102 @@
+# 阶段四：Deliver — PMF + GTM + 商业模式
+
+## 4.3 Todd Jackson（First Round Capital）的四级 PMF 框架
+
+```
+| 等级 | 名称 | 特征 | 你的任务 | 典型公司阶段 |
+|-----|------|------|---------|------------|
+| Level 1 | Nascent PMF（初萌的 PMF） | 找到 3-5 个愿意为解法付费的客户 | 深度服务这些早期用户，找到可重复的模式 | Pre-seed / Seed |
+| Level 2 | Developing PMF（发展中的 PMF） | 开始有口碑传播，但增长还不稳定 | 找到可规模化的获客渠道，提升留存 | Seed / Series A |
+| Level 3 | Strong PMF（强 PMF）| 「鱼儿自己跳进船里」，转介绍成为主要增长来源 | 建立规模化需求渠道，提升效率指标 | Series A / B |
+| Level 4 | Extreme PMF（极端 PMF）| 指标稳健，公司超过 100 人，考虑扩展 TAM | 进入新市场或推出新产品 | Series C+ |
+```
+
+**Four P's（在 Level 1-2 阶段找 PMF 的关键四问）：**
+1. Problem：你要解决的问题，是否真的足够急迫、足够重要？
+2. Promise：你的产品向用户许下了什么承诺？用户相信吗？
+3. Product：你的产品是否真的兑现了这个承诺？
+4. Pitch：你如何让目标用户发现并相信你的产品？
+
+## 4.7 GTM 策略（Go-to-Market）
+
+**适用于：完整模式 / 高完整性 / 产出对象为老板/业务/行销**
+
+产品做出来之后，如何让目标用户知道并开始使用？
+
+### 获客渠道选择
+
+```
+| 渠道类型 | 适合情境 | 典型方法 | 衡量指标 |
+|---------|---------|---------|---------|
+| 产品驱动增长（PLG） | 用户自助能体验到价值的产品 | 免费试用、Freemium、病毒式邀请 | 注册转换率、启用率、邀请率 |
+| 内容与社群 | 目标用户有共同的资讯需求或社群 | 部落格、SEO、社群运营、KOL | 流量、内容转换率、社群活跃度 |
+| 付费获客 | 需要快速验证或有明确 ROI | SEM、社群广告、再行销 | CAC、ROAS、LTV/CAC |
+| 销售驱动 | B2B 高客单价、需要 demo 和谈判 | SDR、AE、Demo、企业合约 | Pipeline、Close rate、ACV |
+| 合作伙伴 | 目标用户集中在某些平台或生态系 | API 整合、分润、共同行销 | 合作渠道转换率、合作伙伴数 |
+```
+
+### 初始 100 位用户获取计划
+
+```
+目标用户画像：[从 Persona 来]
+在哪里找到他们：[他们聚集的线上/线下场所]
+用什么 Hook 吸引他们：[从 PR-FAQ 的 Aha Moment 来]
+怎么让他们试用：[降低门槛的方法]
+初始目标：[X 天内获得 Y 个试用用户]
+```
+
+### Launch 策略
+
+| 策略 | 说明 | 适合情境 |
+|------|------|---------|
+| Closed Beta | 手动邀请 10-50 人，深度收集反馈 | PMF Level 1，产品还在调整 |
+| Open Beta | 公开但标明 Beta，降低期待管理 | PMF Level 1-2，需要更多数据 |
+| Soft Launch | 在特定市场或渠道低调上线 | 需要真实环境测试但不想全面曝光 |
+| Full Launch | 全渠道正式推出 | PMF Level 2-3，产品稳定 |
+
+## 4.8 商业模式与定价
+
+**适用于：完整模式 / 高完整性 / 产出对象为老板/业务**
+
+### 收费模式选择
+
+```
+| 模式 | 运作方式 | 适合产品类型 | 关键指标 |
+|------|---------|------------|---------|
+| Freemium | 基础免费 + 进阶收费 | 用户量大、免费版能展示价值 | 免费→付费转换率（目标 2-5%） |
+| Subscription | 按月/年订阅 | 持续提供价值的工具或服务 | MRR/ARR、Churn rate |
+| 按用量（Usage-based） | 用多少付多少 | API、云端服务、交易平台 | 每用户平均消费、用量增长率 |
+| 一次性付费 | 买断 | 工具型软件、课程 | 客单价、回购率 |
+| 交易抽成 | 每笔交易收取比例 | 平台、市场 | GMV、Take rate |
+| 按座位（Per-seat） | 依使用人数收费 | B2B 协作工具 | 每帐户平均座位数、扩展率 |
+```
+
+### 价值定价对齐
+
+```
+定价核心问题：
+1. 你的产品帮用户省了/赚了多少？（价值锚定）
+2. 用户现在为替代方案付多少钱？（竞争参照）
+3. 你的定价是否与用户获得的价值成正比？（公平感）
+
+定价策略：
+  - 模式选择：[Freemium / Subscription / 按用量 / ...]
+  - 价格区间：[依据价值锚定和竞争参照]
+  - 免费层包含什么：[足以到达 Aha Moment，但不足以满足进阶需求]
+  - 付费触发点：[什么使用行为或使用量触发升级？]
+
+⚠️ 常见定价错误：
+  - 定价太低（传递「不值钱」的讯号）
+  - 免费版太强（没有升级动机）
+  - 价格和价值不对齐（功能定价 vs 价值定价）
+  - B2B 没有年度合约折扣（错失现金流稳定性）
+```
+
+---
+
+## 📎 本阶段的文件整合提示
+
+| 上传内容 | 整合到 | 整合动作 |
+|---------|-------|---------|
+| 财务数据 / 营收报表 | 4.8 商业模式 | 用真实营收结构替代假设，评估定价合理性 |
+| 行销渠道数据 | 4.7 GTM | 用 CAC、转换率等真实数据评估渠道选择 |

package/i18n/zh-CN/references/05c-validation-spec.md

@@ -0,0 +1,117 @@
+# 阶段四：Deliver — 假设验证 + 产品规格摘要
+
+## 4.5 假设验证计划
+
+**适用于：中/高完整性 / 产出对象为数据科学家/自己**
+
+```
+| 核心假设 | 验证方法 | 验证时间点 | 成功标准 | 如果假设错误，我们将... |
+|---------|---------|-----------|---------|----------------------|
+| | Alpha 用户访谈 / 数据 | | | |
+```
+
+原则：质化验证（用户访谈、日记研究）+ 量化验证（数据）并重；对自己的确认偏误保持警惕。
+
+## 4.6 产品规格摘要
+
+产品规格摘要是所有模式的最终产出（快速模式产出一页式方向摘要，结构不同但精神一致）。
+产品规格摘要分为三个区块，对应不同阅读深度：
+
+### 区块一：决策摘要（30 秒能看完）
+
+```
+**产品一句话**：[PR-FAQ 标题]
+**为谁**：[目标 Persona 一句话描述]
+**核心价值**：[JTBD 功能性工作 + 情感性工作，一句话]
+**北极星指标**：[指标名称 + 定义]
+**PMF 目前等级**：[Level 1-4 + 一句话说明]
+```
+
+### 区块二：执行边界（2 分钟能看完）
+
+```
+**核心 JTBD 陈述**：[Target Customer] + 想要在 [Job Context] + 完成 [Job]
+**Aha Moment**：当用户完成 [行为]，他们体验到核心价值。目标在 [X] 内到达。
+**MVP 必须有**：[3-5 个最关键的功能/能力]
+**Not Doing（此版本刻意不做）**：[明确排除项 + 理由]
+**关键假设**：[需要验证的 2-3 个核心假设]
+**Pre-mortem 主要风险**：[最可能导致失败的 2-3 个原因]
+**Hero Metric**：[1-2 个最重要的成功指标 + 目标值]
+```
+
+### 区块三：深度参考（需要时查阅）
+
+```
+**JTBD 细分**：
+  - 功能性 Job：
+  - 情感性 Job：
+  - 社交性 Job：
+**April Dunford 定位**：
+  - 真实竞争替代品：
+  - 我们的独特属性：
+  - 对目标用户的核心价值：
+  - 目标市场特征：
+  - 市场类别：
+**核心 HMW 问题**：[从 Define 阶段得出]
+**解决方案描述**：[从 PR-FAQ 摘要]
+**商业模式**：[收费模式 + 价格策略，若已执行]
+**GTM 策略**：[初始获客渠道 + Launch 策略，若已执行]
+```
+
+完成三个区块后，Claude **必须主动补充以下三个区块**，不等使用者要求：
+
+---
+
+### ⚠️ 风险清单
+
+根据整个企划流程中识别到的所有风险，整合列出（来源：Pre-mortem + 机会评估 + 假设验证）：
+
+```
+| 风险类型 | 风险描述 | 严重程度（高/中/低）| 目前有无对策 |
+|---------|---------|-------------------|------------|
+| 市场风险 | | | |
+| 用户假设风险 | | | |
+| 技术风险 | | | |
+| 竞争风险 | | | |
+| 执行风险 | | | |
+```
+
+---
+
+### 🔍 不完整之处 & 待厘清盲点
+
+Claude 根据整个对话流程，主动识别出以下类型的缺口：
+
+```
+| 类型 | 说明 | 建议的下一步移动 |
+|------|------|----------------|
+| 未执行的步骤 | [哪些框架没有跑，可能造成什么盲点] | |
+| 数据不足 | [哪些判断是基于假设而非真实用户数据] | |
+| 逻辑跳跃 | [哪个地方的推导缺少中间论证] | |
+| 尚未验证的假设 | [列出所有还没有验证方法的核心假设] | |
+| 定义不清楚 | [哪些概念还需要更精确的定义才能执行] | |
+```
+
+---
+
+### 💡 补充建议
+
+Claude 根据产品的特性、阶段和已知风险，提供 3-5 条具体可执行的建议：
+
+```
+1. [最优先建议]：[具体移动] — 建议原因：[为什么这件事最重要]
+2. [次优先建议]：[具体移动] — 建议原因：
+3. [第三建议]：[具体移动] — 建议原因：
+...
+```
+
+建议范围可涵盖：用户验证方法、MVP 边界调整、竞争策略、指标设计、团队分工、下一个里程碑的重点。
+
+---
+
+## 📎 本阶段的文件整合提示
+
+| 上传内容 | 整合到 | 整合动作 |
+|---------|-------|---------|
+| 用户行为数据（CSV / Excel） | 4.2 North Star + 4.3 PMF | 用真实留存率、活跃度数据判断 PMF 等级；校准 North Star 基准值 |
+| Sean Ellis 问卷结果 | 4.3 PMF + 4.2 三层讯号 | 直接计算 Score，填入层级三 |

package/i18n/zh-CN/references/06-html-report.md

@@ -0,0 +1,123 @@
+# HTML 产品企划报告产出
+
+当使用者说「产出报告」或确认最后一个阶段内容无误后触发。
+
+## 设计规范
+
+采用**现代设计风格**，单一 HTML 文件（CSS 与 JS 全部内嵌），确保离线也能阅读。
+
+**整体风格：**
+- 渐层背景的 Hero 区块（含执行模式、产出对象、日期标签）
+- 卡片式排版（圆角 + 阴影），每个区块像是一张独立的资讯卡
+- 清晰的字体层级和舒适的阅读间距
+- 响应式设计，手机上也能顺畅阅读
+
+**配色方案：**
+- 主色调：深蓝系 `#1a1a2e` → `#16213e` → `#0f3460`
+- 强调色：`#e94560` 或 `#533483`
+- 内容区背景：`#f8f9fa`，卡片：白色带 `box-shadow`
+
+**中文字体：** 优先从 Google Fonts CDN 载入 Noto Sans SC，失败时 fallback 到系统字体：
+```css
+/* 在 <head> 中加入 */
+@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+SC:wght@400;500;700&display=swap');
+
+/* CSS 中 */
+font-family: "Noto Sans SC", system-ui, -apple-system, "Microsoft YaHei", "PingFang SC", sans-serif;
+```
+> 这是唯一允许的外部 CDN 依赖。如果 Google Fonts 不可用，页面仍可正常显示。
+
+## 页面结构（依已完成的阶段动态呈现）
+
+```
+┌──────────────────────────────────────────────────────────────┐
+│  Hero 区块（产品名称、一句话描述、执行模式、产出对象、日期）       │
+├──────────────────────────────────────────────────────────────┤
+│  目录导航（Sticky，只显示已完成的区块）                          │
+├──────────────────────────────────────────────────────────────┤
+│  🧭 策略层区块（若有执行）                                       │
+│     ├─ Strategy Blocks 层级图                                  │
+│     ├─ Rumelt 好策略内核（诊断/方针/移动）                       │
+│     └─ Shreyas 三层次产品工作                                   │
+│  ✅ 机会评估区块（若有执行）                                     │
+│  🔍 Discovery 区块（若有执行）                                   │
+│     ├─ Persona Table（卡片式表格）                              │
+│     ├─ Persona 卡片（每人一张）                                  │
+│     ├─ JTBD 分析表（四种类型）                                   │
+│     ├─ Opportunity Solution Tree（视觉化树状）                   │
+│     └─ User Journey Map（概览表 + 手风琴详述）                  │
+│  🎯 Define 区块（若有执行）                                      │
+│     ├─ 痛点汇整表                                               │
+│     ├─ April Dunford 定位框架卡片                               │
+│     ├─ HMW 问题卡片（含 JTBD 类型标签）                          │
+│     └─ 机会评估表（机会成本视角标注）                            │
+│  💡 Develop 区块（若有执行）                                     │
+│     ├─ PR-FAQ 卡片（模拟新闻稿格式）                             │
+│     ├─ 解法发想（三栏平行方案卡片）                              │
+│     ├─ Pre-mortem 风险表（高/中风险色彩标示）                    │
+│     ├─ GEM 矩阵 + Impact/Effort 四象限图                        │
+│     ├─ RICE 优先排序表（若有执行）                               │
+│     ├─ User Story 表（若有执行）                                 │
+│     └─ MVP 范围（三栏卡片 + Not Doing List）                    │
+│  🚀 Deliver 区块（若有执行）                                     │
+│     ├─ Aha Moment 定义卡片（醒目呈现）                          │
+│     ├─ North Star Metric 卡片                                   │
+│     ├─ 三层讯号指标表                                           │
+│     ├─ PMF 等级判定（四级框架视觉化 + 目前位置标记）              │
+│     ├─ GTM 策略（渠道选择 + 初始 100 位用户计划，若有执行）      │
+│     ├─ 商业模式与定价（收费模式 + 定价策略，若有执行）            │
+│     ├─ 假设验证计划表（若有执行）                               │
+│     └─ 产品规格摘要（三区块结构：决策摘要 / 执行边界 / 深度参考）│
+│  ⭐ 最佳切入点分析（完整逻辑链视觉化）                            │
+├──────────────────────────────────────────────────────────────┤
+│  页尾：产出日期 + 执行模式 + 框架来源说明                        │
+└──────────────────────────────────────────────────────────────┘
+```
+
+## 各区块设计细节
+
+**表格样式：** 斑马纹、深色表头、圆角、Hover 高亮
+
+**Persona 卡片：** 每个 Persona 独立一张，痛点用红色左边框，JTBD 用蓝色/紫色色块强调
+
+**Opportunity Solution Tree：** 用 CSS 或轻量 SVG 绘制树状结构，清楚呈现目标→机会→解法的层级关系
+
+**PMF 等级图：** 用进度条或步骤图呈现四个等级，标注用户目前所在位置
+
+**PR-FAQ 卡片：** 模拟新闻稿格式，有标题、副标题、引言，视觉上像真实文件
+
+**Pre-mortem 风险表：** 高风险项目用红色警示，中风险用黄色
+
+**最佳切入点逻辑链：** 视觉化完整推导链，每个节点一张小卡片，箭头连接
+
+## 互动效果
+
+- `scroll-behavior: smooth` — 目录点击平滑滚动
+- Intersection Observer — 滚动时目录高亮当前区块
+- 卡片 hover 微微上浮（`transform: translateY(-2px)` + `transition`）
+- 手风琴展开/收合（User Journey Map 各阶段，`<details>/<summary>`）
+- `@media print` — 打印时隐藏互动元素、确保表格不被截断
+
+## 注意事项
+
+- 所有 CSS 和 JS 内嵌在 HTML 中，除 Google Fonts CDN 载入 Noto Sans SC 外不依赖任何外部资源
+- 如果某个阶段没有完成，不要放空白区块，直接跳过
+- 页面 Hero 区块标明「执行模式」和「产出对象」，让阅读者一眼看到这份文件的定位
+- 页面总长度可能很长，目录导航很重要，确保使用者能快速跳转
+
+## 框架来源与延伸学习（放在页尾）
+
+| 思想家 | 核心贡献 | 出处 |
+|--------|---------|------|
+| Teresa Torres | Continuous Discovery、Opportunity Solution Tree | Lenny's Podcast + 《Continuous Discovery Habits》 |
+| Shreyas Doshi | LNO Framework、Pre-mortem、三层次产品工作、机会成本思维 | Lenny's Podcast Ep.3 |
+| Gibson Biddle | DHM Model、GEM Prioritization | Lenny's Podcast |
+| April Dunford | Positioning Framework | Lenny's Podcast + 《Obviously Awesome》 |
+| Todd Jackson | 四级 PMF 框架、Four P's | Lenny's Podcast（First Round Capital） |
+| Richard Rumelt | Good Strategy / Bad Strategy 好策略内核 | Lenny's Podcast + 《Good Strategy Bad Strategy》 |
+| Marty Cagan | Empowered Teams、Product Discovery | Lenny's Podcast + 《Inspired》《Empowered》 |
+| Chandra Janakiraman | Strategy Blocks | Lenny's Newsletter（Headspace / Meta） |
+| Clayton Christensen | Jobs to Be Done | 《Competing Against Luck》 |
+| Amazon | Working Backwards / PR-FAQ | 《Working Backwards》 |
+| Sean Ellis | Sean Ellis Score、ICE Scoring | 《Hacking Growth》 |
+| Lenny Rachitsky | Shape / Ship / Synchronize、North Star 思维 | Lenny's Newsletter + Podcast |

package/i18n/zh-CN/references/07a-handoff-core.md

@@ -0,0 +1,152 @@
+# 开发衔接 — 核心交接包
+
+> 当使用者说「进入开发」「产出开发交接包」「帮我建专案」「接到 Claude Code」时触发。
+> 读取此文件，整合整个产品规划流程的产出，生成可直接在 Claude Code CLI 中使用的开发交接包。
+
+## 环境限制与衔接策略
+
+**关键事实：Claude Chat / Cowork 和 Claude Code 是独立的运行环境，无法从 Chat 内直接启动 Claude Code。**
+
+因此衔接策略是：**产出结构化的开发交接包（一组文件）**，使用者下载后放入专案数据夹，在 Claude Code 中一句话即可启动整个开发流程。
+
+衔接方式视使用者环境而定：
+
+| 使用者环境 | 衔接方式 |
+|-----------|---------|
+| **Claude Chat（Web/App）** | 产出 zip 档供下载，使用者解压到专案目录后开启 Claude Code |
+| **Claude Cowork（Desktop）** | 同上，但可直接将文件写入使用者指定的本地路径 |
+| **已在 Claude Code 中** | 直接在专案目录中建立所有文件（此情境下此 skill 多半由 CLAUDE.md 引用） |
+
+---
+
+## 开发交接包组成
+
+产出以下文件组合，所有文件放在专案根目录：
+
+```
+[project-name]/
+├── .gitignore             # 版控排除清单（.env、secrets、进度档等，模板见 references/07c-architecture-setup.md）
+├── CLAUDE.md              # Claude Code 的专案记忆档：产品上下文 + 开发规范
+├── TASKS.md               # 功能拆解 + Phase 分期 + 逐 Task 验收标准
+├── TICKETS.md             # 开票内容：每张票的标题、描述、验收标准，PM 可直接开票
+├── docs/
+│   ├── PRD.md             # 完整 PRD（从 04-develop.md 产出格式整合）
+│   ├── ARCHITECTURE.md    # 技术架构：目录结构 + DB schema + API endpoints + 安全架构
+│   └── PRODUCT-SPEC.md    # 产品规格摘要（从 05-deliver.md → 4.6 整合）
+└── scripts/
+    └── setup.sh           # 一键初始化脚本（建立目录 + 安装 dependencies）
+```
+
+---
+
+## 📄 CLAUDE.md 模板
+
+CLAUDE.md 是 Claude Code 的专案记忆档，Claude Code 每次启动时会自动读取。必须包含：
+
+```markdown
+# [产品名称] — 专案指引
+
+## 产品上下文
+
+**一句话描述**：[PR-FAQ 标题]
+**目标用户**：[Persona 一句话描述]
+**核心 JTBD**：[Target Customer] 想要在 [Job Context] 完成 [Job]
+**Aha Moment**：当用户完成 [行为]，他们体验到核心价值
+**北极星指标**：[指标名称 + 定义]
+
+## 技术栈
+
+- **前端**：[框架 + 版本]
+- **后端**：[框架 + 版本]
+- **数据库**：[类型 + 版本]
+- **部署**：[平台]
+- **套件管理**：[工具]
+
+## 开发规范
+
+- 使用 [语言] 开发
+- 遵循 [风格指南/lint 规则]
+- commit message 格式：`[type]: [description]`（type: feat / fix / refactor / docs / test）
+- 分支策略：[main / develop / feature-xxx]
+- 每个功能必须有对应的 User Story 编号（见 TASKS.md）
+
+## MVP 边界
+
+**必须有（P0）**：
+- [功能 1]
+- [功能 2]
+- [功能 3]
+
+**明确不做**：
+- [排除项 1] — 原因：[理由]
+- [排除项 2] — 原因：[理由]
+
+## 关键决策记录
+
+| 决策 | 选择 | 理由 | 日期 |
+|------|------|------|------|
+| [例：数据库选择] | [PostgreSQL] | [需要关联查询 + JSON 支持] | [日期] |
+
+## 风险警示（来自 Pre-mortem）
+
+- ⚠️ [风险 1]：[预防措施]
+- ⚠️ [风险 2]：[预防措施]
+
+## 安全性备注
+
+> 完整安全性检查清单见 `references/08-security-checklist.md`，以下为本产品的关键安全性决策：
+
+- 认证方式：[JWT / Session / OAuth]
+- CORS 政策：[允许的 Origins]
+- Rate Limiting：[策略摘要]
+- 敏感数据：[处理方式]
+
+## 开发流程
+
+请依照 `TASKS.md` 的 Phase 顺序逐步执行。每完成一个 Phase：
+1. 确认所有 Task 的验收标准都通过
+2. 询问使用者是否要进入下一个 Phase
+3. 如果遇到架构问题，参考 `docs/ARCHITECTURE.md`
+```
+
+---
+
+## 技术栈确认流程
+
+产出开发交接包前，必须确认技术栈。如果使用者没有指定，依以下顺序询问：
+
+### 必问（影响所有产出）
+
+```
+1. 这是什么类型的应用？
+   □ Web App（浏览器）
+   □ Mobile App（iOS / Android / 跨平台）
+   □ Desktop App
+   □ API / Backend Service
+   □ CLI 工具
+   □ 其他
+
+2. 你有偏好的技术栈吗？
+   （如果没有，我会根据产品特性推荐）
+```
+
+### 推荐逻辑（使用者没有指定时）
+
+| 应用类型 | 推荐技术栈 | 推荐理由 |
+|---------|-----------|---------|
+| Web App（MVP 快速验证） | Next.js + Tailwind + Supabase | 全端一体、部署简单、内建 Auth |
+| Web App（复杂后端逻辑） | React + Node.js/Express + PostgreSQL | 灵活性高、生态系成熟 |
+| Web App（Python 团队） | React + FastAPI/Django + PostgreSQL | Python 生态系、Django 内建 Admin |
+| Mobile App（跨平台） | React Native / Flutter | 单一 Codebase 覆盖双平台 |
+| API Service | FastAPI / Express / Go | 轻量、高效能 |
+
+> Claude 推荐时应说明理由，并提醒使用者可以覆盖推荐。
+
+### 选填（根据产品需求追问）
+
+```
+3. 需要用户认证吗？（影响 Auth 方案选择）
+4. 有即时性需求吗？（WebSocket / SSE）
+5. 需要文件上传/处理吗？（影响 Storage 选择）
+6. 预计部署在哪里？（Vercel / Railway / AWS / 自建）
+```