夜雨聆风
一条 AI 流程在销售团队跑通了，管理层决定复制给另外四个团队。
第一周，问题就冒出来了：客户资料的格式不同，报价权限不同，例外条款也不同。模型没有明显变差，流程却开始返工。业务说系统不懂现场，技术说需求一直在变，供应商则等着下一轮反馈。
真正的风险随即暴露：没人能回答一句话，这条流程从业务问题到生产结果，究竟由谁牵头负责？
企业可以不设置一个名叫 FDE 的岗位，但必须指定一位总牵头人，把五项责任串起来：业务目标、生产交付、评测证据、版本例外和经验回流。
这里有两层责任：总牵头人对整条流程的闭环负责；五项责任各有一位唯一主责人。主责可以由同一个人兼任，也可以分给不同岗位，但每一项都要能写出一个名字。
FDE 到底是什么，为什么最近总被提起
FDE 是 Forward Deployed Engineer 的缩写，常被译作前线部署工程师。
这个岗位没有一套适用于所有公司的统一定义。OpenAI[1]和 Anthropic[2]的公开岗位说明都把 FDE 放在客户现场与产品工程之间：理解业务问题，建设生产系统，参与评测与部署，再把有效模式带回产品和工程团队。
Palantir 对前线部署工程角色的说明[3]也强调围绕一个客户组合多种能力，并与客户共同建设可持续改进的技术方案。
这些都是厂商自己的岗位设计，不是行业统一标准。企业更需要确认下面五项责任有没有落到人。
第一项责任：把业务问题写成可交付终点
牵头人首先要把一句模糊需求改成可验收的业务任务。
“让 AI 帮销售写方案”不够。至少要说清楚：流程从哪里开始，交付到哪里结束，结果给谁使用，什么叫合格，哪些结果不得由 AI 对外生效。
以销售方案为例，可以写成：
从客户需求确认完成开始，到生成一份经过核验、可交给报价负责人审批的方案包结束。 AI 可以整理需求和生成核验清单，价格、合同条款和对外承诺仍由原审批人决定。
这段话同时定义了终点和边界。后续技术选型、测试与验收才能围绕同一个目标展开。
第二项责任：让方案真的进入生产流程
演示环境里，一份干净样本就能跑通。生产流程会遇到缺字段、旧模板、权限差异、接口超时和人工临时改口径。
牵头人不一定亲自写完所有代码，但要对端到端交付负责：数据从哪里来，系统如何连接，谁能看什么，失败后转给谁，执行证据留在哪里。
如果团队只能展示模型回答，却说不清输入、权限、日志、回退和人工入口，项目还停留在演示阶段，无法持续运行。
第三项责任：用证据决定能否放行
上线只是一次放行动作。验收标准应在开发开始时就进入流程，不能等到最后一天再问“大家觉得效果怎么样”。
销售方案流程至少需要三类测试：
每次版本变化后，都要知道哪些样本重新测过，错误是否集中在同一类场景，人工接管是否增加。最终仍要回到业务数：交付时长、返工率、人工接管、业务结果和单位成本。
第四项责任：维护版本、例外和停止条件
流程复制到更多团队后，例外往往最先失控。
华东团队增加一条特殊报价规则，华南团队换了客户资料模板，总部又调整了审批权限。三次改动各自合理，叠在一起却可能让系统变成没人敢升级的分支集合。
牵头人要维护一份简单但持续更新的变更账：改了什么，为什么改，影响哪些团队，谁批准，哪些测试必须重跑，出现什么信号就回退。
例外可以存在，但不能只留在聊天记录和个人记忆里。
第五项责任：把现场经验变成可复用资产
一次交付结束后，团队至少应留下四类东西：稳定的输入格式、可复用的流程步骤、经过验证的评测样本，以及明确的人工关口。
新团队接入时，应从这些资产开始，再针对自己的业务差异做验证。不能直接复制一整套配置，也不能让每个团队重新从零搭建。
牵头人还要把反复出现的问题反馈给产品和工程团队。哪些能力应该做成公共组件，哪些规则只能保留在本地，哪些例外已经多到需要重新设计流程，都要有人持续判断。
一张填好的“五项责任卡”
仍以销售方案流程为例，负责人可以这样填写：
总牵头人： AI 项目负责人。 负责召集五项主责人，处理跨项冲突，并向管理层报告继续、调整或停止建议。
业务终点｜主责：销售负责人 证据：经过核验、可进入报价审批的方案包。 AI 生成内容不得直接对客户生效。
生产交付｜主责： AI 交付负责人 证据：需求系统、知识库与方案模板已连接；接口失败会转人工并保留日志。
评测证据｜主责：质量负责人 证据：每次变更重跑正常、边界和停止样本；每周记录交付时长、返工与人工接管。
版本例外｜主责：流程负责人 证据：各区域规则进入同一变更账；价格、合同和重大承诺仍走原审批。
经验回流｜主责：产品负责人 证据：每两周整理高频错误和人工修正，明确更新公共规则、本地规则还是产品能力。
五行里如果有一行找不到负责人，先别继续扩团队。问题不会因为账号开通得更多而消失，只会变得更难追踪。
FDE 能帮企业做什么，不能替企业做什么
FDE 或类似的 AI 交付牵头人，可以帮助团队理解问题、建设系统、建立评测、推进上线和沉淀复用模式。
但企业内部仍要保留几项明确责任：谁批准业务规则，谁授权数据和权限，谁接受剩余风险，谁有权暂停或下线流程。
NIST AI RMF 的治理实践建议[4]建议组织明确 AI 全生命周期的角色、责任和授权，并覆盖部署后的维护、监测、再验证、事件响应和停用。它没有要求设置 FDE 岗位，却支持一个很实际的治理判断：外部交付人员可以参与建设，企业不能把最终责任一起外包。
比较稳妥的配置是“一位具名牵头人，加一组按需参与的跨职能支持”：业务负责人决定目标和规则，工程人员负责生产系统，数据与安全人员把住权限，一线使用者提供真实反馈。
负责人今天可以开的 30 分钟责任会
把正在推广的一条 AI 流程放到桌面上，照着上面的责任卡填写六列：责任、唯一主责人、协作方、交付证据、检查频率、停止或升级条件。
先定一位总牵头人，再逐项确认主责。每项只填一位主责人，其他人放在协作方。主责人可以兼任，但不能写“业务部”“技术部”或“大家共同负责”。填不出名字的责任，就是下一轮扩展前要补的缺口。
岗位名可以因公司而异。关键是有人能把一条真实业务流程从问题带到生产结果，并在上线后继续维护证据、版本和反馈。
下一篇继续回答更现实的问题：一次企业 AI 陪跑结束后，负责人到底应该拿到哪六项可验收的交付？几次培训和一套演示显然不够。
建议阅读顺序
参考资料
参考链接
[1] OpenAI: https://openai.com/careers/forward-deployed-engineer-uae-abu-dhabi-uae/
[2] Anthropic: https://job-boards.greenhouse.io/anthropic/jobs/5302966008
[3] Palantir 对前线部署工程角色的说明: https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87
[4] NIST AI RMF 的治理实践建议: https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern
[5] OpenAI, Forward Deployed Engineer - UAE: https://openai.com/careers/forward-deployed-engineer-uae-abu-dhabi-uae/
[6] Anthropic, Forward Deployed Engineer: https://job-boards.greenhouse.io/anthropic/jobs/5302966008
[7] Palantir, Dev versus Delta: Demystifying engineering roles at Palantir: https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87
[8] NIST AI RMF Playbook: Govern: https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern