
到本文结束时,你应该会理解为什么前沿部署工程在今年分化成了两种规模,较小规模在实践中是什么样子,以及为什么一家 20 人的 B2B SaaS 公司永远不应该尝试向较大规模的那种购买服务。
我为创始人主导的 B2B SaaS 公司提供前沿部署 AI 工程服务,这类公司通常有 5 到 50 名员工,已跨过产品市场契合点,拥有付费客户,董事会也在追问 AI 的事。这项工作的形态与 Palantir 发明的、OpenAI 刚刚斥资 100 亿美元成立 The Deployment Company 要做的、以及 Anthropic 在同一个 24 小时窗口内成立自己的部署部门要做的,是同一种。但它的定价大约低 50 倍,在 10 个工作日内完成而不是几个季度,并且交付的是嵌入客户产品中的一个单一、狭窄的工作流,而不是企业级转型。
这个品类的分化是悄然发生的。大多数创始人还没有注意到。这是我当初创业时希望存在的一篇文章。
为什么 FDE 必须分化成两种
前沿部署工程最初的立论依据是经久不衰的:你无法在不身处某个环境内部的情况下为该环境构建软件。Palantir 在 2010 年用随美军特种部队驻扎在阿富汗的 FDE 证明了这一点。作战人员在白天执行任务、反馈意见,FDE 们连夜交付代码。这一原则适用于任何复杂领域。如今它也适用于 AI。
2026 年,全球最大的两家 AI 实验室在 24 小时之内做出了相同的押注。OpenAI 成立了 The Deployment Company,一家 100 亿美元的子公司。Anthropic 也成立了一个类似的部署部门。两者的押注都基于同一个论点:前沿模型不再是产品。部署才是。
两者的押注瞄准的是同一个买家:财富 500 强企业。最低合作金额超过 25 万美元。采购周期以季度计。安全审查比实际工作耗时更长。这是合理的。按前沿实验室的定价,现场工程部署的单位经济模型只有在企业规模下才能成立。
问题在于,20 人的 B2B SaaS 公司如今在三个方面与财富 500 强处于相同的境地。
第一。他们面临董事会层面的压力,要求今年上线 AI 功能。投资人在问。竞争对手在上线。客户也在期待。
第二。他们的内部团队不知道如何界定范围或交付 AI 工作流。有人试过做一个原型。有人建议做一个聊天机器人。但没有任何东西进入生产环境。
第三。前沿模型被闲置着。它完全有能力做他们路线图上需要的事,只差部署这一环。
但他们无法向 The Deployment Company 购买。光是采购流程耗费的时间就会超过工作本身。他们不可能为一个为期两周的项目跑一个长达一个季度的安全审查。
这就是缺口。同样的问题,不同尺寸的容器。
低于企业门槛的 FDE 是什么样子
与企业版相同的交付形态。其他一切都更小。
工作单元是一个 10 个工作日的 Sprint,将一个狭窄的 AI 工作流交付到客户的产品中。范围固定。价格固定。第 10 天代码提交到客户的代码仓库。不是战略演示文稿,不是路线图,也不是市场团队想出来的聊天机器人。而是一个具有清晰输入、清晰输出的工作流,并且客户团队中有一位会使用它的人。
在这个容器中,有三件事是不可妥协的。
它是工作流,不是功能。“功能”意味着一个可以附加的东西:一个按钮、一个标签页、一个界面。“工作流”意味着用户运行的一个流程。输入、操作、输出。这个词汇强制了“功能”一词所不具备的范围界定纪律。你可以围绕一个 AI 功能开会六周,却始终离交付更远。但工作流不行,因为这个词本身就要求你指明用户、触发条件和输出。
它交付到客户的技术栈中,而不是供应商的仪表板。代码存放在客户的代码仓库中。工作流在他们现有的产品或管理工具内运行。前沿部署意味着工程师嵌入到客户的运营中,而不是再卖给他们一个需要维护的 SaaS 产品。Palantir 原则可以浓缩为一句话:不要迁移客户,嵌入他们已有的系统。
默认包含人工审核。每个 v1 工作流都带有人工参与环节。AI 起草;人工审核、编辑,并在任何重要操作之前进行批准。自主性是在赢得信任后的后续迭代中逐步加入的,而不是在首次合作的第 10 天。对于执行不可逆操作、自动发送面向客户的消息或产生法律风险的工作流,在客户团队明确签字同意提高自主性之前,始终保持辅助模式。
实际交付的内容
一个 10 天的 Sprint 以七项交付物结束,打包以便交接:
- 已实现的工作流部署到预发布或生产环境,或以可上生产的 pull request 形式交付,具体取决于客户的基础设施。
- 代码仓库中的实现文档,重点说明三个月后阅读代码的人需要了解的内容。
- 一段 10 到 20 分钟的录制演示,端到端讲解工作流以及关键的实现决策。
- 一份输出质量评分标准,一个 1 到 5 分的评分框架,每个分数级别都附有实际示例,并围绕与工作流相关的维度进行评分(准确性、完整性、语气、格式合规性、抗幻觉能力)。
- 一份工作流操作手册,涵盖目的、输入、预期输出、审核步骤、边界情况和维护指南。
- 一份 Sprint 后 30 天路线图,为客户团队提供具体的下一步建议。
- 一场 60 到 90 分钟的团队交接会议,与客户的工程师一起讲解代码、提示词、评分标准以及如何维护工作流。
评分标准和操作手册是这项工作区别于自由职业提示词工程的两个交付物。做好它们各需约两小时。它们让客户的团队能够在没有我的情况下维护和迭代工作流。它们还创造了天然的长期服务切入点:“我们建立了评分标准,要不要我们在你们上线更多工作流时继续维护它?”
这项服务适合谁,不适合谁
客户画像是刻意收窄的。
合适的客户:拥有 5 到 50 名员工的 B2B SaaS 公司的创始人兼 CEO。已度过产品市场契合期。有付费客户、产品内有真实数据,并面临董事会层面要求今年上线 AI 功能的压力。能快速决策,团队中有人会在交接后负责该工作流,且不打算在 10 天内完成企业级转型。
不合适的客户,会礼貌拒绝:
- 独立开发者和单人创始人。他们的工作量太小,定价不划算;而定价对他们来说又太高。他们应该自己用 Claude Code 上线工作流。
- 超过 200 人的企业。他们的采购周期比交付周期还长。他们的合规要求超出服务范围。他们应该向 The Deployment Company 或 Anthropic 的部署部门购买。
- 尚未达到产品市场契合的初创公司。他们需要的是产品市场契合,而不是 AI 工作流。给一个还没有客户的产品添加 AI 不是正确的下一步。
对错误的客户说不,是这类业务中杠杆率最高的运营纪律之一。每一个不合适的 Sprint 都会出问题:因为匹配错误导致工作失败,客户不满意,而且这个名额被占用,本可以留给一个合适的客户——他们本可以成为案例研究和转介绍来源。诚实的拒绝不是损失收入,而是对产能的保护。
为什么这种规模的 FDE 现在存在而不是更早
这种特定形态的工作(资深操盘手、固定价格、范围收窄、10 天交付)的市场窗口大约有 18 到 30 个月。两件事会将其关闭。
B2B SaaS 公司的内部团队会吸收这种能力。到 2027 或 2028 年,大多数产品和工程团队都会自己上线过至少一个 AI 工作流,不再需要外部帮助来做收窄范围的工作流。这类工作将向复杂度阶梯上方移动。
更大的咨询公司会追上前沿部署工程的定价。随着这个品类成熟,5000 到 10000 美元的固定价格 AI 项目将成为一个竞争性细分市场,而非利基市场。单人操盘手的定价能力将被压缩。
刻意在这个窗口内运营就是策略。未来 18 个月内交付的工作,将成为支撑之后一切的案例研究。
TLDR
- 前沿部署工程今年分化成了两种规模。企业版:25 万美元以上,采购周期长达一个季度,面向财富 500 强。创始人主导的 B2B SaaS 版:5000 到 10000 美元,10 个工作日,固定范围。
- 同样的交付模式。深入客户的技术栈,在他们的代码库中编写代码,交付后附上文档。Palantir 原则可以完美地缩小规模应用。
- 工作单元是一个具体的工作流,而不是一场变革。“工作流”这个词是承重墙式的表述。它强制执行“功能”一词无法带来的范围界定纪律。
- 交付的内容:可运行的代码、一份评分标准、一份操作手册、一份演示指南、一份路线图、一次团队交接。评分标准和操作手册正是这种工作与自由职业的区别所在。
- 市场窗口期为 18 到 30 个月。此后,内部团队会吸收这种能力,咨询公司也会压低价格。
如果你是面临董事会压力、要求今年就交付 AI 功能的 B2B SaaS 创始人,问题不在于你是否需要前沿部署工程的工作,而在于你能否从规模适合你的服务商那里买到这种服务。过去的答案是否定的,而现在正逐渐变为肯定。
如果这个话题对你有帮助,我在我的书 Forward Deployed AI Engineering: A Working Guide to the Hottest Job in Software 中有更深入的探讨。该书现已在 Amazon 上架:https://www.amazon.com/Forward-Deployed-AI-Engineering-Software/dp/B0H3VKKG38/