代码审查与业务建模

• 规范的内容与价值
• 模板与 Prompt 共享的收益
• 落地阻力与持续维护

团队 AI 工具使用规范的真实落地，核心是把"个人摸索"转化为"团队可复用资产"。常见做法包括：建立 Prompt 模板库（如代码评审、测试生成、文档生成的常用 Prompt）、共享经验文档（哪些任务 AI 好用、哪些不可靠）、定义禁止事项（如敏感数据上传红线）与灰名单。落地经验表明：规范的价值在于减少重复摸索、统一输出质量、降低风险，但纯文档式规范容易沦为空谈，必须配合"活"的资产（可复用的模板直接可粘贴使用）+ 版本管理 + 定期更新。实际阻力是"人人都有各自的习惯"和"规范更新滞后"，因此应让规范"随实践演进"而非一次性制定，并让有经验的成员示范与维护。

规范的价值在于把个人经验资产化，但需要"可复用 + 持续维护"而非"一纸规定"。落地靠模板与示范，而非行政命令。

• 工具准入的公平性
• 能力与机会的差异
• 资源与指导的分配

AI 工具的"公平使用"边界指：团队中不同成员接触 AI 工具与能力的机会应公平，避免因工具访问差异或技能差异造成能力与机会的不平等。真实边界体现在：一是工具预算与访问权限应覆盖所有需要的人，而非仅部分成员；二是新手与资深、不同技术栈成员对 AI 的掌握和使用深度不同，需要提供平等的培训与指导，避免"会用的人越用越强、不会用的人被拉开差距"；三是 AI 产出的归属与评价应公平，避免"用 AI 的人看起来产出多"而掩盖真实能力差异。公平使用不等于"人人必须用"，而是"人人有机会用、用得好、且评价公平"，需要团队在预算、培训、评价机制上做出安排。

公平使用关注的是"机会与能力差距"而非"用多用少"。团队需在工具访问、培训指导与结果评价上保障公平，才能避免技术分化。

• AI 评审能发现的问题类型
• AI 评审的盲区
• 分工与噪音控制

AI 代码评审擅长发现"模式化、可判定"的问题：如安全隐患（常见漏洞模式）、代码异味、未使用变量、资源泄漏、错误处理缺失、与常见规范不符等，这些有明确规则可循，AI 能快速扫描并给出提示。其盲区在于：高层的架构问题、业务逻辑正确性、需求符合度、跨模块影响、设计权衡等需要上下文与判断的问题，AI 难以可靠判断。与人工评审的分工原则是：AI 负责"机械、可判定、高频"的检查以减少人工噪音，人工聚焦"语义、架构、业务"的高价值判断。为控制噪音与误报，应设置 AI 检查的阈值与可配置规则、对 AI 提示做分级（阻塞/警告/建议）、并由人工确认后才能作为正式结论，避免团队被大量误报淹没。

分工的本质是"AI 做被规则定义的检查，人工做被判断驱动的审查"。噪音控制靠阈值、分级、确认机制，防止 AI 喧宾夺主。

• 异步沟通的信息整理
• 减少同步等待
• 上下文补充与决策辅助

AI 在跨时区协作中的真实价值体现在：一是信息整理与同步，AI 能自动生成会议纪要、PR 简介、异步讨论摘要，让不同时区的成员快速理解进展，减少"同步开会"的依赖；二是降低沟通成本，开发者可以用 AI 先把问题整理清楚、把代码改写成更易读的形式再提交，减少来回澄清；三是上下文传承，AI 能基于代码库和文档回答"这个模块的背景"，让异步协作的成员更快获得上下文。其价值本质是"把异步沟通的质量提升到接近同步的清晰度"，减少因时差导致的等待与误解。但 AI 不能替代必要的实时决策与关系建立，跨时区协作仍需关键节点的同步对齐。

跨时区协作的痛点是"信息传递慢、上下文难同步"，AI 擅长把信息整理得更清晰、更结构化，从而降低异步协作的摩擦成本。

• 词汇表的价值与作用
• 建立与维护方法
• 落地的阻力与一致性保障

