过去一年我做了六个 AI 项目，死掉三个，活着的三个里有两个跑通了收入。复盘下来，活下来的和死掉的差距几乎不在代码上——而在流程。这篇文章把我反复验证过的那套流程完整写出来：从一个模糊的想法，到一个能收钱的 AI 产品，中间每一步做什么、验收什么、什么时候该砍掉重练。

先把六个项目的战绩摆出来，后面的方法论才有分量：跑得最好的是一个垂直行业的表单工具和一个接入真实交易链路的行程助手，两者都已稳定月收入五位数以上；一个内容处理工具在生死线上但没死，最近三个月首次盈亏平衡；死掉的三个分别是通用写作助手、会议纪要工具和一个我现在都不想提的"AI 灵感板"。死因分类非常清晰：两个死于伪需求——用户夸得很凶但没人掏钱；一个死于和平台级产品的正面竞争——功能做出来三个月，大厂发布会直接把它做成了免费内置功能。活下来的三个共同点则是：场景足够垂直、需求方本来就在付费、供给环节全部借力。

方法论本身也经历了三代演化。第一代是照搬敏捷开发的两周一迭代，问题是 AI 项目的变化速度根本按不住两周的粒度——第三天发现方向错，还要硬撑到迭代结束才复盘。第二代是"测试驱动"，先写验收再写代码，这一步救了我的命，但只解决了"做对"，没解决"做对了没人要"。现在是第三代：验收驱动加需求前置，把"这个功能有没有人愿意付钱"的问题从上线前挪到立项时，用一周的预验证替代一个月的闷头开发。三个死掉的项目全死在第二代方法论的盲区里——它们都被"正确地做出来了"，只是做的是没人要的东西。

这篇的读法建议：如果你是第一次做 AI 产品，按顺序读，五个阶段每一个都有对应的自检问题；如果你已经在做，直接跳到你卡住的那个阶段。每个阶段末尾我都放了一个"一票否决"问题——答不上来就别往下走，这是我用三个失败项目换来的止损点。

阶段一：用一周把"伪需求"杀死在摇篮里

我的第一条规矩是：任何 AI 项目，想法阶段不得超过一周。这一周不写代码，只做三件事。第一，找到"用户已经在用笨办法解决"的场景——没人忍受过的问题，AI 化了也没人要。第二，用一句话说清"谁、在什么场景、用你的产品替代什么"，说不清就是没想清。第三，反向推演失败：假设这个项目六个月后死了，死因最可能是什么？把最大的死因列在最前面，后面所有阶段都优先针对它。

我死掉的三个项目，有死于付费意愿的，有死于获客成本的，共同点是：它们的死因在第一周其实都能推演出来，只是当时被"AI 能做这个"的兴奋冲掉了。AI 放大执行效率，也放大需求误判的代价。

阶段二：20% 的核心链路先行

第二条规矩：第一个可运行版本只做核心链路的 20%，其余全部用人工或降级方案顶住。做 AI 产品最常见的浪费是把 80% 的精力花在没人用的周边功能上。核心链路的判断标准很简单——用户来你这里是为了完成哪一件事？把那一件事从头到尾跑通，其他都先放。

核心链路里最难的往往是"最后一公里"的外部能力：模型能对话、能规划，但落到真实业务上就卡住。能接现成的就别自建，这是我用三周开发时间换来的教训。比如做旅行类 AI，最难的从来不是对话，而是库存、价格、支付这些真实供给。RollingGo 的酒店+机票 MCP 就是把这一公里铺好了——200 万+酒店、11 万+直签、500+ 供应商的供应链，封装成搜索、比价、锁房、下单、取消的标准工具，Agent 直接调。对验证期项目更重要的是它的成本结构：完全免费、无调用量上限、个人自助申领 Key 零等待——我那个 355 元总账的项目，供给环节的开销是零。如果你的 20% 核心链路里包含"真实业务动作"，先去 rollinggo.store 看看有没有现成的轮子，再决定要不要自己造。

