大数跨境
首页
>
驻地、写码、重写两遍本体，最后只交付一个客户能用的工作流
>

驻地、写码、重写两遍本体，最后只交付一个客户能用的工作流

驻地、写码、重写两遍本体，最后只交付一个客户能用的工作流 AI驱动数字化转型
2026-09-30
6
导读：判断一条路线最终成没成，看一个信号，就是人走了以后。系统还在跑，换个人也接得住，那才叫真的落了地。
一家股份制银行的会议室里，开场不到五分钟，客户的信息主管就把话挑明了。数据不能出他们机房，模型必须过等保三级，至于到底要什么，他自己也说不清，让对面看着办。
这三句话出自一位朋友的转述，他人就在那场会上。
他在公司挂的头衔是大模型解决方案专家，最近公司发全员邮件统一改名，唤作前沿部署工程师，也就是硅谷眼下被炒得很热的FDE，名字换了，他手里的活一点没变。
他干活是照着FDE那套标准来的，在客户工位上待了不短的日子，对接三个内部系统，代码亲手写，还帮客户把业务里的实体关系一条条理出来，也就是重做本体，前后做了两遍。
按外面的说法，这已经比多数同行更接近Palantir的做法。
可最后交出去的东西，只能在这家银行的机房里跑，客户一换，这一整套就得推倒重来。
这样的事不算孤例，有人翻过招聘网站，两百多个挂着大模型解决方案、AI实施、私有化部署字样的岗位，拿FDE那几条硬标准去卡，真对得上的不到5%，剩下那九成五，是另一种工种，被等保、信创、数据不出域三道锁按在客户现场的“高配实施工程师”，听着像FDE，骨子里是两个物种。

PART 01
FDE的来历与争议

来历得先说清，FDE不是这两年的新词，它是Palantir在数据行业里做了二十多年的一个岗位，把工程师直接派到客户现场，像工兵一样在泥里解决问题。
去年Anthropic、OpenAI、Sierra接连补招这个岗位，国内一下子就热了。
热起来之后，圈里开始流传一句话：

美国FDE做产品，中国FDE做关系。

这一热，热的其实是个老问题，模型越来越强，企业为什么反而越来越离不开人。
这话有见识，也埋着陷阱，见识在于，中国的AI项目常常不是栽在技术上，是业务、数据、IT、安全和管理层没站到同一条责任链上。
陷阱在于，它太容易被读成美国讲制度、中国讲人情，读到这一层就停住，把搞关系当成了答案。
关系从来不是那个答案，它只是一堆原料。
FDE这个词从Palantir那套打法里冒出来的时候，前提就已经写在里面了。
平台已经在手，产品边界清楚，工程师进场是去接数据、接工具、接权限，把客户那条流程接进产品，再把普遍的问题带回来。
这套前提在中国常常要重写，不是因为中国落后，是因为走到这一步的企业，系统更老，权责更散。
那答案藏在哪，不妨把它换成更具体的一问。
PART 02
AI项目的两张图纸

每个AI项目其实都摊着两张图纸，一张画的是机器怎么想事，数据从哪儿取，判断怎么下，工具怎么接，权限怎么拦，过程记在哪儿。
另一张画的是人，目标谁定，资源谁给，风险谁判，吵起来谁升级，干完谁复盘。前一张图纸，多数项目都会画，接口和数据流拼得整整齐齐。后一张图纸，很多项目从头到尾就没画过。
两张图纸谁先谁后其实不打紧，要紧的是它们得摆在同一张桌上被看见，而不是一份攥在IT手里，另一份只装在某个人心里。
这后一张从来不是什么软活儿，它画不出来，前一张画得再漂亮也会被现实拽回去。预算谁批的，出事谁顶，上线那天谁有权喊停，这些答案不写在系统里，可它们决定系统能不能真的跑起来。

第二张图为什么难画
第二张图之所以难画，自有它的道理在。
企业的信息系统是攒出来的，不是设计出来的。集团一套，子公司一套，部门自己又搭了一套，中间夹着成堆的表格。
数据名义上属于企业，可项目真要用，得逐个来源去谈口径、谈责任、谈风险，没有哪一个人能一句话替所有系统做主。
这就像要盖一栋楼，等到开工才发现地基是好几拨人分批浇的，图纸还各留一份。
决策也是矩阵式的，业务要快，IT要稳，安全手里有一票否决，采购管着合同，财务盯着预算，集团和子公司的优先级还可能拧着。
缺一个跨部门的牵头人，任何一个团队单独都推不动。于是每个环节都要单独去谈一遍，谈成了还不算数，换个部门又得从头再来。
真正管用的流程常常不在制度里，而在现场老员工的脑子里。举个常见的，同一张出库单，系统里的流程是三步，现场的老仓管还有第四步，打个电话问一句，不然账和库对不上。
这一步不写在任何制度里，可缺了它，单子就是错的，AI要学的往往正是这一步。
AI要是只读标准文档，最需要它的边缘情况它偏偏接不住，要是把经验一股脑编进规则，又会把不透明一起固化下来。
采购的规矩是先框定功能、再放团队进场，可团队一进场，看到的往往不是当初框定的那个问题。
到了这一步，改目标等于改合同，于是最省事的办法是加定制，把原合同撑下去，而不是回头重新定义要什么。合同上写的是功能，现场要的是结果，这两样东西经常对不上。
这几条叠在一起，就出现一个局面，系统那头催得紧，人这头没人愿意签，项目于是拖着，或者用一个更大的定制把矛盾盖住。拖到后来，预算花完了，当初那点说服力也花完了。

