做项目的四个动作：PoC、设计、MVP、迭代——顺序错了，钱就白烧了
前言
很多人拿到一个想法，第一件事就是打开编辑器写代码。
AI 编程时代这个冲动更强了——Claude Code 半小时就能给你跑起来一个东西，凭什么还要流程？
但跑起来和做对是两回事。我自己做项目，起手式固定是四个动作：PoC 验证技术 → Claude Design 做设计 → MVP 砍到最精 → 迭代再迭代。这四个动作背后其实是三个不同的问题，顺序错了，回答的成本会指数上升。
- PoC 回答：能不能做出来？（技术风险）
- 设计回答：做出来长什么样？（体验风险）
- MVP 回答：有没有人用？（市场风险）
一、四个动作的全景
四个动作各自要交付的东西完全不同：
| 动作 | 回答的问题 | 交付物 | 合理耗时 |
|---|---|---|---|
| ① PoC | 能不能做出来？ | 一个能跑的验证 + 结论 | 1-3 天 |
| ② 设计 | 做出来什么样？ | 可交互的设计稿/原型 | 几小时-1天 |
| ③ MVP | 有没有人用？ | 真实用户可用的最精简版本 | 2-8 周 |
| ④ 迭代 | 怎么做得更好？ | 下一轮，回到动作① | 循环 |
二、动作①：PoC，先看能不能跑起来
PoC 只回答一个问题：技术上行不行。 " 要不要做这步，有个简单的判断：如果你调用的是成熟模型的成熟能力（标准 RAG、常规对话、常见格式抽取），技术风险很低，可以直接跳过。2026 年的共识也是这样——大多数 AI 用例的技术可行性早已确立，为"Stripe 能不能收款"做 PoC 不叫验证，叫浪费。
但这三种情况，PoC 省不了：
- 准确率敏感：从合同里抽取数据、自动化一个决策，不知道模型准确率够不够
- 生僻集成：对接老旧 ERP、文档稀缺的内部系统，不确定能不能打通
- 硬指标：并发、延迟、吞吐有明确数字要求，没压过测
PoC 的纪律只有一条：代码是一次性的。
硬编码、跳过校验、能省则省——都合理，因为它唯一的任务是回答"行不行"。答案出来后，留下的是结论和学到的坑，不是代码。把 PoC 代码直接演进成产品，是往未来五年里埋技术债最快的方式。
我的做法：1-3 天，一个二元的判断问题，端到端跑通一个真实用例，输出一小段结论。答不了二元问题的 PoC，说明问题还没定义清楚。
三、动作②：用 Claude Design 做设计，不着急写代码
这是四步里最新、也最反直觉的一步：代码之前，先让设计存在。
Anthropic 今年推出的 Claude Design 干的就是这件事——描述需求，它生成初版设计；你通过对话、行内评论、直接编辑、实时调节滑块来打磨。几个能力直接改变了"设计"这一步的成本结构：
- 读你的代码库建立设计系统：颜色、字体、组件自动对齐已上线的产品，产出的原型用的是你真实的组件——不会出现"设计很棒但组件库里没这个东西"的交接灾难
- 一个对话出多个方向：以前设计师受时间限制只能探索两三个方案，现在几分钟十几个方向摆在一起比
- Handoff Bundle 交接 Claude Code：设计定稿后打包成结构化的交接包，带着设计意图一条指令进入实现
为什么这一步值得单独存在？因为改动成本在设计阶段和代码阶段差一个数量级。Brilliant 的设计师说，他们最复杂的交互页面，在其他工具要 20+ 轮提示，Claude Design 两轮搞定；Datadog 的产品团队一个会议之内从粗略想法到能跑的原型。
不着急写代码的本质是：先看清楚，再动手。方案模糊的时候写代码，每一行都是赌注；设计稿面前，所有分歧都变成了可以指着屏幕聊的具体问题。
四、动作③：MVP，最核心最精简的版本
MVP 的"最小"说的是范围，不是质量。
这句话值得加粗。砍掉的是功能，不能砍的是：
- 核心工作流能稳定跑通——用户来就为这一件事
- 基本的数据处理和访问控制
- 日志和监控——出问题要能看见
- 用户反馈的通道
MVP 最容易犯的错是做着做着变成了完整产品。判断自己是不是已经滑进这个坑，有个信号：你在加原始需求里没有的功能。PoC 超 3 天、原型超 2 周，通常都是同一个病。
从设计到 MVP 的时机信号：用户主动回来用你的原型，而且你明确知道他们反复回来是为了哪个工作流——两个信号同时出现，MVP 的范围就有了锚点：围着那个工作流建，其他的全砍。
五、动作④：迭代，然后回到开头
MVP 上线不是终点，是循环的新起点。真实用户的反馈会暴露新的技术疑问、新的设计分歧、新的范围问题——于是你再次回到动作①，只是这一次每个圈都更小、更准。
迭代的燃料是真实行为数据，不是朋友的好评。注册数、任务完成率、次周留存——人们嘴上说"会用"和真的回来用，是两回事。
六、数据与状态流：每一步留下什么
注意每一步留下的是知识和约束，不是上一阶段的代码。PoC 留结论，设计留意图和组件边界，MVP 留数据。这些东西进入下一轮，代码本身随时可以重写——AI 时代重写代码便宜，重蹈覆辙贵。
七、跨端边界：人机分工在哪条线上
这套流程里，人和 AI 的分工边界很清楚：
- 人守住的：定义问题、判断 PoC 结论、审美和取舍、预算决策、"做不做"的最终拍板
- AI 加速的：PoC 的脚手架代码、设计的生成与变体探索、MVP 的实现、迭代的机械部分
一条实操边界：验证阶段对 AI 全速放权，生产阶段必须有人做架构、安全、数据的判断。"能跑起来"和"能当生意运营"之间隔着一堵墙——密码重置流程变成攻击入口、支付在高并发日重复执行，这些问题你点着看是发现不了的，它们只在真实用户和真金白银出现时浮出水面。
八、配置边界与扩展点
配置边界——四个动作各自的环境互不污染：
- PoC 用一次性环境，硬编码无所谓，别连生产数据
- 设计在 Claude Design 里独立成项目，设计系统可维护多套（子品牌、不同产品线）
- MVP 才引入正式的基础设施：CI/CD、监控、备份
- 每个阶段用各自的工具链，别为了"统一"提前付生产级的配置成本
扩展点——流程本身可以生长：
- 团队化后，设计步变成设计系统共享，PoC 结论沉淀成内部知识库
- 迭代循环可以按功能模块并行——每个新功能都走一遍小循环，而不是整个产品一个循环
- AI 工具升级时只替换对应动作的工具，流程骨架不变
九、风险点
- 把"技术能跑"当"产品能成"。PoC 成功就直接开建完整产品，是把两个独立实验当成一个。PoC 证明的是必要条件，不是充分条件
- 跳过设计直接写代码。方案还模糊就动手，每行代码都是赌注，返工成本在设计阶段的十分之一以上
- MVP 范围失控。加着加着变成完整产品，验证周期从两周拖成两个月，市场窗口就没了
- PoC 代码混入生产。一次性代码进了主干，技术债按年计息
- 用反馈代替数据。问朋友"你会用吗"得到的都是客气，真实行为（回访、付费）才算数
- 验证的日历时间压缩不了。AI 把"做出来"压缩了 90%，但留存数据要几周才诚实，B2B 采购周期谁也快进不了——预期管理别跟着编码速度走
记住
四个动作，三个问题：PoC 问能不能做，设计问做成什么样，MVP 问有没有人用。
顺序就是成本的顺序——技术风险最先回答，因为它最便宜；市场风险最后回答，因为它最贵。顺序反了，就是在用最贵的方式回答最便宜的问题。
每一步留下知识和约束，代码随时可以重写。快速跑完每一步，认真对待每一步的输出，然后回到开头，再来一圈。
参考资源
- Anthropic：《Introducing Claude Design by Anthropic Labs》
- Kalvium Labs：《AI POC vs MVP vs Prototype: Which One Do You Need?》
- Mobile Reality：《PoC vs MVP in the AI Era: Why Prototypes Take Hours but Validation Still Takes Months》
- Delcano：《Can Claude Code Alone Build Your MVP?》
- Vinova：《MVP vs POC: How to Choose the Right Strategy Without Burning Your Budget》