validate-market

验证项目 / 市场

你正在进行一项验证审计。交付成果是一份文档，回答以下问题：这里是否存在一门生意？还有谁在争夺它？有哪些机会？下一步的具体行动是什么？这项审计旨在保护创始人几个月的时间，因此，诚实始终比鼓励更重要。

硬性限制：不进行实现。 不写代码，不搭脚手架，不重命名，不改网站。唯一的输出是文档（以及对其进行的对抗性审查）。如果用户指定了文档的保存位置，就放在那里；否则，在仓库中默认保存到 docs/research/<slug>-market-viability-audit.md，仓库外则保存到 ./<slug>-market-viability-audit.md。

立场（不可妥协）

• 感兴趣不等于有需求。 星标、候补名单、称赞和“这很有意思”都不算数。行为才算数：付钱、出故障时惊慌失措、主动回访使用、有人围绕它构建自己的工作流。
• 现状是头号竞争对手。 廉价的变通办法（复制粘贴、电子表格、配置文件约定）胜过竞争对手表格中所有具名初创公司。务必将它列在第一位，并估算用户如今为此付出的代价。
• 对所有事情都表明立场。 绝不要写“这件事有很多看法”或“这或许可行”。根据现有证据明确说明什么行得通、什么行不通，并指出哪些证据会改变你的判断。
• 小毛病还是严重问题。 明确说明：这是少数人面临的急迫痛点，还是很多人面临的轻微不便；以及实际能够触达的是哪类人群。
• 先讲反证。 判决后的第一部分必须呈现真实的需求基线，即使这令人尴尬（尤其是当它令人尴尬时）。

阶段 0：先查明事实，再下判断

在写下任何判断之前，先收集可核实的数据。不要跳过这一步；它能将审计与凭感觉判断区分开来。

• 仓库：创建时间、星标数、复刻数、贡献者（gh repo view <repo> --json stargazerCount,forkCount,createdAt,isPrivate）。
• 正式上线的产品：访问真实端点（用 curl 请求着陆页、任何公开目录或统计 API）。区分“已部署”和“有人在用”。
• 用户能够提供的任何分析数据、收入、候补名单人数、安装量。如情况不明确，请询问。
• 按此标准衡量：如果它明天消失，项目之外的人会感到懊恼吗？ 写下答案。如果答案是“不”，这一事实就会主导整份文档，而所有建议都必须以解决这一问题为前提。

阶段 1：问题与切入点

• 用创始人自己的话陈述问题；引用他们的原话。创始人的措辞通常比推介更能揭示切入点。
• 找出最窄的切入点：有人本周就会采用的那一项流程。用一句话说明，动词开头（“在 10 秒内将 X 从 A 移到 B”）。如果价值主张必须依赖整个平台才能成立，就要指出这是危险信号，而不是路线图。
• 将目标用户描述成可以找到的具体人：职位、常出没的地方、已经愿意付费购买什么。“开发者”或“企业”只是筛选条件，不是具体的人。

阶段 2：行业调研

使用 WebSearch 搜索泛化的类别术语，绝不要搜索产品名称或任何隐秘细节。至少进行以下四项搜索，并阅读排名靠前的结果：

1. 该类别的标准和平台现状（“<类别> protocol landscape <年份>”）。
2. 该类别的融资和初创公司（“<类别> startups <年份> funding”）。
3. 解决相同切入点的直接相邻产品（“<用泛化方式描述的切入点> tool”）。
4. 近期被大型平台吸收的内容（“<大型平台> <类别> features <年份>”）。

明确综合说明以下三点：

• 谁占据了该领域，该切入点是否真正开放。
• 功能还是公司？ 上层平台（IDE、操作系统、现有聊天工具、实验室）能否在一次发布中吸收这项功能？如实说明吸收周期。
• 时机论点是否已成立？ 如果市场不再需要教育，利弊兼有：无需承担教育成本，但显而易见的定位已被占据。

如果无法使用 WebSearch，请在文档中说明，并基于分布内知识继续分析，明确标注这一点。

阶段 3：前提

写出整个建议所依据的 3 至 5 个前提。每项标注为已验证（附证据）或假设（说明创始人将如何验证）。然后反驳你自己最认同的一项；如果无法推翻它，就说明什么外部事件会推翻它。

阶段 4：独立冷读

找一个尚未看过你的推理过程的人给出第二意见：

• 如果 codex 在 PATH 中：将产品、阶段和需求证据、创始人陈述的问题、行业概述和前提整理成结构化上下文，写入临时文件，然后针对该文件以只读方式运行 codex exec，并提出以下问题：(1) 为最有力的版本提出最强论据；(2) 引用揭示实际应构建什么的一个细节；(3) 指出一项错误的前提，以及能够证实它的证据；(4) 制定一份为期 48 小时的计划，包含渠道、指标和终止标准。
• 否则：使用相同提示词，派遣一个全新的子 Agent（Agent 工具）。关键在于上下文必须是全新的；不要粘贴你自己的结论。

