PoC、MVP 顺序错了，钱就白烧

拿到一个想法，第一件事就是打开编辑器写代码——AI 编程时代这个冲动更强了：Claude Code 半小时就能给你跑起来一个东西，凭什么还要流程？

因为跑起来和做对是两回事。AI 把"做出来"压缩了 90%，但每个风险该花多少钱回答，一个子儿都没便宜。

我的起手式固定四个动作，每个动作回答一个独立的问题：

动作	回答的问题	交付物	合理耗时
① PoC	能不能做出来？（技术风险）	能跑的验证 + 结论	1-3 天
② 设计	做出来什么样？（体验风险）	可交互的原型	几小时-1 天
③ MVP	有没有人用？（市场风险）	真实用户可用的最精简版	2-8 周
④ 迭代	怎么做得更好？	下一轮，回到①	循环

顺序就是成本的顺序：技术风险最先回答，因为它最便宜；市场风险最后回答，因为它最贵。顺序反了，就是在用最贵的方式回答最便宜的问题。

PoC：先问要不要做，再问怎么做

2026 年的共识：调用成熟模型的成熟能力（标准 RAG、常规对话），技术风险很低，PoC 可以直接跳过——为"Stripe 能不能收款"做 PoC 不叫验证，叫浪费。

但三种情况省不了：准确率敏感（从合同抽数据，不知道模型够不够准）、生僻集成（对接老旧 ERP，不确定能不能打通）、硬指标（并发延迟吞吐有明确数字，没压过测）。

PoC 的纪律只有一条：代码是一次性的。 硬编码、跳过校验、能省则省——它唯一的任务是回答"行不行"。答案出来，留下的是结论和踩过的坑，不是代码。把 PoC 代码直接演进成产品，是往未来五年里埋技术债最快的方式。

设计：AI 时代最反直觉的一步

代码之前，先让设计存在。现在用 Claude Design 这类工具描述需求就出初版设计，读你的代码库建立设计系统，产出的原型用的是你真实的组件——改设计是一行提示词的事，改代码是十行。

这一步值得单独存在的原因只有一个：改动成本在设计阶段和代码阶段差一个数量级。方案模糊的时候写代码，每一行都是赌注；设计稿面前，所有分歧都变成可以指着屏幕聊的具体问题。

MVP：最小的是范围，不是质量

这句话值得加粗。砍掉的是功能，不能砍的是：核心工作流稳定跑通、基本的数据处理和访问控制、日志监控、用户反馈通道。

判断自己有没有滑进"做着做着变成完整产品"的坑，信号很明确：你在加原始需求里没有的功能。PoC 超 3 天、原型超 2 周，通常都是同一个病。

从设计到 MVP 的时机信号：用户主动回来用你的原型，而且你明确知道他们反复回来是为了哪个工作流——两个信号同时出现，MVP 的范围就有了锚点：围着那个工作流建，其他全砍。

最贵的一课

迭代的燃料是真实行为数据，不是朋友的好评。注册数、任务完成率、次周留存——人们嘴上说"会用"和真的回来用，是两回事。

还有一条谁也绕不过去：验证的日历时间压缩不了。AI 把"做出来"压缩了，但留存数据要几周才诚实，B2B 采购周期谁也快进不了——预期管理别跟着编码速度走。

每一步留下的是知识和约束，不是上一阶段的代码。AI 时代重写代码便宜，重蹈覆辙贵。

聊两句：你有没有一个"PoC 成功就直接开建完整产品，最后发现没人要"的项目？或者反过来——过度设计拖了半年没上线？评论区讲讲那个项目的名字和它的墓志铭，我置顶我自己那个烧了三个月的。

往期：gh 终端之道、Cursor 三课、双模型流水线都在主页；下一篇是压轴——读完一本书，带走 Skill 而不是笔记。关注不迷路。