上周，Boris Cherny 做客 Lenny's Podcast，畅谈 Claude Code——这款 AI 编程助手如今生成了 GitHub 全部提交的 4%，并帮助 Anthropic 实现了 200% 的生产力提升。
Boris 描述的每一个重要洞见——从面向未来能力而非当前约束进行构建，到通过“潜在需求”找到产品市场契合点——都完美地印证了我们作为 Palantir 前沿部署工程师十多年来一直在做的事情。这就像听一个人独立发现了万有引力。
在 Palantir 的七年里，我亲身实践了 FDE 模式：小而精的团队直接嵌入客户现场，构建超越其当前能力的系统，通过观察人们的实际工作方式而非他们口述的需求来发现需求。Boris 证明了这种方法并非过时——它正是我们未来构建 AI 产品的方式。
构建六个月后的产品
“为六个月后的模型而构建，而不是今天的模型，”Boris 说道。Claude Code 团队刻意避免过度搭建脚手架。他们给模型提供工具和目标，然后放手不管，押注于能力的快速提升，而不是将系统限制在当前的局限之内。
这一点深深触动了我，因为这正是 FDE 处理客户部署的方式。我们不会为组织今天所处的状态构建系统——我们为他们六个月后的状态而构建。当我在大型企业部署 Palantir 时，最糟糕的错误就是将系统过度约束在当前的工作流程上。组织会演进，数据会增长，流程会成熟，突然之间，我们根据其“需求”精心定制的系统就变成了一件紧身衣。
最优秀的 FDE 部署会为客户提供略超其当前所能使用的能力。我们会构建能够处理其当前数据量 10 倍的数据管道。我们会创建假设他们最终会提出更复杂问题的分析工作流。我们会设计在团队从 5 人增长到 50 人时无需重新培训的用户界面。
这不是过度工程——而是少加约束。正如 Claude Code 押注模型会变得更聪明一样，我们押注客户会变得更加成熟。
潜在需求作为产品指南针
Boris 透露的一个发现是，Claude Code 的突破来自于观察人们如何以创造性的方式使用它。数据科学家在终端窗口中运行 SQL 查询。非技术用户请它帮忙种番茄。人们用它恢复损坏的婚礼照片。这种“潜在需求”催生了 Cowork——仅用 10 天就构建完成，因为他们能清楚地看到用户想要做什么。
“潜在需求”只是 Boris 对 FDE 每天所做工作的另一种说法：坐在用户身边，观察他们的实际工作方式。
我构建过的最好的功能，都源于对变通做法的观察。有一位分析师每天早上都要在系统之间手动复制粘贴数据，因为官方集成太死板。有一个运营团队维护着一张单独的电子表格，用来追踪官方仪表盘无法展示的内容。有一位调查员会把图表截图粘贴到 Word 文档里，因为导出功能无法捕捉他们需要传达的信息。
这些都不是功能需求——它们是组织的抗体。用户在绕过系统，只为完成他们真正的工作。标准的产品管理流程会调查这些用户，问他们想要什么功能。他们大概会说“更好的导出”或“更多的集成选项”。但这并不是他们真正需要的。
FDE 观察的是工作流，而不是言语。我们看到有人在截图，就会意识到他们需要的不是更好的导出功能——而是一种用数据讲故事的方式。我们看到手动复制粘贴，就会意识到问题不在于集成——而在于官方流程与实际工作流程不匹配。
最成功的 FDE 项目，都源于发现了客户自己无法清晰表达的潜在需求。不是因为他们不聪明，而是因为他们离日常工作太近，反而看不清其中的规律。
想法重于工程产能
“编码问题已基本解决，”Boris 说，“瓶颈在于想法和优先级排序。”在 AI 时代，新的稀缺资源不是工程产能——而是知道该构建什么。
这印证了 FDE 这一角色被设计出来所要解决的一切。我们从来都不是以编码为主。没错，我们能写软件——而且往往写得很快——但我们真正的价值在于对问题有足够深入的理解，从而知道该构建什么。
我在 Palantir 共事过的最优秀的 FDE，并不是团队里最好的程序员。他们是那种能与反恐部门坐在同一个房间里，弄清楚什么才是真正重要的事情的人。能分辨组织说自己需要什么，与什么才能真正让他们的使命取得成功之间的区别。能从不同的部署项目中看出规律，并识别出某个特定客户的问题，实际上是我们以前解决过的某个通用问题的具体案例。
这个人写的代码往往比团队里的初级工程师还少。但他们通过第一次就解决正确的问题，节省了数月的工作。
如今 AI 已经能生成大部分代码，这种能力变得更加关键。如果 Claude 能帮你写函数，你的价值就在于知道哪些函数需要存在。
“软件工程师”的消亡
“‘软件工程师’这个头衔正在消亡，”Boris 观察道，“Builder 才是新的现实。”随着 AI 让编码大众化，工程、产品、设计和部署之间的角色界限正在模糊。
FDE 一直是“建造者”。我们的职位描述根本没法写，因为我们什么都做：产品研究、技术架构、用户界面设计、数据工程、部署运维、用户培训以及持续支持。我们无法被整齐地归入任何组织架构图，因为这个角色是由结果定义的，而不是由职能定义的。
传统软件工程是关于实现规格说明的。由别人决定要构建什么，工程师负责构建。但 FDE 的工作始终是端到端的全权负责。我们决定要构建什么，构建它，部署它，并承担随之而来的一切后果。
这让许多希望角色边界清晰的人感到沮丧。但对于解决那些解决方案空间尚未明确定义的复杂、新颖的问题，这种方式极其有效。
整个行业正在追上 Palantir 多年前就领悟到的道理：当你在构建真正全新的东西时，你需要能够跨越整个技术栈思考的人——涵盖技术、产品和运营。“建造者”这个词比“工程师”更贴切，因为它涵盖了完整的范围。
这对 AI 公司意味着什么
如果你今天正在构建 AI 产品，FDE 模式不是过时的遗产——而是你的行动指南。
停止围绕职能孤岛来组织团队。找到能够从整体上思考问题的人，给他们最好的工具，并让他们直接深入客户现场。构建略微超前于当前能力的产品，而不是受限于当前的工作流程。观察人们实际如何使用你的产品，尤其是他们“误用”它的方式。
最重要的是：要明白你的瓶颈不再是工程能力，而是产品判断力。是知道该构建什么。是找到客户自己都无法清晰表达的潜在需求。
最先想明白这一点公司将抢走所有人的饭碗。不是因为他们拥有更好的 AI 模型，而是因为他们会构建正确的东西。
Boris Cherny 刚刚验证了十五年的 FDE 实践。未来属于那些能够端到端思考、深入客户现场工作、并能看到他人看不到的规律的建造者。
工具已经变了。原则没有变。