一家有几十家门店的连锁消费品牌，过去要安排一名财务，用整整一个月处理会员销卡、门店互转带来的数据核算。
FDE 重构后，这部分工作变成了前后端联动的自动产出，财务岗不再按月拉表、手动对账。
另一家货代公司，全球不同语言、不同格式的货单，过去靠三个人全天手工录入，现在只需要留一个人不定期处理异常。
这两个案例是铭文鼎成科技创始人陈一铭操盘的 FDE 真实项目。过去一年，FDE 从概念逐步进入企业视野，越来越多的公司尝试用这个角色，把 AI 接到真实业务里。
企业端的诉求也在相应变化：从2024、2025 年的 “帮我把内容生成得更快”，到 去年下半年 “接入我的 CRM、分析我的数据”，再到现在的 “直接影响业务结果”。
因此，见实发起了 FDE 系列主题直播。在第二场直播里（第一场：），陈一铭跟见实深入探讨了业务型 FDE 是如何落地的。本文即为直播对话整理。
01 连锁消费品牌从 “小程序不好用” 到财务月算这项工作几乎消失
见实：FDE 不是过去那种 “我提需求你干活” 的驻场开发，而要站在业务视角、对业务结果负责。能不能用一两个真实的项目，带我们完整走一遍 FDE 是怎么落地的？
陈一铭：我拿两个项目举例。第一个是一家有几十家店的连锁消费品牌，客户通过小程序预约到店、到店消费完会进 CRM，诉求是把业务小程序和后台数据打通。
第二个是一家货代公司，货发到全球各地，回传的货单语言、格式都不统一，过去由三个人从早到晚手工录入。
这两个项目颇具代表性：一个表面是系统问题，实则是组织问题；一个表面是录入问题，实则是数据与流程设计的问题。
见实：在这两个案例里，你们是怎么介入的？第一步做什么？
陈一铭：第一步基本不进场，先线上做咨询，以厘清需求核心。
比如第一个案例，传统数字化视角下，这个需求很简单：开发一套系统、打通前端、搭建可视化中台，仅此而已。但我们深入了解后发现，这并非一个预约的问题，而是组织的问题。
先交代背景：这家品牌每个门店相对零散，前后端打不通。业务小程序由独立公司开发，后端由另一家公司开发，且后端系统较为老旧、未开放接口。
其业务数据主要涉及预约、销卡、转卡，表面上无非是几个城市之间的门店流转，但在技术之外，门店与门店之间存在利益抵触。
不同门店的心态大概类似：你是加盟店，我也是加盟店。客户在你的门店办了卡，来我的店消费、核销，后端分成怎么算？
办卡时佣金归你的门店，在我这消费，成本和交付由我承担，佣金却是你拿的。一张卡20次，在他那消费15次、在我这5次，怎么分？是不是平均一下，你拿15次的提成，我拿5次的提成？
真正核算时会发现，这是一套非常复杂的体系。当时这个品牌，要专门安排一名财务，整整一个月处理这些数据。
见实：这种卡点是怎么发现并解决的？
陈一铭：识别需求是 FDE 非常核心的点，这也是 FDE 与传统驻场的区别所在。经验不足的驻场顾问往往会建议：你们业务小程序有接口，想把数据沉淀下来，用多维表格就能落地。
他投入一周、一个月后，前后端打通了、数据也到了后台，但后端所有数据的处理、更新、维护，甲方都无法离开他。每增加一个字段、每做一个算法，都需要他回来修改表格。
这并非 FDE，反而像是让客户更依赖你的数字化驻场人员，这是传统打法。FDE 的价值在于，交付完成后要能离开这个组织，新架构不受影响。
回到这个案例，核心问题不在于小程序的功能，而在于后台客户核销的数据汇算存在矛盾：小程序和 CRM 相互分离，小程序只负责产出表单，财务需要花费一个月时间拉出表单逐日核算，两者是割裂的。
再进一步推理：即便小程序本身存在不足，如果数据能够与后端打通、CRM 能打通，自动工作流、核算算法全部一致，实际也没有太大障碍，无非是速度慢一些、耗费的精力多一些，远未达到需要专门安排一名财务、用整整一个月处理这些数据的程度。
所以我们判断，问题大概率不在系统，系统有影响但不是绝对影响，关键在于数据进入系统之后，门店与门店之间的核算规则不清晰，门店之间对总部规则的理解也不透彻。
而在某种程度上，规则的打通又依赖一套落后的系统支撑：门店提交到总部，总部核算完再反馈，存在非常大的延后性。店长的感受是：客户在你的门店办了卡、把钱拿走，人到我这了，我还要核算、上报总部，总部核算完再返还，很繁琐。
这一延后性，系统有一定原因，但主要原因在于组织之间规则的不透明。所以站在 FDE 的视角，要改的是组织层面这种规则的执行逻辑，这属于偏管理的范畴，与技术基本无关。
见实：那方案怎么设计的？财务一个月的工作最后为什么消失了？
陈一铭：从0到1重构整个架构：
业务小程序和 CRM 不再是两个彼此割裂的模块，小程序本身就基于 CRM 财务核算的逻辑生成，前端加上原有的预约、转卡程序，数据库直接与 CRM 绑定。
前端每完成一个动作，后端数据自动关联、直接可视化，而非系统交付后，财务仍要照旧花费一个月核算。
见实：系统重构了，门店愿意用吗？怎么推下去？
陈一铭：关键仍在于总部推动，决策者要有非常强的领导力。
首先要下发通告，明确这件事必须遵守；然后要把利益落到实处，不能只讲问题、一味画饼。把算法讲清楚，把核算过程透明化，变成一个中台，每个人都能看到：多少人来到本店、如何核算，本店多少人去了其他门店、其他门店如何核算；
再进一步可视化：每个人手机上有看板，店长、助理实时看到数据变化，心中有数，而不是总部一直强力推动，却不告知调整后各店能增收多少、分得多少。
作为组织而言，员工和业务负责人的逻辑很简单：这件事落地后能带来多大的利益，没必要讲提效、讲 AI，他们对这些概念并不在意。
原本一天的工作，现在两小时解决；原本一个月营收 40 多万，现在增至 60 多万，提升 50%。加盟商也只认一个理：提升 50%，除非店里的营收真从 40 万变成 60 万，否则不会相信；而不是来一个人说能提升 50% 就信。
02 货代公司从三个人天天手敲，到一个人偶尔盯
见实：第二个案例，货代公司的货单具体难在哪？
陈一铭：货代公司把货物发往全球各国，货物发出后，对方需回传一份货单。货单存在两个问题：一是语言多样，英语占大多数，但偶尔有其他语言；二是模板格式基本不统一，几百种、几千种都有可能。
而他们的 ERP，需要将单据录入到一个标准格式，形成逐行的列表数据。公司还有很多个网点，类似快递，这个城市一个点、那个城市一个点。
痛点在于：不同语言、不同格式的表单，需要安排专门的部门录入，工作量非常大。当时三名员工每天从上班到下班都在处理这项工作，偶尔还要加班。
见实：他们最开始提出的需求是什么？跟后来发现的真需求一样吗？
陈一铭：从表面需求看，统一表单格式、直接进入 ERP、无需人工参与，是非常直接的解决逻辑。
但具体实施中出现了问题：这些货单包含大量邮政编码，全球邮编非常多，将全球每个国家、每个街道的邮编全部收录，基本需要几百兆。
当一张单据进来，AI 识别出内容后，为了保证精准度，后端需要在邮编库中进行筛选、匹配，在几百兆的库中检索非常耗时。
见实：怎么解决的？
陈一铭：我们发现，日常实际用到的邮编就集中在少数一些。假设全球有 10 万个，日常可能只用 1000 个，而且这 1000 个并非固定，偶尔会有附带、增项的情况。
所以我们的做法是：后端这个库并不是把全球几百兆的所有邮编放在一个库里匹配，而是让每个网点根据自身每天产生的邮编单独形成一个库。业务上，一个网点出现频率越高的邮编，说明使用越多。
把几十个网点汇总在一起，可能只形成一兆左右、包含大量常用邮编的库，而且这个库并非固定，会随新邮编的出现动态扩充。
原来要在几百兆中做遍历、花费很大的时间成本，现在它是一个动态的库，只需付出在几百兆中检索的几百分之一的成本，便能获得与原来质量相当的结果。
同时还要解决一个问题：这些数据实际上属于商业机密，存在极高的泄露风险。
如果邮编库统一，所有网点每个人都有权限拿到这些数据，导出给同行，就可能造成不良影响。所以还要设定每个网点的设备号加网点密码，进行双向匹配。
见实：流程和结果发生了什么变化？原来三个人每天的时间投入具体是怎样的？
陈一铭：过去的流程，收到各类单据后由人工录入 ERP；现在的流程，收到各类单据后，根据每个网点生成的动态邮编池自动匹配。
过去每天几千张单据，需要数人录入；现在基本只需一人处理异常，无法识别时系统会报错，报错后处理一下即可，还可以兼顾其他工作。
人工录入的概率非常小，除非单据特别模糊不清。从原来三个人全天盯守、逐单手录，变成现在一个人偶尔关注。
03 项目成功80%靠组织老大、一线与运营人的路
见实：两个案例看下来，真正落地时最难的是什么？
陈一铭：一个清晰的感知是：
FDE 确实需要技术，但真正落地的过程中，最大的卡点往往不是技术，一个来自决策者，一个来自一线。
签约的企业负责人特别容易凭感觉拍板，合作过程中想法频繁变动。如果 FDE 对整个规划没有定力，很容易沦为甲方说一句、他做一步的执行者，交付边界变得非常模糊：既不知道何时能够完成、身心俱疲，也不知道价值体现在哪里。
所以第一点，要明确交付边界。项目推动前要有非常清晰的规划，FDE 要保持定力、掌握主导，而非一味迎合甲方（需求合理时也要灵活推动）。
当然，主导权不是强调出来的，是设计出来的：可以有人做执行，但一定要有一个人承担咨询的角色；它也来自专业度，当甲方真正认可你，他会全权交付，问题怎么定义、怎么干、怎么决断，都交给你。
见实：一线员工的阻力怎么解决？
陈一铭：一线员工的顾虑来自 “降本增效” 这个概念，担心新工具会代替自己；另一重顾虑是操作繁琐，打开交付的界面，满是各种面板和按钮。他要的很直接：告诉我在哪里点、能看到什么、每天怎么开关。
所以有两个建议：一是利益可视化，让他明白这些动作是把蛋糕做大，而非取代他、分走他的利益；二是做得足够简单，把复杂放在后端，用自动化、公式、算法、工作流解决，前台一线屏幕上每天就是两三个按钮。
你能帮决策者打通认知、让一线认同并愿意执行，项目成功就已经完成了 80%，剩下的无非是技术问题，而 AI 时代技术基本已经平权。
见实：回到主题，为什么说运营人是适合做业务型 FDE 的？最快的路径是什么？
陈一铭：FDE 最核心的能力不在于编写代码，而在于三点：
明白技术边界或工具边界，知道哪个工具能做到哪一步；对问题的定义和判断力，能主动告诉客户应该怎么办；对组织管理的认知，能推动管理决策落地。
而运营恰好具备这些能力的前提，有几个非常明显的特质：
对用户画像、用户意图的分析能力强；对流程总结能力强，SOP 能精确到分钟；擅长梳理知识内容，做知识库、素材库；对数据敏感度高；目标感强；协同能力强。这 6 个模块，构成了运营成为业务型 FDE 非常好的前提。
最快的路径有两个：
第一，建立对问题的定义能力。接到 “帮我写 20 篇稿” 这种需求，运营要训练的是再深入一层，看它到底解决的是什么问题；
第二，掌握工具边界，最快的办法就是写测评。把千问办公、豆包工作、Workbody 放在一起对比，输出一份测评，扎扎实实地去用、去测，能力便会内化为本能。
见实：刚才聊到的第一个案例里，财务最后是失业了吗？另外，一线抵触也有可能是担心活变多吗？这种情况该怎么应对？
陈一铭：财务不会被裁掉。财务掌握着大量隐性知识，不是 AI 能替代的，AI 能替代的只是把繁杂的工作量抽离出来，他不需要每日处理 Excel 合并、公式、透视，而是有了更多自主权去做更重要的工作。
至于一线活变多，如果长期更忙，本质上它是一个失败的 FDE 项目，技术的核心是提效、是提升单位人效，而不是靠更多人的更多工作量去支撑一个更繁杂的项目。
当然前期有必然的摸索：此前我们服务过销售客服项目，需要收集资深销售脑子里的经验，对方每天急着打电话赚钱，频繁被拉去访谈，前期难免不耐烦，但真正有价值的东西确实只存在于一线员工的脑子里，要把它沉淀出来、赋能到新的架构里，这件事需要找到平衡、与甲方共创。
见实：最后，你怎么看 FDE 本身？它本质是不是 To B的？
陈一铭：大家往往认为 FDE 无非是懂点技术、会用 Codex、会编程、能做出产品 demo，就是 FDE 了，这低估了它。
FDE 是基于 AI、Agent 和工作流产生的新岗位，与过去的驻场开发最大的区别，是必须站在业务视角、对业务结果负责。
它之所以备受关注，是因为企业需求在变：2024、2025 年要 AI 更高效地做内容、生成图片和视频；2025 年下半年要接入 CRM、拿数据分析、做 AI 问数；再往后，企业要求直接影响业务结果。
从大模型到工作流，从工作流到 Agent，Agent 又涌现出 MCP、Skill，再到 AI 编程、飞书开放 CLI 让 Agent 接入办公体系。但这些都只是应用，是 FDE 能力的一部分，不是 FDE 本身。
举个例子：组织只说 “帮我们写 20 篇文章”，用豆包毫无压力；如果说 “要在质量可控、品牌可控的情况下提高内容岗效率”，路径便会完全不同：把基线、经验抽离成 Skill、约束边界和工作流，岗位从打磨文字变成定义和审核。
FDE 要解决的 80%，是组织管理和对业务认知的问题，这类能力无法靠上课习得。技术是可以教的，它是标准、可以复制；但最难的是对人的感知、对组织框架的认知、对业务的理解。
FDE 难吗？也不难，对业务有了解、对管理有了解就可以做，技术正在逐步平权。
但前期不能只看技术。只懂技术、不懂组织管理，即便做出产品也很难推进，难以推进就代表无法交付。至于 FDE 本质是不是 to B？起码在签约之前是这样的。
PS：
10月来了：杭州《Codex超级实战课》、广州“高客单行业获客+激活”异业合作私享会、长沙私域私享会、北京某知名快消品牌闭门会、杭州，欢迎加入会员一起参加，可点击文末阅读原文查看活动详情。
热门跟贴