solo-validate

/validate

端到端验证一个创业想法：搜索知识库、进行 Manifest 一致性检查、执行 S.E.E.D. 利基检查、进行 Devil's Advocate 反向推演、开展 STREAM 6 层分析、选择技术栈、生成 PRD。

理念： 验证应当诚实，而非一味乐观。与其花 3 个月打造一个糟糕的想法，不如在 5 分钟内否定它。目标是真相，而非鼓励。

MCP 工具（如可用）

如果有可用的 MCP 工具，优先使用它们，而不是 CLI：

• kb_search(query, n_results) — 搜索知识库中的相关文档
• project_info() — 列出带有技术栈的活跃项目
• web_search(query) — 搜索失败的创业公司和竞争对手案例

如果 MCP 工具不可用，则回退到 Grep/Glob/WebSearch。

步骤

1. 解析想法，从 $ARGUMENTS 中提取。如果为空，询问用户想验证什么想法。

2. 搜索相关知识： 如果 MCP kb_search 工具可用，直接使用：

   • kb_search(query="<idea keywords>", n_results=5) 否则在本地搜索：
   • 在整个项目和知识库的 .md 文件中 Grep 搜索相关关键词 总结找到的相关文档（已有想法、框架、机会）。

3. 深入研究（可选）： 检查该想法是否有对应的 research.md（在 docs/ 或当前工作目录中查找）。

   • 如果存在：阅读内容，并利用其中的发现为 STREAM 分析和 PRD 填充提供依据（竞争对手、痛点、市场规模）。
   • 如果不存在：询问用户是否想先进行深入研究。如果想，告诉他们运行 /research <idea>，然后再回来。如果不想，则继续，无需深入研究。

4. Manifest 一致性检查（严格执行）：

   查阅 references/manifest-checklist.md（随此技能附带），了解 9 项原则和 6 条危险信号的完整清单。逐项检查想法是否符合每一条。这不是走过场——违反 Manifest 原则是一个软性否决信号。

   对每项原则进行评估：符合还是违反？如果违反，指出具体原则。

   关键原则（详情见清单）：

   1. 隐私优先 / 离线优先
   2. 一种痛点 -> 一个功能 -> 发布
   3. AI 是基础，而非功能
   4. 速度优先于完美（数天内完成 MVP）
   5. 反脆弱架构
   6. 盈利但不过度增长
   7. 反对剥削
   8. 订阅疲劳
   9. 创作者，而非机器人

   评分： 0 项违反 = 完美，1-2 项 = 谨慎，3 项以上 = 强烈的 KILL 信号。

   务必诚实。 如果想法与原则冲突，就明确指出。不要强行论证其一致性。

5. S.E.E.D. 利基检查（深入分析前快速进行）：

   从四个维度为想法评分：

   • S — 可搜索性： 能否获得好的排名？论坛/Reddit 是否位列前 10？是否缺少新兴巨头？是否没有视频结果拦截？
   • E — 证据： 是否有真实痛点的真实引述/URL？还是仅凭假设？
   • E — 易实现性： 能否基于现有技术栈在 1-2 天内完成 MVP？是否无需繁重依赖？
   • D — 需求： 是否存在长尾关键词？是否有明确的变现路径？

   否决信号（出现任意一项就立即停止）：

   • 搜索结果页前 10 名由媒体巨头或百科全书占据
   • 已有新近的竞争内容（发布于 <60 天前）对该主题进行了充分覆盖
   • 没有真实用户痛点的证据（只有创始人的假设）
   • 即便使用最合适的技术栈，MVP 也需要超过 1 周才能完成

   如果触发任一否决信号 → 建议 KILL 并说明原因。不要继续进行 STREAM 分析。

