文章结构化摘要

文章主旨：AI 时代数据部门的协作对象从“需求”变为“判断”，因此需要从“把数据交出去”转向“把上下文、能力和边界一起交出去”，同时守住数据不出域、口径唯一、权限跟人走三条底线。

关键要点：

• 旧有“业务提需求—数据排期—开发取数—交付报表”的协作流程依赖三个假设：问题边界清楚、答案形态固定、消费入口唯一；AI 使这三个假设同时失效，瓶颈从取数能力转为上下文能否共享。
• 会员涨价案例表明，一个判断所需的信息分属数据部门与业务部门，靠人工传递权益清单和档位口径来对齐，会导致协作慢、易出错且难以复用。
• 应用层的改法是围绕决策组织上下文：让报告、追问和后续动作在同一频道中发生，并通过 A2A 接入各部门的 Agent，由数据侧拆解、委派和合成答案，同时标注信息来源以解决信任问题。
• 底座层的改法是开放“数据空间”：在安全域内提供数据、权限和知识三类能力，使业务部门能够复用官方数据、权限体系和统一口径，自建用户运营平台，而不是由数据部门逐个定制。
• 协作方式可变，但三条底线不能动：数据不出域，跨部门交换结论和视图而非明细；核心指标只有一个官方口径；权限跟着组织和岗位走，不跟着临时需求走。

内容结构：

引言

文章以数据部门最怕被问的问题变化开篇：过去是“帮我拉个数”，现在是“会员该不该涨价”。前者是可排队的工单，后者是难以排队的判断，由此引出协作方式需要变化。

一、我们习惯了的那套协作，正在失效

文章梳理了过去十年的固定协作流程，并指出其成立依赖三个假设。AI 同时打破了这三个假设：问题边界变得不清楚，答案从报表变为可直接用于决策的结论，数据消费入口从系统看板转向 AI 问答。结论是，卡住协作的不再是取数能力，而是上下文能否共享。

二、一个会员涨价问题，暴露了所有问题

文章用 C 端会员涨价示例说明：数据部门掌握用户行为、付费记录、续费历史和 LTV 等信息，会员/增长部门掌握权益结构、成本、竞品定价和渠道政策等信息，双方都缺少对方的一半答案。当前依靠“手工发过来”对齐，导致协作慢、易错且下次仍需重复。文章据此判断，问题本质不是数据治理不够，而是协作机制没有为跨部门提问设计。

三、第一种改法：从“报表工厂”变成“数据驱动”

文章提出，如果用户不再主动打开系统找数据，数据就应主动走向用户。数据驱动的产物不是看板，而是洞察。文章给出三项标准：有记忆、有判断、有温度。并以 C 端场景概括说明：围绕产品决策组织报告和追问，使会员涨价、灰度效果、改版留存等同类问题在同一频道中讨论。其核心是先把上下文对齐，让协作从“发报表”变为“在同一条消息下干活”。

四、第二种改法：承认自己不可能什么都懂

文章指出，数据驱动解决了人和人处于同一上下文的问题，但另外半个答案在别的部门专业知识里。因此提出 A2A：让部门 Agent 像成员一样加入频道，数据侧 Agent 负责拆解问题，直接取用自有数据，将对方领域的问题委派给部门 Agent，最后合成完整回答并标注来源。文章认为，这解决了跨部门协作中“数是谁说的、是否可信、口径是什么”的信任成本，数据部门的角色也变为连接各方并对口径负责的编排者。

五、但更麻烦的一类需求，在底座层

文章转向另一类需求：业务部门要建自己的用户运营平台，需要用户、行为、交易等数据以及活动配置和人群触达能力。双方存在合规、权限、指标口径、排期和个性化定制等矛盾，但共同诉求是“数据不搬家、能力不重建、口径不走偏”。文章提出以“数据空间”开放底座，在安全域内同时提供数据、权限和知识：官方数据以授权视图只读挂载，部门可上传自有数据联合加工；权限按组织岗位复用并跟人走；知识以官方口径为统一底座，部门经验经抽取审核后补充。文章认为，只给数据等于给原料，三类能力一起给才等于给可直接开工的厂房。

六、变的是方式，不变的是三件事

文章强调协作方式可以改，但三条底线不能动：第一，数据不出域，跨部门交换结论和视图而非明细表；第二，口径只有一个，核心指标必须有官方认证版本，防止 AI 生成看似真实的错误答案；第三，权限跟着人走而不是跟着需求走，临时开口子会积累长期风险。

写在最后

文章回到标题，认为协作方式要变，是因为协作对象从“需求”变成了“判断”：需求可以排队且有边界，判断不能排队且没有边界。数据部门需要在应用层把人、数据、AI 放入同一上下文，并用 A2A 接入各部门专业能力；在底座层用数据空间开放数仓、权限和口径，让部门自行生长平台。数据部门的角色从数据供应商转向口径维护者和编排者。

文章总结：

文章建议数据部门主动重构协作机制，以共享上下文、专业能力和治理边界支撑业务判断；AI 不会让数据部门消失，但会让“只负责出数”的数据部门消失。

一个数据人的自留地

查看原文：AI 时代，数据部门的协作方式要变了

文章来源：

一个数据人的自留地

扫码关注公众号