业务词汇表（Ubiquitous Language）的落地价值在于：统一业务与代码的术语，让领域专家、开发、测试、产品用同一套词汇沟通，减少歧义与"翻译"成本。真实落地经验是：词汇表应随 DDD 建模过程从业务讨论中提炼，而非凭空编写；要维护"词条、定义、使用场景、代码中的对应"；并通过强制在代码、文档、测试与评审中使用来保证一致性。落地阻力包括：术语漂移（团队逐渐用不同说法）、维护成本与被遗忘、以及"口头约定"难以约束。有效做法是：让词汇表"活"在每次讨论与评审中，由建模负责人维护，并把它与代码命名、测试命名绑定，使其成为团队共同遵守的纪律。

词汇表的价值在于"统一语言降低歧义"，但它需要持续维护与纪律约束，否则会退化为无人维护的文档。绑定代码与评审是落地关键。

• 数据所有权的归属界定
• 单一事实来源
• 治理与责任机制

数据所有权的真实工程设计核心是"每一份数据都有且只有一个明确的责任方（owner），该方负责其正确性、质量、生命周期与访问控制"。工程实践上要做的：一是明确数据域的归属，避免"多人共管 = 无人负责"；二是建立单一事实来源（Single Source of Truth），避免同一数据在多个地方重复维护导致不一致；三是设计数据访问与使用权，让消费者通过受控接口获取数据而非直接改源头；四是建立治理机制，明确 owner 对数据质量、schema 变更、SLA 的负责。真实经验是，数据所有权混乱的根源是"归属不清 + 责任不明"，好的设计用"数据蓝图/目录 + 责任矩阵 + 变更评审"来落实，让数据既被清晰归属又便于安全共享。

数据所有权是"数据治理的责任基础"，核心是归属清晰、责任到位、单一事实来源。好的设计让数据"有主可循、可管可控"。

• 数据架构与业务架构的对应关系
• 数据模型反映业务语义
• 协同的落地方式

数据架构与业务架构的真实协同在于：数据架构应服务于并反映业务架构，即数据模型、数据流与数据域要跟业务领域、业务流程、业务能力对齐，而不是脱离业务自建。协同的价值体现在：数据域划分与业务域（限界上下文）对应，让数据治理与业务治理一致；数据契约反映业务规则；数据流映射业务端到端流程，支撑可靠的数据集成。落地方式包括：从业务架构推导数据架构（如 DDD 事件风暴中梳理数据与事件）、在业务架构评审时同步评估数据影响、用数据目录/蓝图把业务元数据与数据资产关联。真实经验是，当数据架构与业务架构脱节时，会出现"技术上的数据模型与业务语义不符"的鸿沟，协同的关键是让业务与数据人员在建模过程中共同参与。

数据架构是业务架构在数据层面的投影，协同的本质是"让数据真实反映业务"。两者对齐才能避免数据与业务两层皮。

• 聚合边界的划分
• 一致性边界与事务边界
• 常见设计误区

聚合根边界的真实设计经验是：聚合是"事务一致性与不变量 (invariant) 的边界"，边界应围绕"业务不变量"来划分，而不是围绕"数据关系"或"方便查询"来划分。设计要点：聚合边界内保证强一致性（同一事务内修改），聚合间通过领域事件实现最终一致性；聚合根是访问聚合的唯一入口，保证业务规则不被绕过；聚合不宜过大（避免"上帝聚合"导致的事务压力和并发瓶颈），也不宜过小（导致聚合间切分过于零碎、事件泛滥）。常见误区是"为了查询方便把不相关的实体塞进一个聚合"或"盲目追求小聚合"。真实经验是：聚合边界由业务不变量与使用场景决定，需要在"一致性"与"性能/并发"之间权衡，并反复迭代。

聚合根边界是"业务不变量决定的强一致性边界"，不是数据关系边界。理解这一点才能避免过大或过小的聚合设计。

• 领域事件的价值
• 适用与不适用的场景
• 事件与命令的区分

领域事件（Domain Event）的真实应用边界在于：它适合表达"业务领域中已经发生的事实"，用于解耦聚合、跨系统/跨服务的通知、以及支撑事件驱动架构与最终一致性。典型适用场景包括：订单已支付、账户已锁定、库存已扣减等"业务状态变化"需要通知其他模块/服务响应。应用边界与误区包括：不应把"操作指令"（命令）当作领域事件，事件是"已发生的事实"而非"要去做的动作"；不应滥用事件做"流程控制"（如用事件实现复杂编排），这会让系统难以追踪；也不应把所有变化都发事件而无视是否真的需要其他部分响应。真实经验是：领域事件用于"有实际消费者、需要异步解耦或跨上下文协同"的场景，其余情况用同步调用即可，避免事件泛滥带来的复杂度。

