Proof of Concept
一个用完即弃的构建，只回答一个问题：这在技术上可行吗。它不是产品、不是 MVP、也不是你交付给用户的东西。
概念验证存在的目的是消除一个特定的技术风险。这个模型能否达到我们需要的延迟。这个集成对接旧系统时是否真的能跑通。在围绕它设计产品之前，我们能否先证明这套密码学。一个 PoC 只回答「这可行吗」，别的什么都不回答。它被快速构建，按能否运作来评判，然后被丢弃。
让公司付出最大代价的区别是 PoC、MVP 与原型之间的区别。PoC 回答「这在技术上可行吗」，面向你自己的团队。原型回答「这感觉对不对」，面向设计与可用性，通常根本没有真正的后端。MVP 回答「到底有没有人会使用并为之付费」，它是一个真正的产品，交付给真实用户，只是裁剪成值得他们花时间的最小版本。它们有不同的受众、不同的质量门槛、不同的完成定义，而这种区别直接对应于你相对 PMF 处在哪个位置。
常见且昂贵的错误是把 PoC 当作生产环境去交付。那段证明某件事可行的代码，是为了证明某件事可行而写的：没有错误处理、没有测试、没有安全评审、到处都是捷径。当演示打动了某个人、于是决定「直接上线」时，你就把所有这些当作地基继承了下来。诚实的做法是把 PoC 当作一个问题的答案，然后把真正的东西好好地构建出来。
有一个办法能让这份纪律在压力下也守得住：在开始之前就写下这个 PoC 要回答的那一个问题，以及判定「是」或「否」的标准。「这个模型能不能在我们最近的 500 张工单上以 90% 的准确率给工单分类」就是一个有明确裁决的问题。没有这个写下来的问题，一个 PoC 会悄悄变异成一个半成品，团队因为它「差不多能跑」就一直打磨它，于是你在没有任何人做出决定的情况下，滑进了在用完即弃的地基上构建 V1。这个写下来的问题，也是保护你不被沉没成本拽着去上线那段废弃代码的东西：一旦问题被回答，PoC 就完成了它的使命、值得被删掉，无论那个演示看起来多漂亮。
当存在真正值得在投入构建之前消除的技术风险时，Wavect 才做 PoC。大多数项目并不需要它；它们需要的是一个为工作划定范围的发现阶段。我们会告诉你你面对的是哪一种。