7 月底， Reddit 的 r/dataengineering 出现了一篇很火的帖子，截止到现在依然是过去一个月这个话题的热度第一。
发帖人是一名 Palantir 客户侧的数据工程师。
他们公司签下了一份价值数百万美元的 Palantir 企业合同。
项目最初预计4 个月完成。
最后却用了15 个月，才做到 MVP。
Palantir 的 FDE 离场后，内部团队开始接手，很快发现了各种问题：
日期被 hard code，账号被 hard code，同一个业务概念在不同地方使用不同输入。
一些问题也没有被真正解决，而是继续靠 hard-coded logic 打补丁。
作者还顺带提到一个细节：
他们也用了 AI FDE，最后生成了一团 “spaghetti mess logic”。
截至发帖时，他认为整个项目的 ROI 依然是：
0
当然，这只是一个匿名客户的单一案例，不能代表 Palantir 的平均交付水平。
原帖真正批评的，也是整个 Palantir FDE 项目的交付质量。
AI FDE 只是其中一个细节。
但这反而让我开始想另外一个问题：
FDE 这种模式，到底能不能规模化？
01
FDE 最大的优势，也是它最大的瓶颈
FDE，Forward Deployed Engineer，是 Palantir 很有代表性的一种工作方式。最近一年在各种 AI 相关的新闻反复出现的热词。因为企业 AI 真正困难的地方，已经不是模型本身。
FDE 的价值，就是进入客户现场，把这些模糊的问题，一步步变成可以被软件解决的问题。
客户说：
“我希望 AI 帮我优化库存。”
这句话说完，真正困难的工作才刚刚开始。
库存到底怎么定义？
数据和旧系统在哪里？
AI 应该进入哪一步业务流程？
哪些动作可以自动执行？
最后谁来用，出了问题又由谁负责？
随着企业 AI 越来越深入业务，类似的 Forward Deployed 模式，也开始被更多 AI 公司采用。
原因并不复杂：
模型越来越通用，但企业最后一公里依然不通用。
可这套模式有一个天然的问题。
每增加一个复杂客户，就意味着重新理解一次业务，重新接一套数据，重新面对一批系统和组织问题。
所以 FDE 最有价值的地方，和它最大的瓶颈，其实是同一个东西：
人。
一个足够好的 FDE，可以理解复杂业务、连接不同系统、做关键判断，把一个模糊的问题真正推进到上线。
但如果业务增长始终意味着增加更多这样的高水平人才，那么这套模式再强，也很难摆脱专业服务的线性增长逻辑。
这也是我最近重新看 Palantir 时，觉得AI FDE很有意思的原因，这是 PLTR 拓展的 AI 版本的 FDE。
02
Palantir 想改变的，是 FDE 的生产方式
AI FDE 可以直接进入 Foundry，完成数据集成、代码修改、Ontology 配置、应用开发和系统操作。
这些功能本身当然很强。
更重要的是，Palantir 想用它改变 FDE 的生产方式。
在 2025 年 Q3 财报会上，Palantir CTO Shyam Sankar 提到：
AI FDE 最初就是为了提高公司内部 FDE 的生产力而开发的。
他的说法是，它已经让 FDE 变得：
“wildly more productive”
效果好到后来 Palantir 决定把这套能力开放给客户。
他还举过一个很极端的案例：
两个真人 FDE，加上一批 AI FDE，只用了 5 天，就帮助一个客户完成了一次 legacy data warehouse migration。
这个项目和 Reddit 那个 15 个月的项目范围完全不同，不能直接横向比较。
但这个案例至少说明了 Palantir 对 AI FDE 的期待。
过去，
FDE 自己就是产能。
一个人能理解多少客户、推进多少项目、写多少代码，基本都被自己的时间限制。
AI FDE 想改变的，就是这个关系。
真人 FDE 更多去理解问题、定义架构、做关键判断和 Review。
数据集成、代码修改、迁移、测试，以及大量系统操作，则逐渐交给 Agent。
于是 FDE 的角色开始发生变化：
从一个
亲自完成交付的人
变成一个
能够调动更多交付能力的人。
这和 Coding Agent 正在软件开发里发生的事情很像。
工程师没有消失。
变化的是，一个工程师可以调用的生产能力突然变多了。
AI FDE 改变的是杠杆率。
如果这套模式能够稳定成立，一个 FDE 可以承担的客户和任务，就不再和自己的时间严格线性绑定。
FDE 也第一次有机会获得过去没有的软件杠杆。
03
但杠杆只负责放大
这里有一个很容易被忽略的问题。
杠杆只负责放大。
它不会自动帮你判断：
什么东西值得被放大。
至少从今天的 Agent 能力来看，最先被放大的通常还是 Execution。
代码可以写得更快。
Pipeline 可以搭得更快。
数据迁移可以做得更快。
大量重复的系统操作，也可以更快完成。
但 FDE 最难复制的部分，往往发生在执行之前：
到底应该解决什么问题。
业务应该怎么抽象。
什么东西值得进入系统。
架构应该怎么取舍。
哪些地方应该自动化，哪些地方不应该。
以及最后，
谁愿意为这些判断负责。
这些判断如果是对的，Agent 会成为巨大的杠杆。
方向一旦错了，Agent 同样会高效地把错误变成更多代码、更多 Pipeline 和更多技术债。
所以 Reddit 里那句：
“AI FDE 写出了 spaghetti mess logic”
它证明不了 AI FDE 到底好不好用。
但它提醒了一件更重要的事：
Agent 确实放大能力，但不会自动提高判断质量。
04
做得更快，和做对了，是两回事
这也是我最近用越来越多 Agent 时，反复感受到的一件事。
现在越来越多事情都可以：
“做得更快”。
但“做得更快”和“做对了”，从来不是一回事。
过去，一个工程师一天最多制造一天的技术债。
现在，一个工程师如果同时管理十个 Agent——
也许一天就可以制造十天的技术债。
这可能才是 AI FDE 最值得观察的地方。
FDE 能不能规模化，已经不只是一个“AI 能不能替人干活”的问题。
决定这套杠杆有没有价值的，是执行能力被放大之后：
人的判断、取舍，
以及对结果负责的能力。