领域事件是"已发生事实"的载体，价值在解耦与最终一致性，但不该用它替代命令或做复杂流程编排，否则会引入难以运维的复杂度。

• 中小团队的资源约束
• 轻量落地方式
• 简化与取舍

领域驱动设计（DDD）在中小团队的真实落地边界在于：中小团队通常人力有限、迭代快、带业务复杂度相对可控，直接套用全套 DDD（战术 + 战略 + 事件风暴 + CQRS 等）可能成本过高、过于繁重。真实落地经验是：中小团队应"轻量取用"——重点采用限界上下文与统一语言的建模价值，保留领域模型与聚合的基本概念，但不必在每个模块都做完整复杂的战术建模；事件风暴、CQRS 等重工具按需选用，仅在业务复杂度确实需要时引入。边界在于：不要为了"用了 DDD"而牺牲交付速度，也不要因为"简单"而完全放弃建模。关键是识别"业务复杂度真正高的核心域"，在那里投入 DDD 深度，其余支撑域用更简单的方式。

中小团队落地 DDD 的关键是"按需取舍、成本-收益匹配"，DDD 的价值在建模，但复杂度成本需与团队规模匹配，核心域投入、支撑域简化。

• CQRS 的适用场景
• 复杂度与收益权衡
• 与 DDD 的结合

CQRS（命令与查询分离）在 DDD 上下文中的真实工程取舍是：它把"写入（命令）"与"读取（查询）"分离，只对"读多写少、读写模型差异大、需要独立扩展查询"的系统有明显收益。它的价值在于：查询模型可针对读场景优化（如投影、视图），读写压力可独立扩展，写模型与读模型可分别建模。但代价是复杂度显著上升：需要维护读写模型的同步（事件投影）、两套模型与两套验证、数据一致性（通常最终一致）等。因此真实的工程取舍是：只有当"读写差异大、查询复杂、性能或扩展性要求高"时才值得引入 CQRS，简单 CRUD 系统引入 CQRS 是过度设计。在 DDD 中，CQRS 通常与 DDD 的领域模型（写侧）和查询投影（读侧）搭配，但并非 DDD 的必需品。

CQRS 是"用复杂度换读写灵活性"的取舍，只在读写差异大、收益明确时值得，简单系统引入是过度设计。

• 参与人员与角色
• 过程与节奏把控
• 产出与后续落地

事件风暴（Event Storming）工作坊的真实组织经验包括：一是参与人员要"跨角色"，需要领域专家、产品、开发、测试共同参与，因为它的核心是"通过集体讨论激发领域知识"，缺了领域专家价值大打折扣；二是过程上先"发散再收敛"——先用便签风暴出大量领域事件（橙色），再按时间顺序排列、识别命令、聚合、限界上下文，最后收敛成可用的领域模型；三是节奏把控，工作坊不宜过长，可分多轮，避免疲劳；四是产出要可落地，最终要形成领域模型、事件清单、边界划分，并转化为后续开发与代码结构的输入。真实经验是：工作坊的价值依赖"现场对话"，难点在于让领域专家真正参与并让讨论聚焦，需要经验丰富的引导者。

事件风暴是"用集体对话提炼领域知识"的建模方法，价值在讨论本身，组织关键是跨角色参与、发散-收敛节奏与可落地产出。

• 六边形架构的价值
• 抽象层与样板成本
• 落地复杂度与取舍

六边形架构（端口与适配器）的真实价值在于：把核心业务逻辑与外部依赖（数据库、消息、UI、外部 API）隔离，通过端口（port）与适配器（adapter）使核心逻辑可独立测试、可替换依赖、降低耦合。但真实落地的复杂度评估需要考虑：它引入了额外的抽象层、接口定义与依赖注入，对简单 CRUD 系统而言，这些是"过度抽象"的样板成本，可能让代码更绕、理解的认知负担更高。真实的复杂度权衡是：当系统有多个外部依赖、需要独立测试核心逻辑、或未来可能替换外部技术时，六边形架构的收益才明显；对简单系统，直接调用依赖更务实。落地时应"按需分层"，避免把每个模块都套上六边形导致"为模式而模式"。

六边形架构是"用抽象换可测试性与解耦"的取舍，复杂度收益与系统规模、外部依赖多样性相关，简单系统应避免过度抽象。