6. Devil's Advocate（反向推演）：

   “反过来问：怎样才能确保失败？”——STREAM 第 3 层（反向推演）

   此步骤为必选——在给出正面评分前，主动尝试否定这个想法。目标是找出不该开发它的理由。 6a. 反向推演 — 5 种失败方式： 列出这个想法可能失败的 5 种具体、明确的方式。不要写泛泛的风险（如“竞争”），而要提供具体情景和证据：

   • 哪个具体竞争对手可能击溃它？（名称、融资、策略）
   • 哪种用户行为会让它无法成立？（流失数据、付费意愿）
   • 哪种监管／法律事件会导致它夭折？（具体法律、判例）
   • 哪种技术限制会阻碍它？（延迟、成本、准确性）
   • 哪种市场动态会让这个“机会”变成海市蜃楼？

   6b. 已倒闭初创公司搜索： 搜索尝试过类似方向但失败或转型的初创公司：

   • WebSearch："<idea category>" startup failed OR pivoted OR shut down
   • WebSearch："<competitor>" pivot OR layoffs OR shutdown
   • 如果找到相关公司：是什么导致它们失败？这里是否也存在同样的风险？

   6c. 单位经济效益压力测试（如果 research.md 存在）： 使用悲观假设重新计算单位经济效益：

   指标	乐观	实际	悲观
   月流失率	10%	30-40%（行业数据）	50%+（第一年）
   平均生命周期	10 个月	2.5-3 个月	1.5 个月
   LTV	(价格 × 10)	(价格 × 2.5)	(价格 × 1.5)
   CAC	<$20	$30-50	$50-80
   LTV:CAC	>3:1	~1:1	<1:1（无利可图）

   如果悲观情景下的 LTV:CAC < 1 → 标记为重大风险。

   6d. “空白市场”测试： 如果分析发现了“空白”细分市场或定价缺口，请询问：

   • 它为什么是空白？ 这是机会还是坟场？
   • 搜索曾尝试过这种确切定位但失败的公司
   • 这个细分市场空白，是否因为该价格点没有需求？

   6e. 诚实面对宣言冲突： 重新检查第 4 步的发现。针对发现的每项宣言违背，明确说明冲突：“这需要 X，而这违反了原则 Y，因为 Z。” 不要为冲突找借口。是否继续由用户决定，而非此技能。

7. STREAM 分析： 从全部 6 个层面分析这个想法。

   查阅 references/stream-layers.md（随此技能附带），了解完整的 6 层框架及各层问题。

   对每一层，都要给出正面和负面评估。使用框架中的实际问题：

   • 第 1 层（范围）： 地图≠疆域、简洁性、边界 — 哪些假设尚未得到验证？
   • 第 2 层（时间）： 熵、林迪效应 — 5 年后它还会存在吗？
   • 第 3 层（路径）： 反向推演（采用“魔鬼代言人”调查结果）、二阶效应 — 效应的效应是什么？
   • 第 4 层（风险）： 不对称性、反脆弱性 — 使用悲观数据评估实际风险／回报
   • 第 5 层（受众）： 声誉、网络 — 是存入还是取出？
   • 第 6 层（元层面）： 生命有限、平衡 — 值得投入有限的时间吗？是否符合使命？

   评分规则：

   • 每层评分 1-10
   • 如果“魔鬼代言人”分析发现重大问题，必须降低受影响层面的评分
   • 如果宣言契合度存在违背，必须降低第 6 层（元层面）的评分
   • 最终得分 = 加权平均（元层面和风险层面的权重为 1.5 倍）

8. 滩头细分市场（首个目标市场）：

   根据研究中的用户画像（如有）或想法描述，定义滩头市场：

   • 具体是谁？ — 精确的细分群体，而非“所有人”（例如，“月收入 3-8K 美元的自由职业设计师”，而不是“自由职业者”）
   • 为什么先选他们？ — 容易触达、痛点强烈、愿意付费，并且能通过特定渠道触达
   • 通过什么渠道触达他们？ — 一个具体渠道（subreddit、社群、通讯）
   • 接下来拓展哪个相邻细分市场？ — 赢得滩头市场后，向哪里拓展

   这将用于 PRD 的 ICP 部分和 /launch GTM 策略。

9. 定价模型（2-3 个选项及理由）：

   根据竞争对手定价（来自 research.md）和宣言原则（订阅疲劳确实存在——尽可能优先考虑一次性购买或诚实透明的定价）：

   模型	价格	推理依据	与宣言的契合度
   一次性付费	$X	无运行成本 → 无需重复收费	最契合（无锁定）
   免费增值	免费 / $X/mo	服务端成本足以证明订阅费合理	可以接受，前提是诚实透明
   按使用量付费	每 Y $X	按实际使用量付费	很契合（透明）

   宣言（templates/principles/manifest.md）中的规则：

   • 如果运行它不需要成本，就应该免费
   • 尽可能选择一次性购买，而非订阅
   • 构建与锁定相反的产品：工具归用户所有，数据由用户掌控
   • 不使用暗黑模式，不设置人为限制来强迫用户升级

   选择推荐的模式并说明原因。将其写入 PRD。

10. 技术栈选择： 根据研究数据自动检测，然后确认或询问。

自动检测规则（来自 research.md 的 product_type 字段或创意关键词）：

• product_type: ios → ios-swift
• product_type: android → kotlin-android
• product_type: web + 提及 AI/ML → nextjs-supabase（或 nextjs-ai-agents）
• product_type: web + 落地页/静态网站 → astro-static
• product_type: web + 内容网站，且部分页面需要 SSR（CDN 数据、文字稿、动态内容）→ astro-hybrid
• product_type: web（默认）→ nextjs-supabase
• product_type: api → python-api
• product_type: cli + Python 关键词 → python-ml
• product_type: cli + JS/TS 关键词 → nextjs-supabase（单体仓库）
• 边缘计算/无服务器关键词 → cloudflare-workers

