Moonxi
预约诊断
Forward Deployed Engineer(前置驻场工程师)

工程做进你的业务里,而不是做成一份关于它的报告。

工程师和一线的人坐在一起,在你的环境里写代码,并为留在生产环境里的东西负责。这是 Palantir 在 2010 年代初创造的模式,后来 OpenAI 和 Anthropic 也用它,把 AI 装进已经在运转的公司里。

预约诊断 →

先别管名字:这个人到底做什么。

把英文名字拿掉,剩下的描述很朴素。这是一个软件工程师,在你公司内部、在你的系统里、用你真实的数据,和每天做这件事的人一起干活。他不是写一份关于你业务的文档:他写的是你业务将要用起来的那段代码。

三件事定义了这个形态。少掉任何一件,它就变成别的东西了。

01.

待在活真正发生的地方

不是开进度会。是跟着一线的人,在业务真正运转的那个时段,看到那个从来没写进文档的步骤 —— 因为对做的人来说它太理所当然了。

02.

在你的环境里写代码

你的代码仓库、你的云、你真实的数据 —— 不是一个拿匿名数据做的概念验证,之后还得有人重写一遍才能真用。

03.

为结果负责

验收标准不是「范围交付完了」。是业务确实变好了,而且工程师走出这间屋子之后它继续正常运转。

它从哪儿来

这个模式不新。它是现在才变紧急的。

它诞生在一家向政府和重工业卖软件的公司里 —— 在那里,交完许可证就走人从来没成功过。当 AI 开始依赖每一个客户自己的数据和流程时,同一个问题回来了,于是前沿的那几家公司照抄了这个解法。

Palantir · 2010 年代初

这个岗位是在这儿被造出来的

工程师在客户那边干活,而不是在总部。到 2016 年前后,公司里做这件事的人比产品工程师还多。

来源:The Pragmatic Engineer
OpenAI · 2025 年

第一个照抄的

这个团队 2025 年初从两名工程师起步,后来超过十人,分布在八个城市,把前沿模型送进客户内部的生产环境。

来源:The Pragmatic Engineer
Anthropic · 在招

招聘要求写了什么

在客户的系统里建生产级应用,25% 到 50% 的时间出差到现场工作,并把反复出现的模式带回给产品团队。

来源:该职位的招聘说明

a16z 把这个岗位称为行业里最抢手的岗位,并且开了自己的培养项目:第一期 65 人,从数千份申请里挑出来。来源:a16z

工程师待在外面时,什么会坏掉。

试点跑通了,却上不了生产环境

在演示里跑的那个东西没有对接、没有人操作,也没有一套「出错了怎么办」的现成答案。

我们写过这个 →

决定难案子的那条规则没写下来

它在那个干了很多年的人身上。而且只有当有人坐在旁边、一起看着屏幕、正好碰上那个难案子的时候,他才会说出来。

对接的问题在切换那天才冒出来

有一部分记录里那个字段是空的、那个系统只接受凌晨的批量导入、那份报表一直有人手工改。靠开会做调研,这些一个都发现不了。

上线之后没人是主人

交付单签了,团队解散了,生产环境第一次出错时找不到人。项目变成亏损是在这一刻,不是在建设阶段。

在 Moonxi,它一周一周是怎么走的。

它不是第六条业务线。它是 Moonxi 交付 建设软件开发专属团队 这三条线的方式。报价照旧在诊断阶段按业务线定死。

第 1 周 · 摸底

和一线操作的人聊。拿到系统和数据库的只读权限。画出数据地图:在哪儿、什么状态、谁在用。还有你以前试过什么、卡在哪一步。

第 2 周 · 文档和报价

AI 先从哪儿进、架构怎么搭、每月跑起来多少钱、哪些必须人工审批。按业务线给出固定报价,带工期。一行代码都不写。

签约之后 · 进到业务里面

节奏变成每周一次:和一线的人过一遍、一块能在你环境里跑起来的东西、外加一份改动清单。建设过程中你的团队复核每一步。

每个月 · 交接棒往前递

你团队里会有人在建设过程中就学会操作、复核和纠正,不是等交付完再学。上线的东西都带文档和运维手册。

不变的部分:我们怎么做 里的规矩在这里同样成立。每个数字都带着来源,动作发出去之前由人点头,敏感数据不出你的环境。

适合谁。

你想自动化的那个决定,在一摊已经运转起来的业务里面,有人、有系统、有量。

出错要付出金钱、工期或者监管风险的代价 —— 而且出错时得有人负责。

你这边有一个人愿意去操作、复核和纠正。这个人不需要会写代码。

不适合谁。

你要的是一份能拿去给董事会的建议。那种情况下解决问题的是 调研与架构 那条业务线。

你缺的是按小时算、没有目标的人手。那是人头外包,Moonxi 不做。

你的系统一个都不能让外面的人碰。没有事先谈好的真实环境访问权限,这个模式就不成立。

和咨询、和按小时计费的合同比,差在哪儿。

三种形态都存在,因为它们解决的是不同的问题。真正重要的差别永远是同样三点:这个人在哪儿干活、他走之后留下什么,以及周三下午三点它坏掉的时候谁来接。

咨询

在哪儿干活在演示文稿和文档里
留下什么一份建议和一份计划
生产环境谁负责之后来执行的那个人

当瓶颈是「决定」而不是「系统」的时候,它管用。

按小时计费的合同

在哪儿干活在你指定的那些任务上
留下什么你要求的那些,按你要求的样子
生产环境谁负责定范围的你自己

当你已经有架构、有目标、有人复核的时候,它管用。

Forward Deployed Engineer

在哪儿干活在你的业务内部,在你的环境里
留下什么跑在生产环境的系统,带文档和手册
生产环境谁负责写它的人,和你的团队一起

当系统必须每天正常运转、而且它不转的时候得有一个具体的人名,它管用。

关于这个模式的问题。

Forward Deployed Engineer 是 Moonxi 的第六条业务线吗?

不是。它是 Moonxi 交付建设、软件开发和专属团队这三条业务线的方式。报价照旧在诊断阶段按业务线定死。

工程师会坐在我的办公室里吗?

一部分时间会,前提是这项工作本身需要到现场。其余时间他在你的数字环境里:你的代码仓库、你的云、你团队的例会。具体怎么安排,开工前在诊断里就写清楚。

你们需要访问我的系统吗?

需要,而且访问级别提前谈好。诊断阶段只有只读权限。数据敏感的地方,标准架构会把带身份标识的数据留在你的环境里。

这是不是换了个名字的人头外包?

不是。人头外包卖的是没有目标的工时。这里有明确的交付范围、有工期,也有人为生产环境里跑着的东西负责。

以后我想自己接手怎么办?

可以。上线的东西都带文档和运维手册,而且你团队里会有人在建设过程中就学会操作、复核和纠正,不是等交付完才学。

多少钱?

报价在诊断阶段按业务线定死。没有价目表,因为没有两个项目是一样的。

从一次诊断开始。

两周,一份文档,一份固定报价。

预约诊断 →