AI落地困境：比写代码更难的是如何用好AI

瓶颈通常不在模型。

企业数据分散在多个系统中，层级权限复杂，流程中隐藏着许多未文档化的例外。业务部门要求“AI客服”，但实施时需要回答具体问题：哪些问题自动回答？哪些需要人工？数据在哪里？错误能否撤回？上线后看什么指标来判断是否节省时间？

这正是 FDE 的核心任务。

FDE 代表 Forward Deployed Engineer，通常译为前向部署工程师。简单来说，他需要深入客户的实际业务，将 AI 接入现有系统，编写可运行的工具，并持续监控其使用情况。

FDE在现场连接业务流程与AI系统

该职位近期备受关注：模型调用越来越简单，但将其嵌入复杂、混乱且涉及人的业务流程却很难。

FDE 究竟在做什么

让我们看一个具体场景。

一家连锁零售公司想实现“智能补货”。乍听之下很清楚，但 FDE 到场后，挑战才刚刚开始：

第一周，他可能一行代码也没写。他必须与门店经理、供应链、IT 和安全团队坐下来梳理流程。一旦问题拆解，工程工作才启动：接入库存和订单系统，清洗数据，编排 Agent 工作流，设计界面，添加权限、日志、监控和人工复核。

上线不是终点。

门店是否在使用？采纳了多少建议？缺货率是否下降？员工为什么又回到 Excel？这些问题必须持续追踪。界面难用就改，模型输出不稳定就调整流程，权限不够就重新接入。FDE 交付的是一条正在运行的业务流程，而不是一张架构图。

我更愿意将 FDE 的工作压缩为六个步骤：

它与传统的售前、实施和解决方案角色有重叠，但责任边界更靠后。售前证明产品值得购买，FDE 则面对客户买回后的一团糟：系统不兼容、数据不干净、权限被拒、安全部门不通过，以及用户拒绝改变习惯。

此外，FDE 中的“E”不是装饰。真正的 FDE 必须编写生产代码，阅读陌生的代码库，调用接口，部署系统，并快速排查问题。

售前、方案架构、实施交付与FDE的职责边界

为什么现在需要这类人

过去，许多 AI 讨论集中在模型能力上：谁的模型更聪明，谁有更长的上下文，谁更便宜。

在企业落地阶段，客户关心的问题变了：模型只是引擎。业务上下文、工具调用、数据权限和评估体系决定了这辆车能否上路。

这也是 FDE 价值上升的原因。客户不缺一个聊天页面，缺的是一个能融入工作流、处理异常、经得起审计且被持续使用的系统。

企业 AI 的另一个特点是很难完全标准化。

同样是合同审查，不同公司的格式、审批制度、权限和风险边界都不同。同样是客服 Agent，有的允许自动退款，有的必须人工确认。向客户销售通用产品仅完成了“可用”的一小部分，其余工作通常在现场完成。

因此，FDE 还必须充当翻译者。

他将业务人员所说的“流程太慢”转化为可执行的工程问题；将工程团队所说的“这个功能需要重做权限模型”转化为客户能理解的后果、成本和时间。

一套可靠的实施顺序

FDE 最害怕两件事：一开始就做大项目，以及为了显得智能而在任何地方都使用 Agent。

更稳妥的方法是先审计，再评估，最后部署。

Agent从低权限观察到高权限变更的渐进式部署流程

第一步：审计业务。

跟随一线员工走过流程，记录他们实际在做什么。不要只问“你希望 AI 帮你做什么”，还要看他们在哪里复制粘贴、反复查阅、等待审批和手动核对。

优先选择这些任务：频率高，耗时，人工成本高，结果可衡量，错误代价可控。一个月只运行几次的 Agent，即使演示漂亮，也不一定有经济价值。

第二步：判断使用什么工具。

规则清晰、输入固定的任务通常更便宜且稳定。不要为了用 AI 而用 AI。

输入杂乱但规则大致固定，且需要调用多个系统时，可以考虑使用 Agent。例如从邮件和附件中提取信息，查询库存，生成建议，并提交人工审批。

涉及高风险决策、复杂专业判断或强领域经验的环节应保留人工参与。AI 可以协助整理材料、提示风险、提供选项，但不一定能直接做决定。

第三步：从低权限开始。

不要让 Agent 立即更改订单、发送邮件或操作数据库。先让它做风险较低的工作：搜索信息、查找 Bug、分析日志、生成摘要。稳定后，逐步开放写入权限、提交审批或创建 PR。

这个顺序至关重要。Agent 的能力不是一次性交付的，而是在真实数据和反馈中逐步获得的。

第四步：建立评估。