PART 03
FDE的核心解法

所以得把两张图纸摊在一起画，判断一个系统节点画没画全，有个很土的检验办法，看它旁边有没有名字。
知识库不光是那个存向量的库，它还得有内容负责人、更新频率、失效怎么处理、错了谁来改。
自动审批不光是那套流程引擎，它还得有额度、有例外、有具名的审核人、有出事之后担责的人。
模型监控也不只看那几个指标，它还得说清谁判断业务退化、什么时候暂停、怎么把消息通知到人。
一张节点上没有名字的系统图，说到底只是一张愿望。
再往下，才是FDE真正该干的那件事，把现场这些关系翻译成两样东西，一样是落到人头的责任，一样是能被机器读进去的结构。
责任那半张，上面看名字的办法已经说清；结构那半张，指向的东西是本体。
有一份FDE模式的行业观察报告讲得实在，FDE面向平台要沉淀四样东西，行业场景、系统接口、测试方法、失败案例，把它们做成能复用的组件，而这些沉淀最后共同的落脚点，是本体层。
腾讯云那篇文章讲得更不留情面，驻场、写码、重做本体，这些动作那位朋友全做了，可只要没有回流、没有沉淀，交出去的就只是这一家客户的私有工作流，下一个客户，从零再走一遍。
于是判断FDE到底落地没有，有个很朴素的标准，看它交出去的东西，下一个客户能不能接住其中一部分。
关系最后得变成产品里的一部分，才算真落了地。只留在一个客户机房里、只跟着某个能人走的，那叫交情，不叫能力。

PART 04
落地的自查判断

也可以拿几道题自查，有没有一个具名的人为业务结果负责，真实用户有没有参与定义什么叫做对了，数据和系统的负责人肯不肯承诺响应时间，安全和合规是不是从画图纸那天就在场，真吵起来有没有一条明确的升级路径和一个最终拍板的人，上线之后业务结果和运行风险有没有人一直盯着。
还要多问一句，真到了该喊停的时候，谁有权喊，喊了算不算数。这些题答不上两条，项目就还没到写代码的时候，这时候补责任链比加参数管用。
还能看一个反向的数，有多少关键进展仍然靠某个人私下催出来。项目越成熟，这个数越该往下走，让正式的责任、服务级别和决策门接住它。
反过来，要是每周开会还在重新解释目标、确认谁来配合，那说明第二张图纸始终没画出来，技术迭代只是在替组织欠下的账打掩护。
制造业里有个例子最典型，企业想让AI解释质量异常、推荐处置，技术上接进MES、质量系统、设备数据，再搭检索和规则就能跑，可真正的坎在另一头。
同一个异常，生产、质量、设备三个部门各有一套说法，要停线的建议会拖累产量，谁都不想先开口，过往的处置记录里混着大段自由文本和事后改动，机器给的建议万一错了，班组长到底能不能推翻，供应商那台设备的数据还被合同锁着。这个节骨眼上直接训模型，等于把几个部门的分歧打包成一个看着统一的答案。
更稳的走法是先把三样东西定下来，共同的事件对象、证据从哪来、风险怎么分级，低风险的给建议并记下有没有被采纳，高风险的只把证据摆齐、交给具名的人去拍，口径谈不拢就进一个联合规则委员会，每条建议都留着依据和版本。
最怕的是另一种结局，项目上线了，账也好看，可它靠的是那位能人每天在群里催，靠的是他和几个部门头头的关系，人一走，系统就凉。这种项目不能算成功，顶多算是一次暂停。把谁该负责这件事摆到桌面上，技术那边才接得稳。
PART 05
最后的提醒：让关系变轻，不是变重

还有一件事得防着，FDE要懂关系，不等于靠私人关系绕过治理。
关键权限和决定都要留痕，谁也不能因为跟项目组熟就多拿一份数据，对岗位的影响和已知风险不能只向上面报喜，项目也不该靠某个部门默默多扛一份活才落空。
信任确实是干活的润滑剂，可它替代不了制度，制度立住了，信任才不会变成几个人的私人资产。
成熟的团队，是让藏在心里的顾虑能摆到正式桌面上谈，让不同角色拿共同的结果和证据来做选择。它要做的是让关系变轻，不是让关系变重。
判断一条路线最终成没成，看一个信号，就是人走了以后。系统还在跑，换个人也接得住，那才叫真的落了地。
中国FDE把组织关系摆在最前面，但不是要一直泡在关系里。是要把关系翻译成责任和结构，让产品最后不再依赖某一个人。

【声明】内容源于网络
0
0
AI驱动数字化转型
专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。
内容 1095
粉丝 1
AI驱动数字化转型 专注AI，促进智造行业数据衍生，服务智能制造企业的数字化、智能化，聚焦大模型私域部署、大模型微调、数据清洗、AI模型训练、私域知识库及agent技术延展等。行业智能，落地为先。
总阅读12.1k
粉丝1
内容1.1k