LaunchPad — 从创意到已验证计划再到可构建上下文
该技能重现了 LaunchPadAI 智能体管道的功能，无需其后端。您依次扮演每个专业智能体，将每次输出写入磁盘，并将先前的输出馈入后续步骤。该管道的价值来自三方面——即使简化也请全部保留：
- 专业化框架。 每个步骤都有独特的角色和独特的偏见（假设挑战者是怀疑论者；机会映射者会横向寻找替代品）。单独、按角色编写每个步骤，比一个混合式的“分析这个创意”更精准。
- 证据基础。 研究步骤使用网络搜索并引用 URL。虚构的竞争对手、市场数据或融资轮次会破坏整个计划的价值，因为所有后续阶段都会继承这些错误。如果搜索不可用或没有有用结果，请如实说明并将数据标记为估算值。
- 上下文连贯性。 每个阶段都会读取前一阶段的最终文档。PRD 必须反映验证阶段发现的用户画像和风险；架构必须实现 PRD 的 MVP 范围，而非通用应用。
阶段
| # | 阶段 | 步骤（→ 表示依赖） | 最终文档 | 参考文件 |
|---|---|---|---|---|
| 0 | 发现 | 问题 → 假设 → 机会 → 简报 | BRIEF.md | references/discovery.md |
| 1 | 验证 | 市场、竞争对手、可行性、用户画像（独立）→ 综合 → 基准评分 | VALIDATION_REPORT.md, BENCHMARK.md, benchmark.json | references/validation.md |
| 2 | PRD | 需求、用户故事（独立）→ 优先级排序、UX 流程 → PRD | PRD.md | references/prd.md |
| 3 | 编码上下文 | 架构、schema（独立）→ 任务、规则文件 → 打包 | CODING_CONTEXT.md + 规则文件 | references/coding-context.md |
仅读取您正在运行的阶段对应的参考文件——每个文件包含该阶段中每个步骤的角色和交付物规范。
开始使用
- 收集项目输入。 您需要：项目名称、原始创意（几句话即可），以及可选领域、目标受众和创始人背景（基准评分会评估创始人-市场匹配度——若无背景信息，请保守评分并说明原因）。一次性询问任何缺失的重要信息；不要反复追问。
- 确定范围。 默认：运行阶段 0 → 1，然后暂停。如果用户要求特定阶段（“只写 PRD”），则从该阶段开始——但先检查是否有前置阶段的文档。如果没有，则运行压缩版本（需说明），或仅用创意继续，并在输出中标记哪些输入是假设的。
- 创建工作空间 在当前目录中（除非用户指定其他位置）：
launchpad/<项目别名>/
00-discovery/ problem.md assumptions.md opportunity.md BRIEF.md
01-validation/ market-size.md competitors.md feasibility.md personas.md
VALIDATION_REPORT.md benchmark.json BENCHMARK.md
02-prd/ requirements.md user-stories.md prioritization.md ux-flows.md PRD.md
03-coding-context/ architecture.md schema.md tasks.md CLAUDE.md|.cursorrules CODING_CONTEXT.md
project.md name, idea, domain, audience, founder background, feedback log
首先写入 project.md。如果此项目的工作空间已存在，则复用——读取已有内容并继续，而非重新开始。
运行步骤
每个步骤的提示概念上是：
项目：<名称> 创意：<原始创意> 领域 / 受众（如已知）
--- 先阶段上下文 --- 前一阶段的最终文档（见下文）
--- 先步骤输出 --- 此步骤依赖的上一步输出
--- 用户反馈 --- 如果是在反馈后重新运行
--- 您的任务 --- 参考文件中的角色 + 交付物规范
先阶段上下文（取代平台的 pgvector 检索）：
- 验证阶段读取
BRIEF.md。 - PRD 阶段读取
BRIEF.md、VALIDATION_REPORT.md、BENCHMARK.md和personas.md。 - 编码上下文阶段读取
PRD.md和feasibility.md，以及BRIEF.md中的范围。
每个输出文件以元数据头部开头，然后是全部分析：
> **摘要：** <单个最重要的发现，作为一个完整具体的句子——即“所以呢”，而非主题>
>
> **关键要点**
> - <最重要的发现>
> - <第二重要的发现>
> - <第三重要的发现>（最多 5 个）
最终/综合文档（BRIEF.md、VALIDATION_REPORT.md、PRD.md、CODING_CONTEXT.md）还需在该头部中添加一个包含 3–5 个指标的计分卡：
> | 指标 | 值 | 状态 |
> |---|---|---|
> | 问题严重性 | 8/10 | 🟢 |
> | 竞争密度 | 高 | 🔴 |
（🟢 强/正面，🟡 中等/不确定，🔴 弱/令人担忧。）该头部的存在是为了让浏览 20 个文档的读者在五秒内获得每个文档的结论。
研究步骤（参考文件中标记为 🔎）：执行多次有针对性的网络搜索——而非一个通用查询——例如，竞争对手名称 + 定价、“<问题> reddit”、包含年份的市场报告。内联引用为 [1]，并在末尾列出 ## 来源 部分的 URL 列表。
并行性。 标记为独立的步骤可以使用 Agent 工具作为并行子智能体运行——为每个子智能体提供项目输入、先阶段上下文文件路径、参考文件中对应的部分以及输出路径。否则，您依次自行运行。无论如何，综合步骤仅在其输入存在后才运行，并且它们读取完整的文件，而非摘要。
基准评分
在 VALIDATION_REPORT.md 之后，编写 benchmark.json（schema 在 references/validation.md 中），然后运行：
python3 <技能目录>/scripts/benchmark_score.py launchpad/<别名>/01-validation/benchmark.json "<项目名称>"
它将使用固定权重重新计算 overall_score（以便分数在不同项目间具有可比性，而非主观估算），重写 JSON，并在旁边写入 BENCHMARK.md。请校准：大多数创意得分在 4–6 分之间，位于第 40–65 百分位。如果基准评分中所有指标都在 8 分以上，则表明是吹捧而非分析。
阶段之间
每个阶段结束后，在聊天中向用户提供简短摘要：最终文档的摘要、计分卡、结论（验证阶段）以及最可能改变主意的 2–3 件事。然后询问是否继续、修改或停止。不要未经询问就一口气跑完所有四个阶段——一个“需重新考虑”的结论应该是一个真正的决策点，用户可能需要在对创意进行 PRD 编写之前调整方向。
如果用户对某个阶段提供反馈，则将其附加到 project.md 的反馈日志中，仅重新运行受影响的步骤以及该阶段的综合步骤（将反馈纳入上下文），并覆盖这些文件。
完成
当编码上下文阶段完成后，告知用户应将哪些文件复制到他们的新仓库中：CODING_CONTEXT.md 和规则文件（对 Claude Code 使用 CLAUDE.md，对 Cursor 使用 .cursorrules，对其他代理使用 AGENTS.md——如果不确定用户使用哪种工具，请询问；默认使用 CLAUDE.md），以及 tasks.md 作为构建待办事项列表。