FDE和数据工程师的界限在哪？

在很多 AI 落地项目里，这两个角色的工作内容有大幅重叠——都在跟数据库打交道，都在写清洗逻辑，都在跟业务确认字段含义。但如果你问他们「这个项目算成功的标志是什么」，答案会完全不同。

一、目标函数不同

数据工程师的目标函数是可用性：数据准时到、字段完整、口径一致、任务不断流。他成功的标志是没人来找他，因为一切正常运转。

FDE 的目标函数是业务改变：某个岗位的某个动作因为这套系统变得更快或更准。他成功的标志是有人主动来找他，因为想再加一个场景。

这两个目标不冲突，但优先级会打架。数据工程师倾向于先把底座建好再谈应用，FDE 倾向于先跑通一个场景再倒推需要什么数据。

二、在中小企业项目里谁先谁后

标准答案是先建数据底座。但对大多数中小企业来说，这是一条走不通的路——数据治理动辄半年起，钱花完了业务一点感觉都没有，项目就死在中途。

更务实的顺序是倒着来：先选一个价值明确的场景，只治理这个场景需要的那几张表，跑出结果给业务看见，再用这个结果去换下一步的预算和耐心。

这不是说数据治理不重要，而是治理的范围要跟着场景走。一次治理一个业务动作需要的数据，比一次性治理全公司的数据，成功率高得多。

全量治理是大企业的奢侈品，场景驱动才是中小企业的活法。

三、能力上怎么互补

数据工程师的强项是规范和稳定性——知道怎么建表不会踩坑，知道调度失败怎么补数，知道口径变更要通知谁。这些是 FDE 常常欠缺的。

FDE 的强项是业务判断和取舍——知道这个字段虽然脏但不影响结论，知道这个环节业务上根本没人看所以不必做，知道该在哪里停手。

理想配合是：FDE 定方向和边界，数据工程师保底座和质量。最怕的情况是两边都只做自己熟悉的部分，中间那段「这个字段业务上到底什么意思」没人管。

四、阿优至简的视角

中小企业往往两个角色都没有，数据散在 Excel、ERP、微信群和老师傅的脑子里。我们的做法是先做一次轻量盘点：只针对目标场景，把数据在哪、谁在维护、多久更新一次问清楚，通常两三天就够。

盘完之后往往会发现，真正卡住项目的不是技术，而是某张关键表没人负责更新。这类问题技术手段解决不了，得靠流程和责任人。指出这一点，本身就是交付价值的一部分。

落地前的三条至简建议

1. 先选场景：让业务价值决定治理范围，而不是让治理进度决定业务何时受益。
2. 先抽样：正式开工前随机抽查真实数据，比看数据字典可靠得多。
3. 先找责任人：每张关键表都要有明确的维护人，没有的话先补这个再谈技术。

数据工程师让数据能用，FDE 让数据有用。项目里缺哪一个都跑不远，但顺序错了会更贵。