• 数据契约的要素定义
• 契约驱动的上下游一致性
• 破裂检测与告警

数据契约的定义应包括三个核心要素：一是 schema（字段、类型、是否必填、枚举、兼容性规则），它是契约的"结构"；二是质量（数据完整性、有效性、约束、可接受的质量指标），保证数据可信；三是时效（数据新鲜度、延迟、SLA 要求），保证数据可用。契约通过这些要素驱动上下游一致性：上游生产者按契约产出，下游消费者按契约消费，通过 schema 校验在集成点进行强制约束。契约破裂的检测与告警落地方式是：在生产者/消费者集成点做 schema 校验与质量监控，当字段变更、类型不匹配、质量不达标或时效超时（延迟超限）时触发告警，并纳入事件/告警体系。真实经验是：契约不仅要"定义"，还要"自动校验 + 监控 + 告警"，形成闭环，避免"纸上契约"与"实际数据"脱节。

数据契约是"上下游之间可验证的约定"，schema、质量、时效是三个落地维度，破裂检测靠自动校验与监控告警，使契约真正可执行。

• 治理的组织与责任
• 标准与流程
• 集中与分散的平衡

数据架构治理的真实组织经验核心是"在集中控制与分散效率之间取得平衡"。要点包括：一是明确治理的组织与责任，通常需要数据负责人（Data Owner/Steward）与治理委员会，但避免过度官僚化；二是建立标准与流程，如数据域划分、命名规范、schema 变更评审、数据质量与元数据管理，让治理有据可依；三是平衡"中央治理"与"团队自治"——中央负责统一标准与跨域协调，具体团队负责各自数据域的落地，避免"中央集权僵化"或"完全放任"。真实经验是：治理要"轻、可执行、随业务演进"，靠流程与工具赋能而非靠人盯，且治理与业务价值挂钩，否则容易沦为"为了治理而治理"。

数据治理是"标准化与自治的平衡"，核心是让责任清晰、标准可执行、流程不僵化，并让治理服务于业务价值。

• 示例映射的流程
• 澄清需求的机制
• 与测试的衔接

示例映射（Example Mapping）的真实业务建模价值在于：它通过"具体例子"来澄清需求，把抽象的用户故事转化为一组可验证的"规则 + 示例"组合，从而在开发前就暴露理解偏差与遗漏。它的流程是：围绕一个用户故事，用卡片记录规则（规则卡）、示例（绿色卡）、疑问（红色卡）和新故事（蓝色卡），通过讨论让团队与业务方对齐。价值体现在：一是用具体例子逼出模糊点，比抽象描述更能暴露需求不清晰处；二是产出可直接转成测试用例（与 BDD 的 Given/When/Then 衔接）的验收素材；三是促进团队与业务方深度对话，减少开发和测试阶段的返工。真实经验是，示例映射的收益在"讨论过程中"而非"文档本身"，它把"一次性的需求澄清"变成"可验证的沟通成果"。

示例映射用"具体例子驱动需求澄清"，价值在于逼出模糊点、衔接测试、促进对话，是"把需求讲清楚"的高效建模手段。

• AI 审查的擅长领域
• 人类审查的独有价值
• 分工的配合方式

AI 与人类审查的分工真实边界在于：AI 擅长"高频率、可判定、规则化"的检查——代码风格、常见缺陷模式、安全隐患、未使用代码、与规范不符等，能覆盖大量机械性检查并减少人类负担；人类擅长"低频率、需判断、依赖上下文"的审查——架构合理性、业务正确性、设计权衡、跨模块影响、可维护性与团队上下文。真实分工是"AI 负责广度与扫描，人类负责深度与判断"：AI 先做第一道扫描过滤明显问题，人类聚焦高价值判断与整体设计。配合方式上，AI 提示应作为"线索"供人类参考，而非"结论"，人类保留最终决策权，并通过对 AI 误报的反馈不断优化 AI 检查配置。

分工的本质是"按任务性质匹配能力"——AI 与人类的强项互补，AI 做规则扫描、人类做判断，二者配合而非替代。

• 召回率与精度的概念
• AI 检测的误报与漏报
• 实际使用中的权衡

