3 第 2 章解决正确的问题

「在错误的问题上，一切执行力都是浪费。」

3.1 2.1 概念验证坟墓的解剖报告

硅谷有个词，叫「概念验证炼狱」（POC purgatory）。进去的项目出不来：没死透，不能宣告失败；没活成，不敢加大投入。于是它们在季度汇报里一年一年地「持续推进中」，像一屋子插着管子的病人。

麻省理工学院的研究者给这座坟墓做过一次系统解剖。他们归纳出企业人工智能项目规模化路上的五大路障，按出现频率排下来：

员工不愿用新工具——讽刺的是，这些人每天私下用 ChatGPT 用得飞起
对模型输出质量的担忧
糟糕的用户体验
缺乏高管支持
变革管理困难

请注意这份清单里缺席的东西：模型不够聪明、算力不够便宜、技术不够先进——都不在列。杀死这些项目的，几乎全部发生在「问题定义」和「组织现实」层面，不是技术层面。

报告里有个被反复引用的细节，值得单独讲。一家企业花五万美元采购了专业的合同分析工具，功能清单洋洋洒洒。但公司的一位资深律师就是不用——她继续用免费的 ChatGPT 起草合同。理由很朴素：买的那个工具，摘要太死板，没法按她的习惯定制。采购部门的报表上写着「已部署」，真实的日常却是官方系统空转、员工绕道而行。（出处见附录 C）这个细节揭示了第一大路障的真正成因：不是员工守旧，是消费级产品把他们的胃口养刁了——每天在家用得飞起的人，没法忍受办公室里的「人工智障」。

还有一组更扎心的对比：与外部专业供应商合作的项目，成功率约为内部自建的两倍。为什么外部团队反而胜率高？不是他们更聪明，是他们输不起——按结果收钱的人，定义错问题的代价是自己买单。日本一家公司的内部项目就是典型的反面教材：抽调三四名最强工程师组成攻坚组，演示惊艳、领导点头，唯独从第一天起就没有人能回答「这套系统的好，由什么标准衡量」。半年后项目从汇报材料里悄悄消失，没有人宣布它失败，它就这样自然死亡了。（出处见附录 C）

这就是本章的第一性原理：在错误的问题上，一切执行力都是浪费；而企业里错误问题的密度，远超想象。这一章只讲一件事：写第一行代码之前，怎么确保你在解决正确的问题。

3.2 2.2 PSF：找到问题与方案的契合

互联网创业方法论里有个核心概念叫 PMF（Product-Market Fit，产品与市场的契合）：产品对了，市场自己会拉动增长。在 FDE 的世界里，对应的单位不是「产品与市场」，而是「问题与方案」——我称之为 PSF（Problem-Solution Fit，问题与方案的契合）。

区别微妙而关键。PMF 问「我的产品有没有市场要」，视角在供给方；PSF 问「客户这个具体的问题，值不值得、能不能被我们的能力解决」，视角在需求方。一个企业客户内部，可能有几百个「人工智能能做点什么」的机会点，但真正值得做的，必须同时过三关。

第一关，痛点检验：这个问题，是不是某个具体的人的具体的痛？注意是两个「具体」。「提升客服效率」不是痛点，是方向；「客服主管每周一早上要花三小时，从四个系统里手动汇总上周的升级工单，而她真正的工作应该是分析升级原因」——这才是痛点。麦格鲁给过一个更锋利的标准：去解决首席执行官最关注的五个问题之一。理由很现实，只有这个量级的问题，才能帮你碾过企业内部的官僚阻力（第 3 章会展开怎么用它过信息部门这道关）。Sierra 的智能体工程负责人默勒的标准是同一个原则的另一种说法：只接两类问题——真的难的，和真的有业务影响的。只有难没有影响，是炫技；只有影响不难，轮不到你。

第二关，经济性检验：解决这个问题，值多少钱？很多痛点是真痛，但不值钱；算不清这笔账的项目，做了也活不过下一个预算季。你可以粗略地算：这个问题每周吃掉多少人时？折合多少人力成本？出错一次赔多少？省下来的人手能去干什么？Palantir 的训练营干脆把这关前置——客户开始前就得锁定「核心战场」、给出量化靶子，「排产冲突降低 30%」「库存周转缩短 15%」。那份报告里有个被广泛引用的发现，恰好说明这关多容易被跳过：超过半数的企业人工智能预算投向前台的销售营销，回报却集中在后台的合同审查、采购、风控这些「不性感」的地方——大家都在解决「演示效果好的问题」，而不是「值钱的问题」。

