夜雨聆风你肯定遇到过这种场景。
花大半小时写了事无巨细的需求文档，喂给AI生成完代码一看，交互全错，动效节奏完全不是你想要的感觉。
改了三四轮，补了一堆细节描述，最后产出还是一堆不符合预期的奇怪产物，时间全耗在无意义的掰扯上。
Matt Pocock点破了AI编程圈这个普遍误区：很多人拿到AI第一反应就错了——先死磕一份完美的Spec文档，本质是在走信息损耗极大的冤枉路。
他给出的解法非常简单：别先急着写全需求，先做原型。
原型根本不是AI时代的新概念，敏捷开发时期的Spike验证思路早已有之。真正发生质变的是成本，AI把生成可运行代码的价格打到了地板价，做一份可丢弃原型的性价比前所未有得高。
原型的核心定义很清晰：用来回答一个问题的可丢弃代码。
这里可以引入一个非常实用的分析维度：保真度频谱。
那些极低复杂度的基础规则，比如弹窗要有确认和取消按钮，这类内容和团队同事聊两句就能对齐，完全没必要写进文档里折腾。
但高保真度的问题，光靠文字描述永远说不清楚。
比如筛选器的交互手感、动效的节奏快慢、弹窗里的内容排版舒不舒服，你靠几百字的描述根本没法把脑子里的感知精准传递给AI和协作方。
一旦你脑子里冒出「我得看看它实际跑起来是什么样」的念头，别犹豫，立刻放弃继续补文字文档，切到原型模式。
同样做一个订单状态追踪页面，两种路径的结果差得离谱。
走传统Spec驱动，你要花40分钟写800字文档，前后迭代4轮，最后产出的代码还是有步骤条溢出、时区没处理、边缘状态没覆盖一堆bug。
信息损耗就发生在每一轮「文字描述→AI凭空生成代码→你发现不对再改描述」的跳跃里，每一步都丢细节。
换成原型驱动，先花2分钟和AI对齐基础范围，直接让它一次性生成3个不同布局的可运行原型。
你在浏览器里实际跑起来看效果，直接口述反馈调整，前后15分钟就能得到可验收的版本。
可运行的代码本身就是精度最高的需求文档，远比任何文字描述都精准。
需要特别说明的是，原型驱动和Spec驱动并不是完全互斥的对立关系。
阿里云2026年百支产研团队调研数据显示，纯原型驱动的团队后期生产代码重构率会高出29%，纯Spec驱动的前期对齐耗时要多57%。
最优的方案是混合使用：前期需求模糊的验证环节用原型快速对齐交互体验，锁定最终形态后，再基于确认的原型整理必要的规范约束交付生产级代码，综合效能比单一模式高40%以上。
Matt把这套切换逻辑嵌入了Wayfinder工作框架，你完全不用纠结什么时候该写文档什么时候该写代码。
默认先通过沟通对齐基础的项目范围、命名规则、文件结构这类基础信息，只要碰到需要靠实际运行效果判断的问题，直接切原型就行。
整套实操步骤没有任何理解门槛，普通开发者当天就能落地：
- 明确要验证的核心问题，让AI一次性生成2-3个原型变体，全部做成可直接运行的版本
- 逐个打开看实际效果，不用写正式评估文档，口述直接给出感受，收集不同变体里你觉得好用的设计决策
- 把多个变体的优点融合，迭代2-3轮直到拿到完全符合预期的原型
- 做一次上下文压缩，把所有设计决策沉淀下来，直接交给后台异步AFK agent完成生产环境落地
很多人误以为原型只适用于前端UI开发，其实后端复杂场景也完全能用。
复杂状态机的状态转移逻辑、数据处理管道的边界输出、批量任务的异常处理流程，都可以做无UI的纯逻辑原型。
你不用写页面不用写路由，就跑一个极简的小脚本，把所有边缘测试用例喂进去看实际输出，验证逻辑完全没问题之后再写生产代码，能省掉大量后期调试的时间。
这套方法论和Ryan Singer《Shape Up》里的Spike思路一脉相承，本质是把过去敏捷开发验证有效思路，在AI时代放大了它的效率优势。
你不用再死守传统产研的路径依赖，把消耗在写冗余需求文档上的时间，挪到更高保真度的原型验证上，AI编程的返工成本就能直接下一个台阶。