一个团队想做一款新产品。
会议上，大家很快进入熟悉的状态：产品经理写完整需求，设计师画完整页面，工程师估算完整排期，老板要求一次发布就要像正式产品。每个人都很认真，也都在努力降低不确定性。可是三个月后，产品终于上线，用户第一天就卡在一个团队从来没认真想过的问题上：他们根本不愿意导入历史数据。团队原来讨论了很多功能细节，却没有验证最关键的前提。
另一个团队处理同样的问题，先没有做完整系统。他们做了一张可以点击的页面、一段人工导入流程、一份价格说明和十个真实客户访谈。这个原型很粗糙，甚至很多地方不是自动化的。但它很快暴露出三个事实：客户愿意试用，但迁移成本比想象高；真正有购买权的人不是每天使用产品的人；销售话术里最打动人的不是“功能更多”，而是“少丢数据、少打扰现有流程”。
第二个团队没有比第一个团队更聪明。它只是更早把未知放到现实里，让现实回应自己。
迭代与原型要解决的，就是这种不确定环境下的行动问题：
不要把未经验证的想象一次性做成承诺；
先用低成本形式暴露关键未知，再根据反馈持续修正。
原型不是粗糙成品。粗糙成品的目标仍然是假装自己已经完成，只是质量差一点。原型的目标不同，它是为了测试假设、发现盲点、降低误解、提前暴露风险。
迭代也不是无方向试错。无方向试错只是今天改一点、明天换一点，最后谁也说不清学到了什么。真正的迭代有假设、有反馈、有约束、有节奏。每一轮都应该回答：我们原来相信什么？现实给了什么证据？下一步要保留、修改、放弃还是放大？
一句话概括：
原型负责让未知变得可见；
迭代负责让学习变成下一轮更好的行动。
一、原型不是低配版产品，而是低成本实验
很多人一听“原型”，就想到一个功能不全、界面粗糙、还没打磨好的产品。
这会带来两个误解。
第一，团队会嫌原型“不够正式”，于是过早追求完整。页面要精美，流程要自动化，后台要可扩展，数据要全打通，品牌表达要一步到位。等这些都做完，原型已经不再便宜，也不再灵活。它变成了一个带着大量沉没成本的半成品。
第二，团队会把原型当作偷工减料。既然只是原型，就随便做一下，功能能点、页面能看、故事能讲就行。结果它并没有检验关键问题，只是制造了一种“我们已经行动了”的心理安慰。
真正的原型，首先要问：
这次原型要暴露哪一个未知？
如果未知是用户是否有痛点，原型可以是一组访谈问题、一张流程图、一个人工服务试点。
如果未知是用户能否理解价值，原型可以是一页着陆页、一段演示视频、一份报价单。
如果未知是技术路径是否可行，原型可以是一个只验证核心算法的小程序。
如果未知是组织流程是否跑得通，原型可以是一个小部门试运行、一周手工记录、一次模拟演练。
原型的好坏，不取决于它像不像成品，而取决于它是否用足够低的成本回答了足够关键的问题。
这也是为什么有些看起来“不像产品”的东西，反而是好原型。手工处理、纸面流程、可点击页面、假门测试、客户访谈、样章、试点制度、最小可用服务，都可以是原型。它们不完美，但它们能让团队在花大钱之前看到现实。
原型的核心价值不是“先做一点”，而是：
先把最贵的未知变成便宜的反馈。
二、迭代不是乱改，而是有学习节奏的演进
迭代这个词也很容易被误用。
有些团队每周都发版本，却没有真正迭代。因为每个版本只是追加需求、修补抱怨、回应老板的新想法。做了很多事，但没有形成学习闭环。
真正的迭代至少包含四个环节：
假设 -> 行动 -> 反馈 -> 调整
假设，是说清这一轮为什么这样做。比如：我们认为用户不付费是因为迁移成本高，而不是价格高；我们认为投资标的的关键变量是续费率，而不是短期收入增长；我们认为文章不好读，是因为段落缺少现实例子，而不是标题不够吸引人。
行动，是用最小足够的方式让假设进入现实。不要把一轮迭代做成一项巨大工程。越小，越容易判断因果；越大，越容易把多个变量混在一起。
反馈，是收集能改变判断的信息。反馈不只是数据，也包括行为、访谈、复盘、错误日志、客户拒绝理由、读者停留位置、组织执行中的摩擦。关键是，它必须能帮助你分辨原来的假设对不对。
调整，是把反馈转化成下一轮决策。继续、修改、放弃、扩大、暂停，都可以是调整。没有调整的反馈，只是被观看过的数据。
所以，迭代不是“不断变化”。有些变化只是摇摆。
真正的迭代有方向感。它知道自己正在靠近什么，也知道每一轮想减少哪一种不确定性。它的节奏不是盲目加速，而是让学习速度和风险承受能力匹配。
一个好的迭代节奏通常长这样：
先验证需求是否真实；
再验证解决方案是否有效；
再验证交付方式是否可持续；
最后才验证规模化是否经济。
顺序反了，就容易把还没证明有价值的东西提前做大。
三、为什么复杂问题需要原型
在简单问题里，计划可以很有效。
如果你要复制一份文件、安装一个书架、执行一套成熟流程，事前规划越清楚，结果越稳定。因为问题结构已知，变量有限，因果关系相对明确。
但产品、投资、写作、组织和个人成长里的许多问题，并不是这种线性任务。它们面对的是复杂系统：用户会变化，竞争者会反应，读者会误解，组织会产生惯性，个人会高估意志力，市场会用价格和叙事同时干扰判断。
在复杂问题里，最危险的不是没有计划，而是把计划当成现实。
计划是地图，现实是疆域。地图再精美，也不会自动包含用户的真实动机、组织的隐性阻力、投资标的的二阶变化、个人精力的波动、读者阅读时的困惑。原型的作用，就是让地图尽早碰到疆域。
原型能暴露三类计划里常常看不到的东西。
第一，需求是否真的存在。
人们在访谈中说“我会用”，和真的愿意付钱、迁移、学习、改变习惯，是两回事。一个原型可以把口头认同变成行为证据。
第二，理解是否一致。
团队内部以为自己说的是同一个东西，真正画出流程、做出演示、跑一次试点，才发现每个人脑子里的产品、制度或文章结构完全不同。
第三，代价是否可承受。
一个方案在白板上看起来优雅，落地后可能发现支持成本很高、数据质量很差、客服解释困难、工程维护复杂、个人时间无法长期支撑。
复杂问题不能完全靠想象解决。你需要让现实尽早参与设计。
四、产品：先验证风险最大的假设
产品迭代最容易陷入功能崇拜。
团队会问：还缺什么功能？竞品有什么功能？用户提了哪些功能？老板想加什么功能？这些问题都不是错，但它们经常绕开更重要的问题：
这个产品最危险的假设是什么？
一个面向企业客户的工具，最危险的假设可能不是功能能不能做出来，而是客户是否愿意改变流程。
一个内容社区，最危险的假设可能不是用户能不能注册，而是早期供给是否足够稳定。
一个付费应用，最危险的假设可能不是免费用户是否喜欢，而是用户是否愿意在明确价格前继续行动。
一个内部系统，最危险的假设可能不是技术可行，而是一线人员是否会按新流程录入数据。
原型应该优先攻击这些假设。
如果最危险的是需求，就不要先做复杂后台，先做访谈、着陆页、试用名单、人工服务。
如果最危险的是可用性，就不要只写需求文档，先做可点击原型，让真实用户完成任务。
如果最危险的是交付成本，就不要只看成功案例，先跑小规模服务，把人工、客服、异常和维护都记下来。
如果最危险的是规模化，就不要只看第一批热情用户，观察普通用户是否也能理解、使用和留存。
产品里的原型，不是为了证明团队是对的，而是为了尽早发现团队哪里错了。
这需要一种文化约束：原型失败不等于团队失败。原型失败的意思是，它用较小代价把一个大错提前暴露出来。如果一个原型让团队放弃了错误方向，它可能比一个漂亮上线更有价值。
真正糟糕的是原型看起来成功，却没有验证关键假设。那会把团队带着更强信心推向更大的错误。
五、投资研究：小仓位、投资备忘录和反证也是原型
投资里也有迭代与原型。
很多人以为投资决策只有买或不买。实际上，投资研究可以分层推进：先形成假设，再找反证，再小规模验证，再根据新信息更新判断。
一份投资备忘录，就是研究原型。
它把原来散落在脑子里的判断写出来：这家公司靠什么赚钱？护城河在哪里？关键变量是什么？我最可能错在哪里？什么信号会证明我错了？估值里最脆弱的假设是什么？如果收入增长、利润率、资本开支或竞争格局低于预期，结论还成立吗？
写下来之后，你才知道自己到底在相信什么。
小仓位也可以是一种原型。它不是为了“先买一点求安心”，而是为了让自己开始持续观察，同时把错误成本限制在可承受范围内。小仓位会带来真实心理反馈：价格波动时你是否还理解企业，坏消息出现时你是否知道该看什么，市场叙事变化时你是否被情绪牵着走。
但投资迭代有一个重要边界：不能把频繁交易误认为迭代。
如果每次价格波动都让你改变观点，那不是学习，而是被噪声驱动。如果每次新闻都让你重写逻辑，那不是贝叶斯更新，而是缺少稳定框架。
投资中的迭代应该围绕基本假设更新，而不是围绕情绪波动打转：
业务质量是否变了？
竞争结构是否变了？
管理层行为是否变了？
资产负债表是否变脆弱了？
我原来最关键的判断是否被证据削弱了？
投资研究的原型越清楚，后续迭代越不容易被市场噪声带偏。
六、写作：先让观点被看见，再让结构变清楚
写作也很适合用原型思维。
很多人写不出来，不是因为没有能力，而是因为一开始就要求自己写出完整成品。标题要好，结构要稳，例子要准，语言要漂亮，逻辑要无懈可击。结果每一句都像正式发布，写作变成自我审查。
写作原型可以很轻。
它可以是一句话中心论点，一张段落提纲，一个现实例子，一组反例，一个开头场景，甚至是一段对朋友的解释。它不负责好看，它负责让你看到：这个观点是否真的清楚？例子能否承载论点？读者可能在哪里误解？哪些地方只是口号，哪些地方有真实机制？
好的写作迭代通常不是“润色一遍”这么简单，而是分层修正：
第一轮：观点是否成立？
第二轮：结构是否顺？
第三轮：例子是否真实？
第四轮：边界是否说清？
第五轮：语言是否干净？
如果顺序反了，容易把精力花在不该保留的句子上。先把句子磨得很美，后来发现整段逻辑要删，反而更舍不得。
写作中的原型精神，是允许早期文本不漂亮，但不允许它不诚实。它要尽快暴露自己到底有没有东西可说。迭代精神，是每一轮修改都解决一个层次的问题，而不是无休止地把同一段话改来改去。
一篇文章真正成熟，不是因为第一稿完美，而是因为它经历过有效反馈：作者自己读懂了，读者能跟上，反例能承受，边界不再含糊。
七、组织流程：先试点，再制度化
组织流程最怕把猜想直接写成制度。
一个公司发现项目延期，于是立刻增加审批；发现质量问题，于是立刻增加表格；发现沟通混乱，于是立刻增加会议；发现有人犯错，于是立刻增加权限限制。每个动作都有理由，但如果没有试点和反馈，流程会不断增厚，组织却未必更好。
流程也是产品。它的用户是组织内部的人。它也需要原型和迭代。
一个新流程在全公司推行前，可以先在一个团队试运行两周。观察它是否真的减少错误，是否增加了无意义等待，是否把责任变清楚，是否让一线人员更容易完成正确动作，是否产生了新的绕行路径。
试点不是走形式。它要带着问题：
这个流程要防止哪类故障？
关键节点是否清楚？
信息是否重复录入？
谁有权处理例外？
出了问题是否能追溯？
它降低的风险是否大于新增的摩擦？
组织流程的迭代，尤其要警惕一种倾向：只增加，不删除。
增加一条规则很容易，因为它显得负责。删除一条规则很难，因为它需要承担风险。结果流程像沉积物一样越堆越厚。真正有迭代能力的组织，不只是会加流程，也会根据反馈废止、合并、简化和重写流程。
流程原型的目的，不是让制度变得随意，而是在正式固化之前知道它会如何影响真实行为。
八、个人成长：把改变做成可观察的小实验
个人成长中，很多计划失败，是因为一开始就做得太像宣誓。
从明天开始每天五点起床。
从这个月开始每天读两小时书。
从现在开始彻底自律。
从今年开始重塑人生。
这些话在情绪高点很有力量，但它们往往没有原型，也没有迭代。它们没有回答：我原来的生活结构为什么支撑不了这个行为？我最容易在哪个时段失败？失败后如何恢复？什么反馈说明计划太重？什么反馈说明方法有效？
个人改变可以更像实验。
想运动，不必先承诺一年。可以先做两周，每次二十分钟，记录阻力来自时间、地点、身体还是心理。
想读书，不必先买一堆书。可以先固定一个最容易开始的场景，观察自己在哪类书上能持续。
想早睡，不必只靠意志。可以先调整睡前一小时环境，记录真正破坏睡眠的是工作、手机、社交还是焦虑。
想转行，不必立刻辞职。可以先做一个小项目、访谈从业者、公开写几篇分析，验证自己是否真的理解新领域。
个人迭代的关键，是把失败看成信息，而不是人格审判。
一次没执行，不只说明“我不自律”。它可能说明计划太重，触发环境太差，反馈太慢，奖励太远，睡眠不足，或者这个目标并不真正重要。把失败拆成信息，下一轮才有改进空间。
但个人成长也不能永远停在小实验。某些能力需要长期承诺：语言、写作、投资、健康、亲密关系、职业信誉，都不可能只靠两周试验获得复利。原型帮助你找到合适路径，迭代帮助你修正节奏，最终仍然需要稳定投入。
九、什么时候不适合迭代
迭代不是万能模型。
最重要的边界，是高不可逆、高后果场景。
如果一次错误会造成严重人身伤害、法律后果、信任崩塌、数据永久丢失、资本出局、公共安全事故或声誉长期损害，就不能用“先试试看”轻轻带过。
医疗、航空、桥梁、药品、金融杠杆、核心数据迁移、重大并购、公开承诺、儿童安全、隐私泄露、法律合规，这些场景可以有仿真、沙盒、演练、灰度和小范围验证，但不能把真实用户、真实患者、真实资金、真实安全当成随便试错的对象。
高后果场景里，正确顺序通常是：
先模拟；
再隔离；
再小范围；
再监控；
再准备回滚和补偿；
最后才扩大。
有些事情不是不能迭代，而是迭代必须发生在受控环境里。飞行员可以在模拟器里反复训练，医生可以在模型和导师监督下练习，工程团队可以在测试环境和灰度环境中验证，投资者可以用小仓位和纸面组合学习。但不能把不可逆损害包装成“快速试错”。
另一个不适合迭代的场景，是价值底线明确的事情。
诚信、合规、安全、尊重、隐私，不应该通过“试试用户会不会发现”来迭代。你可以迭代表达方式、流程设计和执行工具，但不应该迭代底线本身。底线一旦被当成实验变量，组织很容易在短期激励下慢慢滑坡。
迭代还有一个边界：不要用它逃避判断。
有些人永远说“再试一版”，其实是不愿承认方向错了。迭代必须有停止规则。如果连续反馈都否定关键假设，如果每一轮都需要越来越多解释才能维持信心，如果修补成本超过潜在价值，就应该停止，而不是把沉没成本改名叫长期主义。
十、误用：把原型做成借口，把迭代做成噪声
迭代与原型常见的误用有五种。
第一，把粗糙当成原型。
粗糙不是问题，没目标才是问题。一个原型可以难看、手工、不完整，但它必须清楚自己要验证什么。没有假设的粗糙，只是低质量。
第二，把频繁变化当成迭代。
今天听客户 A 改，明天听老板改，后天看竞品改，大后天被数据噪声改。变化很多，学习很少。这种迭代会消耗团队信心，让所有人觉得方向随时会变。
第三，只收集支持自己的反馈。
如果原型只是用来向上汇报“用户很喜欢”，它就失去了价值。好的原型应该主动寻找反证，尤其寻找那些会推翻关键假设的反馈。
第四，没有约束地试。
试验必须有成本上限、时间上限、风险边界和判断标准。否则试验会自然膨胀，最后变成没有正式承诺的长期项目。
第五，永远停在原型。
原型阶段可以灵活，但不能永远不交付。一个想法经过验证后，需要进入更稳定、更可靠、更可维护的形态。继续用临时脚手架服务核心业务，会把早期速度变成后期风险。
所以，原型和迭代都需要纪律：
原型要有问题；
迭代要有证据；
试验要有边界；
放大要有标准；
停止要有勇气。
十一、如何使用迭代与原型
遇到一个不确定任务，可以按下面的顺序走。
第一，写出关键假设。
不要一开始就问“怎么做”。先问：这件事成立，依赖哪些判断为真？用户真的有需求吗？客户真的愿意付费吗？技术真的可行吗？组织真的能执行吗？自己真的能长期坚持吗？投资标的真的有护城河吗？
第二，找出最危险假设。
不是所有假设都同等重要。优先验证那些一旦错误就会让整个计划失效、成本最高、最难事后修正的假设。
第三，设计最低成本原型。
原型不追求完整，而追求足够暴露问题。问自己：有没有比完整开发、全面推行、重仓投入、正式发布更便宜的验证方式？
第四，定义反馈标准。
什么算成功？什么算失败？什么信号要求继续？什么信号要求停止？如果事前不定义，事后很容易用解释保护原来的想法。
第五，限制风险和时间。
一轮迭代要有边界。投入多少人、多少钱、多少时间，影响哪些用户，能否回滚，出了问题谁负责处理，都要说清楚。
第六，复盘并决定下一步。
不要只汇报结果，要更新判断。原假设被支持、削弱还是推翻？下一轮要验证什么？该扩大、修改、暂停还是放弃？
这套流程看起来慢，实际是在防止更大的慢。它把大规模返工、大额亏损、组织惯性和不可逆承诺，尽量提前压缩成小规模学习。
十二、和其他模型的关系
迭代与原型和可逆性与不可逆性关系最直接。可逆决策适合小步快跑、快速学习；不可逆决策需要更高证据、更厚安全边际和更严格预案。原型的价值，就是把部分不可逆承诺拆成可逆步骤。
它和安全边际相连。原型是一种认知安全边际：在正式投入前，给判断错误留出空间。迭代是一种行动安全边际：让系统在每一轮都能根据反馈修正，而不是一次性押满。
它和故障模式分析互补。故障模式分析问“这个方案会怎样坏”；原型和迭代问“能不能用低成本让某些坏法提前出现”。一个负责想象失败路径，一个负责在可控环境中验证失败路径。
它和可维护性设计也相连。原型阶段可以轻，但进入长期系统后必须可维护。临时方案如果不及时收束，会变成未来的复杂债务。真正成熟的迭代，不只是越改越多，也要越改越清楚。
它和反馈环关系密切。没有反馈，迭代只是动作重复；有反馈但不更新判断，也不是学习。反馈环越短、越真实、越能影响下一步，迭代质量越高。
它还和能力圈、贝叶斯更新、检查清单方法、沉没成本谬误相连。能力圈外更需要小原型；新证据出现后要更新概率判断；重要试验要用检查清单防止遗漏；方向被证伪时要停止，而不是被沉没成本拖着继续。
十三、一句话总结
迭代与原型训练的是一种谦逊的行动能力：
承认自己不知道，
但不要停在不知道；
用小成本接触现实，
再让现实改变下一步。
原型不是粗糙成品，而是把未知变成反馈的工具。迭代不是无方向试错，而是带着假设、约束和学习节奏的演进。
在可逆、低成本、不确定的地方，早点做原型，早点听反馈，早点修正。
在高不可逆、高后果、底线明确的地方，先模拟、隔离、演练、加安全边际，不要把真实损害当成学习成本。
真正好的行动者，不是计划到一切都确定才出发，也不是把莽撞包装成敏捷。他会先问：我现在最不知道什么？怎样用最小代价知道一点？知道以后，下一步该怎么变？
来源说明
- 《查理·芒格的思维模型·完整版》：最终 registry 中“迭代与原型”位于工程与可靠性类，本文以此作为主来源条目，并结合相邻的“可逆性与不可逆性”“安全边际”“故障模式分析”“可维护性设计”“反馈环”等模型展开。
mental-models/models/可逆性与不可逆性.md：主要用于本文关于把不可逆承诺拆成可逆步骤、高后果场景需要更高证据和回滚能力的讨论。mental-models/models/故障模式分析.md、mental-models/models/可维护性设计.md、mental-models/models/安全边际.md：主要用于本文关于上线前暴露失败路径、原型阶段与长期维护阶段的边界、以及试验中保留成本和风险缓冲的讨论。- 《从0到1：开启商业与未来的秘密》《重新定义公司：谷歌是如何运营的》在本仓库提炼记录中提供了产品、战略、计划、数据决策和组织试验相关的背景线索；本文没有把它们作为直接主模型来源，而是将其作为产品和组织场景的辅助语境。