第三关，可行性检验：以我们现在的能力，和这个客户的数据现实，能做到几分？这一关最容易被热情淹没。有两个必须现场回答的问题：数据在哪、什么状态？答案经常比想象糟——分散在七个系统里、三个版本对不上、最权威的那份在某个老员工私人的表格里。以及，这个问题需要的准确率门槛是多少？「99% 可用」和「90% 可用」之间隔着数量级的工程投入，而很多业务场景其实 90% 加人工复核就是最优解——判断这一点需要的不是技术，是对业务后果的理解。

三关都过，才算摸到问题与方案的契合。而这三关，必须在客户现场过——坐在总部会议室里对着二手信息做判断，是本章一切错误的总根源。

3.3 2.3 拒绝昂贵的「概念验证坟墓」

2025 年，一家做企业人工智能落地的中国服务商，在官网上写了一段颇为狠辣的话，劝退潜在客户：场景还没验证的，先去参加演示活动；数据一张表就能导出的，轻量服务就够了；只是想了解人工智能的，用免费的方式。最后一句最狠：「FDE 是重投入，我们宁可你晚一点开始，也不希望你在错的时机开始。」（出处见附录 C）

这段话值得每个做企业人工智能的人抄在墙上。它道出了一个反销售直觉的真理：拒绝错误的项目，是 FDE 模式最重要的盈利能力。

错误的项目为什么危险？因为 FDE 的成本结构是前置的——最优秀的工程师、最贵的差旅、最长的现场投入，全部发生在回款之前。一旦陷入泥潭，不是亏一单的问题，是整支精英团队被拖住、机会成本雪崩的问题。

前 Palantir 工程师 Barry 回忆，公司当年「在客户试点上烧掉过数百万美元，很多项目的利润率字面意义上是负无穷，因为我们是免费做的」。他紧接着补充的视角才是重点：Palantir 烧得起，是因为它把试点当研发组合来投资——像风险投资一样，多数下注归零没关系，成的那些要赢回一切。但如果你既没有它的资本厚度，又没有「把失败试点转化为产品资产」的机制，那么每一个错误的试点，都是纯失血。（出处见附录 C）

所以 FDE 团队需要一套「拒绝的机制」，而不只是拒绝的勇气。三条可操作的防线。

防线一：概念验证必须有「毕业标准」 。每个验证项目启动时就写明：多少周后、用什么指标、达到什么数值，项目「毕业」进入付费部署；达不到，双方体面散伙。Palantir 的训练营把这套逻辑做到了极致——它不是概念验证，是概念验证的工业化替代品：一到五天、客户带真实数据、现场做出能部署的原型、高管当场拍板。要么几天内见真东西，要么不要开始。传统概念验证之所以沦为坟墓，恰恰因为它「无限期、无指标、无裁判」。
防线二： 警惕三类高危信号。综合从业者的经验，三类信号出现两个以上就要高度警惕。一是「没有土地的所有权」——项目在公司内部没有明确的业务方负责人，只有信息部门在对接；信息部门关心的是合规与稳定，而合规与稳定从来不是做新项目的理由。二是「只许看、不给碰」——客户要求你先证明能力，但拒绝提供真实数据；没有真实数据的验证，注定做出自欺欺人的假阳性。三是「宇宙级需求」——第一次会议就要「覆盖全公司所有场景」的客户，往往还没准备好做任何一个场景。
防线三： 给「拒绝」留个体面的台阶。拒绝不等于断交。最好的做法是把「现在不做」翻译成「什么时候做」：「这个场景的数据基础还差三件事，我们建议先做另一个场景，顺手把这三件事补齐，下个季度再来。」把拒绝包装成路线图，既守住产能，又维护关系——第 3 章的「灯塔客户筛选」会沿着这条线继续。

3.4 2.4 痛点，催生部署的第一原动力

正确的问题从哪来？教科书会告诉你：从需求调研来。FDE 的现场经验会告诉你：从痛来。而痛不会出现在会议室里，只会出现在工作现场。

