第 2 章 解决正确的问题
「在错误的问题上，一切执行力都是浪费。」
2.1 概念验证坟墓的解剖报告
硅谷有个词，叫「概念验证坟墓」（PoC purgatory——PoC 即 Proof of Concept，概念验证；purgatory 直译「炼狱」）。进去的项目出不来：没死透，不能宣告失败；没活成，不敢加大投入。于是它们在季度汇报里一年一年地「持续推进中」，像一屋子插着管子的病人。
麻省理工学院 NANDA 实验室的研究者在《生成式人工智能的鸿沟》报告里，给这座坟墓做过一次系统解剖。他们归纳出企业人工智能项目规模化路上的五大路障，按出现频率排下来：
- 员工不愿用新工具——而这些人每天私下用 ChatGPT 用得飞起
- 对模型输出质量的担忧
- 糟糕的用户体验
- 缺乏高管支持
- 变革管理困难
这份清单里缺席的东西更值得看：模型不够聪明、算力不够便宜、技术不够先进——都不在列。杀死这些项目的，几乎全部发生在「问题定义」和「组织现实」层面，不是技术层面。
一家企业花五万美元采购了专业的合同分析工具，功能清单洋洋洒洒。但公司的一位资深律师就是不用——她继续用免费的 ChatGPT 起草合同。理由很朴素：买的那个工具，摘要太死板，没法按她的习惯定制。采购部门的报表上写着「已部署」，真实的日常却是官方系统空转、员工绕道而行。（出处见附录 C）
这个细节揭示了第一大路障的真正成因：不是员工守旧，是消费级产品把他们的胃口养刁了——每天在家用得飞起的人，没法忍受办公室里的「人工智障」。
还有一组更扎心的对比：与外部专业供应商合作的项目，成功率约为内部自建的三倍。为什么外部团队反而胜率高？他们输不起——按结果收钱的人，定义错问题的代价是自己买单。
日本一家公司的内部项目就是典型的反面教材：抽调三四名最强工程师组成攻坚组，演示惊艳、领导点头，唯独从第一天起就没有人能回答「这套系统的好，由什么标准衡量」。半年后项目从汇报材料里悄悄消失，没有人宣布它失败，它就这样自然死亡了。（出处见附录 C）
这就是第一性原理：企业里的错误问题，比想象中多得多。所以写第一行代码之前，先得确保你在解决正确的问题。
2.2 PSF：找到问题与方案的契合
互联网创业方法论里有个核心概念叫 PMF（Product-Market Fit，产品与市场的契合）：产品对了，市场自己会拉动增长。在 FDE 的世界里，对应的单位不是「产品与市场」，而是「问题与方案」——我称之为 PSF（Problem-Solution Fit，问题与方案的契合）。
区别微妙而关键。PMF 问「我的产品有没有市场要」，视角在供给方；PSF 问「客户这个具体的问题，值不值得、能不能被我们的能力解决」，视角在需求方。一个企业客户内部，可能有几百个「人工智能能做点什么」的机会点，但真正值得做的，必须同时过三关。
第一关，痛点检验：这个问题，是不是某个具体的人的具体的痛？注意是两个「具体」。「提升客服效率」不是痛点，是方向；「客服主管每周一早上要花三小时，从四个系统里手动汇总上周的升级工单，而她真正的工作应该是分析升级原因」——这才是痛点。
麦格鲁给过一个更锋利的标准：去解决首席执行官最关注的五个问题之一。理由很现实，只有这个量级的问题，才能帮你碾过企业内部的官僚阻力。Sierra 的智能体工程负责人默勒的标准是同一个原则的另一种说法：只接两类问题——真的难的，和真的有业务影响的。只有难没有影响，是炫技；只有影响不难，轮不到你。
第二关，经济性检验：解决这个问题，值多少钱？很多痛点是真痛，但不值钱；算不清这笔账的项目，做了也活不过下一个预算季。
你可以粗略地算：这个问题每周吃掉多少人时？折合多少人力成本？出错一次赔多少？省下来的人手能去干什么？
Palantir 的训练营干脆把这关前置——客户开始前就得锁定「核心战场」、给出量化靶子，「排产冲突降低 30%」「库存周转天数缩短 15%」。NANDA 的报告里有个被广泛引用的发现，恰好说明这关多容易被跳过：超过半数的企业人工智能预算投向前台的销售营销，回报却集中在后台的合同审查、采购、风控这些「不性感」的地方——大家都在解决「演示效果好的问题」，而不是「值钱的问题」。
第三关，可行性检验：以我们现在的能力，和这个客户的数据现实，能做到几分？这一关最容易被热情淹没。有两个必须现场回答的问题：数据在哪、什么状态？答案经常比想象糟——分散在七个系统里、三个版本对不上、最权威的那份在某个老员工私人的表格里。
OpenAI 的 FDE 负责人科林·贾维斯用一句话概括过现场经验：客户在选题阶段描述的问题，常常和地面上真实的数据与系统状况对不上。
第二个必须现场回答的问题：准确率门槛是多少？「99% 可用」和「90% 可用」之间隔着数量级的工程投入，而很多业务场景其实 90% 加人工复核就是最优解——判断这一点需要的不是技术，是对业务后果的理解。
「能做到几分」不是猜出来的，是测出来的——所以老练的团队把「先建考题」放在「上线」之前。摩根士丹利就是这么干的：从三个具体场景起步，让理财顾问和工程师逐条给模型输出打分，分数直接回流到迭代里，此后每天把旧考题重跑一遍——防止模型悄悄退步——在质量下滑抵达一线顾问之前拦截。
OpenAI 官方面向企业的部署指南列了七条经验，第一条同样是「从测试题库开始」。为什么要每天跑？因为人工智能系统出错时往往不报错，它只是悄悄变得不靠谱——等用户自己察觉，信任的账单已经到期了。
三关都过，才算摸到问题与方案的契合。而这三关必须在客户现场过——前面那些错误，大多是从总部会议室里对着二手信息做判断时长出来的。
而且这三关不是进场前过一遍就一劳永逸，这套检验得变成一种日常纪律。企业支出管理公司 Ramp 给自家 FDE 定的第一条原则就叫「永远在选题」：不能对客户的要求照单全收，每接一个需求，先收集上下文、验证假设、评估对整体排期的影响。这条纪律是他们交过学费换来的——曾经为一个客户做了几周的安卓端功能，交付前才发现这家公司内部强制只用 iPhone，几周工作全部作废。选题纪律松懈的代价，以周计算。
2.3 拒绝昂贵的「概念验证坟墓」
2025 年，聚焦不动产与设施管理行业的中国服务商启盟科技，在官网上写了一段颇为狠辣的话，劝退潜在客户：场景还没验证的，先去参加演示活动；数据一张表就能导出的，轻量服务就够了；只是想了解人工智能的，用免费的方式。最后一句最狠：「FDE 是重投入，我们宁可你晚一点开始，也不希望你在错的时机开始。」（出处见附录 C）
这段话说出了一个反销售直觉的事实：拒绝错误的项目，本身就是 FDE 模式的盈利能力。
错误的项目为什么危险？因为 FDE 的成本结构是前置的——最优秀的工程师、最贵的差旅、最长的现场投入，全部发生在回款之前。一旦陷入泥潭，不是亏一单的问题，是整支精英团队被拖住、机会成本雪崩的问题。
前 Palantir 工程师 Barry 回忆：「我们烧掉数百万美元做客户试点，很多项目利润率字面是负无穷，因为我们是免费做的。」他紧接着补充的视角才是重点：Palantir 烧得起，是因为它把试点当研发组合来投资——像风险投资一样，多数下注归零没关系，但成的那些要赢回一切。可如果你既没有它的资本厚度，又没有「把失败试点转化为产品资产」的机制，那么每一个错误的试点，都是纯失血。（出处见附录 C）
所以 FDE 团队需要一套「拒绝的机制」，而不只是拒绝的勇气。三条可操作的防线。
防线一：概念验证必须有「毕业标准」。每个验证项目启动时就写明：多少周后、用什么指标、达到什么数值，项目「毕业」进入付费部署；达不到，双方体面散伙。Palantir 的训练营把这套逻辑做到了极致——它不是概念验证，是概念验证的工业化替代品：一到五天、客户带真实数据、现场做出能部署的原型、高管当场拍板。要么几天内见真东西，要么不要开始。传统概念验证之所以沦为坟墓，恰恰因为它「无限期、无指标、无裁判」。
防线二： 警惕三类高危信号。综合从业者的经验，三类信号出现两个以上就要高度警惕。一是「无主之地」——项目在公司内部没有明确的业务方负责人，只有信息部门在对接。信息部门关心的是合规与稳定，而合规与稳定从来不是做新项目的理由。二是「只许看、不给碰」——客户要求你先证明能力，但拒绝提供真实数据。如果没有真实数据的验证，做出的成功就只是假象。三是「宇宙级需求」——第一次会议就要「覆盖全公司所有场景」的客户，往往还没准备好做任何一个场景。
防线三： 给「拒绝」留个体面的台阶。拒绝不等于断交。最好的做法是把「现在不做」翻译成「什么时候做」：「这个场景的数据基础还差三件事，我们建议先做另一个场景，顺手把这三件事补齐，下个季度再来。」把拒绝包装成路线图，既守住产能，又维护关系——第 3 章的「灯塔客户筛选」会沿着这条线继续。
这三条防线是写给乙方的筛子。翻过来用，就是甲方的自检表——买 FDE 服务的人，比卖 FDE 服务的人多得多。
如果你的项目在乙方眼里亮起「无主之地」信号——集团发文压下来、信息部门牵头、业务部门无人署名——老练的乙方会警惕，而你应该比他更警惕：连供应商都看得出这个项目没有真正的主人。如果你的采购流程天然制造「只许看、不给碰」——安全审查要求对方先证明能力，真实数据却一份也不给——那你买到的验证只能是假象。
如果你写进招标书的需求是宇宙级的——「人工智能赋能全集团」——你吓跑的是最懂行的供应商，吸引来的是最敢吹牛的。
2.4 痛点，催生部署的第一原动力
正确的问题从哪来？FDE 的现场经验是：从痛来。而痛不会出现在会议室里，只会出现在工作现场。
这套方法，Palantir 二十年前就用血写出来了。回看 1.2 节那个伊拉克战场的故事：士兵需要路边炸弹预警工具——这个需求在任何访谈里都问不出来，因为士兵不知道「可以向软件要这个」，他们以为这就是巡逻生活的一部分。这种痛点用户自己说不出来，要靠工程师坐在旁边亲眼看见。驻场工程师跟着巡逻队出任务，亲眼看到车队在可疑路段前的犹豫与恐惧，才有了那个改变战场的简陋地图工具。
这个方法在人类学里有名字，叫「参与式观察」；在丰田生产方式里叫「现地现物」——到现场去，看实物，得实情。FDE 把它变成了一套可操作的田野方法，我称之为「影子工作法」。
跟着真实用户，过完他真实的一天。不是采访他，是坐在他旁边看他工作——看他打开哪些系统、在哪些电子表格之间复制粘贴、在哪些环节皱眉头、绕过哪些「官方流程」。
OpenAI 的 FDE 团队在约翰迪尔项目里就是这么做的：飞到爱荷华州，跟着农艺专家和农场主下地，看他们如何做施药决策、看哪些信息真正进入决策、看农时这道硬期限如何支配一切。他们要打掉的那个旧流程，原本的形态是农艺师挨家挨户打电话给农户、口头给设备使用建议——这种工作流不会出现在任何文档里，只有下地才看得见。那句被反复引用的从业者箴言，说的就是这套方法的发现对象：「难的是找到那个没人写进文档的工作流、人们真正信任的那个数据源、以及知道流程为什么是那样的那个人。」这三样东西，每一样都只能在现场找到。
下到地里还确认了一件会议室里永远说不清的事：农户要的从来不是「人工智能」，是少打药、多打粮——后来长出来的产品，干脆按实际启用技术的英亩数收费，客户付的每一分钱都和他得到的价值对齐。这套计价逻辑搬到中国，对应的变形是按启用的产线、门店或网点数收费——在按项目制验收的采购习惯里，它是「按结果收费」最容易被采购科接受的第一步。
重点观察「变通」，而不是「流程」。官方流程图告诉你组织「应该怎么运转」，变通告诉你组织「实际怎么运转」。
员工为什么坚持把数据导出到表格里再算一遍？为什么部门里公认「这张表要找小王」？为什么明明有数据系统，决策会前总有人手动核对数字？每一个变通背后，都是一个未被满足的痛点、一次系统的失败——也都是 FDE 的机会。
警惕「翻译过的痛点」。你听到的需求，如果是经客户信息部门、采购部门、咨询顾问转述的，每转一手就失真一次——信息部门会把业务痛点翻译成技术需求（「需要一个数据平台」），采购部门会把它翻译成合规条目（「需要满足某某标准」）。
传统软件项目的灾难往往就从这里开始：厂商对翻译件负责，而不是对痛点本身负责。所以你的第一要务，是绕过翻译件，直达疼痛的神经末梢。这也是 Palantir 双人模型里「回声」的核心职责——理解客户的「使命」而不是「需求」：写在需求文档里的，是痛点被转述过的版本；客户的使命，才是痛点本来的出处。
找到了真痛点，下一步是用最小的代价验证：我们的方案，真能止这个痛吗？
2.5 用「最小可行部署」验证价值
互联网创业方法论里有个著名概念叫 MVP（Minimum Viable Product，最小可行产品）：用最小的产品验证市场的需求。FDE 对应的概念，我称之为 MVD（Minimum Viable Deployment，最小可行部署）——用最小的工程投入，在客户的真实环境里，对真实的痛点，验证一次价值的真实发生。
一字之差，差在裁判。MVP 验证「要不要做这个产品」，裁判是市场；MVD 验证「这个方案在这个客户身上能不能产生价值」，裁判是这个具体客户的具体业务。
一个在十个客户那里验证成功的方案，在第十一个客户那里照样可能失败——数据基础不同、组织惯性不同、痛点的形状不同。这就是企业交付的残酷之处：价值没法从上十个客户那里继承，只能在这一个客户身上重新验证。
MVD 有三条军规。
第一条： 真实数据，没有例外。用客户提供的「脱敏（隐去敏感信息）的样例数据」或自己构造的演示数据做验证，是概念验证坟墓的第一块砖。真实数据里藏着一切魔鬼：字段含义与文档不符、三成的空值、三年前的编码规则，以及最要命的——数据本身记录着错误的流程。还有一种更隐蔽的魔鬼：数据里并存着两个互相矛盾、各自「正确」的答案。Salesforce 把自家客服智能体当第一客户用了一年，踩过的最大的坑就是这个——智能体遇到两个打架的答案时会试图调和、甚至编造，一份过时又没被链接的旧页面就足以污染回答。逼得他们回头把公司内部六百多条数据流整合成唯一权威数据源，每个问题只留一个权威答案。
- 落地只有一条硬杠：客户必须带自己的真实业务数据来。 Palantir 的训练营把这条写进规则，约翰迪尔项目把「评审数百个真实作业案例」放在建模之前。OpenAI 内部干脆按这条线划分了两个岗位：解决方案架构师可以用匿名的样例数据做演示和验证，FDE 则必须在客户的基础设施上、用客户的真实数据写生产代码。在假数据上成立的方案，上线那天就会遇到文档里不存在的字段——那时候已经付了真价钱。
第二条： 缩小的是范围，不是价值。常见错误是把 MVD 理解成「阉割版的大方案」——功能砍掉七成，做得四不像。正确的做法是不砍方案的深度，只砍覆盖的面：不追求「覆盖全公司的智能客服」，而是「只覆盖退换货这一类工单，但做到端到端、无人干预」；不追求「全集团的供应链优化」，而是「只做这条产线的排产冲突，但每周实实在在省下 20 个人时」。切口小到价值密度足够高，高到业务部门肉眼可见、主动传播。法律人工智能公司 Harvey 的扩张路径就是这个打法的教科书：不做全所铺开，先打透一个全球业务组，让第一批合伙人成为信徒，六个月实战后再横向扩展。
第三条： 定死截止时间，倒逼取舍。MVD 的验证周期应该以「周」计，不是以「月」计。Palantir 的训练营一到五天，Sierra 公开报道的最快上线案例四周，Decagon 的典型部署四到八周。截止时间的意义不在快，而在强迫双方做诚实的取舍：凡不能在这几周里体现价值的部分，都还不是核心价值。一个六个月的「最小验证」，几乎必然重新长成一个什么都想要的大项目——那就是概念验证坟墓的又一次开工。
这种速度在客户眼里值多少钱？美国坦帕综合医院的首席数字与创新官斯科特·阿诺德（Scott Arnold）在一场行业大会上说得很直白：「我们能用几小时、几天解决问题，而不是几个月、几年。」血液供应商 OneBlood 遭网络攻击时，这家医院用 Palantir 的平台在几个小时内搭出一个血液库存调配应用，随后交给佛罗里达州供其他医院复用。他同时承认 Palantir 的价格有溢价，「但这溢价值得」——周级的节奏，买的从来不只是快，是出事当晚手里就有工具的确定性。
训练营：MVD 的工业化
Palantir 在 2023 年推出的 AIP 训练营（AIP Bootcamp），是目前唯一被大规模验证过的 MVD 流水线。
先看数据：从 2022 年的不足百场试点起步，场次连年倍增，媒体追踪显示累计完成场次早已过千，2025 年高峰期平均每天近 6 场；企业软件传统的销售周期（九到十二个月）被压到数周；美国商业收入 2025 年第四季度同比增长 137%，公司公开把增长几乎全部归因于此。（出处见附录 C）
再看流程，它把 MVD 拆成五个标准化动作。第 0 天，筹备：双方锁定一个极其聚焦的核心战场——「优化某条产线排产」「降低库存周转天数」，拒绝一切宏大叙事。第 1 天，接入：打通客户的现有系统，把孤立数据抽出来，构建初步的本体模型。
第 2 到 3 天，构建：FDE 与客户技术人员背靠背写代码、配规则，把大模型接入业务流，做出能执行真实动作的自动化工作流。第 4 到 5 天，演示与拍板：产出的不是报告，是活的软件界面，业务高管亲手点击，看着人工智能基于自己公司的数据给出建议——震撼过后，直接进入商务谈判。
训练营的精妙，在于它同时解决了 MVD 的三个经典难题：真实数据问题（客户自己带来）、期限问题（五天封顶）、裁判问题（高管亲手用）。它还顺手解决了一个更深的问题——信任。让决策者亲手操作基于自己数据的系统，可行性报告就可以省掉大半。
训练营之后的合同，签得有多快？Palantir 在财报电话会上披露过一组真实节奏，快到同行都未必信：一家大型医疗公司，12 月参加训练营，五周后签下五年期、年合同额（ACV，年度合同价值）2600 万美元的协议；一家全球银行，试点一个月后先签 200 万美元初始合同，四个月后扩展为三年期、年合同额 1900 万美元；连锁药房 Walgreens 先在 10 家门店试点，店内运营效率提升 30%，然后八个月内推到 4000 家门店，人工智能驱动的端到端工作流每天自动处理原本要人工做出的约 3840 亿次决策。（出处见附录 C）这组数字回答了「MVD 之后会发生什么」：验证通过的项目不是慢慢长大，是跳跃式放大——客户在五天里已经亲眼见过价值，剩下的只是商务流程。
这套「先十家、后四千」的节奏，在中国企业语境里的对应物，是先拿下一个事业部、一个厂区或一个区域公司，用使用数据去敲集团的门。
当然，这套模式的复制有门槛：背后得有成熟的平台底座，否则五天连环境都搭不起来。对没有平台的团队，可执行的简化版是「两周冲刺验证」：第一周进场、接数据、定指标，第二周做出一个只解决单点问题、但能跑真实业务的原型，周末向业务方演示并当场决定进退。形式可以裁剪，军规却不能裁剪。
两周的日程可以拆得很具体。第一周：第 1 天进场对齐，和客户一起把「单点问题」写成一句话、把验收指标写成一个数；第 2 到 3 天接数据，只接这个问题需要的最小数据集，权限、脱敏、导出方式当场定死；第 4 到 5 天搭出能查数、能回答的骨架。
第二周：第 6 到 8 天把原型接进真实业务流，让一两个真实用户开始用；第 9 天收集使用痕迹和问题清单；第 10 天演示——不是给信息部门演示功能，是给业务方演示「你那个问题，现在这样了」，然后当场决定：放大、调整，还是散伙。
如果没有平台底座，工具链就用手头现成的凑：模型调商用接口，或拿开源模型做私有化部署；知识检索用开源的向量数据库；流程编排用开源框架；界面用最轻的前端模板。这套「散装」组合足以撑过一次单点验证。唯一要警惕的，是把冲刺开成技术选型大会——验证期选型的唯一标准是快；能不能复用、能不能扩展，是验证通过之后才配考虑的问题。
客户侧也有三项配合要求：1）一个能拍板的业务方负责人在场；2）一个懂数据的内部接口人全程陪同；3）真实数据的访问权限第 1 天就位，而不是「正在走流程」。三条只要缺一条，两周冲刺就大概率滑回传统的概念验证。
2.6 早期要不要迁就客户的现有环境
MVD 阶段有一个几乎每个项目都会撞上的分歧：客户的现有技术环境——那堆跑了二十年的老系统、部门自建的小工具、还有严格的安全合规边界——我们的方案应该在多大程度上迁就它？
两派都有道理。「迁就派」说：在客户的真实约束里验证，才是真实的验证。「重构派」说：为一个即将被替换的旧环境做深度适配，是把宝贵的验证期浪费在注定要扔掉的工程上。
FDE 的实践给出一条中间路线：数据上兼容旧系统，而架构上绝不迁就旧系统——我称之为「读旧写新」。
数据层面，深度兼容旧环境。客户的数据在哪里，就从哪里读——哪怕它在一台老式主机里、在共享盘的表格里、在某个古老系统的私有接口里。金融业的老式大型机、医疗行业数百家诊所的异构系统，历来是部署工作的核心战场。读数据的兼容没有捷径，因为数据是验证价值的前提，而数据永远不会为了迁就你的架构而搬家。
好消息是，这一层工作正在被人工智能本身改变：过去需要人工解读的字段映射、跨系统搬运、没有接口的老系统取数，现在可以大量交给智能体完成——比如用浏览器智能体模拟人工操作，从没有接口的老系统里取数。集成成本正在数量级地下降。（出处见附录 C）
架构层面，坚决不做旧环境的寄生体。验证期的系统应该运行在自己可控的边界内，通过接口与旧系统交互，而不是把代码写进旧系统里。理由有三：1）验证期方案本身有一半以上的概率被推翻重写，寄生越深浪费越大；2）写入旧系统要走客户的变更管理流程，周期以月计，与 MVD 的周级节奏根本冲突；3）保持「可撤离」的姿态，本身就是谈判筹码和诚实姿态——FDE 做完会走，寄生体却永远走不了。
流程层面，顺从人的习惯，而不是系统的习惯。这是最容易被技术团队搞反的一条。技术环境可以强硬，人的习惯却必须顺从。
如果业务用户的核心动作发生在表格和邮件里，MVD 的界面就应该出现在表格插件和邮件里，而不是要求用户登录一个崭新的门户。OpenAI 在西班牙对外银行的部署，从 12 万员工已经在用的 ChatGPT 界面切入，而不是另起炉灶，就是顺从习惯的典范。2.1 节那条死因在这里依然成立：员工不愿采用新工具，在五大路障里排第一。新系统真正难对付的，是用户的旧习惯。
2.7 「行胜于言」的用户调研
最后，把镜头拉回方法论的源头，谈谈 FDE 式的用户调研与传统调研的分野。
传统调研的信条是「问」：问卷、访谈、焦点小组。FDE 的信条是「看」和「做」——行胜于言。原因有三，层层递进。
第一层：客户不知道自己要什么。这是认知规律。面对全新品类——2004 年的情报分析软件，2025 年的人工智能智能体——用户没有参照系来描述需求。
Palantir 的演示循环之所以有效，恰恰因为它不问「你要什么」，而是说「这是我做的东西，你来说说哪里不对」。人对「哪里不对」的判断力，远强于对「要什么」的想象力。
第二层：客户说的和做的，是两回事。2.1 节那个律师群体的例子是最好的证明：问卷调研「是否愿意使用专业法律人工智能」，采购部门会告诉你意愿强烈——毕竟刚花五万美元买了工具。但观察律师们的实际行为，他们在用 ChatGPT 起草合同。
企业语境下，「说」被太多因素污染：政治正确、对供应商的客气、对自身角色的维护。只有行为不会撒谎。影子工作法观察行为，MVD 测量行为，都建立在「做比说真」的基础上。
第三层：最高质量的调研，发生在共同劳动中。访谈里，客户是「被研究对象」，警惕而表演；并肩干活时，客户是同事，松弛而真实。训练营里 FDE 与客户技术人员背靠背写代码的那两三天，交换的信息密度超过任何正式调研——客户会在调试的间隙随口说出「其实这个字段我们从来不信」「这条流程表面走系统，实际还是打电话」。
这些话在正式访谈里永远不会出现，因为它们看起来「不正式」。但它们恰恰是部署成败的关键情报。
访谈本身也在被人工智能改造。营销技术公司特赞的首席技术官丁鑫栋分享的做法是，不再发结构化问卷，而是用智能体对企业全员做自主访谈——根据不同的场景和不同人的实际痛点，做差异化沟通，最后汇总出一张「每条产品线处于什么阶段、痛点是什么、适合用什么方式推进」的全局诊断图。人工智能把这种全员深聊的成本打了下来。（出处见附录 C）
到这里，正确的问题已经锁定，价值已经初步验证。下一个战场，是把验证过的单点价值变成一纸真正的合同，以及一段真正开始的关系——如何赢得客户。