先许愿，再快速验证，然后确认契合|许愿式编码（Vibe Coding）

作者：Dean Peters，2025 年 6 月 8 日

翻译：优普丰 AI 敏捷创新咨询

原文：https://deanpeters.substack.com/p/vibe-first-validate-fast-verify-fit

💪🏻先活下来，再扩张

欢迎来到许愿式编码（Vibe Coding）时代的产品探索——AI 辅助原型制作看似真实却可能并非如此——AI 智能体工具和利益干系人剧场（译者注：为了给利益相关者留下印象或满足他们的形式主义要求，而进行的一些不必要的、表面化的、甚至带有欺骗性的活动）——错误的原型成本远高于错误的路线图。

[图1：你现在还不需要扩大规模。但你确实需要停止猜测。]

“测试你的想法最昂贵的方式是构建生产级质量的软件。” ~Jeff Patton,Dual Track Development

每个原型都讲述一个故事。有的低声诉说可行性，有的咋呼，“看这个 Figma原型图！”，还有的则撒谎……美丽、自信且频繁。你的高管们相信它们。作为产品经理，你现在还不需要扩大规模……但你确实需要停止猜测什么值得构建。

让我们来解决这个问题。但首先，让我们重新定义 2026 年（这不是打字错误，朋友们）的“原型”意味着什么。

🔍 重启：生命力（Proof of Life）探测器

回到 2015 年，我困于与高管的“功能人质谈判”（译者注：”Feature hostage negotiations 是一个在产品管理领域非常形象的术语，用来描述产品经理在确定产品功能优先级和路线图时，与内部或外部利益相关者之间进行的一种高压、不对等的谈判局面）中，他们无法区分原型和生产级构建。所以我发明了一种新型工件：

PoL 探测器——生命力证明

• 轻量级
• 一次性
• 范围狭窄
• 极其诚实
• 小巧且专注

将它们视为探测任务，而非 MVP。永远不是 MVP！*这些*微小的发现行为（TADs）*旨在降低决策风险……而不是证明 HiPPO （薪水最高的人的意见）最新的想法，或被受到相信许愿式编码的海鸥型经理突然俯冲和排便（译者注：swoop-n-pooped，海鸥的行为，这里指乱拍脑袋）。

🧠 明智（且经济）地选择

不是每个问题都是需要锤子的钉子。也就是说，仅仅因为许愿式编码让它看起来真实，并不意味着它就是真实的。并非一切都值得许愿式编码。

所以，在像万圣节糖果一样分发开发时间之前，问问自己：

我们试图降低什么风险？以及听到最残酷真相的最便宜、最快的方式是什么？

🍦 原型的几种风味（现在带有 AI 配料）

1. 可行性检查我们甚至能构建这个吗？1-2 天的突击和删除测试。想象：GenAI 提示链，LMMs 评估，数据完整性扫描，第三方 API 嗅探测试，或评估工具契合度。这是关于揭示技术风险——而不是为了给人留下印象而构建。
2. 聚焦任务的测试用户能否顺利完成这项工作而无摩擦？验证关键瞬间：一个字段标签，一个决策点，一个流失点。像 Optimal Workshop 和 UsabilityHub 这样的工具使这变得非常简单。
3. 叙事原型这个工作流程是否值得一个“绝对肯定”？考虑 Loom 演示，宣讲视频，或幻灯片故事板。这不是“构建与购买”。这是“讲述与测试”。讲述故事，然后看看谁买账。像 Sora、Synthesia 和 Veo3 这样的文本到视频工具让你快速、低努力地创造叙事——无需编写代码或制作可点击原型。
4. 合成数据模拟我们能否在不消耗生产资源的情况下建模？使用像 Synthea 这样的工具模拟用户。利用像 DataStax LangFlow 这样的系统测试提示逻辑，边缘情况，或揭示未知数。这就像风洞测试——只是比事后分析便宜。
5. 许愿式编码 PoL 探测器（旧称“混合原型”）这个弗兰肯（译者注：怪物）软件能否在与用户接触中生存？通过 Canvas 屏幕连接的 ChatGPT 提示，用一点 Replit 和 Airtable 部署？砰：假前端，半可信后端，48 小时内的用户反馈。这不是产品——这只是足够的幻觉来捕捉真实信号。如果他们使用它，太好了。如果他们忽略它？更好——你刚刚避开了一个六个月的路线图绕道。只是不要将动力与成熟度混淆。“最大的风险是构建没有人想要的东西。这就是为什么在投资构建完整解决方案之前，我们需要验证我们的假设。”~Melissa Perri,Escaping the Build Trap

🧪 头号原则

使用最便宜的原型来揭示最残酷的真相。如果它不刺痛，那可能只是表演。

[图2：为工作选择合适的工具。为你的假设选择合适的测试规模。]

🙌 向前辈OG 致敬

这篇文章借鉴了 Marty Cagan 2014 年的博客文章“原型的几种风味”和他的书中《启示录：如何创造客户喜爱的科技产品》第 43 章。

虽然他的例子在今天的生成式助手和廉价原型工具的世界里可能已经过时…… … 他的观点仍然有用…… ……我们需要有意识的生命力验证，而不是原型剧场。

🎯 轮到你了

当你需要在开发人员投入之前进行风险检查时，你的 PoL 探测器是什么？

在评论中留下你最喜欢的风味——或者你最大的失败。

让我们更聪明地验证，更干净地出原型。并避开下一次俯冲和排便。