我们被人民网报道了？1028 济南到底发生了什么

FDE-Watson
FDE-Watson

AI 数智化实验室

2026年11月1日 14:24
山东

去阅读

QUOTE

交付系统容易，留下一种能力难。

10 月 30 日晚上，朋友把一条人民网的链接甩进群里：你们 1028 那场沙龙，上报道了。

团队群热闹了十分钟。第二天，后台收到的问题却有点出乎意料。问「下一场什么时候」的不少，但问得更多的是另一句：

你们到底是做什么的？

有人以为我们是办活动的，有人以为我们是卖软件的，还有人以为我们是做企业培训的。都沾一点，都不准确。

所以这篇不写活动通稿，把四件事一次说清楚：我们办了一场什么活动、FDE 是干什么的、怎么和传统企业结合、如果你想做该从哪开始。

01

WHAT WE DID

一场 400 人的活动，真正留下了什么

先交代事实。

10 月 28 日下午，济南。原定 200 个座位，报名超过 400 人。13 点 20 分签到，13 点 50 分开场，过道里站了人。

来的人覆盖 15 个行业、140 多家企业，大部分是制造、能源、物流、医药和国企的信息化负责人。

人民网山东频道的报道里，有一组数字：济南算力规模 9866.5P，居全省首位；建成 56 类 人工智能场景资源池；设立规模 50 亿元 的人工智能产业基金；落地 130 个 大模型。这是这个城市 AI 供给侧的底子。

但现场没人问「算力够不够」。

问得最多的是三类问题：

1

「我们这种传统行业，第一个场景选什么？」

2

「预算不多，是先做知识库，还是先做质检？」

3

「员工不用怎么办？」

这三个问题，没有一个在问技术。它们都在问判断。

更值得记的是散场之后。台上讲完，嘉宾被围在过道里，十几个人拿着手机里的流程图，一个接一个问「我们这种情况能不能做」。那天最具体的对话，几乎都发生在议程结束之后。

所以这场活动真正留下的，不是 400 这个数字，也不是一篇报道，而是一个很清楚的信号：企业不缺 AI 信息，缺的是「从哪开始」。

这也正是我们做 FDE 的原因。

02

WHAT IS FDE

FDE 是什么：先进入现场，再谈方案

FDE，全称 Forward Deployed Engineer，中文通常叫「前沿部署工程师」。

这个角色没有统一的证书，也没有标准答案，但有一个共同点：人不在办公室里想方案，而是进到客户的业务现场，和业务人员一起把问题拆开，把一个能跑的最小闭环做出来。

具体是三个动作：

动作 1进现场

跟岗，看真实的一天怎么过：谁在填表，谁在打电话，谁在等审批，哪个环节每天耗掉两个小时。不看流程图上的流程，看人实际怎么干活。

动作 2定问题

把「我们想用 AI」翻译成一条具体链路、一个可验证的指标。不是「提升效率」，是「报价从三天压到四小时」；不是「知识库」，是「新人独立回答客户问题的比例」。

动作 3共建

和业务部门一起做最小闭环，跑出结果，再把方法、数据和运营动作交接给企业自己的人。项目结束，能力要留下来。

Datawhale 在《FDE 案例 100》的前言里有一句话，我们很认同：FDE 不是简单地来到企业完成一个项目，再把一个系统交付出去，而是一种共建关系——一起发现问题、定义问题、构建方案、验证价值，同时帮助企业把方法、经验与能力沉淀在组织内部。

有人会把 FDE 理解成高级驻场外包。区别在交付物：外包交付的是工时和功能清单，FDE 交付的是一段跑通的业务，和一套企业自己能接手的方法。

用我们自己的话说：FDE 是业务翻译、系统落地和能力交接，三件事合在一个人身上。

只懂技术，会做出一个没人用的系统；只懂业务，会停在 PPT 上；只会交付，项目结束能力就跟着走了。

03

WHY FDE

传统企业为什么需要 FDE：三个错位

传统企业做 AI，最常卡在三个错位上。

第一个错位：方案不等于链路。

在会议室里演示，什么都对；一进业务就散。因为 demo 处理的是标准输入，业务现场给的是例外、是脏数据、是「这个情况特殊，得问老师傅」。

FDE 的动作是：先跟岗，把链路画出来，再决定技术放在哪一段。

第二个错位：工具不等于数据。

模型很强，但数据在另一个部门，格式不对，口径不一，拿不出来。很多项目不是死在模型上，是死在「数据在，但取不到」。

