前沿部署工程 · 第 2 部分（共 4 部分）

第 1 部分回答了什么是前沿部署工程师。这一部分要回答的是：他们一周到底在做什么。

上期回顾

第 1 部分定义了这个角色：一名工程师，走到问题所在的地方，弄清楚真正的问题是什么，构建解决方案，并将其投入实际使用。

这就留下了一个显而易见的问题。如果这份工作不只是按照规格说明写代码，那么工作日里到底装满了什么？

简短的回答是：FDE 坐落在两个交汇点上——既贴近客户，又贴近技术。任何单独一面都不构成这份工作。本文将带你看看这在实践中是什么样子——工作所遵循的八个阶段循环、真实的一天、关键技能、技术栈，以及如果你想走到那一步的学习路径。

核心理念 软件工程师构建软件。前沿部署工程师围绕真实的客户问题构建并部署解决方案——并且始终对它是否奏效负责。

工作遵循一个循环

每一个客户项目，无论身处哪个行业，都会大致经历同样的八个阶段。在深入任何单个环节之前，值得先看清整体形态。

图 1 —— 八个阶段，以及把终点连回起点的闭环。

注意，这是一个循环，而不是一条直线。部署之后发生的事情会直接反馈回来，帮助更好地理解问题。大多数工程流程在第 7 阶段就停止了。

八项职责，逐一展开

关于这个角色最常见的误解是：它只是一份多了些会议的软件工程工作。实际上，FDE 每周要换好几次“帽子”。某一天是在访谈用户、梳理工作流程；第二天则是在写 Python、接 API、测试 LLM 工作流、部署容器——然后向高管汇报结果。

1. 理解真实的业务问题

客户描述的是症状。FDE 的首要任务是找到症状之下的原因。这意味着在触碰任何技术之前，先问一组朴素但关键的问题：

● 这个流程今天实际上是怎么运转的？

● 人们在哪些地方浪费了最多的时间？

● 错误容易在哪些环节悄悄出现？

● 已经存在哪些数据，谁有权查看它们？

● 我们如何判断解决方案是否奏效？

实践中 一家零售商说客户正在放弃购物车。答案未必是新的折扣引擎。真正的原因可能是结账太慢、运费出乎意料、支付失败，或者最后一步令人困惑。如果先去构建折扣引擎，什么问题都解决不了。

2. 直接与客户协作

FDE 会花实实在在的时间和实际干活的人在一起。开展工作坊、观察工作流程、演示原型、收集反馈，并把听到的东西转化为工程决策。

实践中 一家医院表示希望用 AI 帮助医生。在做出任何决定之前，FDE 会观察医生如何检索病历、护士如何更新信息，以及会议纪要实际流向何处。只有这样，助手的形态才会变得清晰。

3. 将业务语言转化为技术设计

利益相关者不会用 API、检索层或身份验证来描述问题。把一个业务成果转化为可实现的架构是一种独特的能力，而这正是这个岗位真正获得报酬的原因之一。

实践中 “我们需要更快的客户支持”可以转化为：一个连接到经批准的知识库的助手，包含检索层、LLM、CRM API、身份验证、分析功能，以及明确的转人工升级路径。

4. 设计契合的方案——而不是最炫技的方案

一位优秀的 FDE 会判断 AI 应该用在哪里，同样也常常判断它不该用在哪里。传统应用逻辑、LLM、检索、Agent 工作流、确定性的业务规则——或者某种组合。以下问题可以帮你做出判断：

● 这真的需要语言模型吗，还是普通逻辑会更可靠？

● 是从经批准的文档中检索，还是直接提示？

● 必须连接哪些现有系统？

● 在任何操作发生之前，哪些环节必须由人工审批？

● 适用哪些安全与合规控制？

实践中 对于内部政策助手来说，检索通常是比训练新模型更好的答案——因为每个回答都必须基于组织自己经批准的文档，并且能够追溯到这些文档。

5. 构建快速原型

一个小型可运行的东西在一周内教给你的东西，比一个月的需求讨论还要多。人们无法抽象地告诉你他们想要什么，但面对眼前的东西，他们能立刻做出反应。