这套方法，Palantir 二十年前就用血写出来了。回看 1.2 节那个伊拉克战场的故事：士兵需要路边炸弹预警工具——这个需求在任何访谈里都问不出来，因为士兵不知道「可以向软件要这个」，他们以为这就是巡逻生活的一部分。痛点是被工程师「看见」的，不是被用户「说出来」的。驻场工程师跟着巡逻队出任务，亲眼看到车队在可疑路段前的犹豫与恐惧，才有了那个改变战场的简陋地图工具。

这个方法在人类学里有名字，叫「参与式观察」；在丰田生产方式里叫「现地现物」——到现场去，看实物，得实情。FDE 把它变成了一套可操作的田野方法，我称之为「影子工作法」。

跟着真实用户，过完他真实的一天。不是采访他，是坐在他旁边看他工作——看他打开哪些系统、在哪些电子表格之间复制粘贴、在哪些环节皱眉头、绕过哪些「官方流程」。OpenAI 的 FDE 团队在约翰迪尔项目里就是这么做的：飞到爱荷华州，跟着农艺专家和农场主下地，看他们如何做施药决策、看哪些信息真正进入决策、看季节死线如何支配一切。那句被反复引用的从业者箴言，说的就是这套方法的发现对象：「难的是找到那个没人写进文档的工作流、人们真正信任的那个数据源、以及知道流程为什么是那样的人。」这三样东西，每一样都只能在现场找到。

重点观察「变通」，而不是「流程」。官方流程图告诉你组织「应该怎么运转」，变通告诉你组织「实际怎么运转」——每一个变通，都是一个未被满足的痛点在尖叫。员工为什么坚持把数据导出到表格里再算一遍？为什么部门里公认「这张表要找小王」？为什么明明有数据系统，决策会前总有人手动核对数字？变通是组织的疤，每道疤下面都是一次系统的失败，也都是 FDE 的机会。

警惕「翻译过的痛点」。你听到的需求，如果是经客户信息部门、采购部门、咨询顾问转述的，每转一手就失真一次——信息部门会把业务痛点翻译成技术需求（「需要一个数据平台」），采购部门会把它翻译成合规条目（「需要满足某某标准」）。传统软件项目的灾难往往就从这里开始：厂商对翻译件负责，而不是对痛点本身负责。所以你的第一要务，是绕过翻译件，直达疼痛的神经末梢。这也是 Palantir 双人模型里「回声」的核心职责——理解客户的「使命」而不是「需求」：需求是痛点的二手叙述，使命才是痛点的一手出处。

找到了真痛点，下一步是用最小的代价验证：我们的方案，真能止这个痛吗？

3.5 2.5 用「最小可行部署」验证价值

互联网创业方法论里有个著名概念叫 MVP（Minimum Viable Product，最小可行产品）：用最小的产品验证市场的需求。FDE 对应的概念，我称之为 MVD（Minimum Viable Deployment，最小可行部署）——用最小的工程投入，在客户的真实环境里，对真实的痛点，验证一次价值的真实发生。

一字之差，差别在骨头里。MVP 验证「要不要做这个产品」，裁判是市场；MVD 验证「这个方案在这个客户身上能不能产生价值」，裁判是这个具体客户的具体业务。一个在十个客户那里验证成功的方案，在第十一个客户那里照样可能失败——数据基础不同、组织惯性不同、痛点的形状不同。这就是企业交付的残酷之处：价值不能继承，只能逐个验证。

MVD 有三条军规。

第一条： 真实数据，没有例外。用客户提供的「脱敏（隐去敏感信息）的样例数据」或自己构造的演示数据做验证，是概念验证坟墓的第一块砖。真实数据里藏着一切魔鬼：字段含义与文档不符、三成的空值、三年前的编码规则，以及最要命的——数据本身记录着错误的流程。- 这条军规怎么落地： Palantir 的训练营把「客户必须带自己的真实业务数据来」写进规则，约翰迪尔项目把「评审数百个真实作业案例」放在建模之前。在假数据上成立的方案，只是精心制作的自我安慰。
第二条： 缩小切口，而不是缩小野心。常见错误是把 MVD 理解成「阉割版的大方案」——功能砍掉七成，做得四不像。正确的做法是换一个维度缩小：不砍价值，砍范围。不追求「覆盖全公司的智能客服」，而是「只覆盖退换货这一类工单，但做到端到端、无人干预」；不追求「全集团的供应链优化」，而是「只做这条产线的排产冲突，但每周实实在在省下 20 个人时」。切口小到价值密度足够高，高到业务部门肉眼可见、主动传播。法律人工智能公司 Harvey 的扩张路径就是这个打法的教科书：不做全所铺开，先打透一个全球业务组，让第一批合伙人成为信徒，六个月实战后再横向扩展。
第三条： 定死截止时间，倒逼取舍。MVD 的验证周期应该以「周」计，不是以「月」计。Palantir 的训练营一到五天，Sierra 公开报道的最快上线案例四周，Decagon 的典型部署四到八周。截止时间的意义不在快，而在强迫双方做诚实的取舍：凡不能在这几周里体现价值的部分，都还不是核心价值。一个六个月的「最小验证」，几乎必然重新长成一个什么都想要的大项目——那就是概念验证坟墓的又一次开工。

