第三课　客户带来的是方案，FDE要找出问题

一套在实验室里正确、在现场里崩溃的系统

Ganesh先讲了一个失败故事。Palantir曾在隔离环境中开发一个代号 Phoenix 的系统，测试表现不错；一放进真实数据，问题同时爆发。空白日期被默认成1970年1月1日，数据分区膨胀成数百万个keyspace，Cassandra的文件句柄和内存行为让系统启动需要极其夸张的资源。

Phoenix的目标并不荒唐。团队想为大型金融客户保存海量交易记录，为了便于按时间清理旧数据，把数据切进按时间分桶的keyspace。只要日期正常，这种设计相当整齐：到了保留期限，就删除对应时间桶，不必逐行扫描。问题在于，真实银行数据里存在空日期。系统把空值回退到Unix时间起点——1970年1月1日——随后尝试为1970年至2013年之间每一个十分钟区间创建时间桶。

结果不是性能稍微下降，而是结构数量爆炸。Ganesh回忆，系统生成了大约230万个keyspace；Cassandra为相关文件句柄预留资源，启动估算需要约14TB内存。产品在设计条件下“完全正确”，到了客户数据上却几乎无法启动。这个事故尤其有启发性，因为失败不来自高深的分布式算法，而来自一个极其普通的脏数据事实：日期可能为空。

这里每个细节都指向同一个教训：产品团队以为自己在处理“典型数据”，现场却从不典型。真实世界里有缺失值、旧格式、组织留下的历史包袱，也有只有实际用户才知道的使用方式。没有现场，工程师优化的是一个想象中的客户。

团队事后才发现，真正缺少的不是又一轮市场调研，也不是更多样本，而是共同承担构建结果的人。产品工程师没有被嵌入客户环境，客户也没有进入设计循环，双方因而都无法在系统架构形成之前暴露那些看似琐碎、实际上致命的约束。

Ganesh借用 Palantir CTO Shyam Sankar 的说法，把FDE称为“伪装的产品战略”。现场不是产品完成后的交付末端，而是产品发现自己应该成为什么的地方。

这句话也是他整场演讲与其他讲者最明显的分歧。FDE后来经常被视为一种高客单价的进入市场策略：派工程师帮助客户使用复杂平台，换取更大的合同。但Ganesh回忆，Palantir在2013年前后建设Foundry时，现场工程首先是产品策略。工程师的考核重点不是促成多少销售，而是能否作为产品团队的延伸，发现新的能力机会，并把现场解法一般化。

他本人曾负责Project Frontline，一项把普通软件工程师轮训为FDE的项目。按他的演讲口径，大约350名后来分布在OpenAI、Anthropic、xAI等AI公司的工程师参加过这套训练。他在Citadel又做过类似工作，让工程师进入投资团队，围绕数据和软件帮助投资经理形成研究与交易能力。两段经历让他坚持：FDE首先要改变产品，而不只是提高交付速度。

47页需求，最后只剩一条消息

一家做运输与调度的客户交来47页需求，希望获得完整的商业智能工具、14项指标和开发环境。照单全收，团队大概要花三个月。

团队最初真的把这份文档当作需求。他们花了四个月讨论范围、页面和指标，却始终没有进入调度员每天工作的地方。后来，一名工程师因为家人恰好住在客户所在地，顺便去了现场，才问出那个改变项目的问题：“周一早上，你拿到这些信息之后，第一件事是什么？”

Ganesh没有继续讨论功能，而是问：“下周一早上，你看见这些信息之后会做什么？”

答案不是分析十四张图表，而是发现某种异常后通知一个人采取行动。于是团队先在四小时内做出一条告警消息。它不完整，却直接抵达了业务动作。客户很快能判断：这是否值得继续？阈值对不对？谁应该收到？什么情况是误报？

调度员的真实流程大致是：查看是否有车辆延误，如果延误会影响后续安排，就打电话给相关调度人员，重新安排货物或运力。47页文档描述的是一套想象中的分析系统，真正决定价值的却只有“发现延误—通知正确的人—采取替代行动”这条链。团队最后先做的不是缩小版BI（商业智能）平台——即用报表和仪表板分析经营数据的系统——而是一条能够触发行动的消息。

这个案例把需求发现从“把名词写清楚”改成“把动作追到底”。Ganesh建议连续追问三件事：

• 你真正想达到的目标是什么？
• 看到结果之后，下一步具体会发生什么？
• 今天没有这套系统时，你怎样绕过去？

如果一个版本能在一天以内完成，就先交付、观察并关闭反馈循环。速度的价值不只是提前上线，而是用真实行为替代会议中的猜测。