实践中 对于法律文档助手，早期原型可能处理上传、摘要、问答和引用。律师们在使用十分钟后抱怨的地方，就决定了生产环境的范围。

6. 与现有系统集成

真实的企业已经在运行 CRM、ERP、数据库、身份平台、工单系统、文档存储，以及二十年间积累的自建应用。新方案必须融入其中，而不是游离其外。

实践中 员工向 HR 助手询问自己的假期余额。回答需要同时做两件事：从文档中检索政策文本，以及从 HR 系统获取实时余额。

7. 部署并运营它

成功的演示并不是终点。一个能服务十个用户的东西，在成千上万人依赖它之前必须经过加固——可靠性、权限、成本控制、日志、监控，以及出现故障时的合理行为。

在实践中 服务于十名试点用户的原型不会遇到三千用户时出现的问题：权限边界情况、每次查询的成本、模型响应慢时怎么办，以及凌晨两点该呼叫谁。

8. 衡量是否奏效

一个系统在技术上可能很健康，但仍然算失败。FDE 会将技术表现与业务数字联系起来——节省的时间、降低的成本、提升的质量、采用率、满意度、收入。

在实践中 如果一个客服助手回答正确，但客户因为不信任它而继续致电人工客服，那么技术实现就不算成功。准确性从来都不是关键约束。

工作的一天

没有固定的时间表，因为工作会随项目阶段而变化。但一个有代表性的一天可以展示这个角色如何融合沟通、设计、工程和交付。

图 2 — 一个有代表性的工作日，按工作类型用颜色标注。

编写代码很重要，但它只是那一天中的一个环节。探索、沟通、架构、测试、部署和反馈占据了其余时间——而这些并不是围绕工作的额外负担。它们本身就是工作。

技能的三个层次

将技能分组而不是逐一列举会更有帮助。共有三个层次，它们的普遍程度并不相同。

图 3 — 技能的三个层次。大多数工程师在第一层很强。

技术栈

最好将技术栈理解为分层结构而不是一份清单，因为每一层只有在下一层稳固时才能正常运作。

图 4 — 分层的技术栈，基础在前。

具体工具因公司和项目而异，而且会不断变化。持久的技能不是记住一份框架清单——而是充分理解相关概念，以便能为客户的环境选择合适的工具，包括那些不允许你安装任何新东西的环境。

学习路线图

如果你在朝这个角色努力，顺序很重要。在薄弱的工程基础之上叠加 AI，只会产出无法部署的演示。

图 5 — 四个阶段，按顺序进行。

走通这条路最有效的方式是以项目为驱动：学习一个概念，将其应用到真实的业务场景中，部署它，获取反馈，然后改进。这个循环就是实际工作的一个缩影。

一个项目，端到端

假设一家公司说：“我们的员工在搜索内部政策上浪费了太多时间。”下面是这个需求如何经历八个阶段的过程。

贯穿始终的思维方式

上面几乎所有内容都源于一个习惯：你的起点。

不要从“我应该使用哪个 AI 框架？”开始。而要从“客户想要改进什么，以及证明它可以被改进的最简单可靠的东西是什么？”开始。

第二部分五句话总结

● FDE 远不止是一名开发者——工作范围从发现真正的问题一直延伸到衡量解决方案是否带来了改变。

● 工作遵循一个不断重复的八阶段循环，而且这个循环并不止步于部署。

● 涵盖工程、数据、云和 AI 的技术广度只是入门要求，而非差异化优势。

● 沟通能力、好奇心、商业思维以及对模糊性的适应力，才是把一名工程师转变为值得信赖的面向客户的问题解决者的关键。

● 学习它的最快方式是项目驱动：构建、部署、获取反馈、改进——与这份工作本身相同的循环。

即将推出

第 3 部分将从职责和技能转向实际应用：医疗、银行、制造和零售用例；在各项目中反复出现的工具；重要的业务领域知识；以及从这个角色发展出的职业路径。

如需更深入的技术见解和文章，欢迎浏览：

Ebasiq

GirishBlogBox

Ganitham Guru

  • Substack: Ganitham Guru——探索吠陀数学、古代数学、现代数学及更多领域的数学之美。