AI 辅助识别潜在 Bug 的召回率（能发现多少真实 bug）与精度（发现的问题中有多少是真 bug）因模型与任务而异，但普遍特征是"召回不错但精度有限"：AI 能发现不少常见模式问题（如空指针、资源泄漏、边界错误），但也会产生较多误报（把正确代码误判为 bug），导致精度不高。真实使用中的权衡是：在高召回低精度下，AI 更多是"提示线索"而非"权威结论"，需要人工筛选确认，否则会因误报产生噪音；应针对团队代码库调优提示词与规则，聚焦高置信度问题，并记录误报反馈以迭代。真实经验是，把 AI 检测作为"辅助扫描 + 人工确认"，而非"自动拦截"，能让召回收益与误报成本取得平衡。

召回与精度的权衡决定了 AI 检测的落地方式——宁可用"提示线索"降低误报成本，也不追求"自动拦截"而引入大量噪音。

• Linter/Formatter 的确定性
• AI 审查的语义性
• 互补配合方式

Linter 与 Formatter 解决的是"确定性、可规则化"的风格与语法问题，它们规则明确、结果确定、即改即得，能保证代码风格统一、避免低级错误；AI 审查则擅长"语义性、需要理解"的问题，如逻辑缺陷、潜在错误、最佳实践建议，它们没有固定规则，需要模型判断。真实互补关系是：Linter/Formatter 作为"第一道确定性防线"自动化处理风格与机械问题，AI 审查作为"第二道语义检查"辅助发现逻辑与设计问题，二者配合而非替代。落地时，先用 Linter/Formatter 保证基线，再让 AI 审查聚焦语义问题，并把 AI 发现的"可规则化"问题沉淀回 Linter 规则，形成"AI 发现 → 规则固化"的良性循环，降低对 AI 的重复依赖。

互补的本质是"确定性问题用规则、语义问题用 AI"，且 AI 可把可重复的发现沉淀为规则，实现"AI 发现新问题、规则固化防复发"。

• 描述的结构与完整性
• 变更概述的准确性
• 简化与人工确认

AI 辅助 PR 描述撰写的真实质量通常较高，尤其在"结构完整性"上：它能基于变更差异生成结构化的 PR 描述，包括变更概要、做了什么、为什么、测试说明、影响范围、相关链接等，帮助开发者快速补齐规范化的 PR 文案，提升评审效率。其质量优势体现在"组织与表述"上，能清晰呈现变更内容。但真实边界是：AI 基于 diff 推断的"为什么"可能与真实意图不符，可能遗漏关键上下文、业务背景或风险提示，也可能过度美化或弱化某些变更。因此，AI 生成的 PR 描述应作为"草稿基线"，由开发者补充真实的动机、背景与风险，并确认描述与变更一致，避免"形式完善但内容失真"。

PR 描述的价值在于"准确传达变更意图与风险"，AI 擅长结构化与表述，但"为什么"与风险需开发者补充确认，防止失真。

• 常见代码异味识别
• 误报与上下文
• 与重构决策的衔接

AI 辅助识别代码异味（Code Smell）在"常见、可识别"的异味上可靠性较高，如过长函数、过深嵌套、重复代码、过度耦合、魔法数字、命名不当等，这些有可观察的模式特征，AI 能较准确地提示。但真实可靠性边界在于：是否"异味"往往依赖上下文与设计意图——某个看似复杂的写法可能是领域所需的合理设计，AI 缺乏这种判断，可能对合理的代码给出"异味"误报；同时，AI 识别的是"现象"而非"根因与重构方向"。因此，AI 的异味识别应作为"重构提示"而非"强制结论"，需要人工结合代码上下文判断是否真的需要重构、以及如何重构，避免"AI 报异味就盲目重构"导致的过度设计。

代码异味是"需要关注"的信号而非"必须修改"的定论，AI 能识别常见信号，但是否重构依赖上下文判断，需人工把关。

• OLTP 与 OLAP 的差异
• 读写/查询分离的触发点
• 数据同步与一致性

OLTP 与 OLAP 边界划分的真实经验是：它们解决不同的问题模式——OLTP（事务型）侧重高并发、低延迟、频繁的增删改查与强一致性，适合在线业务；OLAP（分析型）侧重大数据量、复杂聚合查询、批量分析，适合报表与决策。真实的边界划分不是"一刀切"，而是根据"查询复杂度与数据量到了什么程度"来决定分离：当业务上的分析查询开始拖累在线事务性能、或分析需求需要大量数据聚合时，就应引入 OLAP（如数据仓库、分析型数据库），通过 ETL/ELT 同步数据。经验要点：区分"事务型读写"与"分析型查询"的负载，避免在 OLTP 上跑重分析查询；明确数据同步的时效与一致性要求（准实时或 T+1）；两个系统各司其职，用数据管道衔接。真实经验是"先识别负载模式，再决定是否分离"，避免过早或过晚。