Ganesh甚至建议：如果问题能在一天内解决，就先不要把它上升成宏大产品战略，也不必立即召集所有产品经理讨论路线图。把最短方案交到用户手里，看看工作是否真的改变。小交付不会自动产生产品方向，但它能让团队从争论假设转向观察事实。

“谁定义问题，谁就拥有解决方案。”这句话揭示了快速交付的第二层价值。若供应商只接收客户写好的功能清单，就只能在客户设定的框架里竞争；若FDE通过现场理解重新定义问题，并用一个小结果证明判断，客户会逐渐允许他进入更重要的流程。信任不是靠善于聊天获得的，而是靠连续解决真实问题获得的。获得的现场权限越深，产品团队能看见的共性也越多。

小问题为什么通向大产品

FDE容易被“大项目”诱惑。Ganesh的经验恰好相反：先解决一个小而痛的问题，能赢得信任、访问权和更多现场信息。你越快证明自己理解工作，用户越愿意让你靠近真正关键的流程。

他讲了一个Parquet迁移案例。工程上，CSV转换成Parquet可以显著改善存储和处理效率；一位数据质量工程师却长期反对。技术团队不断解释性能，她仍然不同意。FDE到现场后才看到，她每天会双击CSV文件，快速抽查几行数据。Parquet对机器更高效，却夺走了她最重要的质量控制动作。

团队连夜做了一个简单的Parquet查看器。她第二天仍能像以前一样打开和检查数据，迁移很快获批。Ganesh称，这次改变让一条流水线的时间从约17小时缩短到约2小时。这是演讲中的案例数字，更重要的不是精确倍数，而是阻力的真正来源：反对者不是不懂技术，她是在保护一个没人注意到的工作环节。

此前，系统每天要向客户的AWS对象存储服务S3投放大约1TB数据；S3把文件和相关元数据作为“对象”，放进名为“存储桶”的容器。数量庞大的CSV文件给双方的数据管道和计算成本带来压力。工程师把迁移到Parquet视为显而易见的优化：列式格式更适合分析，压缩和读取效率也更好。那位数据质量工程师却反对了近一年，每次只说“Parquet更糟”“它不好用”。双方都在重复各自语言里的正确答案，却没有人观察她所谓“不好用”具体发生在哪里。

现场一看就明白了。她把CSV手动下载到Windows电脑，双击打开，抽查几行来确认当天数据是否正常。Parquet对计算系统更友好，但操作系统没有给她一个同样直接的查看方式。架构团队想优化17小时的数据管道，她想保住每天几分钟完成的质量检查。一个很小的查看器把两种目标重新接上，性能优化才真正成立。

工位旁边的信息密度

在访谈里，人会描述自己认为正确、正式、可以被别人理解的工作；在现场，身体会暴露真实流程。Ganesh建议观察：

• 哪一步总在复制粘贴？
• 用户何时在几个工具之间切换？
• 哪种情况会让他拿起电话，而不是继续点系统？
• 每天早上最烦的事情是什么？
• 哪一次叹气发生在什么界面之后？

他用一句带有现场感的话概括：“Residents get truth.” 长期待在现场的人得到真实情况。工牌、邮箱和会议邀请，不只是行政安排，更像进入一座组织的数据采集许可。

这里的“驻场”不一定要求永远坐在客户办公室，而是要求进入工作发生的环境。Ganesh列举的观察信号极其具体：同一动作每天重复几次；内容从一个工具复制到另一个工具；用户频繁切换标签页；系统转圈时掏出手机；一提到某个步骤，对方下意识说“没办法，只能这样”。这些动作不是噪声，而是尚未被写成需求的产品机会。

文档通常记录组织希望流程如何运行，现场暴露流程实际上如何运行。会议里的人会省略自己已经习惯的绕行，也会用正式制度掩盖例外。只有拿到客户工牌、内部邮箱和真实会议邀请，工程师才能看到问题在部门之间怎样传递。Ganesh形容这些访问权是“数据挖掘许可证”：不是让FDE随意收集信息，而是让他有机会从真实协作里建立产品判断。

他给出的起始问题很朴素：“每天早上最烦的事情是什么？”它比“你希望我们增加什么功能”更接近重复摩擦。FDE的目标，是让用户的明天与今天有所不同。只要一个重复动作被消除、一个等待被缩短，团队就获得了一条关于产品方向的高质量证据。

为客户的语言建模

不同公司会用“客户”“账户”“计费实体”“组织ID”指代看似相似、实际不同的对象。如果这些名词不先说清，数据模型、界面和指标都会不断打架。

这种混乱通常不是某个团队不专业。销售关心关系与机会，因此说“客户”；运营关心服务对象，因此说“client”；财务必须知道谁付款，因此说“billing entity”；开发者在数据库里只看见“org_id”。每一种称呼都适合局部工作，却可能在系统集成时指向不同边界。两个部门都说“活跃客户”，分母和时间窗口也可能完全不同。

