PoC 通过，离上线还很远
AI 项目最令人兴奋的时刻，常常是第一次跑出一个漂亮结果。固定样本上回答准确，演示链路顺畅，团队很容易把它解释成“技术已经验证，接下来就是产品化”。
这句话把两个完全不同的问题混在了一起。PoC 证明的是某个关键假设在受控条件下能否成立；上线要求真实用户在完整任务里使用，系统出错后仍然有人能管。前者可以成功，后者仍可能完全不成立。
把 PoC 当成准生产版本，是许多 AI 项目从惊艳 Demo 走向失控返工的起点。
四个阶段，购买的是不同证据
预研回答问题是否值得继续查。它寻找最大未知，盘点数据、风险与替代方案，产物是下一步实验和退出条件。
PoC只验证最危险的一个假设。固定资料、样本、版本和评分，比较完整方案是否达到事先门槛。它的核心产物是可重复证据，不是必须继承的代码。
MVP验证一小群目标用户能否在最小但完整的任务中用起来。登录、权限、失败、反馈、人工接管和监控都不能缺席。
上线扩展才回答更大范围下的稳定性、成本、运营、版本和供应商治理。它需要灰度、回退、事故处理和持续回归。
阶段名称不重要，重要的是每走一步都获得新的证据，而不是给同一份 Demo 换标签。
PoC 故意忽略的，恰好是生产必须承担的
为了验证关键假设，PoC 可以使用干净样本、固定知识、单一角色和人工准备的输入。这是合理的实验控制。但上线环境会带回被省略的复杂性：资料缺失、权限差异、来源更新、外部服务失败、用户取消、长任务恢复和真实成本。
PoC 中“检索后生成答案”可行，不代表知识有 Owner 和删除链；“工具可以调用”不代表重复调用安全；“专家认为结果不错”不代表用户愿意在流程中采纳；“一次运行成本可接受”不代表高峰或长尾任务可持续。
这些不是边角优化，而是产品能否承担现实责任的条件。
从 PoC 到 MVP，要补的是闭环
一个最小可用产品并不是 PoC 外面包一层漂亮页面。它至少要补齐：
- 明确用户、任务范围和非目标；
- 登录、对象权限和高风险动作确认；
- 数据与知识的来源、版本、更新和撤回；
- 缺输入、低把握、工具失败、结果未知与人工接管；
- 可观察的任务状态、用户反馈和 Bad Case 收集；
- 版本化评测、回归、监控、单位成本与回退。
这些条件共同形成最小生产闭环。少一个页面可能仍可用，少了失败去向和责任 Owner，系统就只适合演示。
PoC 代码可以丢，证据不能丢
团队常因已经投入而不愿重做 PoC，结果把临时代码、宽权限和人工步骤直接带进生产。实际上，PoC 的价值在于降低未知，不在于形成长期资产。
实验必须保留样本版本、方案配置、运行结果、失败分类和决定记录。代码是否继承，应由安全性、可维护性和生产架构重新判断。需要重写并不代表 PoC 失败；它可能恰好完成了自己的职责。
相反，如果只保留演示代码，没有保存实验协议和反例，团队甚至无法证明当初验证了什么。
每一关都要允许缩范围和停止
阶段 Gate 不是只为项目放行。预研发现非 AI 方案更合适，可以停止；PoC 发现核心失败不可控，可以缩小任务；MVP 中用户不采纳，也可能退回带引用的辅助工具，而不是继续增加自动化。
真正负责的项目管理，不把停止视为失败，而把它视为避免继续购买无效复杂度。每一关都应提前写清：什么证据支持继续，什么条件需要补充，什么情况应当退出。
尤其是 AI 项目，模型能力容易制造“再调一下就好”的期待。没有停止条件，PoC 会无限延长，MVP 会不断加功能，却始终没人承担上线判断。
灰度不是放一点流量看看
小范围上线也需要假设和护栏。选择哪些用户、哪些任务、观察多长时间，主结果和风险指标是什么，谁每天读 Bad Case，触发什么条件立即关闭能力，都要提前确定。
如果灰度用户没有代表性、反馈没人处理、版本中途频繁变化，最终得到的只是一些使用记录，不是可支持扩大的证据。
灰度的目的不是降低心理压力，而是在可回退范围内验证真实运行。
Demo 回答“能不能”，产品回答“谁负责”
PoC 通过值得庆祝，它说明一个关键未知已经减少。但从这一步到上线，还要回答用户、权限、状态、数据、失败、评测、成本、运营和回退。
真正的生产就绪，不是模型在最好条件下给出过正确答案，而是系统在条件不完整时仍知道怎样停下，在版本变化后能证明没有退化，在出错时能找到 Owner，并且随时有一条可执行的退路。