OLTP/OLAP 分离是"负载模式驱动"的取舍——当分析负载拖累事务负载才分离，关键是识别负载差异并设计数据同步与一致性。

• 主数据的定义与价值
• 治理与统一的边界
• 收益与成本权衡

主数据（Master Data）管理的真实边界在于：主数据是跨系统共享、被业务反复引用的核心基础数据（如客户、产品、供应商、组织），其价值是保证"一份数据、全系统一致"，避免各系统各自维护导致重复与冲突。真实的边界与权衡在于：主数据治理需要投入（数据标准化、归属、质量、同步机制），但并非所有数据都值得纳入主数据管理——只有"跨系统共享、变更影响大、需要统一"的核心数据才值得；针对单一系统使用的数据纳入主数据治理反而增加成本。真实经验是：主数据管理要"聚焦核心数据资产 + 平衡治理成本"，通过明确主数据范围、owner 与同步机制来落地，避免"什么都管"的过度治理。

主数据管理的关键是"范围界定"——只对跨系统共享的核心数据做统一治理，否则治理成本会超过收益，是"聚焦 + 权衡"的实践。

• 识别信号的来源
• 概念与语义的边界
• 团队与组织边界

限界上下文（Bounded Context）的真实识别信号主要来自"语义与概念是否一致"以及"组织形式"：一是当同一个业务概念在不同业务场景中语义不同（如"订单"在销售与物流中的含义不同）、或术语有歧义时，往往提示存在不同限界上下文；二是当业务规则、不变量或模型在不同团队/部门间有差异时，边界随之出现；三是团队组织结构、发布节奏、独立部署单元往往与限界上下文对齐。真实识别信号包括：术语冲突、语义差异、独立业务能力、独立团队/系统的边界。识别经验是"从统一语言和业务能力出发"——当团队需要为同一概念定义不同含义以满足不同业务场景时，就应划分边界；同时结合团队拓扑与部署边界，让限界上下文与团队自治对齐。

限界上下文的信号是"语义差异与边界"，它的划分要结合概念语义、业务能力与团队组织，让每个上下文有独立一致的模型。

• 可移植性的定义与价值
• 开放格式与标准
• 导出与互操作

数据可移植性（Data Portability）指用户或系统能够以标准、可互操作的方式导出自己的数据，并能在系统间迁移或复用。真实设计原则包括：一是使用开放、标准的数据格式（如 JSON、CSV、标准 schema、开放 API），避免私有格式锁死；二是提供明确的导出接口与充分的数据范围，让用户能拿到完整数据（而非缺失拼凑）；三是保证数据在全量导出、可重复导出、时效与一致性上的可用性；四是关注跨系统互操作（schema 兼容、语义一致）。真实经验是：可移植性既是对用户权益的保障（尤其在监管如 GDPR 的数据可携权要求下），也是降低"供应商锁定"风险的手段。设计上应把"导出"作为一等公民功能，而非事后补救。

数据可移植性遵循"开放、标准、可互操作"原则，核心是让数据不被锁定、可迁移，既是合规要求也是工程设计。

• 数据网格的理念
• 组织与平台挑战
• 渐进式落地

数据网格（Data Mesh）的真实落地难度主要体现在"组织与工程的双重挑战"：它在理念上主张"数据按业务域分布自治 + 数据产品化 + 自助式数据平台 + 联邦计算治理"，愿景美好，但落地很困难。真实的难度包括：一是组织变革难——需要业务团队真正承担数据产品所有权并具备数据能力，这往往与现有团队结构与技能不匹配；二是平台建设成本高——需要搭建自助式数据平台提供数据接入、治理、消费能力，否则"域自治"无从谈起；三是治理难——联邦治理要在"自治"与"统一标准"间平衡，容易陷入混乱或过度集权。真实经验是：数据网格应"渐进式"引入，从数据产品化、明确域 owner 等较轻的实践起步，先解决"数据无人负责"的问题，再逐步扩展，而非一步到位推行全量数据网格。

数据网格的落地难度本质是"组织与治理变革"，远超纯技术问题，需渐进式地从数据产品化与域 ownership 起步。