企业很少因为缺少一个更强的模型而无法推进 AI 项目。模型之外的工作通常更耗时：数据散落在旧系统里，部门使用不同术语描述同一对象，正式流程与实际操作不一致，需求清单也没有说明业务结果。
Forward Deployed Engineer（FDE，前线部署工程师）长期工作在这些问题发生的位置。这个角色同时承担现场调查、产品判断和工程交付，把客户的模糊诉求改写为可验证任务，再把一次项目中重复出现的能力交还给产品团队。
FDE 的工程难点主要来自取舍。现场总能发现更多问题，技术也总能继续增加复杂度，但每次交付只能集中解决一个可衡量的业务问题。
FDE 处理产品与现场之间的距离
复杂平台通常由技术团队构建，却未必由技术人员购买和使用。业务负责人关心收入、成本、风险与交付时间，工程团队关心接口、权限、数据质量和运行边界。FDE 负责让两组问题在同一个项目里对应起来。
| 工作视角 | 需要回答的问题 | 形成的结果 |
| 顾问 | 现场实际怎样工作，谁在何时做什么 | 真实流程、例外情况、重复动作 |
| 产品经理 | 哪个问题值得现在解决，成功如何判断 | 范围、非目标、验收指标 |
| 工程师 | 如何接入现有系统并长期运行 | 代码、测试、日志、交接文档 |
| 产品反馈 | 哪些现场经验可以供更多客户使用 | 通用能力、配置项、自助入口 |
这四项工作构成连续循环。只做前两项，项目会停在咨询报告；只做工程实现，团队容易按表面需求堆积功能；只做客户定制，交付能力会随客户数量线性增长。
FDE 因此属于产品工程的一部分。客户现场提供高密度反馈，产品团队负责把反馈变成可维护的公共能力。团队需要提前约定这条反馈路径，否则现场工程师会逐渐变成长期维护定制代码的外部开发人员。
先看动作，再整理需求
访谈能说明组织希望怎样工作，现场动作能说明组织现在怎样工作。两者之间的差异往往就是项目入口。
Vinoo Ganesh 在 How Forward Deployed Engineering is done at Kepler 中回顾过两个例子。
一个运输调度团队准备了 47 页需求，包含仪表盘、指标和逐层查看能力。工程师在现场询问调度员每周一首先做什么，得到的答案是检查卡车是否晚点，再联系人员调整路线。团队用约 4 小时交付了一条 Slack 提醒，先解决了最直接的操作问题。
另一个数据团队每天向 S3 写入约 1 TB 数据，希望从 CSV 迁移到 Parquet，但数据质量人员长期反对。现场观察发现，她每天会下载 CSV，用 Excel 打开并抽查数据；Parquet 打断了这个检查动作。团队补充查看工具后，迁移获得认可，演讲中给出的流水线运行时间从约 17 小时降到约 2 小时。
这两个例子共同暴露了需求文档遗漏的内容：操作者为完成工作必须执行哪些动作。FDE 可以重点记录以下信号：
同一动作每天或每周重复出现；
内容需要在多个页面、表格或消息之间复制；
操作者频繁切换标签页或工具；
流程依赖「必须先手工处理」的隐含步骤；
正常路径很短，例外处理却占用了大部分时间。
观察时还要区分个人习惯与业务约束。一个人喜欢 Excel，不代表系统必须围绕 Excel 设计；如果抽查是数据发布前的责任要求，那么可视化检查能力就是迁移方案的一部分。
把症状改写为可验收任务
客户提出的通常是解决方案名称，例如「增加仪表盘」「接入 Agent」或「把流程自动化」。范围界定要退回到业务结果，逐项验证隐藏前提。
一份最小任务契约可以包含以下内容：
| 字段 | 需要写清的内容 |
| 当前动作 | 谁在什么条件下，通过哪些系统完成工作 |
| 业务结果 | 需要缩短时间、减少错误、增加收入，还是降低风险 |
| 成功指标 | 当前基线、目标值、测量窗口与数据来源 |
| 前提条件 | 设备、权限、网络、数据格式和系统版本是否真实存在 |
| 非目标 | 本轮明确不处理哪些相关问题 |
| 最小改动 | 能验证业务结果的最小生产方案是什么 |
| 责任归属 | 谁确认结果，谁维护系统，异常时由谁处理 |
连续追问「为什么」用于区分症状、手段和结果。例如，「仪表盘加载太慢」可能需要查询优化，也可能源于操作人员只缺少一条异常提醒。只有结果明确后，技术选择才有判断依据。
范围还需要经济约束。若规则固定、输入结构稳定，并且一段确定性代码可以完成任务，就先用脚本或普通服务。模型适合处理含义判断、非结构化输入和难以穷举的变化，不应替代能够清楚编码的业务规则。
Anthropic 在 Building Effective AI Agents 中也建议从最简单的可行方案开始，只在确实改善结果时增加 Agent 系统的复杂度。对 FDE 来说，这项原则还会缩短验证周期：越早让操作者使用真实方案，越早发现需求理解是否正确。
快速交付仍然要按生产标准处理
现场方案一旦让工作变得更容易，就可能被长期保留。Ganesh 在同一场演讲中提到，一段为客户快速编写的数据保留脚本后来进入大规模生产使用，团队不得不长期承担维护责任。作者原本认为它只是临时实现，客户看到的却是一项已经解决问题的能力。
最小方案收缩功能范围，同时保留完整的生产责任。至少需要确认：
输入与错误语义：无效、缺失和矛盾数据如何处理，失败能否被操作者理解；
幂等与重试：重复执行会不会产生重复记录，外部服务超时后如何恢复；
可观察性：日志、指标和审计记录能否回答系统处理了什么、为何失败；
验证能力：类型检查、单元测试、集成测试或端到端测试覆盖哪些关键行为；
权限边界：系统能读取和修改哪些数据，哪些动作必须人工确认；
交接责任：FDE 离场后由客户团队、平台团队还是产品团队维护。
准备度建设也属于交付。缺少稳定测试、发布流程和反馈数据时，Agent 很难从失败中改进，团队也无法判断新版本是否更好。必要的 CI/CD、类型检查、评估集和审计日志决定自动化能否持续运行。
用统一语言减少集成错误
企业内部经常用多个名称描述同一实体。销售团队说「客户」，财务团队说「账单主体」，工程系统保存 organization_id。这些词可能指向同一个对象，也可能只在部分情况下重合。
FDE 需要在写代码前整理名词、动作和所有权：
一个名词对应哪个业务实体，唯一标识来自哪里；
不同部门的同名词是否具有相同含义；
一个动作由谁发起，会改变哪些状态；
哪个系统是权威数据源，冲突时采用什么规则；
Agent 检索上下文时，应使用哪组正式术语和别名。
词汇表只是记录方式。统一语言会直接进入数据映射、工具参数、权限策略、评估样本和产品界面。概念边界模糊时，模型只会更快地产生不一致结果。
把一次性交付变成产品证据
现场实现需要同时交付两个结果。第一个是当前客户可以运行和维护的方案，第二个是供产品团队判断是否通用化的证据。
适合进入核心产品的信号包括：
多个客户出现相同任务，只是字段和权限配置不同；
现场代码反复实现同一类连接、校验或审计能力；
同一个失败原因在多个项目中持续阻碍采用；
客户可以通过配置和文档自行完成后续操作；
通用化能够减少后续 FDE 的维护负担。
一次请求不能直接证明市场需要。FDE 应记录问题频率、使用数据、失败类型、维护成本和客户能够独立完成的范围，再由产品团队决定做成公共能力、配置模板、内部工具，还是继续保留为项目代码。
用 AI 扩大调查与准备能力
FDE 团队很难只靠增加人数覆盖更多深度集成项目。AI 更适合先承担资料密集、结果可复核的准备工作，让工程师把时间留给现场判断。
| AI 适合承担 | 人类 FDE 继续负责 |
| 汇总历史工单、会议记录和系统文档 | 判断材料是否反映真实流程 |
| 找出术语冲突、重复步骤和缺失字段 | 与不同角色确认概念和责任边界 |
| 根据模板起草任务契约与问题清单 | 决定范围、非目标和成功指标 |
| 运行评估、比较日志并整理异常样本 | 判断业务风险与是否可以上线 |
| 生成连接代码、测试草稿和交接文档 | 审查架构、安全与长期维护责任 |
这类 AI 助理需要受限的数据权限、可追溯引用和清楚的停止条件。它可以提出「还缺少哪些信息」，不应在没有现场证据时替 FDE 决定客户真正的问题。
资深 FDE 的 30 天训练计划
30 天训练以完成一次可以检查的调查、交付和业务验收循环为目标。选择一个每周都会发生、有真实操作者、两周内能够观察结果的流程，例如发票处理、客服分流或运营异常检查。
| 时间 | 训练重点 | 交付物 | 验收证据 |
| 第 1 周 | 建立反馈 | 任务契约、最小 Workflow、工具调用、记忆范围和审计日志 | 10 组真实样本与完整执行记录 |
| 第 2 周 | 处理失败 | 缺失、错误、矛盾、超时和重复输入的故障矩阵 | 重试、幂等、人工接管与恢复测试 |
| 第 3 周 | 衡量收益 | 固定评估集、质量基线、耗时与运行成本记录 | 与人工流程比较准确率、周期和总成本 |
| 第 4 周 | 做部署决策 | 工程评审材料与业务决策说明 | 安全边界、上线条件、回滚方案和 ROI 结论 |
ROI 不应只写「提高效率」。可以采用一条简单公式，把假设逐项列出：
月度净收益 = 节省工时对应的成本 + 风险损失减少 + 新增收入 - 运行与维护成本
无法可靠换算金额时，保留原始指标也比虚构财务数字更有用，例如平均处理时间、人工接管率、严重错误数和任务完成率。第四周需要用两种语言说明同一方案：工程评审回答系统为何可靠，业务评审回答现在是否值得部署。
第 30 天应留下一个能继续运行的窄方案、一组失败证据、一份业务结果记录，以及明确的后续归属。然后再判断下一步是扩大范围、形成产品能力，还是停止投入。