FDE要和客户一起定义业务的名词与动词：有哪些对象？它们怎样关联？人可以对它们执行哪些动作？这就是本体工作。好的本体不只整理数据，也让团队逐渐用同一套语言讨论业务。用户开始自然使用产品中的概念时，产品已经进入了组织的思考方式。

Ganesh把企业拆成“名词”和“动词”。名词是客户、账户、发票、设备等实体，动词是批准、调度、退款、升级等动作。FDE要找出哪些词被过载使用，哪些系统之间需要翻译，哪些系统是短期不可能替换的记录源。然后把这套语言编码进平台，让数据、权限、应用和操作围绕同一套定义运行。

语言一旦进入产品，就会反过来塑造组织。今天行业里大量使用“skill”（可复用的能力封装）、“MCP”（Model Context Protocol，一种让AI应用以统一方式连接外部工具和数据源的开放协议）、“agent”等词，其中一些原本只是内部实现或旧概念的新包装；但当产品界面、文档和生态都采用同一称呼，它就成为人们讨论问题的默认单位。Ganesh所谓“定义语言，就控制叙事”，不是营销话术，而是平台锁定的一种深层形式：客户开始用你的名词描述自己的业务，后续工具也会自然围绕这些名词构建。

这也是Foundry能够支撑后来大规模FDE交付的基础。早期现场工程师先从无数客户环境里提炼名词、动词和系统边界，再把它们固化为ontology能力；后来的FDE才可以更快完成数据集成和应用组装。没有前一轮产品化，就不会有后一轮进入市场效率。

每个临时补丁都可能活进生产

Ganesh最后讲了一个令人不安的事实：现场为了赶进度写下的临时补丁（hack），几乎总会进入生产。他曾见过一段临时Groovy脚本在一个十万人规模的客户环境中活了一年以上，甚至有了自己的昵称。Groovy是运行在Java生态上、常用于写脚本和自动化的编程语言；这里重要的不是语言选择，而是临时脚本变成了长期基础设施。

那段脚本原本只为处理一次数据保留问题。Ganesh随手用Groovy写成，没有按生产软件设计，也没有考虑多处复用。十二个月后，它已经运行在这家近十万人的企业多个地方，团队不得不长期支持。脚本的文件名甚至变成Ganesh在Palantir的绰号；在他的婚礼上，还有同事把名字印到衣服上。笑话之所以流传，是因为每个现场工程师都见过同一种命运：越是解决了真实痛点的临时东西，越不可能被轻易移除。

为什么删不掉？因为它真的解决了问题，后来又被别的流程依赖；项目继续向前，没人愿意承担改写风险。“临时”只是写代码那天的心理状态，不是系统的生命周期。

因此，他建议把快速交付按“可能存活18个月”来写：至少要有清晰所有者、日志、基本测试、权限边界和退出方案。快不是不要工程纪律，而是用更小的范围保住纪律。

在按下部署按钮前，他建议FDE问几件不舒服的问题：六个月后它坏掉，我会不会接到凌晨两点的电话？为了今天的速度，我给整个产品留下了什么负担？我离开客户之后，谁接手——客户、另一名FDE，还是核心产品团队？故障怎样被发现，谁有权限修复？如果答案都是“以后再说”，那就不是快速产品发现，而是在透支未来团队。

解决方案架构师、客户成功和FDE也因此不能只按“让客户满意”区分。客户成功当然重要，但Ganesh给FDE增加了一条更严格的产品责任：交付必须让核心产品获得杠杆。一个补丁若只让当前客户暂时高兴，却没有带来可验证的产品学习，甚至制造永久维护债务，就没有完成FDE作为产品延伸的工作。

把整堂课压缩成一张工作清单，大致是四步。第一，重新定义问题，不把客户写出的解决方案直接当需求。第二，真正进入现场，用小交付赢得访问权，并从重复动作里收集证据。第三，提炼客户的名词、动词和系统边界，把语言变成平台。第四，对每个临时方案承担生产后果，并决定它应该进入核心产品、留作客户特例，还是尽快删除。

这四步最终都指向“产品杠杆”。一次交付当然要让当前客户的工作变好，但更高的标准是：它是否使下一次交付更快，是否让平台能处理一种以前处理不了的问题，是否改变了公司对产品边界的理解。对于早期公司，FDE如果只被当作销售后的救火队，会耗尽最宝贵的现场信号；把它放进产品发现循环，才可能从几个项目长出真正的平台。

Kepler展示的是从一个具体动作里发现产品机会。但企业AI最终要进入的，往往不是一个动作，而是一整套跨部门流程。下一课把镜头从调度员和数据工程师移到财务部门，看看正常路径、异常处理和系统记录怎样共同决定Agent能否工作。