仅检查最终答案是不够的。还要检查它是否遵循正确的流程，调用了正确的工具，没有遗漏关键事实，以及是否在遇到异常时停止并移交人工。

可以先记录一组人类专家的案例，分解他们的步骤，然后检查 Agent 是否覆盖了这些关键节点。偶尔答对是不够的；过程稳定且错误可追踪才有机会进入生产环境。

第五步：接入现有系统。

企业通常不希望为 AI 重写一切。更现实的做法是在现有数据库、文档库、ERP 或权限系统上添加接口，让 AI 调用它们。这不够花哨，但更容易上线。企业真正需要的往往不是新系统，而是让旧系统少做重复工作。

谁适合转型

FDE 不是某个专业的专属职位；它是多种能力的交汇点。

软件工程师最接近这条路径。你会写代码、调试和部署；下一步是学习业务访谈、流程拆解、ROI 和用户采用率。不要只等别人把需求写成 Jira 任务；参加会议并追问“谁会每天用这个”。

数据分析师了解指标和业务沟通。短板在于工程：如何将 Notebook 变成服务，如何处理 API、权限、部署、监控和恢复。将一次只能自己运行的分析变成同事每天使用的工具，就是很好的练习。

产品经理、顾问、行业运营和实施人员通常拥有稀缺的行业经验。做过制造业的知道排产；做过零售的知道库存；做过金融的知道合规。这些经验很难短期获得。你需要补充编程、数据库、API 和部署，然后亲手制作一个可运行的系统。

售前和解决方案架构师可能已经完成了一半。你了解客户、权限和旧系统；下一步是跨过“只做方案”的障碍，深入开发、测试、上线和维护。

完全零基础的人也有机会，但直接冲刺 FDE 会很吃力。更现实的切入点可能是数据分析、AI 运营、技术支持、实施顾问、初级开发或行业解决方案助理。FDE 很少是第一站；它通常是几段经验的汇聚点。

不要把六个月的时间花在收集课程上。

如果真的想走这条路，我建议把学习目标换成一份可运行的作品集。

半年FDE作品集成长路线

前两个月，建立工程基础：Python/TypeScript、SQL、数据库、HTTP、JSON、API、Git、测试、Docker 和基础部署。标准：独立构建一个带数据库和 API 的应用程序并部署以供他人使用。

第三、四个月：在此应用中添加模型能力。做一个客服助手、销售线索整理器、报销检查器或运营警报。重点不是让它看起来像产品发布会，而是添加日志、评估、重试、人工复核和权限控制。

第五、六个月：找到三到五个真实用户，让他们连续使用两周。记录原流程耗时多少，新流程节省了多少，采纳了哪些建议，哪些错误需要人工处理，以及用户为什么放弃。

真实用户会揭示隐藏问题：脏数据、权限不足、界面难用、流程变更、模型成本高。解决这些问题会让你的项目看起来像一个真正的 FDE 项目。

最后，将其写成案例，而不是技术术语列表：简历上少写“熟悉 X 框架”，多写“谁用、多久、指标如何变化”。

求职时，先弄清楚这份 FDE 是什么。

FDE 这个头衔尚未统一。你可能看到 Forward Deployed Engineer、Applied AI Engineer、AI Deployment Engineer、Solutions Engineer、AI Solutions Architect、Deployment Strategist 等名称。

不要只看职位名称；面试时直接问：

我通常将此类职位分为两类。

第一类：FDE 编写生产代码，对结果负责，现场经验反馈给产品团队，重复工作沉淀为平台能力。这类工作辛苦，但能积累真正的复合技能。

第二类：职位名称很新，工作方式很旧。整天围着验收、驻场和人天转，代码进不了主仓库，每个项目都定制。这更像是换了名字的实施职位。

两者都可能需要出差且忙碌。区别在于你的工作是否留下了可复用的资产。

最后，先做一个真实的小工具。

FDE 让我感兴趣的不是它听起来像是一个新职业，而是它把问题带回了现实：技术出来后，谁来用？怎么接？出错了怎么办？两周后，业务真的变快了吗？

AI 会继续变强，但企业不会因为模型排行榜更新而自动改变工作方式。真正的落地需要有人走进现场，查看数据、询问流程、编写代码、处理权限，并盯着用户使用工具。

所以，如果你想进入 AI，不妨先做一件不那么宏大但现实的事：找一个真实问题，做一个可上线的工具，让三个人连续使用两周。

在这两周里，你遇到的脏数据、坏接口、权限问题和抱怨比十门课程更能让你了解自己离 FDE 还有多远。

职位名称可以以后再定。先把东西做出来。