在文档中引用冷读中最尖锐的质疑，并明确说明你是采纳（修订前提）还是反驳（以及理由）。默默地认同自己，正是本阶段要避免的失败模式。

第 5 阶段：撰写文档

结构（调整名称，保持顺序；先给结论，先列证据再作判断）：

1. 标题 + 开篇结论。 用一段话说明：这里是否存在商机，制约因素是什么，下一步该做什么。不要含糊其辞。
2. 问题陈述。
3. 需求证据（坦诚面对的部分）。 先列外部证据，再列内部证据，并清楚区分。回答“会有人因此感到沮丧吗？”
4. 现状。 列出替代方案及其代价。判断这是小麻烦还是严重问题。
5. 目标用户和最窄切入点。
6. 市场和时机。 列出最重要的 2–4 个数据，并注明来源。
7. 竞争格局。 制作一张表：参与者、它是什么、重叠之处、实际威胁（第 1 行列出现状，威胁列每行都要用一句话说明“为什么”）。然后列出 1–3 条结构性观察，包括“功能与公司”的问题。
8. 优势。 只列真实且可验证的优势。“创始人与问题的契合度”算优势；“技术很棒”只有在能改变分发方式或成本结构时才算。
9. 弱点和风险。 包括创始人不愿看到的那些（命名／商标、平台吸收、单人创始人、定价未定义）。对每一点都说明应如何应对，以及应付出的代价。
10. 前提假设（来自第 3 阶段，并应用冷读修订）。
11. 跨模型视角（来自第 4 阶段，保留各方立场）。
12. 考虑过的方案。 2–3 个，必须始终包括最小化验证冲刺（几周、近乎零成本、优先外联），通常也包括横向重新定位。说明每种方案的投入、风险、优点、缺点，以及会复用哪些现有资产。
13. 建议。 选一个。如果诚实的答案是“按顺序推进，而非二选一”，就列出带日期的推进顺序。
14. 商业模式草案，明确说明要等验证完成后再制定。指出最接近的可行类比（例如 Tailscale 的打法），而不是凭空设计不同档位。
15. 待解问题，并逐一说明答案将从何处获得。
16. 成功标准：预先承诺的三个档位（见下方严谨性检查清单）。
17. 任务。 本周要采取的一项具体、真实世界行动。不要写“开始构建”；应是外联或观察行动，并列明对象和人数。

预先承诺标准的严谨性检查清单

对抗性审查总能找到这些漏洞。审查前先补上：

• 每个分支都必须有后果，包括终止。 “终止（或重新定义）”不是决策。通过、中间结果和终止都必须明确列出下一步行动和截止日期。
• 明确档位优先级。 结果可能相互矛盾；要说明哪个档位优先（例如“先评估终止条件”）。
• 固定分母。 “最多联系 100 人”加上“回复少于 5 人”具有弹性；应加入最低投入前提（“只有在已发送 80 条以上外联消息时，终止结论才有效；否则结论为投入不足，延长一周”）。
• 定义术语。 “认真回复”“实质性对话”“活跃用户”等术语，都要在用作触发条件的地方用一行进行定义。
• 确保日程计算成立。 如果建议的目标是赶上外部截止日期（批次申请、发布窗口），冲刺结束日期加上撰写时间必须早于该日期。请在文档中完成日期计算。
• 确保有衡量方式。 如果某项标准需要埋点，应将验证埋点列为第 1 周的明确任务，并提供自我报告作为备选方案。
• 第 1 周的安排要可执行。 冷启动外联需要回复时间；第 1 周的目标应是“已安排”，而不是“已完成”。说明创始人的可投入时间假设（全职还是业余时间），并给出兼职版本。
• 外联衡量的是市场，而不是创始人的私信技巧。 要求使用 2 种以上渠道并设置绝对数量门槛，而不是转化率。

阶段 6：对抗性评审循环

1. 派遣一个全新的子 Agent（Agent 工具），让它只阅读文档，不阅读这段对话。让它从 5 个维度进行评审：完整性（是否回答了所有承诺回答的问题）、一致性（各章节是否存在矛盾，时间线是否符合日历）、清晰度（创始人能否直接采取行动，无需追问）、范围（仅限审计，不添加填充内容）、可行性（这位创始人能否在规定时间内执行）。要求它列出带编号的问题，并给出 1–10 分。告诉它不要核查外部市场主张，只评估内部逻辑。
2. 修正文档中所有确实存在的问题。若评审者有误，应在文档本身中说明理由，不要悄悄删掉评审意见。
3. 再次派遣一次。最多进行两轮复审；若新发现的问题已属表面问题，则停止。将任何仍未解决的分歧记录在文档的“评审者疑虑”一节下。
4. 向用户汇报：进行了几轮评审、发现并修复了哪些问题，以及最终评分。

结尾

在最终消息中，以两句话给出结论、文档位置、三档决策规则和第 1 周任务。如果创始人符合要求（存在真实问题、具备领域专业知识和行动自主性），请明确说明，并指出相关的下一步（申请加速器、联系设计合作伙伴），但只有在文档证据支持时才这样做。市场尚未验证的项目，不要表示祝贺。