别再做 POC 了，做最小可行部署

POC 本来是为了验证方向，但很多企业 AI 的 POC 最后变成了演示工程。演示数据是干净的，演示流程是设计好的，演示用户是配合的，演示结果是可控的。它证明的是“看起来能做”，不是“真的能用”。

最小可行部署和 POC 最大的区别在于：它必须进入真实环境。

最小可行部署的第一条原则是范围要小。不要一上来做全公司智能客服，而是先做退换货工单自动分流。不要一上来做企业级 AI 平台，而是先让一个部门的一条流程跑起来。范围小，才能缩短周期，也才能让双方聚焦真正的价值。

第二条原则是价值要完整。范围小不等于只做半截。一个小场景也要尽量端到端，从数据输入到结果输出，从用户使用到指标验证，形成闭环。如果只做一个孤立功能，看起来完成了，但仍然不能证明业务价值。

第三条原则是环境要真实。用真实数据、真实用户、真实权限、真实业务流程。只有真实环境会暴露真正的问题：字段缺失、权限不足、异常情况太多、用户不愿意切换工具、模型输出需要人工复核。假数据上的成功，很多时候只是精心制作的幻觉。

第四条原则是周期要短。如果一个验证项目要做半年，它就已经不是最小验证。短周期会逼迫双方做取舍。哪些功能是真正必要的，哪些只是锦上添花，哪些流程必须进入第一版，哪些可以后置，只有在时间约束下才会变清楚。

最小可行部署不是大系统的缩小版，而是价值验证的最小闭环。它的目标不是让客户觉得“这个东西很先进”，而是让客户看到“这个东西在我们的环境里确实改变了一个结果”。

做完之后，要马上回答三个问题：是否产生了可见价值？是否值得扩展到相邻场景？哪些现场经验应该沉淀成复用资产？

如果不能回答这三个问题，验证就还没有结束。真正好的最小可行部署，会让客户从“这东西挺厉害”转向“我们能不能把它用到下一个流程里”。

做最小可行部署时，最容易犯的错误是“范围小，但价值也小”。比如只做一个问答窗口，没有接真实知识库，没有用户反馈，没有使用指标。这样的东西虽然小，但不能验证业务价值。真正好的小切口，应该像针一样扎进一个具体痛点。

可以用“两周验证”作为参考节奏。第一到三天做现场观察和指标定义，确认真实流程和数据源。第四到七天做最小系统，能接真实数据，能让真实用户完成一个动作。第二周让用户试用，收集反馈，修关键障碍，最后用指标和用户行为判断是否继续。

最小可行部署结束时，要产出三样东西：一个能跑的小系统，一组初步业务数据，一份复用复盘。小系统证明可能性，业务数据证明价值，复用复盘决定这个项目对公司有没有长期意义。

如果只交付系统，没有数据，它只是 Demo。如果只有数据，没有复盘，它只是一次项目。如果系统、数据、复盘都有，它才开始成为 FDE 的资产。

这一篇适合加入一个强判断：POC 最大的问题不是太小，而是不够真。很多 POC 范围也小，但它用假数据、假流程、假用户，最后只能证明供应商会做演示。最小可行部署不怕小，怕的是没有进入真实业务。

可以把最小可行部署拆成四件交付物：真实数据接入、一个端到端流程、核心指标看板、项目复盘文档。这样客户看到的不只是界面，而是一套可继续演进的基础。