3.5.1 训练营：MVD 的工业化

Palantir 在 2023 年推出的 AIP 训练营（AIP Bootcamp），值得作为「MVD 工业化」的标杆单独拆解——它是目前唯一被大规模验证过的 MVD 流水线。

先看数据：从 2022 年的不足百场试点起步，场次连年倍增，媒体追踪显示累计完成场次早已过千，2025 年高峰期平均每天近 6 场；企业软件传统的销售周期（九到十二个月）被压到数周；美国商业收入 2025 年第四季度同比增长 137%，公司公开把增长几乎全部归因于此。（出处见附录 C）

再看流程，它把 MVD 拆成五个标准化动作。第 0 天，筹备：双方锁定一个极其聚焦的核心战场——「优化某条产线排产」「降低库存周转天数」，拒绝一切宏大叙事。第 1 天，接入：打通客户的现有系统，把孤立数据抽出来，构建初步的本体模型。第 2 到 3 天，构建：FDE 与客户技术人员背靠背写代码、配规则，把大模型接入业务流，做出能执行真实动作的自动化工作流。第 4 到 5 天，演示与拍板：产出的不是报告，是活的软件界面，业务高管亲手点击，看着人工智能基于自己公司的数据给出建议——震撼过后，直接进入商务谈判。

训练营的精妙，在于它同时解决了 MVD 的三个经典难题：真实数据问题（客户自己带来）、死线问题（五天封顶）、裁判问题（高管亲手用）。它还顺手解决了一个更深的问题——信任。让决策者亲手操作基于自己数据的系统，胜过一百页可行性报告。

训练营之后的合同，签得有多快？Palantir 在财报电话会上披露过一组真实节奏，快到同行都未必信：一家大型医疗公司，12 月参加训练营，五周后签下五年期、年合同额 2600 万美元的协议；一家全球银行，试点一个月后先签 200 万美元初始合同，四个月后扩展为三年期、年合同额 1900 万美元；连锁药房 Walgreens 先在 10 家门店试点，店内运营效率提升 30%，然后八个月内推到 4000 家门店，人工智能驱动的端到端工作流每天自动处理原本要人工作出的约 3840 亿次决策。（出处见附录 C）这组数字回答了「MVD 之后会发生什么」：验证通过的项目不是慢慢长大，是跳跃式放大——客户在五天里已经亲眼见过价值，剩下的只是商务流程。

当然，这套模式的复制有门槛：背后得有成熟的平台底座，否则五天连环境都搭不起来。对没有平台的团队，可执行的简化版是「两周冲刺验证」：第一周进场、接数据、定指标，第二周做出一个只解决单点问题、但能跑真实业务的原型，周末向业务方演示并当场决定进退。形式可以裁剪，军规不能裁剪。

3.6 2.6 早期要不要迁就客户的现有环境

MVD 阶段有一个几乎每个项目都会撞上的分歧：客户的现有技术环境——那堆跑了二十年的老系统、部门自建的小工具、还有严格的安全合规边界——我们的方案应该在多大程度上迁就它？

两派都有道理。「迁就派」说：在客户的真实约束里验证，才是真实的验证。「重构派」说：为一个即将被替换的旧环境做深度适配，是把宝贵的验证期浪费在注定要扔掉的工程上。

FDE 的实践给出一条中间路线：数据上兼容旧系统，架构上绝不迁就旧系统——我称之为「读旧写新」。