FDE 的动作是：先盘数据，再选工具。数据不通，先修数据，不急着上模型。

第三个错位：上线不等于用起来。

系统上线第一周很热，第三个月没人管，半年后没人敢动。验收看的是功能清单，不是使用率。

FDE 的动作是：交接使用率，不交接满意度；把「谁来用、多久用一次、不用怎么办」写进交付。

这三个错位，不是靠买一个更强的模型能解决的。得有人在现场，把它们一个个对上。

04

HOW WE WORK

怎么结合：90 天，只跑通一段

和传统企业结合，我们不做「全面转型」，只做一段。

一段，指的是价值链上的一段具体流程：从询盘到报价，从下单到回款，从报修到派单。90 天，四步（图 2）：

为什么是 90 天？一个月只能看到 demo；一个季度才跨得过业务的一个完整周期——月结、排产、报税，也才看得出使用率会不会在第三个月掉下去。

01前两周，跟岗

不急着提方案，先看业务人员怎么干活，把真实链路、例外情况和数据位置摸清。

02第三、四周，定指标

把「更快、更准、更省」换成能数出来的数：几个人天、几天交付、多少返工。指标定不下来，项目就先不立项。

03第五到十周，做最小闭环

只接管最标准、最重复的那一段，人机分工写清楚：哪些机器做，哪些人复核，异常怎么退回。

04最后两周，交接

把使用率、维护动作和责任人定下来，企业自己的人能接手，我们才退出。

— 图 1 90 天最小闭环：四段推进

选哪一段，用五道筛子过一遍：

—业务价值能不能被验证，能不能算成数字；

—数据拿不拿得到，干不干净，能不能持续拿；

—结果能不能写回业务系统，而不是停在聊天框里；

—这个问题是不是 AI 真能解决，还是流程、权限、管理问题；

—业务人员愿不愿意用。

五条里有一条明显不过，就先换一段。容易做，不等于值得先做。

上线之后还要算三笔账：人力账、返工账、维护账。前两笔决定项目值不值，第三笔决定它能活多久。算不清维护账，项目就是「上线即巅峰」。

05

BOUNDARIES

我们的边界：不做什么

说清楚做什么，也要说清楚不做什么。

—不卖算力，不代理平台。 企业已有的云和模型，能用就继续用；我们的价值在把 AI 接进流程，不在卖资源。

—不接没有业务 owner 的项目。 只有 IT 部门牵头、业务部门不参与的项目，我们不做。因为最后用不用，是业务说了算。

—不把演示当交付。 演示能过，不等于业务能跑。我们只认跑过一段真实业务的结果。

—不接「先把系统建起来，再想场景」的需求。 顺序反了，钱大概率白花。

这些边界让我们丢掉一些单子。但接了的项目，更容易真的落地。

06

TWO PATHS

两条路：自己团队做，或我们一起做

看到这里，如果你也在想「我们公司该从哪开始」，有两条路。

第一条，自己团队做。 我们把 90 天的方法做成了一门课：不讲工具大全，按一段真实流程排。学员带一个自己的场景进来，课上把链路画出来、把指标定下来、把五道筛子打一遍分，带着一份能回去执行的方案走。适合有信息化团队、想自己主导的企业。

第二条，我们一起做。 从跟岗开始，选一段链路，90 天跑出结果。适合业务复杂、内部推不动，或者想先看到样板再复制的情况。

两条路都不便宜，也都不承诺「包治百病」。AI 能解决的是具体链路里的具体问题，不是一句「全面智能化」。

如果你不确定该走哪条，可以先聊一次。把你想动的那条链路说清楚，我们一起判断：值不值得做、先做哪一段、大概要多少人。

07

THE START

报道是起点，不是答案

人民网报道这场沙龙，对我们是个鼓励。它让更多企业看见我们在做的事。

但一家企业的 AI 落地，不会因为一篇报道发生。

它更可能发生在某个普通的下午：业务负责人坐下来，拿一张白纸，把从客户下单到回款的那条链路画出来，标出三个节点——数据看不清的、反复搬运的、只能靠老师傅判断的。

标完，第一个场景往往就浮出来了。

如果你愿意，可以把这条链路发给我们。我们不一定都能接，但可以一起看看，哪个节点最值得先动。

END

我是 watson，一个专业的企业 AI 应用落地专家。

如果这篇对你有用，欢迎点赞、在看、转发。