FDE岗位暴增800%，年薪200万起步，但真正落地时第一步该做什么？本文从9年企业数字化经验出发，拆解AI Coding落地的四个阶段，揭示数据基建是隐形天花板，并给出从“工具选型”到“协作制度”的完整操作手册。
最近 FDE（Forward-Deployed Engineer，前向部署工程师）这个岗位火得一塌糊涂，岗位暴增800%+，年薪200万起步。OpenAI专门成立了40亿美元的公司派驻场团队，Anthropic把应用团队翻了五倍，国内字节、蚂蚁、智谱都在抢人。
说白了，这就是一个帮企业把AI真正用起来的岗位，所有人都在聊”这个岗位多重要”，但没人告诉你：当你真的走进一家企业，面对”我们 ERP 是 SaaS 的、数据在三个系统里、自研团队就两个人”这种现实时，你第一步该干什么。
这篇文章就是答案。
它是我从个人 AI Coding 一路踩坑到帮企业设计落地路径的完整复盘，它也是我自己如果去做 FDE，会拿在手里的操作手册。
前言：这一篇是不是纸上谈兵？写这篇的底气来自两件事：一是做了9年企业数字化产品，见过各种阶段的企业内部长什么样；二是自己用AI Coding走完了从简单首页到统一后台的全链路：从最简单的AI 生成首页开始。到用 AI 做跨境独立站：视觉算法、深度学习、统一支付、算力调度，每一样都是AI写的代码跑在生产环境里。个人踩过的坑，就是企业的避雷针。
从”用 AI 写一个页面”到”用 AI 搭一个完整的研发体系”。这条路径，恰好覆盖了企业从”试试水”到”重构研发”的完整光谱。
这篇文章不是方法论的推导，而是我走过每一步之后认知复盘和避坑指南。
一、企业 AI Coding 落地的四个阶段我画这张图的时候只问了自己两个问题：第一，这家公司自己写了多少代码？第二，它的数据能给 AI 看到多少？两个问题一交叉，四个阶段就出来了：
自研占比：企业自己写的代码 vs 第三方采购的比例数据准备度：数据在哪、能不能给 AI 看到、访问权限和合规边界如何两个变量交叉，得出四个阶段。
阶段1：第三方采购为主画像：ERP/WMS/CRM 全是第三方 SaaS，自研团队可能就 1-2 个人，主要负责运维和小修小补。数据在 SaaS 厂商手里，API 有限，权限锁死。
AI Coding 能做什么：几乎不能直接参与核心系统开发。能做的只有”外部工具”——用 AI 生成数据处理脚本、生成周报模板、生成营销素材。
这个阶段的核心不是 AI Coding，是 AI 提效。别再想什么”让 AI 写代码”，先让业务部门用上 AI 工具：AI 写会议纪要、AI 做数据分析、AI 生成营销文案。把”什么都指望数字化团队”的心态打破。
嘻嘻的实际做法是：做统一的 AI 培训。不分部门、不分职级，从”怎么提问”到”怎么判断 AI 输出靠不靠谱”，一套方法论打透。培训不是讲完就散：每周围绕一个真实业务场景做实战：这周用 AI 写需求文档，下周用 AI 做竞品分析，再下周用 AI 处理报表。目标很清晰：让业务侧有能力解决”本来应该找数字化团队但数字化团队没空做”的问题。这一步走通，后续阶段才有群众基础。
阶段2：开始自研，自研团队没几个人画像：核心系统还是三方的，但开始有一些自研小项目：如内部管理工具、数据看板、微信小程序。自研团队 3-5 人，技术栈简单。数据开始有一部分在自己的数据库里，但权限管理零散，部分数据仍然隔离在第三方系统里。
AI Coding 的切入点：分开打。
三方系统部分：和阶段1一样，在 SaaS/PaaS 上叠加 AI 工作流（比如用 Make/n8n/Zapier 搭自动化）自研部分：AI coding 可以做独立的小模块（一个表单页面、一个数据导出功能、一个简单的API）但不能做整块系统。关键是”拆任务给AI”而不是”把项目给AI”；业务侧：重点投入 AI 工具培训。教业务同事用 AI 写需求文档、用 AI 做竞品分析、用 AI 处理 Excel。目标是让业务侧有能力解决”本来应该找数字化团队但数字化团队没空做”的问题；这个阶段最有价值的一句话：教业务用 AI，不要什么都指望数字化。
阶段3：大部分自研，核心三方系统维持画像：自研占比 60%+，有统一的技术栈和代码规范。ERP/WMS 等少数核心系统还是三方的。有自己的数据库/数仓/BI，但部分系统之间数据还没有完全打通。自研团队 15-30 人，有 CI/CD 流程。
AI Coding 的切入点：替换初级开发的工作任务，而不是整块工作。
这个区别非常关键。不是”把整个需求给 AI”——那是视频里演示的，不是企业里能干的。而是：
一个中级开发拆完需求 → 把其中”简单但耗时”的部分标记出来 → AI 写初版 → 人 review → 人接手复杂逻辑和集成
信任的建立是一个渐进过程：先让 AI 写单元测试，通过了 → 再让 AI 写工具函数，通过了 → 再让 AI 写简单的 CRUD 接口，通过了 → 才能让 AI 写业务逻辑。
没有跳跃式信任。每个阶段都必须通过质检才能进入下一级。
阶段4：全自研画像：自研占比 80%+，有自己的技术平台、中间件、组件库。数据+代码+工具链基本打通。团队规模 50+，分层明确。
AI Coding 的切入点：从”人+AI 协作”进化为”AI 参与任务分发”。这个阶段的方案不是一步到位，而是三级：
聊完四个阶段，有一个前提必须单拎出来讲。
AI Coding 的上限，不取决于你用的模型有多强，取决于你能给 AI 看到多少数据。
这件事经常被忽略。市面聊 AI Coding 都在说”选 Cursor 还是 Copilot””prompt 怎么写更好”，但到了企业场景，第一个卡住你的不是工具，是数据。
三层数据分级从产品视角看，企业数据分三层：
三层分好了，才能回答”这个任务能不能让 AI 做”，它不是看任务本身的复杂度，而是看任务涉及的数据在哪一层。
不是技术问题，是组织问题数据基建在落地时最大的阻碍不是”技术做不到”，是”没人愿意牵头”。IT 部门说要管数据，业务部门说数据是我的凭什么你管；安全部门说要加密，开发部门说加了密效率掉一半。
嘻嘻的实际经验：做跨境独立站的时候，数据分三块a.公开的商品信息随便喂给 AI，b.内部的订单数据脱敏后用，c.客户的支付信息碰都不让碰。三层分清楚之前，AI Coding 根本没法正经用，因为你不知道哪些代码能发给外部模型、哪些必须本地跑。后来这条分层的习惯直接平移到了企业场景，只是换了数据种类：代码仓库代替了商品信息，测试用例代替了订单数据，密钥证书和客户隐私就是永远的红线。
说人话就是：别一上来就搞大一统数据中台，从”AI 需要的最小数据集”开始。
先打通 AI Coding 直接依赖的那部分数据：代码仓库、接口文档、测试用例。把这三样管好，就已经解决了 80% 的 AI Coding 需求。剩下的 20% 在推进中逐步完善。
一句话：数据基建不是给 AI 建粮仓，是给 AI 划定活动范围定规矩。知道哪些能吃、哪些不能吃，比囤多少粮更重要。
三、在聊”怎么做”之前需要关注，划重点Cursor/Copilot （或其他工具，以下用cursor 代称）是执行层的工具，不是企业 AI 化的答案。
市面有一个常见的认知错位：企业上了 Cursor = 企业已经 AI Coding 化了。完全不对。
把”用 Cursor”和”完成 AI 转型”混淆，就像把”办了健身卡”当成”健完了身了”。
Cursor 只是换了开发者的工具链。企业 AI Coding 真正要解决的是：谁来拆任务、谁来决定 AI 做哪个、做完了怎么验收、代码规范怎么保持一致、CI/CD 流程怎么适配。
执行层工具可以按功能分层：
这些工具全是执行层的。但没有一个能替代路由层的决策，这就是你把 AI Coding 带进企业时的核心价值。你不是在帮企业”装个 Copilot”，你是在帮企业”建立一套人和 AI 的协作制度”。
四、阶段2深度展开目标提效，不是替代。比如让 3-5 人的小团队跑出 6-8 人的产出。
怎么做项目拆解粒度要细： 不要把”做一个管理后台”给 AI，要拆成”用户列表页””权限配置弹窗””数据导出按钮”这种粒度自研小模块优先：内部工具、运营后台、数据看板这类不怕出错的先上三方系统做 AI 工作流外挂： 不碰 SaaS 系统内核，在外部用 AI 做自动化衔接（比如 A 系统导出 Excel → AI 清洗 → 导入 B 系统）业务侧 AI 培训实质性推进： 不是讲一节课就完。每周XX个场景实战：这周用 AI 写产品需求文档，下周用 AI 做分析看板怎么质检验收代码原则：AI 写的代码必须过 Code Review，和人工代码同一标准功能测试：以人写的测试用例为准，不信任 AI 自己写的测试性能底线：API 响应时间、页面加载速度，不允许 AI 写出”能跑但慢三倍”的代码可能的坑“分而治之”：三方系统外挂 AI 工作流，自研模块用 AI 加速，业务侧用 AI 自助。三方各跑各的，互不干扰。
五、阶段3深度展开目标替换低价值开发工作，释放中级以上开发的时间。提效的衡量标准从”写得更快”变成”人的时间花在更有价值的地方”。
怎么做建立任务分类制度：每个 Sprint 的需求过一遍：哪些是纯 CRUD？哪些是复杂业务逻辑？哪些涉及交易/安全？只有第一类可以标记为”AI 优先”渐进式信任建设：单测 → 工具函数 → CRUD 接口 → 简单业务逻辑。每个层级至少跑满一个 Sprint，质检通过率稳定在 90%+ 才能进下一级代码规范前置化： 不是写出代码再检查，而是在 prompt 里就把代码规范（ESLint 配置、命名规则、目录结构）写进去。把规范变成 AI 的默认行为建立 AI 代码回滚机制：AI 写的代码必须有独立的代码审查记录，出问题能快速定位到是哪次 AI 提交、哪个 prompt、哪个模型版本怎么质检验收质检 Pass 率：AI 代码一次 CR 通过的比例，目标从 50% 起步，稳定提升到 80%+回归测试：AI 改动过的模块必须跑全量回归灰度上线：AI 写的功能先上灰度环境 24 小时，监控错误率，没问题再全量AI 代码标注：所有 AI 生成的代码必须在 Git 提交信息里标注 [AI-Generated]，方便事后回溯可能的坑“分级信任”：不跳级、不急于证明 AI 厉害，按”单测→函数→接口→逻辑”的四级阶梯渐进。每一级都有明确的质检门槛，通过了才开下一级。
六、阶段4深度展开目标从”人+AI 协作写代码”进化为”人设计制度和规则，AI 参与执行和分发”。
怎么做按三级模型推进：
初阶：人肉路由 + AI 执行
Tech Lead 在每个 Sprint Planning 中将任务分为三类：纯人工 / 人+AI 协作 / AI 优先
分类标准：涉及交易/不可逆流程/重大用户体验/涉密 = 纯人工；CRUD/数据展示/工具脚本 = AI 优先；介于中间的 = 人+AI 协作
AI 执行层工具矩阵：编码（Cursor/Copilot）、审查（CodeRabbit）、测试（自动生成）、文档（Mintlify）
关键：路由层的判断：”这个任务适合 AI 吗”。是最值钱的能力，不是每个人都会。
这里引入一个嘻嘻的思考：当团队里每个人都用 AI 写代码，“管理”的定义变了。
以前的管理是管人：分任务、追进度、做 review、打绩效。
现在的管理多了一层：管 AI。prompt 怎么写更省 token、同一个任务哪个模型性价比最高、AI 输出的代码规范怎么保持一致，要不要淘汰 AI…这些不是”技术选型”，是日常管理动作。大厂研发人员的现状其实就是”人人都是 AI 的管理者”，你甚至需要思考怎么节约 token。
中阶：成熟工具二次开发
基于团队已有的项目管理工具（Jira / 飞书项目 / Linear / 禅道）做 AI 增强
可落地的方向：
Jira：自动化 issue 分类 + AI 难易度评估 + 自动分配飞书多维表格：AI 字段自动生成需求摘要、自动识别需求冲突Linear：利用其 AI issue triage，自动打标签和优先级禅道：二次开发加入 AI 模块，自动生成测试用例不做从零开发，只做”在成熟工具上加一层 AI”。降低实施风险和开发成本
高阶：自研任务分发平台
这是终局方向，但目前行业还在早期阶段（上次demo day听到有同学的公司已经内部用起来了，不过大部分的大家都还在探索）。
正在发生的趋势：
飞书：多维表格 AI 字段 + 飞书项目 AI 助手otion AI：文档到任务的自动转化GitHub Copilot Workspace：从 issue 到 PR 的全链路 AI 介入钉钉宜搭 AI：低代码平台的 AI 能力增强ONES AI / PingCode AI：国内研发管理工具的 AI 化企业自研平台的思路：不是重新造一个 Jira，而是在”任务分发→代码生成→自动测试→AI Review→自动部署”这条链路上，把每个节点的 AI 能力串起来
怎么质检验收任务分类准度：人肉路由阶段，AI 优先任务的”事后证明确实适合 AI 做”的准确率AI 代码占比：全团队代码中 AI 生成的比例，但不是说越高越好：要配合”AI 代码返工率”一起看开发周期压缩：同类型需求，AI 参与前后的端到端交付时间对比可能的坑“三级不跳级”：人肉路由是必经过渡期，先跑通”人和AI怎么分任务”，再考虑工具化。工具化跑通半年、ROI 验证为正，才考虑自研。
每一级都是下一级的必要条件。
七、AI Coding 的边界：什么绝对不适合以下场景，AI只能出方案、不能碰代码。硬要碰也可以，但你得准备好加班修bug：
一句话：数据是最内核的，营销是最外层的。
AI Coding 从外层往内核打，但尽量晚点碰内核。
八、总结：企业 AI Coding 不是选工具，是选路径回到最开始的判断：市面所有人都在聊 AI Coding 用什么工具，但没人告诉你”你的企业在哪个阶段、适合做什么、不适合做什么、先做什么后做什么”。
这就是这篇文章想解决的问题。
从简单首页到统一后台，这条路我完整走了一遍。四阶段框架不是推导出来的，是踩完坑回头看画出来的最实用的捷径。
AI Coding 企业落地这件事，市面上不缺工具推荐，不缺 prompt 模板，缺的是”你的企业在哪个位置、下一步怎么走”的判断框架。
这篇文章要解决的问题不是告诉你用什么工具，而是让你能自己判断：现在在哪、要往哪走、路上有什么坑、怎么样做成这件事。
工具会变，模型会迭代，但判断力：那些由经验、经历和人的视角构成的判断力，是不会过时的。
最不会被 AI 替代的，是那个能做 AI 老大的脑子。
本文由 @嘻嘻李 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
美港通证券提示：文章来自网络，不代表本站观点。
