企业AI为什么总卡在最后一公里
FDE模式给出了一套从现场部署到长期运维的落地解法
模型能力只是起点，业务结果才是交付
FDE
企业AI
这篇文章整理自8月6日的学习分享会交流，内容覆盖企业AI落地、泰国酒店案例，以及咨询、法律、财务和内容创业者的现场讨论。
很多企业已经把AI请进了公司，能不能留下来，又是另一回事。
账号买了，知识库搭了，演示时也能让人眼前一亮。等系统真的交给员工，麻烦接连冒出来。AI不懂公司的规矩，资料散在文档、聊天记录和员工脑子里，同一个问题换种问法，答案可能就变了。上线后再碰到接口变化、知识过期，谁来修也说不清。最初围着看演示的人不少，几个月后还在用的人却没几个。
8月6日的学习分享会交流中，赛凌科技分享了他们用FDE模式帮助企业部署AI的实践。整场交流接近三个小时，内容涉及酒店、国际教育、医疗康复、跨境电商、金融、法律和财务等多个行业。
听完整场分享，FDE这个有点陌生的缩写才慢慢落到具体工作上。它不只是坐在电脑前写代码。工程师要走进企业，听老板说需求，看员工怎样干活，再把一团说不清的业务问题拆成AI可以完成、企业可以验收的任务。系统上线了，他还不能走，后面的结果和运行也要有人接住。
01
PART
企业AI落地，先要过三道关
BARRIERS
赛凌科技把企业使用AI时遇到的问题归纳成三类。
第一道关卡在模型和业务之间。模型什么都能聊，老板的需求却常常只有一句话。客服能不能自动回复，销售能不能整理客户，我能不能直接问公司这个月赚了多少钱。每句话听着都能做，往下追问，流程怎么走、谁有权限看、做到什么程度算合格，答案往往还没想清楚。FDE先做的，就是把这些业务语言翻译成可以开发和验收的任务。
第二道关卡藏在企业自己的知识里。制度放在文档中，客户信息留在聊天记录里，工作经验则跟着老员工走。AI找不到可靠依据，只能凭模型原有的知识回答，答错也就不奇怪。企业要先把这些材料收拢起来，让答案有出处，内容过期后也有人更新。
第三道关卡在上线以后。很多中小企业没有自己的技术团队，模型变了、接口断了、业务规则改了，系统就可能停在那里。交付团队只管装好，不管以后，AI工具很快会成为又一套没人打开的软件。
这三个问题也对应着FDE模式的三层方案。
第一层按岗位安排AI Agent。客服、销售、运营、工单和老板助理各干各的活，不再让一个万能机器人承包整家公司。
第二层是派FDE到企业现场。工程师和各部门负责人一对一沟通，把需求拆成可以验证的功能，再根据实际使用情况不断调整。
第三层是持续运维。赛凌科技把它称为AI运维舰队，由AI全天监控已经部署的Agent，发现问题后尝试修复，并记录问题发生的原因和处理方法。团队每个月向客户提供运维报告，让企业知道系统解决过哪些故障。
岗位上有人干活，现场有人改系统，出了问题还有人维护，三层接起来，企业买到的才是一套能持续使用的AI服务。
02
PART
FDE怎样把模糊需求变成可用系统
DELIVERY
传统软件项目常常从一份很厚的需求文档开始。开发几个月，测试再跑几个月，等产品交到客户手里，业务已经换了想法，员工看着陌生的界面也不愿意动。
FDE把这个周期压到了天。
按照现场介绍的交付方式，团队先进入企业，逐个找部门负责人聊，看看大家每天把时间花在哪里，哪个小问题最适合先交给AI。找到切口后，一到三天做出演示版本，马上交给员工试。上午发现不顺手，下午就改，必要时一天更新好几个版本。
团队希望在两周内让功能真正上岗。这个节奏很适合企业里的需求。很多老板面对空白文档时说不清自己想要什么，看到第一版以后，意见一下就具体了。这里不对，那里少一步，这个结果正是我要的。需求就在一轮轮试用中被说清楚。
客服知识库就是一个很直观的例子。传统FAQ机器人认的是预先写好的问题，用户稍微换个说法，它可能就愣住。项目团队会先拿一百到两百道题测试，看看系统究竟会多少，再去补知识库、调整调用方式。按照现场给出的数据，早期只能覆盖约四成问题，调整后可以达到九成以上。这个提升来自企业知识的整理，以及AI能否准确调用这些知识。
FDE因此需要同时做几类工作。他要像咨询顾问一样理解企业，像产品经理一样拆需求，像工程师一样完成部署，最后还要接住运维。现场分享提到，目前项目中超过九成的代码已经由AI完成，FDE的主要精力逐渐转向需求设计、功能校验和系统架构。
03
PART
一家泰国酒店的AI落地过程
CASE STUDY
一家泰国国际度假酒店，把这些问题几乎凑齐了。
酒店有四百多间客房，员工接近五百人。客人来自多个国家，旺季仅处理多语言咨询，就需要五到八名员工轮班。客人说房间需要维修，前台要把消息转给相关部门，中间多传一次，处理就慢一拍。酒店还经营着八个OTA平台，评论一条条进来，总经理得花大量时间回复。
系统其实买过不少，问题也没有跟着消失。员工不会操作，功能藏在层层菜单里，最后还是靠人传话、靠人盯评论。
项目团队进场后，没有急着做界面。他们先去整理酒店散落各处的知识。
他们先搭建可以审计的企业知识库。AI回答客人时要找得到依据，酒店也要查得出这句话来自哪份规定。
知识整理好以后，再给员工开发AI工作台。客人提出需求，系统直接生成工单，送到对应部门。谁接了、处理到哪一步，管理者都能看见，后续也能用于员工考核。原来要在几个部门之间传递的一句话，开始沿着一张工单往前走。
客户端则接住多语言咨询和OTA评论。AI回答常见问题，处理八个平台上的评论，再把客人反复提到的意见汇总给管理层。前台少守几个对话框，总经理也不用每天在八个平台之间来回切换。
按照现场分享的项目数据，酒店在多个平台上的平均评分从8.5提高到了9.6。整套系统计划于2026年8月15日正式上线，因此它能否在长期运行中保持效果，还需要上线后继续观察。
这个案例也让一种新的产品形态变得清楚。管理者不必记报表藏在哪个菜单，也不用先导出数据再交给人整理。他只要说出自己想看什么，AI就去调用系统里的功能。过去换一套系统，员工要跟着学一套操作。对话式系统把很多操作藏到后面，人只管把需求讲明白。
04
PART
企业知识库为什么是第一步
KNOWLEDGE
现场反复绕回同一个问题。AI进了企业，究竟拿什么回答员工和客户？
赛凌科技使用一种轻量、可持续更新的知识组织方式，把企业制度、岗位资料和业务经验整理成AI可以读取的内容。不同Agent拥有各自的记忆，同时共享企业知识。客服Agent可以调用产品资料，工单Agent可以识别负责部门，管理者的AI助手则可以汇总经营信息。
知识库还得回答另一件事，AI为什么这样说。企业客服、法务和医疗康复都经不起随口编一个答案。企业能够检查来源，才能发现哪条规定过期了，哪份资料需要更新。
企业不能把所有数据直接交给外部模型。现场讨论中给出了一种常见的折中方案。企业数据保存在本地，需要推理时调用第三方大模型。敏感部门可以单独部署服务器，并和其他部门进行物理隔离。
完全本地部署大模型需要采购大量硬件。按照现场说法，大型企业的投入可能达到数千万元，多数中小企业很难承受。具体采用哪种方式，需要结合数据敏感程度、预算和行业要求决定。
05
PART
定制项目怎样逐步变成可复制的服务
SERVICE
FDE要驻场，要逐个部门聊，还要跟着员工反复改，天然是一门重生意。每个客户都从头做一遍，团队很快就会被项目拖住。
现场给出的思路是暂时不做覆盖所有行业的标准化SaaS，把已经完成的功能拆成模块。同一个行业的客户可以复用知识库、客服、工单和经营分析等模块，再按照企业自己的流程重新组合。
这种模式保留了定制能力，也让前一个项目中做过的功能可以进入下一个项目。团队当前更看重解决企业眼前的问题，没有急着搭建复杂的云端多租户系统。
项目越做越深，收费也要跟着变。
早期可以按照Agent数量和定制开发内容收费。项目边界比较清楚，客户知道每个功能需要多少钱。随着合作深入，企业提出的需求越来越多，每增加一个功能都要重新报价，沟通成本也会增加。
赛凌科技正在尝试年度AI陪跑。现场提到的第一年试行价格为八十万元，价格仍在调整。另一种讨论较多的方式，是收取基础服务费，再从新增收入或节约成本中按比例分成。
现场有人把这件事讲得很直白。帮企业多赚两千万元，按比例分两百万元，企业容易接受。帮企业省钱就尴尬一些，成本越压越低，客户下一步很可能想把服务商的费用也省掉。
这也意味着，FDE最终要对业务结果负责。客户不会长期为模型多聪明付费，他会看客服处理了多少咨询，工单流转快了多少，员工减少了哪些重复工作，经营结果有没有发生变化。
06
PART
AI交付完成后，还要保证它一直在线
OPERATIONS
AI系统最让人头疼的部分，往往从上线那天才开始。模型会更新，接口会变化，企业知识也会过期，第一次交付不可能把以后遇到的问题全算进去。
赛凌科技让AI也参与运维。系统全天盯着已经部署的Agent，发现异常先尝试处理。每解决一个新问题，团队就把原因和修复方法记下来。下次再遇到同类故障，系统不用从头摸索。
现场给出的目标在线率是99.8%。这一数字来自分享者的项目口径，后续仍要结合不同系统的运行周期理解。它至少说明了一件事，企业AI项目的交付标准不能停在“可以打开”。系统能否持续运行，出现错误后多久恢复，知识由谁更新，这些工作同样属于交付。
FDE模式把企业AI从一次开发变成了一项长期服务。前线工程师进入企业，把需求理清并完成部署，运维系统接住后续问题，有能力的客户团队再逐步接管自己的系统。缺少开发团队的中小企业，则可以继续通过年度合作获得更新和维护。
07
PART
后半场交流中，七个方向正在尝试把AI做进业务
ROUNDTABLE
图片
主题分享结束后，现场的话题一下散开了。做咨询的、做法律的、做财务的、做内容的、做数据开发的，依次讲起自己手里的项目。方向看着很远，大家追问的却是同一件事。AI到了我的行业，究竟能先接走哪一份工作？
一位ESG咨询从业者先谈到报告生成。国内上市公司需要披露ESG报告，这项工作过去要投入大量人工。现在把企业资料交给大模型，一份报告很快就能出来，麻烦也恰恰在这里。国内企业有自己的表达习惯和尺度，模型写得通顺，未必写得像这家企业，更未必符合相关机构的要求。政策语境、企业类型和评价指标，缺一块都不行。
做AI IP孵化的团队，烦恼的是同一个角色总在变脸。AI生成一张图很快，换个场景，角色的外形、性格甚至故事线都可能跑偏。团队给每个IP建立完整档案，把外观、性格和故事设定固定下来。目前视频小样已经做出，他们想先做带故事的治愈系IP，再往潮玩盲盒和交互式陪伴玩偶延伸。
做健身内容的创作者带来的是C端反馈。他原来从事互联网策略运营，现在一边做AI产品，一边经营健身类小红书。一篇AI个人工作台笔记，两天获得四万浏览。流量说明普通用户对这类产品有兴趣，兴趣怎样变成一款愿意付费的产品，他还在找切口。下一步，他想把健身IP和AI结合起来。
企业Agent的尝试已经走进微信群。一位参会者部署的Agent每天会自己提出任务，等人批准后继续完善能力。它还能判断群里的几个人是否在讨论同一个话题，再根据聊天内容生成图片。项目已经开始向企业报价，十万元起步。能不能让Agent继续自主开发应用，团队还在试。
一位财务信息化运维从业者，想先让AI把自己的工作学会。他希望把重复的系统运维逐步交出去，自己腾出时间做AIGC创作。目前他正在接触内容授权和运营合作。别人担心被AI替代，他主动把这件事排进了自己的计划，先让AI接旧工作，再把人挪到新方向。
轮到法律行业，讨论很快落到责任上。一位法律从业者从2020年开始关注自动化处理法律工作。ChatGPT出现以后，她发现检索资料、编辑文本、起草文书这些耗时的事务，AI已经能接走相当一部分。她甚至在考虑组建一个小型AI律师团队。
可法律服务有一道线绕不过去。AI能给建议，能写初稿，最后是谁签字、谁向客户交付、出了问题谁负责？答案仍然是律师。现场也提到，企业法务已经可以让Agent查资料、写初稿，同时要加上多重限制，尽量压低AI编造内容的风险。
最后一类是数据与AI产品。有参会者专门做数据开发和AI产品，这次来到现场，主要想了解对话式系统进入企业后怎样运行、开发效率能提高多少，以及用户是否愿意改变原来的工作方式。
没有人拿出一份统一答案。每个人都带着一个尚未解完的问题。ESG报告怎样写得像企业，IP角色怎样不变脸，健身流量怎样变成产品，Agent怎样证明自己值十万元，运维经验怎样教给AI，法律结果又由谁负责。
08
PART
行业不同，落地时反复碰到的是同几类问题
INSIGHTS
后半场还有一个明显变化。大家很少继续讨论哪个模型更强，问题集中在知识、交付、收费和责任上。
AI进入专业行业，第一步都要学习行业知识。ESG报告有自己的政策语言，法律文书有自己的推理和责任要求，IP角色也有必须保持一致的设定。通用模型可以生成内容，行业项目仍然要把这些知识整理出来，再限制AI怎样使用。
产品做出来以后，还要找到愿意付费的人。现场有人已经向企业报出十万元起步的Agent项目，也有人在探索内容授权、年度陪跑和结果分成。不同项目仍在试价格，大家更认同的一点是，收费要和企业得到的结果联系起来。
开发分工也在改变。现场分享提到，目前项目里超过九成的代码可以由AI编写。工程师的工作逐渐转向需求设计、功能校验和架构优化。参会者讨论到，过去需要多年积累的开发经验，现在可以通过AI按需学习，加快掌握新知识。
代码写得更快以后，业务理解显得更重要。一个人能不能进入客户现场，听懂岗位在做什么，判断哪一段流程适合AI，再把结果交给员工使用，这些能力决定项目能不能继续走下去。
企业AI落地的难点，已经不只是能不能做出一个功能。谁去理解业务，谁把需求做成可验收的任务，谁保证系统半年后还能用，这些问题更难，也更值钱。
FDE正在补的，正是这段从模型能力到业务结果之间的距离。