FDEs have the hottest job in AI. Labs, startups and PE firms are all hiring engineers to sit inside their customers’ operations and solve their problems. Almost none of them agree on what those engineers are supposed to accomplish, or what the strategy underneath the hiring actually is.FDE 是 AI 领域最热门的职位。实验室、初创公司和私募股权公司都在聘请工程师深入客户业务内部去解决问题。然而，几乎没有公司能就这些工程师应该达成什么目标，或者招聘背后的具体策略是什么达成共识。
I’m Vinoo, CEO of Kepler, the deterministic infrastructure for AI. I’ve built pieces of the forward deployed function three times, at three different institutions, over the course of over a decade. Here’s what I’ve seen work, what I’ve seen fail, and where I think this goes.我是 Vinoo，Kepler 的首席执行官，我们致力于为 AI 提供确定性的基础设施。在过去十多年里，我曾在三家不同的机构三次构建过前线部署职能。以下是我所见过的有效做法、失败教训以及我对该领域未来发展的看法。
The first was Palantir. I started there on product development, building storage and retrieval systems, and was later deployed as an FDE across commercial, DoD and NatSec, healthcare, and oil and gas. I also led Project Frontline, the rotation that took our software engineers and turned them into forward deployed engineers. Around 250 people went through this program, and a lot of them run forward deployed teams now at companies like OpenAI, Anthropic, xAI and Anduril.第一次是在 Palantir。我最初从事产品开发，构建存储和检索系统，后来被派往商业、国防、国家安全、医疗保健以及石油和天然气等领域担任 FDE。我还领导了 Project Frontline，这是一个将软件工程师转型为前线部署工程师的轮岗项目。约有 250 人参加了该项目，其中许多人现在在 OpenAI、Anthropic、xAI 和 Anduril 等公司领导前线部署团队。
The second was Citadel, where I ran business engineering. Our customers were portfolio managers, and the only question that mattered was whether the data and software products we built helped them generate alpha.第二次是在 Citadel，我负责业务工程。我们的客户是投资组合经理，唯一重要的问题就是我们构建的数据和软件产品能否帮助他们产生 Alpha 收益。
The third is Kepler, where the forward deployed function sits inside product rather than sales, in a domain where a plausible wrong answer is worse than no answer at all.第三次是在 Kepler，这里的前线部署职能归属于产品部门而非销售部门，所处的领域要求极高——在这里，一个看似合理但错误的答案比没有答案更糟糕。
FDE misunderstandings对 FDE 的误解
A few months ago, a16z launched the Forward Deployed Engineer Fellowship and I was nominated as one of the fellows, alongside a handful of people I used to work with. It’s a great program and I’ve enjoyed so many of the conversations. Last week I went to my first fellow dinner in SF.几个月前，a16z 推出了“前线部署工程师奖学金”项目，我和几位曾经的同事一起被提名为学员。这是一个很棒的项目，我非常享受其中的交流。上周，我参加了在旧金山举行的首次学员晚宴。
Around the table were FDEs from Snowflake, Anthropic, and a number of startups I’d been reading about, and over the course of the evening it became clear that we were all using the same two words (forward deployed) to describe jobs that had almost nothing in common. In one part of the conversation an FDE was a sales engineer who joined ‘the second call,’ somewhere else it was a quota-carrying rep who could write Python, and a few seats down it was closer to a consultant with a laptop and a statement of work, brought in to deliver something the product couldn’t.席间有来自 Snowflake、Anthropic 以及我曾读到过的一些初创公司的 FDE。随着晚宴的进行，我们清楚地发现，尽管大家都在使用同样的两个词（前线部署）来描述工作，但这些工作之间几乎没有任何共同点。在谈话的某个部分，FDE 被定义为参加“第二次会议”的销售工程师；在另一个地方，它指代的是会写 Python 的销售代表；而坐在几位之外的另一位则更像是一名带着笔记本电脑和工作说明书的顾问，被请来交付产品无法实现的功能。
A few days later, someone earnestly asked our WhatsApp group how their FDE team should split scope with the consulting firm already sitting in the account. That’s a reasonable question to ask, but a strange one to have to answer, at least based on my own belief about what constitutes an FDE.几天后，有人在我们的 WhatsApp 群组里诚恳地询问，他们的 FDE 团队应该如何与已经在客户账户中的咨询公司划分工作范围。这是一个合理的问题，但在我看来，必须回答这个问题显得有些奇怪，至少基于我对 FDE 定义的理解是如此。
To be clear, I’m not interested in gatekeeping a term; and meanings shift, this one faster than most. But what’s interesting is that folks in this group, the current experts at FDE, are describing fundamentally different jobs, with different reporting lines and different incentives. It’s no wonder half the comments on any YouTube video about FDEs are some version of “isn’t this just reinventing consulting?”明确一点，我无意垄断这个术语；含义总是在变化，而这个词的变化速度比大多数词都要快。但有趣的是，这群人——目前 FDE 领域的专家们——所描述的工作在本质上完全不同，有着不同的汇报线和激励机制。难怪 YouTube 上任何关于 FDE 的视频评论区里，总有人会问：“这不就是重塑咨询吗？”
So in the rest of this article, I will tell you the story of Project Frontline, through the narrow lens of a mistake I helped make, how that mistake turned me into an FDE, and how it eventually informed the rotation that turned our software engineers into FDEs.因此，在本文的剩余部分，我将通过我曾经犯过的一个错误，讲述 Project Frontline 的故事。这个错误不仅让我成为了 FDE，也最终促成了我们将软件工程师转型为 FDE 的轮岗机制。
The history of Project FrontlineProject Frontline 的历史
First, some context. From nearly the beginning, Palantir was split into two separate functions. The first, Product Development (PD), built the platform. The second was Business Development (BD), which despite the name contained both the technical BD folks (already called FDEs) and non-engineering customer-oriented folks (we called them Embedded Analysts, or Deployment Strategists).首先，交代一些背景。几乎从一开始，Palantir 就被划分为两个独立的职能部门。第一是产品开发（PD），负责构建平台。第二是业务开发（BD），尽管名字如此，但它既包含技术型 BD 人员（当时已被称为 FDE），也包含非工程类的客户导向人员（我们称之为嵌入式分析师或部署策略师）。
PD, in the vast majority of situations, wasn’t directly engaging with customers; and BD, in the vast majority of situations, wasn’t directly contributing to building the core, generalized platform. PD tended to do customer discovery secondhand, by chatting with BD or by consuming the successful build-in-the-field features into the core product. None of that was a process, though. It ran on relationships — such as which FDE happened to know which PD engineer well enough to grab them. So a good insight from the field made it into the platform (or was dropped) depending on who was in the room.在绝大多数情况下，PD 不会直接与客户接触；而 BD 在绝大多数情况下也不会直接为构建核心通用平台做出贡献。PD 倾向于通过与 BD 聊天，或将现场构建的成功功能纳入核心产品来间接进行客户调研。然而，这并非一个流程，而是依赖于人际关系——比如哪位 FDE 恰好与哪位 PD 工程师关系够好，能把他们拉过来。因此，现场得出的好见解能否进入平台（或被丢弃），取决于当时在场的人是谁。
In 2013, in my early days at Palantir, I got to work on a transaction store called Phoenix. The store was designed by some of the best engineers I’ve ever worked with, and it had an abundantly clean design scoped to a clear set of customer use cases. The use cases, though, had been relayed to us second-hand. We knew and understood the design requirements, which had a focus on the commercial requirements of retention periods, and had clever solutions to bucket data in a way that enabled storing a rolling window of data. It behaved exactly as specified in every environment we controlled.2013 年，我在 Palantir 工作初期，参与了一个名为 Phoenix 的事务存储系统。该系统由我共事过的最优秀的工程师设计，其设计非常简洁，针对一组明确的客户用例。然而，这些用例是二手转达给我们的。我们了解并理解设计要求，重点关注保留期限的商业需求，并针对分桶数据以实现滚动窗口存储提供了巧妙的解决方案。在我们控制的每一个环境中，它的表现都完全符合规范。
Then we deployed it at a bank, and real financial data turned out to have holes in it that our test data never did. A blank timestamp fell through to the epoch, so the retention logic dutifully requested a ten-minute bucket for every window between January 1st 1970 and the present day. That came out to some 2.3 million keyspaces against a system where Cassandra (the backing tech) needed roughly five megabytes per file handle. The server rightfully OOMed [Out-Of-Memory] and starting it up again would have required 14 terabytes of RAM. Meaning this process was effectively dead on arrival.后来，我们在一家银行部署了它，结果发现真实的金融数据中存在测试数据从未出现过的漏洞。一个空白的时间戳导致逻辑回溯到了纪元时间，于是保留逻辑尽职地为 1970 年 1 月 1 日至今的每一个窗口请求了十分钟的分桶。这导致了约 230 万个键空间，而 Cassandra（底层技术）每个文件句柄大约需要 5MB 内存。服务器理所当然地出现了内存溢出（OOM），若要重启，则需要 14TB 的内存。这意味着该进程在启动时实际上就已经瘫痪了。
The root cause here wasn’t a lack of user research, as you might guess. We had a spec, we understood our use case, and we had read plenty about how institutions like this store their data. What we had never done was stand inside the building while the system ran against their production data. This meant that nobody on our side owned the gap between the design and the daily reality. Everything we knew about that bank had been relayed secondhand and by well intentioned people for whom bad data was just another normality.问题的根源并非像你想象的那样缺乏用户研究。我们有规范，理解用例，也阅读了大量关于此类机构如何存储数据的资料。但我们从未在系统运行于他们的生产数据时亲临现场。这意味着我们这一方没有人负责弥合设计与日常现实之间的差距。关于那家银行的一切知识都是由善意的人通过二手转达的，对他们来说，坏数据只是常态。
That’s how I became an FDE, which is a generous description of what actually happened. As Phoenix rolled out across Palantir’s commercial fleet I found myself flying out to fix what we’d shipped, and that put me in front of our actual users for the first time. In this case the users were Palantir’s own FDEs, which was lucky for me, because they could tell me what was wrong in the language I already spoke. I started building and expanding systems in service of what they were trying to do.这就是我成为 FDE 的过程——这是对当时所发生之事的慷慨描述。随着 Phoenix 在 Palantir 的商业客户群中推广，我发现自己不得不飞往现场去修复我们交付的产品，这让我第一次面对了真正的用户。在这种情况下，用户是 Palantir 自己的 FDE，这对我来说很幸运，因为他们可以用我熟悉的语言告诉我哪里出了问题。我开始根据他们试图实现的目标来构建和扩展系统。
So this is also the story of how I learned the FDE mindset viscerally rather than intellectually.所以，这也是我如何从直觉上而非理智上学习 FDE 思维方式的故事。
This is where the ordinary version of this story ends, with some lesson about paying attention to your users. Phoenix turned into something more interesting than that. It became a platform, and Palantir’s FDEs started building on top of it across cybersecurity, KYC, AML, and a long tail of use cases nobody had scoped for. Eventually, we (Product Development) had to think about how to expand the Phoenix platform to support all of these use cases.这个故事的普通版本到此结束，通常会附带一些关于关注用户的教训。Phoenix 演变成了一个比这更有趣的东西。它成为了一个平台，Palantir 的 FDE 开始在它之上构建网络安全、KYC、AML 以及许多我们未曾设想过的长尾用例。最终，我们（产品开发部）不得不考虑如何扩展 Phoenix 平台以支持所有这些用例。
I didn’t see it at the time, but that iteration cycle is the whole idea. An FDE solves customer problems in order to earn the insight that informs what gets built next. The role is an extension of the product team.当时我没有意识到，但这种迭代周期就是核心理念所在。FDE 通过解决客户问题来获取洞察，从而为下一步的构建提供依据。这个角色是产品团队的延伸。
FDEs today今天的 FDE
The reality is that none of this is the mentality of the vast majority of FDEs you see today. The term has been co-opted to mean something close to “a person who does something that vaguely involves a customer,” which is how you end up with job posts for a forward deployed equity researcher, or a forward deployed sales engineer. The instinct underneath the co-option is correct, even when the titles are silly, because customers matter more now than they did five years ago, and they matter more for a specific reason.现实是，这根本不是今天大多数 FDE 所具备的心态。这个术语被挪用为“做一些与客户模糊相关的事情的人”，这就是为什么会出现“前线部署股票研究员”或“前线部署销售工程师”这类招聘启事的原因。这种挪用背后的本能是正确的，即使头衔看起来很滑稽，因为客户现在比五年前更重要，而且他们之所以重要有着特定的原因。
The low-hanging fruit is gone. The problems that could be solved by a well-designed product sold identically to a thousand companies have largely been solved. What’s left is the work that sits inside the walls, in workflows that are messy and undocumented and nearly impossible to proxy from the outside. That’s why everyone is suddenly “forward deployed.” You cannot infer from a discovery call how a specific company closes its books, and the part of the problem that resists inference is now the part that’s left.低垂的果实已经被摘完了。那些可以通过设计良好的产品并以同样方式卖给一千家公司来解决的问题，大部分已经解决了。剩下的工作存在于企业内部，存在于杂乱无章、缺乏文档且几乎无法从外部推断的工作流中。这就是为什么每个人突然都成了“前线部署”。你无法通过一次挖掘电话来推断某家公司是如何结算账目的，而问题中那些无法被推断的部分，正是目前剩下的部分。
Which means the holy grail has quietly moved. For a long time it was the repeatable motion, the same SaaS product sold the same way over and over; and that’s still the right ambition if what you sell is tokens or bytes or something physical. For everyone else the value has migrated to customization, to the last mile, to the twenty percent of the workflow that no product could have anticipated and which determines whether the other eighty percent gets used at all. Being forward deployed has become synonymous with solving that last mile.这意味着圣杯已经悄然转移。长期以来，它是可重复的动作，是同一种 SaaS 产品一遍又一遍地以同样方式售出；如果你销售的是代币、字节或某种物理产品，这仍然是正确的追求。对于其他人来说，价值已经迁移到了定制化，迁移到了“最后一公里”，迁移到了那 20% 的、任何产品都无法预见、却决定了其余 80% 是否会被使用的关键工作流中。前线部署已经成为解决那“最后一公里”问题的代名词。
But solving it is only half of what the role is for. The last-mile problem you solve at one customer is the signal that tells you which piece of your platform needs to become generalizable. An FDE function that solves last miles without ever sending that signal home is a services/consulting team with a better title.但解决它只是该角色职责的一半。你在一个客户那里解决的“最后一公里”问题，是告诉你平台哪一部分需要通用化的信号。一个只解决“最后一公里”却从不将信号传回总部的 FDE 职能，不过是一个拥有更好头衔的服务/咨询团队。
So what are today’s FDEs supposed to be doing?那么，今天的 FDE 应该做什么？
I’d contend that your job as an FDE should be to collect nouns and verbs. Let’s break that down.我认为，作为一名 FDE，你的工作应该是收集名词和动词。让我们拆解一下。
Spend a week inside a company and you’ll notice that the same concept usually has at least four different names. Sales says customer, ops says client, finance books a billing entity, engineering writes org_id, and every seam between those teams hides a translation that breaks the moment somebody changes a definition. Those names are the surface and underneath them is the operating model. Meaning, you can really proxy the way a company works by learning their nouns and verbs.在一家公司待上一周，你会发现同一个概念通常至少有四个不同的名称。销售说“客户”，运营说“委托人”，财务记账为“结算实体”，工程部写成“org_id”，而这些团队之间的每一个衔接点都隐藏着一种转换，一旦有人改变定义，这种转换就会失效。这些名称是表面，而其下是运营模式。这意味着，通过学习他们的名词和动词，你确实可以推断出一家公司的运作方式。
The nouns are what the people in a business treat as real. It’s usually a “thing.” A position, or a trade, or a counterparty. Usually, on a per-team basis, there are a handful of objects the whole operation turns on, and none of them are defined the way a textbook would define them. That’s because two firms will describe a position identically on a slide and completely differently in the code. That’s not a bug, that’s just what makes companies unique. I mean that if every company had the exact same set of nouns, then you would really just need one company.名词是企业里的人视为“真实”的事物。通常是一个“东西”。一个头寸、一笔交易或一个交易对手。通常在每个团队中，都有少数几个核心对象支撑着整个运营，而且它们都没有按照教科书定义的那样被定义。这是因为两家公司在幻灯片上对头寸的描述可能完全相同，但在代码中却完全不同。这不是 bug，这正是让公司独一无二的原因。我的意思是，如果每家公司都有完全相同的名词集，那么你只需要一家公司就够了。
The verbs are how nouns move. Things like how a trade gets booked, or what has to be true before the books can close, or who signs off on an exception at eleven at night and what happens when that person is on vacation.动词是名词移动的方式。例如交易如何入账，结账前必须满足什么条件，或者在深夜谁来签署异常处理，以及当那个人休假时会发生什么。
Almost none of this is written down — it’s lived. It’s the system of operations through which an organization lives. It’s culture. It lives in the heads of the six people who have been there long enough to stop noticing it, and in a spreadsheet somebody built four years ago that the entire team now quietly depends on. That’s why it’s worth so much, and it’s also why you can’t ask for it.这些内容几乎没有被写下来——它们是活的。它是组织赖以生存的运营系统。它是文化。它活在那些待得足够久、已经不再注意到它的六个人的脑海里，也活在四年前某人建立的一个电子表格里，而整个团队现在都默默地依赖着它。这就是它价值所在，也是你无法通过询问获得它的原因。
Usually, the people who hold this knowledge don’t know they have it. In one of my last startups, we spent close to a year trying to move a customer from CSV to Parquet, and one data quality engineer blocked it every single time. We could never understand why and the reasons would always change, but would always be some variation of “a parquet is worse,” “it doesn’t work,” “it doesn’t make sense to me,” et cetera. We used the customer storage reduction argument, the compute minimization argument, the pipeline optimization argument…and none of it moved her, because none of it was about the actual problem.通常，拥有这些知识的人并不知道自己拥有它。在我最后一家初创公司中，我们花了近一年时间试图将客户从 CSV 迁移到 Parquet，但一位数据质量工程师每次都阻挠。我们永远无法理解原因，理由总是变来变去，但总是“Parquet 更差”、“它不好用”、“我不理解”之类的变体。我们使用了客户存储空间缩减、计算最小化、流水线优化等论点……但都没有打动她，因为这些都不是真正的核心问题。
Then we had one of our FDEs go in and watch this particular data quality engineer work. She was pulling CSVs down from S3 onto a Windows laptop, double-clicking them open, and eyeballing the rows. That was the data quality check. Parquet had no native viewer at the time, so what we were proposing would have taken away the only data quality instrument she had and handed her nothing back. She wasn’t being difficult, she was just protecting the one thing that let her do her job.后来，我们派了一名 FDE 去观察这位数据质量工程师的工作。她正从 S3 上将 CSV 下载到 Windows 笔记本电脑上，双击打开，然后用肉眼检查每一行。这就是她的数据质量检查方式。当时 Parquet 没有原生的查看器，所以我们提出的方案剥夺了她唯一拥有的数据质量工具，却没给她提供任何替代品。她并不是在故意刁难，她只是在保护那个让她能完成工作的唯一工具。
We built a Parquet viewer that night, she approved the migration two days later, and pipeline execution went from about seventeen hours to two. She would never have said any of this in an interview. From where she sat, the reason was obvious and not worth mentioning.那天晚上我们构建了一个 Parquet 查看器，两天后她就批准了迁移，流水线执行时间从大约 17 小时缩短到了 2 小时。她在采访中绝不会提到这些。从她的角度来看，原因显而易见，不值一提。
Understanding and defining the system of operations, or nouns-and-verbs, of this analyst enabled us to not just understand the problem, but build a solution that we could then deliver across a fleet of customers with the same problem.理解并定义这位分析师的运营系统（名词和动词），不仅使我们理解了问题，还使我们构建了一个可以交付给拥有同样问题的广大客户群的解决方案。
The output needs to be a product产出必须是产品
Understanding the nouns and verbs contextualizes problems, but the output needs to be a product rather than just one happy customer.理解名词和动词能使问题情境化，但产出必须是产品，而不仅仅是一个满意的客户。
The nouns and verbs tell you what a problem actually is. They don’t tell you what to do about it; and this is where most FDE functions quietly go wrong, because solving the problem in front of you is satisfying and legible, and someone will thank you for it that same week.名词和动词告诉你问题本质是什么。它们不会告诉你该怎么做；这正是大多数 FDE 职能悄然出错的地方，因为解决眼前的问题既令人满意又清晰可见，而且当周就会有人感谢你。
Keeping the customer happy is a real job and a good one. It belongs to solutions architects, who are rightly measured on it. The forward deployed engineer is there to turn what the field teaches into the thing every future customer gets. An FDE engagement that ends with one delighted account and nothing changed upstream has failed at the only thing the role exists for. You got the context and you spent it locally.让客户满意是一项真正的工作，也是一份好工作。它属于解决方案架构师，他们的绩效评估理应基于此。前线部署工程师的存在是为了将现场经验转化为未来每一位客户都能获得的东西。如果一个 FDE 的工作以一个满意的账户告终，而上游没有任何改变，那么它在这一角色存在的唯一目的上就失败了。你获取了背景信息，却只在局部消耗了它。
I learned that one expensively. In one case a customer needed a data retention job, so I hacked together a groovy script named “vinoo.groovy” to hold them over — an afternoon of work that was never meant to survive the week. A year later, it was running across a customer of nearly a hundred thousand people, with my name fused to it. It became such a ridiculous story that my team started calling me vinoo.groovy. We fixed the problem, but never turned the fix into a product — so we spent years maintaining a hack that should have died immediately. Every shortcut you ship becomes something you own. The discipline is knowing which fixes belong in the platform and which ones you throw away on purpose the moment they’ve done their job.我曾为此付出了昂贵的代价。有一次，客户需要一个数据保留作业，于是我拼凑了一个名为“vinoo.groovy”的 Groovy 脚本来应付——这是一个下午的工作，本不打算存活过那周。一年后，它在一家拥有近十万人的客户那里运行，并贴上了我的名字。这成了一个荒谬的故事，我的团队开始叫我“vinoo.groovy”。我们解决了问题，但从未将修复转化为产品——所以我们花了数年时间维护一个本应立即废弃的临时方案。你交付的每一个捷径都会成为你的负担。纪律在于知道哪些修复属于平台，哪些是你一旦完成任务就故意丢弃的。
The fork分叉
This is where the whole thing splits. Do the work with nothing underneath it and you learn one company’s model, ship something shaped exactly to it, and lose all of it when the engagement closes. The next customer starts from zero, and so does the one after that. That’s consulting. It pays well, the people are excellent, and it doesn’t compound.这就是整个事情的分叉点。做没有底层支撑的工作，你只会学到一家公司的模式，交付一个完全契合它的东西，并在合作结束后失去一切。下一个客户从零开始，再下一个也是。那是咨询。它薪水不错，人才优秀，但它不会产生复利。
Put a platform underneath the same work and every company you map makes the next deployment faster and the product sharper, because what the engineer brought home has somewhere to live. That’s the difference between selling hours and building an asset, and my honest read of this gold rush is that most of the companies in it are building the first one and describing the second to their board.在同样的工作下放入一个平台，你映射的每一家公司都会使下一次部署更快，产品更敏锐，因为工程师带回来的东西有了归宿。这就是销售工时与构建资产的区别，我对这场淘金热的诚实看法是，其中大多数公司都在构建前者，却向董事会描述后者。
That’s your job: build the platform.这就是你的工作：构建平台。
What we do at Kepler and what you can take from it.我们在 Kepler 做什么，以及你可以从中借鉴什么。
At Kepler, we set the function up this way from day one, before we had the customers to justify it. The alternative is to discover in month fourteen that your engineers have been optimizing for the wrong thing. From the beginning, our FDEs act as an extension of the product team; and that is the structural decision everything else follows from.在 Kepler，我们从第一天起就以这种方式设置职能，甚至在我们拥有足够证明其合理性的客户之前。另一种选择是在第 14 个月发现你的工程师一直在为错误的目标进行优化。从一开始，我们的 FDE 就充当产品团队的延伸；这是所有其他结构性决策的出发点。
We sell to hedge funds, investment banks, PE firms, and other financial institutions. These are fundamentally different institutions with different mandates, but all of them share a single non-negotiable: numbers have to be right, and someone has to be able to show why they are right. That is the constraint we design against and it turns out to be a useful one, because it forces the operating model into the open. No firm we’re involved with can produce a work product without a clear trail of provenance behind every number in it. That invariant defines our platform and gives us a bedrock to execute against.我们向对冲基金、投资银行、私募股权公司和其他金融机构销售。这些是本质上不同的机构，有着不同的使命，但它们都有一个不可妥协的共同点：数字必须准确，且必须有人能证明它们为何准确。这是我们设计时所遵循的约束，事实证明这很有用，因为它迫使运营模式显露出来。我们接触的任何公司在没有明确的来源追踪的情况下，都无法产出工作成果。该不变式定义了我们的平台，并为我们提供了执行的基石。
These problems are universal. The vocabulary is not.这些问题是普遍的。但词汇不是。
Every one of these firms is running some version of the same ontology underneath, and every one of them describes it differently. A position means one thing on a credit desk and something adjacent on an equities desk at the same bank. Two funds will use identical language for a return calculation and disagree about what goes into the denominator. Most of these differences exist because somebody made a reasonable decision in (say) 2011 and the decision outlived the person; also, it’s not written down anywhere that you can find.每一家公司都在底层运行着某种版本的相同本体论，但每一家公司的描述方式都不同。头寸在同一家银行的信贷部门意味着一件事，在股票部门则意味着另一件事。两家基金对收益计算使用相同的语言，但对分母中包含什么却有分歧。大多数这些差异的存在是因为某人在（比如）2011 年做出了合理的决定，而这个决定比那个人活得更久；而且，这些都没有写在任何你可以找到的地方。
Identifying and filling that gap is the job of an FDE. A schema tells you what is stored. It does not tell you what is meant, and the distance between the two is exactly where a system that sounds right produces a number that is wrong.识别并填补这一空白是 FDE 的工作。Schema（模式）告诉你存储了什么，但它不会告诉你意味着什么，而两者之间的距离正是听起来正确的系统产生错误数字的原因。
Provenance is a correctness requirement for our customers, but for us it does something else as well: it makes the field work compound. A system that can improvise around a bad encoding will never tell you the encoding was bad. Our system does not improvise. When we misunderstand how a firm defines something, that misunderstanding surfaces as a failure rather than as an answer that merely looks reasonable. The engineer who got it wrong finds out from the system, rather than from a client in a meeting six weeks later.对于我们的客户来说，来源追踪是准确性要求，但对于我们来说，它还有另一个作用：它使现场工作产生复利。一个可以围绕糟糕编码进行即兴发挥的系统永远不会告诉你编码是糟糕的。我们的系统不会即兴发挥。当我们误解了一家公司如何定义某件事时，这种误解会表现为失败，而不是仅仅看起来合理的答案。犯错的工程师会从系统中发现，而不是在六周后的会议上从客户那里得知。
The deployments then tell us what to extend in the platform, which is a narrower question than it sounds. We are not trying to learn which feature a given fund would like to have. We are trying to find the places where the platform is too narrow to hold what we keep running into. Three firms asking for the same feature is easy to notice and worth relatively little. Three firms needing something the provenance layer cannot express is the signal we actually care about; and it usually arrives quietly, in the form of an engineer working around the same limitation for the third time.部署之后会告诉我们平台需要扩展什么，这比听起来要窄得多。我们不是试图了解某个基金想要什么功能。我们是在寻找平台太窄而无法容纳我们不断遇到的问题的地方。三家公司要求同一个功能很容易注意到，但价值相对较低。三家公司需要来源层无法表达的东西，才是我们真正关心的信号；它通常悄无声息地到来，表现为一名工程师第三次绕过同一个限制。
If you are building somewhere else, here is the part I would take from all of this.如果你在其他地方进行构建，这是我建议你从中汲取的部分。
Product leverage is what buys you the right to experiment. Every capability that lands in the platform makes the next deployment cheaper to attempt, and cheap attempts are how a small company learns anything at speed. Without that leverage, you get one expensive guess per customer. You scope carefully, build for months, and if the guess was wrong you have spent an account and a quarter finding out. We would rather be wrong four times in a month, because each of those attempts costs less than the one before it.产品杠杆是你进行实验的权利。平台中落地的每一项能力都使得下一次部署的尝试成本更低，而低成本尝试是一家小公司快速学习的途径。没有这种杠杆，你每个客户只能进行一次昂贵的猜测。你仔细规划，构建数月，如果猜错了，你就浪费了一个账户和一个季度的时间。我们宁愿在一个月内犯错四次，因为每次尝试的成本都比上一次低。
Which is why the reporting line is not an administrative detail. Point the function at sales and the incentive becomes closing the account in front of you — which is a real job and one that somebody at the company should be doing. It is not this one. Point the function at product and every deployment is asked to produce something the next deployment can start from.这就是为什么汇报线不是行政细节。将职能指向销售，激励就变成了搞定眼前的账户——这确实是一份工作，公司里应该有人在做。但不是这份工作。将职能指向产品，每一次部署都会被要求产出下一次部署可以起步的东西。
Where the moat is护城河在哪里
So here’s where I’d put the moat in this era. It isn’t the model, which cheapens by the month and which you’re renting from somebody else regardless. It isn’t the talent either, because every lab is bidding for the same few hundred people and that price has already been discovered.那么，在这个时代，我会把护城河放在哪里？它不是模型，模型每个月都在贬值，而且无论如何你都是从别人那里租来的。也不是人才，因为每个实验室都在争夺那几百个人，价格已经被市场发现了。
It also isn’t the map of any one customer. That was true even a few years ago and it’s the same now, because extraction is nearly free and anyone can draft how a firm operates in an afternoon. 它也不是任何一个客户的地图。即使在几年前也是如此，现在依然如此，因为提取几乎是免费的，任何人都能在一个下午草拟出一家公司的运作方式。
The draft is not the asset. Knowing which parts of it are wrong is the asset, and that only comes from having been corrected.草稿不是资产。知道哪些部分是错的才是资产，而这只能来自于被纠正。
So, for us, the moat is the accumulated, current, verified understanding of how firms in a vertical actually operate, held in a platform that keeps it current and can prove it. Each of those words is load-bearing. Accumulated, because one deployment is an anecdote and the tenth is a pattern. Current, because operations drift and a stale model fails silently underneath an AI system in a way it never did in front of an analyst. Verified, because a plausible encoding and a correct one look identical until something breaks, and the whole point of insisting on provenance is that you find out which one you have.因此，对我们来说，护城河是关于垂直领域内公司如何实际运作的、累积的、当前的、经过验证的理解，并保存在一个能保持其最新状态且能证明其正确性的平台中。这些词中的每一个都是承重墙。累积，因为一次部署是轶事，第十次就是模式。当前，因为运营会漂移，陈旧的模型在 AI 系统下会静默失效，这与分析师面前的情况不同。验证，因为合理的编码和正确的编码看起来是一样的，直到出现问题，而坚持来源追踪的全部意义在于让你发现你拥有的是哪一种。
That is not purchasable. A competitor can hire your engineers, copy your interface, and read this article (ours try to do all 3!). What they cannot shortcut is the sequence of being wrong inside a customer, being corrected, folding the correction into the platform, and arriving at the next firm already knowing which questions are load-bearing. Every cycle of that makes the next one cheaper, and that compounding is the thing you own.这不是可以购买的。竞争对手可以雇佣你的工程师，复制你的界面，阅读这篇文章（我们的竞争对手试图做所有这 3 件事！）。他们无法走捷径的是：在客户内部犯错、被纠正、将纠正纳入平台，并带着已知哪些问题是承重墙的经验到达下一家公司的过程。每一次循环都使下一次变得更便宜，这种复利就是你拥有的东西。
I’ve watched this function get built three times and the pattern held every time. The engineers who mattered weren’t the ones who shipped the most for customers, but the engineers who came back and changed what we built.我观察过这个职能被构建了三次，模式每次都成立。真正重要的工程师不是那些为客户交付最多的人，而是那些回来改变了我们构建方式的人。
Hiring forward deployed engineers buys you exactly one thing, which is the right to identify which problems are worth solving. Most companies never get that far. But it’s the entry fee, not the prize.招聘前线部署工程师只能为你买到一件事，那就是识别哪些问题值得解决的权利。大多数公司从未走到那一步。但这只是入场费，不是奖品。
I’m Vinoo Ganesh, CEO of Kepler, where we’re building the layer this piece is about, the ground truth that lets an AI product trace every number back to source. Before Kepler I led Spark at Palantir and built Project Frontline, then ran business engineering at Citadel. If you’re building here, or you think I’ve got a piece of this wrong, you can argue with me on LinkedIn.我是 Vinoo Ganesh，Kepler 的首席执行官，我们正在构建本文所讨论的层级，即让 AI 产品能够将每一个数字追溯到源头的地面真理。在 Kepler 之前，我曾在 Palantir 领导 Spark 并构建了 Project Frontline，随后在 Citadel 负责业务工程。如果你正在此领域进行构建，或者认为我哪里说错了，欢迎在 LinkedIn 上与我辩论。
