互联网方法论说 MVP（最小可行产品），验证的是「市场要不要这个产品」；企业 AI 需要的 MVD（最小可行部署），验证的是「这个方案在你这套数据、组织、流程里，能不能真的产出价值」。一字之差，裁判从市场换成了你的业务。
价值不能继承，只能逐个验证
一个方案在十个客户那里都成功了，第十一个客户照样可能失败——数据基础不同、组织惯性不同、痛点的形状不同。这是企业交付的残酷之处。演示里惊艳四座的模型，进了你的环境可能水土不服，不是模型不行，是「在你的环境里」这件事本身需要验证。
所以 MVD 的第一原则：用最小的工程投入，在客户的真实环境里，对真实的痛点，验证一次价值的真实发生。我们把它翻译成项目语言就是——先做 1–2 个高价值场景的试点验证（通常 4–6 周），达标再谈生产部署。
MVD 的三条军规
概念验证要有「毕业标准」
FDE 模式对概念验证的态度很明确：它不是「先试试」，是投产前的关卡。每个验证项目启动时就写明：多少周后、用什么指标、达到什么数值，项目「毕业」进入付费部署；达不到，双方体面散伙。
这要求验收指标在开工前就定好。我们在 《AI Agent POC 验收指标设计》里给过一套可落地的指标框架：任务完成率、来源引用率、流程成功率、持续使用率。指标的作用不只是验收，它还是试点的「停止条件」——连续两周不达标，就该停下来诊断是数据问题、链路问题还是场景选错了，而不是硬撑到演示日。
数据上兼容旧系统，架构上绝不迁就
MVD 阶段几乎每个项目都会撞上一个分歧：客户的现有环境——跑了二十年的老系统、部门自建的小工具、严格的安全边界——方案应该迁就多少？
FDE 实践给了一条中间路线：数据层深度兼容旧环境——客户的数据在哪就从哪读，哪怕在老旧系统的私有接口里；架构层坚决不做旧环境的寄生物——验证期系统运行在自己可控的边界内，通过接口交互，保持「可撤离」的姿态。对应到我们的做法，就是 REST API、数据库受控访问、消息队列、文件交换、项目适配层五种接入方式——数据兼容，架构独立。
还有一条经常被技术团队搞反的：技术环境可以强硬，人的习惯必须顺从。如果业务用户的核心动作发生在表格和邮件里，界面就应该出现在表格插件和邮件里，而不是要求用户登录一个崭新的门户。员工不愿用新工具，是五大路障里排第一的死亡原因。
试点之后会发生什么
验证通过的智能体不是慢慢长大，是跳跃式放大。Palantir 的客户节奏可以作为参照：一家大型医疗公司参加训练营后五周签约，一家全球银行试点一个月后先签 200 万美元初始合同，四个月后扩展为三年期大单。
客户在几周里已经亲眼见过价值，剩下的只是商务流程。这也是我们建议先试点再投产的原因：试点验证到生产交付通常 2–3 个月，中间省掉的是反复扯皮、功能堆砌和「上线了没人用」的返工成本。