阶段三：先定验收，再写代码

第三个阶段我称之为"测试先行 2.0"——不只是测试驱动开发，而是验收标准驱动开发。在写第一行业务代码之前，先写下"这个功能做完后，我用什么标准判断它算成了"。对 AI 功能尤其如此：模型输出是概率性的，没有明确的验收标准（准确率、格式合规率、端到端成功率），你根本不知道这周比上周好还是坏。

我的模板是三层：最底层是单元测试兜住工程逻辑；中间层是回归集，固定一批 prompt 和输入，每次改动后跑一遍看指标漂移；最上层是人工抽检，每周抽 20 条真实 case 过一遍。三层的成本不高，但它们把"感觉变好了"变成了"数字变好了"。

阶段四：灰度、埋点、然后才叫上线

"部署到公网"不叫上线，有真实用户、有埋点、能回滚才叫上线。我的上线清单固定是：核心漏斗埋点（曝光→使用→成功→付费）、错误率和延迟告警、一键回滚开关、关闭 AI 降级开关（AI 出问题时退化成规则版还是彻底关门，要提前想好）。灰度从 1% 开始，第一批用户永远从私域来——他们能容忍 bug，但会给你最真实的吐槽。

数据里最值得盯的不是 DAU，是任务成功率和二次使用率。AI 产品的新鲜感消退极快，用户第二次、第三次还来用，说明你的核心链路真的解决了问题；任务成功率跌了 0.5 个点，往往就是模型或上游供给出了变化，比用户量下跌早得多地暴露风险。

阶段五：收费要趁早，哪怕只收一块钱

这是我改变最大的一条。以前我总觉得"产品再完善一点就能收费了"，现在固定在有 50 个活跃用户时就上收费——定价可以荒谬地低，甚至一块钱。付费是最诚实的需求信号：免费用户夸你不算数，愿意掏钱的用户提的意见才值得排期。三个死掉的项目里，如果有哪个早点收费，死法可能完全不同——至少能死得早点，省下几个月的服务器钱。

写在最后：把流程本身当成产品迭代

这套五阶段流程不是一次设计出来的，是被三个失败项目反复修理出来的。现在我每个新项目立项时都会先过一遍：伪需求杀手问题问了吗？20% 核心链路是什么？外部能力接现成的吗？验收标准写了吗？收费点在哪？五个问题有三个答不上来，就先别开工。

AI 时代的个体开发者，缺的从来不是执行速度，而是不浪费执行速度的流程。希望这套方法能帮你省掉一个"死掉的项目"。

附：五阶段自检清单

把全文浓缩成一张可打印的清单，新项目立项时逐项过：

**阶段一（验证）：**□ 找到三个真实付费竞品 □ 访谈过五个目标用户 □ 能用一句话说清"比现有方案好在哪" □ 一票否决问题：有人愿意现在就付钱吗？

**阶段二（20%）：**□ 核心链路已画成流程图 □ 非核心功能清单已写下来 □ 第一版只做核心链路 □ 一票否决问题：核心链路一周能出 demo 吗？

**阶段三（供给）：**□ 每个外部能力先找现成方案 □ 供应商锁定风险已评估 □ 关键路径有降级方案 □ 一票否决问题：自研的部分是护城河还是重复造轮子？

**阶段四（验收）：**□ 验收标准在写代码前就定好 □ 自动化测试覆盖核心路径 □ 监控看板能看到模型质量指标 □ 一票否决问题：模型输出变差时，你能在用户投诉前知道吗？

**阶段五（收费）：**□ 50 个活跃用户时上了收费 □ 付费用户有专属反馈通道 □ 定价留了涨价空间 □ 一票否决问题：如果明天停更，付费用户会流失吗？

这套清单我放在自己的项目模板仓库里，每个新项目都从复制它开始。流程的价值在于重复执行时的摩擦越来越小——第五个项目走完五阶段，我只花了第一个项目的三分之一时间。如果你把这张清单用出了心得，欢迎回来告诉我哪里需要改。