如果自动检测的置信度较高，说明选择并继续。 如果存在歧义（例如，可能是 Web 或移动应用），通过 AskUserQuestion 询问，并提供 2-3 个首选项。 如果 MCP project_info 可用，将用户现有的技术栈作为参考展示。

11. 生成 PRD： 在当前项目目录下创建 PRD 文档 docs/prd.md。根据创意生成 kebab-case 项目名称。

PRD 必须通过完成定义：

• 问题陈述 ≥ 30 个词（谁在何时、为何遭遇问题，以及为何是现在）
• ICP + JTBD——目标细分群体 + 2-3 个待完成任务
• 3-5 项功能，每项都有可衡量的验收标准
• 3-5 个 KPI，注明单位（每日/每周）和目标值
• 为每个 KPI 设定扼杀/迭代/扩展阈值
• 3-5 项风险及其缓解计划
• 诚实评估部分（来自唱反调步骤）
• 单位经济效益：乐观和悲观两种情况（两列均须填写）
• 失败创业公司的先例（谁尝试过这个方向并失败了？）
• 与宣言的冲突（明确列出违反的原则）
• 滩头细分市场——首先面向谁、为何选择他们、如何触达
• 定价模式——推荐选项及其与宣言的契合度检查
• 包含关键软件包的技术栈
• 架构原则（SOLID、DRY、KISS、架构优先定义 Schema）
• 证据优先——数字/论断须附来源 URL（如有 research.md，则取自其中）

12. 输出摘要：
    • 创意名称和一句话描述
    • S.E.E.D. 评分（S/E/E/D 各评为低/中/高）
    • 与宣言的契合度（符合 X/9 项原则，列出违反项）
    • 两项评分：
      • 乐观评分（0-10）：基于最佳情况的假设
      • 现实评分（0-10）：基于悲观的单位经济效益、真实流失率和有资金支持的竞争对手
    • 唱反调者的首要发现（最有力的一条不应该构建此产品的理由）
    • 关键风险和关键优势
    • 生成的 PRD 路径
    • “如果我对……的判断有误”——指出唯一一个一旦判断错误就会改变结论的假设
    • 建议的下一步行动（以下选一项）：
      • /research <idea>——如果证据不足，先收集数据
      • /scaffold <name> <stack>——如果现实评分 ≥ 7，就开始构建
      • 虚假入口测试——如果现实评分为 5-7，在编写代码前花 $20 制作一个简易落地页
      • 扼杀——如果现实评分 < 5 或触发扼杀标志
      • 转向——如果创意有价值，但当前方向行不通（提出具体的转向方案）

重要

• 不要跳过 Devil's Advocate 步骤（步骤 6）。这是强制步骤。
• 不要跳过对 references/manifest-checklist.md 和 references/stream-layers.md 的阅读（随此技能附带）。它们包含实际的检查清单。
• 质量和诚实比速度更重要。请在步骤 4、6 和 7 上多花些时间。
• 建议 KILL 是合理且有价值的结果，可以避免数月的努力白费。

适用场景

• 在着手构建任何非简单项目之前
• 在运行 /research 或 /swarm 后，为 PRD 评分并生成 PRD
• 在多个创意中做选择时（分别运行并比较现实的评分）
• 朋友向你征求创业反馈时（诚实，不要只说好听的）

常见问题

触发了 S.E.E.D. 终止标记

原因： 创意未通过基本的利基可行性评估（SERP 被主导、缺乏证据、MVP 过于复杂）。 解决方法： 这是有意设计的——终止标记可以节省时间。可以考虑调整创意方向，或运行 /research 获取更深入的证据。

找不到 research.md

原因： 跳过了 /research 步骤。 解决方法： 技能会询问你是否想先进行研究。要生成更可靠的 PRD，请在运行 /validate 前先运行 /research <idea>。

技术栈自动检测错误

原因： 产品类型不明确（可能是 Web 或移动应用）。 解决方法： 如果存在歧义，技能会通过 AskUserQuestion 询问。请在创意描述中明确指定产品类型。

评分似乎过高

原因： 确认偏误——找到了支持该创意的证据后就停止查找了。 解决方法： Devil's Advocate 步骤现为强制步骤。如果跳过了该步骤，评分就无效。请通过完整的逆向分析重新运行。

为 Manifest 冲突找借口

原因： 创意很吸引人，但与原则冲突。 解决方法： 明确说明冲突。“这违反了 X，因为 Y”比保持沉默更有用。是否继续由用户决定，而不是由技能决定。