数据层面，深度兼容旧环境。客户的数据在哪里，就从哪里读——哪怕它在一台老式主机里、在共享盘的表格里、在某个古老系统的私有接口里。金融业的老式大型机、医疗行业数百家诊所的异构系统，历来是部署工作的核心战场。读数据的兼容没有捷径，因为数据是验证价值的前提，而数据永远不会为了迁就你的架构而搬家。好消息是，这一层工作正在被人工智能本身改变：过去需要人工解读的字段映射、跨系统搬运、没有接口的老系统取数，现在可以大量交给智能体完成——比如用浏览器智能体模拟人工操作，从没有接口的老系统里取数。集成成本正在数量级地下降。（出处见附录 C）

架构层面，坚决不做旧环境的寄生体。验证期的系统应该运行在自己可控的边界内，通过接口与旧系统交互，而不是把代码写进旧系统里。理由有三：验证期方案本身有一半以上的概率被推翻重写，寄生越深浪费越大；写入旧系统要走客户的变更管理流程，周期以月计，与 MVD 的周级节奏根本冲突；保持「可撤离」的姿态，本身就是谈判筹码和诚实姿态——FDE 做完会走，寄生体永远走不了。

流程层面，顺从人的习惯，而不是系统的习惯。这是最容易被技术团队搞反的一条。技术环境可以强硬，人的习惯必须顺从。如果业务用户的核心动作发生在表格和邮件里，MVD 的界面就应该出现在表格插件和邮件里，而不是要求用户登录一个崭新的门户。OpenAI 在西班牙对外银行的部署，从 12 万员工已经在用的 ChatGPT 界面切入，而不是另起炉灶，就是顺从习惯的典范。记住 2.1 节那条死因：员工不愿采用新工具，在五大路障里排第一。新系统最大的敌人不是旧系统，是旧习惯。

3.7 2.7 「行胜于言」的用户调研

本章最后，把镜头拉回方法论的源头，谈谈 FDE 式的用户调研与传统调研的分野。

传统调研的信条是「问」：问卷、访谈、焦点小组。FDE 的信条是「看」和「做」——行胜于言。原因有三，层层递进。

第一层：客户不知道自己要什么。这不是贬低，是认知规律。面对全新品类——2004 年的情报分析软件，2025 年的人工智能智能体——用户没有参照系来描述需求。Palantir 的演示循环之所以有效，恰恰因为它不问「你要什么」，而是说「这是我做的东西，你来说说哪里不对」。人对「哪里不对」的判断力，远强于对「要什么」的想象力。给方案挑毛病是人类的天赋，凭空描述理想方案是人类的短板。

第二层：客户说的和做的，是两回事。2.1 节那个律师群体的例子是最好的证明：问卷调研「是否愿意使用专业法律人工智能」，采购部门会告诉你意愿强烈——毕竟刚花五万美元买了工具；但观察律师们的实际行为，他们在用 ChatGPT 起草合同。企业语境下，「说」被太多因素污染：政治正确、对供应商的客气、对自身角色的维护。只有行为不会撒谎。影子工作法观察行为，MVD 测量行为，都建立在「做比说真」的基础上。

第三层：最高质量的调研，发生在共同劳动中。访谈里，客户是「被研究对象」，警惕而表演；并肩干活时，客户是同事，松弛而真实。训练营里 FDE 与客户技术人员背靠背写代码的那两三天，交换的信息密度超过任何正式调研——客户会在调试的间隙随口说出「其实这个字段我们从来不信」「这条流程表面走系统，实际还是打电话」。这些话在正式访谈里永远不会出现，因为它们看起来「不正式」。但它们恰恰是部署成败的关键情报。

还有一个 2026 年的新变量值得补在这里：访谈本身也在被 AI 改造。特赞 CTO 丁鑫栋分享的做法是，不再发结构化问卷，而是用 Agent 对企业全员做自主访谈——根据不同的场景和不同人的实际痛点，做差异化沟通，最后汇总出一张「每条产品线处于什么阶段、痛点是什么、适合用什么方式推进」的全局诊断图。问卷问出的是答案，访谈聊出的是痛点——AI 把后者的成本打了下来。（出处见附录 C）

三层合起来，FDE 的调研方法论可以浓缩成一句话：用影子工作法找到痛点，用最小可行部署验证方案，用共同劳动赢得真相。

到这里，正确的问题已经锁定，价值已经初步验证。下一个战场，是把验证过的单点价值变成一纸真正的合同，以及一段真正开始的关系——如何赢得客户。