客户第一次见面说：「我们想做一个销售 Agent。」
多数团队会立刻追问：想用哪个模型？知识库有多少文档？要不要私有化？
「FDE 前线」最近发了一篇文章，给出了另一套问法——20 个问题，分五组：业务结果、真实流程、数据与系统、风险与权限、采用与责任。第一问就不是「用什么模型」，而是「这条流程最终要产生什么业务结果」。
这 20 问在网上被当成销售技巧清单转发。但我读完后的判断不一样：这不是一份访谈提纲，而是一份组织上下文的采集协议。它真正的价值，和它最大的问题，是同一件事——它太贵了。
一、先说这 20 问为什么值得认真对待
我把文章里最有分量的三个设计拆开看。
第一，答案要分证据等级。 同一个问题，客户可能给出三种性质完全不同的回答：
「上个月处理了 4280 张工单，平均解决时间 16 小时」——事实，可以回系统核验。
「客服觉得查政策最浪费时间」——一线判断，需要跟岗和抽样验证。
「希望上线后效率提升一倍」——愿望，不能直接当项目基线。
文章要求 FDE 在会议记录里给每个答案标注证据等级。这一条看似琐碎，其实是在防企业 AI 项目最常见的死法：在客户的愿望上做方案和报价。
第二，区分名义流程和实际流程。 审批写在系统里，真正的优先级在微信群确认；数据名义上归某部门，接口权限却由集团 IT 管理。文章的原话是：把这些组织现实问出来，「往往比多确认一个模型参数更能预测项目能否落地」。
这一点我在 AI 让每个人都变快了，为什么公司没有变快 里从另一个方向撞上过：企业发 token 月花千万，个人都变快了，流程还是人传人。人传人意味着真实流程不在任何系统里——它只在人的聊天记录和肌肉记忆里。20 问的第六问「能不能现场带我走一遍最近一个真实案例」，就是专门用来抓这个东西的：不听 SOP，让执行者打开真实系统从头走一遍，FDE 才能看到复制粘贴、私人表格和群内确认。
第三，也是最容易被忽略的一点。 文章引用了 OpenAI 当前 FDE 岗位的定义：discovery、technical scoping、system design、build、production rollout 放在同一个人的端到端责任里。我去查了 OpenAI 官网的招聘原文，确实如此——「You will own discovery, technical scoping, system design, build, and production rollout」。
这句话的分量在于：FDE 做 discovery 不是为了交接，是为了自己建。 问问题的人和写代码的人是同一个人，所以每一个问题都直接服务于「这个东西能不能跑起来」。这和售前顾问的调研有本质区别——售后的调研服务于签单，FDE 的调研服务于交付。
到这一步，20 问的价值很清楚：它把价值、流程、依赖、风险、责任五件事变得可见。这正是我在 钉钉数字员工架构与落地实践 里说的数字员工落地的四个组织问题——身份、知识、权限、责任。20 问等于把这四个组织问题翻译成了一份可以逐条问的清单。
二、但 20 问有一个致命问题：它太贵了
现在说它的致命问题。
文章自己给出了这套流程的成本：一次 60 到 90 分钟的首次会议，前 15 分钟问目标，中间 40 分钟走真实案例，随后 20 分钟确认系统与风险，最后 10 分钟复述下一步。然后呢？然后是流程跟访、数据抽样、安全评审、评估工作会——每一项都要责任人和日期，都要把一线、技术、风险相关方分别拉进后续会议。
算一笔账：一个像样的 discovery，至少是 1 次首会 + 3 到 5 次专项工作会 + 若干次跟岗，一个 FDE 一周的产能，最多覆盖一两个客户。
这个成本结构不是新问题。Palantir 用 FDE 模式服务了二十年，服务的是最大的几百家客户——我在 Palantir 从本体长到 Agent，我们从 Agent 长回本体 里分析过它的模式。二十年的交付沉淀，换来几百家客户的深度覆盖。这不是 Palantir 的失败，这是人肉 discovery 的物理上限。
再看一个更微妙的信号：这篇文章本身就是「FDE 中国社区」写的。一个社区的成立、一份 20 问清单的传播，说明 FDE 的知识正在被 codify——从个别高手的隐性经验，变成可以流传的显性清单。知识一旦被写成清单，下一步必然是被写成代码。 这是所有专业服务的宿命：审计有审计底稿，尽调有尽调清单，咨询有方法论文档——清单出现的地方，就是产品化开始的地方。
于是矛盾出现了：
人肉 FDE 模式
─────────────
客户 ──→ FDE 驻场访谈 ──→ 人工整理 ──→ 方案
成本：周 / 客户 覆盖：几百家
产品化模式
─────────
客户 ──→ 平台采集 + 计算 ──→ 人工补关键问 ──→ 方案
成本：小时 / 客户 覆盖：千万家
钉钉服务的是上千万家企业。这个体量下，「一家配一个 FDE」在数学上就不成立。所以问题不是「要不要学 Palantir 招 FDE」，而是：怎么把 20 问从人的技能，变成平台的特性。
三、Discovery 产品化的三级阶梯
先立一个反方。最聪明的读者会在这里反驳我：
「Discovery 本质上是人的工作。名义流程和实际流程的差异藏在人际政治里，最有价值的问题是顺着客户回答现场追出来的追问——这怎么做成产品？把 20 问做成表单，客户就会用名义流程的 SOP 来填表，你拿到的恰恰是最没价值的东西。」
这个反驳是对的——如果产品化的意思是「做一张问卷」。所以我把产品化拆成三级，每一级保留不同比例的人：
| 层级 | 谁问 | 谁答 | 人的位置 | 成本 |
|---|---|---|---|---|
| ① 人问，工具记 | FDE | 客户 | 全程在场 | 省的是会后整理 |
| ② 工具先答，人问剩下的 | 平台 + FDE | 系统数据 + 客户 | 只问人才能答的 | 省一半会议 |
| ③ 组织可查询 | 平台 | 组织本身 | 只处理例外 | 发现变成后台任务 |
第一级：人问，工具记。 FDE 照常访谈，但访谈记录不再靠人回来整理，而是实时结构化成一份 discovery 对象——每个答案自动标注证据等级，每个未知项自动变成待验证任务，会后五项交付（问题陈述、流程地图、系统清单、AI/人工边界、下一步计划）自动生成初稿。文章里说「未知项本身就是发现成果，只要它被记录成验证任务，而不是被乐观假设掩盖」——把这句话变成产品，就是第一级。
这一级的关键数据结构很简单，但它是后面两级的地基：
from dataclasses import dataclass, field
from enum import Enum
from datetime import date
class Evidence(Enum):
"""答案的证据等级——决定它能不能进方案和报价。"""
SYSTEM_VERIFIED = "系统可核验" # 事实：能回系统查
FIELD_OBSERVED = "一线判断" # 需跟岗抽样验证
ASPIRATION = "目标愿望" # 不能当基线
@dataclass
class DiscoveryAnswer:
"""一个问题的回答，带着它的证据等级和责任归属。"""
question_id: int # 20 问编号
answer: str
evidence: Evidence
owner: str # 谁对这个答案负责
needs_verification: bool = False # 未知项 → 验证任务
@dataclass
class DiscoveryNote:
"""一次客户发现会的完整产出——不是纪要，是可执行对象。"""
problem_statement: str # 一句话问题陈述
answers: list[DiscoveryAnswer] = field(default_factory=list)
unknowns: list[str] = field(default_factory=list) # 客户待提供
fde_to_verify: list[str] = field(default_factory=list) # FDE 待验证
risk_decisions: list[str] = field(default_factory=list) # 需安全/法务决策
next_steps: list[tuple[str, str, date]] = field(default_factory=list)
# generated by hugo AI
注意 unknowns、fde_to_verify、risk_decisions 三个字段——这正是文章要求的会后交付里「把未知内容单独列出，并区分客户待提供、FDE 待验证、需安全或法务决策」。纪要是一次性的，对象是可以被下一次会议读取的。
第二级：工具先答，人问剩下的。 20 问里有一大半其实不需要问人。第三问「这项工作每天发生多少次」、第七问「最常见的例外是什么」、第八问「哪一步最慢」——如果客户的流程本来就跑在平台上，这些答案系统里就有：审批量、工单量、每个节点的停留时长、被打回的次数。FDE 进场前，平台先把这些空填好，会议时间全部留给只有人才能回答的问题：谁是真正的 Owner、哪个来源是权威版本、哪些动作必须人批准。
这一级我们其实已经迈出过第一步。在 FDE 基础设施实战：一天做出销售 Agent 矩阵 里，小林到客户现场用的不是笔记本，是「SOP 采集器」——跟着销售总监走一遍流程，把每个环节的耗时、等待、瓶颈实时标进去。那还是人在采集。下一步是让平台里已经存在的流程数据自己说话，采集器只补平台看不见的部分。
第三级：组织可查询。 到这一级，discovery 不再是「问出来」，而是「算出来」。组织跑在平台上，意味着组织架构、审批链、消息流、任务流转本身就是数据——谁批什么、批多久、卡在哪、绕道去了哪个群，全部可查询。20 问里关于频率、例外、瓶颈的问题，变成对组织运行数据的查询；FDE 进场时手里已经有一份预填了 80% 的发现报告，他的工作从提问变成核实。
这一级听着激进，其实方向是现成的。Palantir 的答案是 Ontology——把企业变成可查询的语义层，Agent 从本体里长出来，我在 #358 里写过。区别在于：Palantir 的 Ontology 是 FDE 驻场几个月手工建出来的，所以它只能服务几百家客户；而对一个组织本来就在其上运行的平台，Ontology 是副产品——组织每天的使用行为，就是在持续回答那 20 个问题。
四、人留在哪里
三级阶梯不是要把人挤出去，恰恰相反——它要回答「人应该留在哪里」。
文章自己给了边界：第四组问题（错误的最坏后果、数据红线、必须人批准的动作、升级路径）「必须尽早识别需要谁进入下一轮」。这些问题的答案不在任何系统里，它们在法务的判断里、在安全团队的红线里、在业务负责人愿意承担的责任里。权限归属、数据红线、组织政治，永远问不出来，只能由人确认。 这是第三级的天花板，也是 FDE 这个岗位不会消失的原因。
所以产品化的终点不是无人化，而是一个明确的分工：
平台负责把 20 问里能被数据和流程回答的部分变成查询；人负责剩下的部分——确认权威、划定红线、承担责任。
这和数字员工的上岗逻辑是同一件事。数字员工的本分率 里我说过，敢不敢给它发工号，才是真正的上岗考试。Discovery 产品化也一样：平台能替人问 16 个问题不难，难的是它清楚地知道剩下 4 个问题必须由人来答。
五、企业 AI 竞争的不是模型，是谁先把「问」变成「查」
回到开头那句「我们想做一个销售 Agent」。
文章说得好：「销售 Agent」可能指会后整理纪要，也可能指线索评分、自动跟进、报价生成，甚至端到端推进商机——不同目标需要完全不同的数据、权限、风险和投入。FDE 第一次见客户的任务，是判断模糊愿望背后有没有值得解决的真实工作流。
这个判断能力，今天是稀缺的、昂贵的、按周计费的。谁先把它变成按小时计费的工具，再变成按查询计费的平台特性，谁就能服务那个「几百家」之外的市场——那才是千万家企业所在的地方。
大多数企业 AI 的终点是人，Palantir 的终点是业务 里，我说企业 AI 的分水岭在于 AI 连接的是搜索框还是业务本体。现在可以往前推一步：连接业务本体之前，先得有人把本体问出来——而这份问卷，不该由人一个一个问。
你们公司的 AI 项目，第一次需求调研是带着清单去的，还是带着模型参数去的？欢迎留言聊聊。