构建 AI-Ready 数据组织：从需求到交付的全流程最佳实践

摘要：本文围绕指标口径不一致、需求表达模糊和跨团队交付效率不足等问题，介绍构建 AI-Ready 数据组织的四步实践路径：统一指标与数据资产定义、结构化需求表达、通过 Data Agent 辅助开发准备，以及将质量保障融入开发和运行流程。通过明确业务方、数据分析师、开发与测试人员的职责及协作方式，为企业减少沟通与返工成本、提升数据交付效率与可信度提供实践参考。

一、背景：数据团队面临的三重压力

在过去几年里，越来越多的企业数据团队开始感受到一种共同的困境——数据越来越多，但真正能驱动决策的价值却越来越难以释放。这种困境背后，有三层相互叠加的压力。

第一层：内部协作的摩擦成本居高不下。 在典型的数据项目中，业务方提出需求、数据分析师转译、数据开发实现，这条链路上的每一次交接都是一次语义损耗。”日活”到底是自然日还是过去 24 小时？”转化率”的分母是曝光用户还是点击用户？这类争议在每个团队里反复发生，耗费大量对齐成本，却没有任何业务价值产出。

第二层：组织的数字化转型要求更快的数据响应速度。 业务决策的窗口越来越短，但数据需求从提出到上线的周期往往以周甚至以月计。这种速度不匹配，正在让数据团队从”业务加速器”变成”交付瓶颈”。

第三层：行业正在进入 AI-Ready 数据架构的新阶段。 从 Kimball 维度建模到 Medallion 湖仓架构，再到今天以 AI Agent 为核心的智能数据平台，架构范式的每一次演进都在重新定义数据团队的工作方式。那些没有完成语义层统一、流程规范化的团队，将很难享受到 AI 带来的生产力红利——因为 AI 也需要一个”干净”的工作环境。

本文将从典型问题的根因分析出发，系统介绍一套面向 AI-Ready 数据组织的流程框架，涵盖角色分工、需求澄清、指标治理、Data Agent 落地，以及开发交付全流程的质量保障体系。

[图 1]

二、两个典型问题：协作断层的根源

2.1 指标定义的持续争议

指标混乱是数据团队最常见的深层问题之一，通常以两种形式出现。

问题一：不确定什么该做成指标。 当有人说”我需要看一下用户数据”，这既可能是一个需要 ETL 处理的业务指标（如月活跃用户数 MAU），也可能只是一个原始字段（如 user_id）。两者在数据分层中的位置、开发方式、复用逻辑截然不同，但在需求沟通中往往被混为一谈。

问题二：指标漂移（Metric Drift）。 同一个指标名称，在不同报表、不同时期、不同团队口径下计算逻辑悄然发生变化，且没有变更记录。比如”退款率”，财务口径是退款金额/GMV，客服口径是退款订单数/总订单数——两者都叫”退款率”，但数字相差甚远，直到高管在一次周会上发现两张报表的数字对不上，才触发了一次代价高昂的排查。

2.1.1 解决这个问题的第一步，是建立清晰的概念边界

正确的分层设计应当是：字段层 → 指标层 → 应用层。只有当指标的口径、公式、周期被明确记录在数据资产目录中，并纳入变更审批流程，指标漂移才能被系统性地消除，而不是靠人肉排查来补救。

2.2 “一句话需求”困境

业务方的真实需求往往是这样表述的：”我要看各阶段的转化率，最好能按区域和产品线筛选。”

这句话对业务方来说已经足够清晰，但对数据开发团队来说，它缺少了几乎所有关键信息：转化率的分子分母是什么？各阶段指哪几个阶段？数据刷新频率是多少？如果数据源异常怎么处理？

比需求细节缺失更棘手的是，业务方可能连要看什么指标都没有明确，只提出“看一下用户数据”这样的笼统诉求。这时，识别和定义指标的工作通常落在分析师身上：分析师需要通过沟通理解业务方的意图，有时还要从现有数据湖出发，寻找可能有用的指标，再拿给业务方确认，逐步明确究竟要看什么。因此，在需求能够交给开发之前，分析师就可能已经在指标的探索、定义和反复确认上投入了大量时间。

这种”一句话需求”被直接带入开发环节后，通常会在交付验收阶段爆发——业务方发现做出来的东西”不对”，但也说不清楚哪里不对，最终陷入反复返工的循环。

三、组织形式与角色分工

在讨论解决方案之前，有必要先明确数据团队的组织结构，因为流程的落地依赖清晰的角色边界。

数据团队通常有三种典型的组织形式：中心化（Centralized）、去中心化（Decentralized） 和 联邦制（Federated）。

中心化模式统一管理，标准化强但响应速度慢；去中心化模式业务灵活但容易形成数据孤岛；联邦制在两者之间取得平衡，由中台提供平台能力和规范约束，各业务域保留自主开发权。

在引入 AI 能力后，联邦制架构的优势进一步放大——中台可以沉淀共性的 AI 工具链和数据规范，各 Domain 专注业务语义，通过 AI Agent 桥接两者。

当前阶段的核心角色与职责如下

四、分步推进：从混乱到 AI-Ready 的实践路径

理清了问题根源与角色分工，解题思路就变得清晰：不是一次性推倒重建，而是分四步逐层夯实。每一步都有独立的业务价值，也是下一步的前提条件。

4.1 第一步：统一语言 —— 给指标建立”户口”

前文提到，指标争议往往源于指标口径缺乏统一约定：同一个词在不同人口中指向不同的计算逻辑，却没有清晰的定义可供核对。因此，第一步是把每一个指标的定义写清楚，写到一个所有人都能查阅、共同认可的地方。

数据分析师需要牵头建立并维护三类数据资产目录：

• 业务数据资产目录：记录来自业务系统的源字段定义、数据类型与业务含义，由业务开发负责维护
• 模型数据资产目录：记录数仓各层的 ERD、物理表结构与分区策略，由数据分析师维护
• 指标数据资产目录：这是核心——记录每个指标的中英文名称、口径定义、计算公式、统计周期、数据来源与变更历史，由数据分析师维护

一个完整的指标定义条目应该是这样的：

指标名称：月活跃用户数（MAU）
口径定义：过去自然月内，至少发生 1 次有效 Session 事件的不重复 user_id 数量
计算公式：COUNT(DISTINCT user_id) WHERE event_date IN [月初, 月末] AND session_duration > 0
统计周期：自然月，UTC+8
数据来源：dwd_user_event_di
最近更新：2026-09-01，变更原因：新增 session_duration > 0 过滤条件，排除无效打开

这里有一点值得特别强调：指标不等于字段。user_id 是字段，是数据库表中的原子存储单元；”月活跃用户数”是指标，是基于字段的业务计算结果。两者在数仓分层中的位置、开发方式和复用逻辑截然不同。在需求沟通和方案设计时，清晰区分这两个概念，是避免”鸡同鸭讲”的基础。

正确的分层逻辑是：字段层（原始存储）→ 指标层（业务计算）→ 应用层（分析决策）。需求文档、报表设计和数据开发，都应该在同一套分层框架下对话。

有了资产目录之后，AI 可以在这一步发挥增量作用——通过 Amazon Bedrock 构建语义比对 Agent，自动扫描各 Domain 的指标定义，识别同名异义或异名同义的潜在冲突，生成差异对比报告，辅助数据分析师主导的口径拉齐会议。这将原本需要数天人工排查的工作压缩到分钟级，但人工判断和最终确认仍然是必须的——AI 负责发现问题，数据分析师负责裁决。

4.2 第二步：规范入口 —— 让需求在进入开发前就”说清楚”

语言统一之后，第二个断层在需求传递环节。第三章描述的每一个角色，在这个环节都有各自的责任边界：业务方（用户）负责写清楚”想要什么”，数据分析师负责转译成”能开发什么”。

业务方提交需求时，采用用户故事（User Story）格式，聚焦业务场景和收益，而非技术实现：

这个格式的价值在于，它迫使需求提出方说清楚”谁在用、用来干什么、为什么这么做”，而不是直接跳到”我要一张表”。

数据分析师收到需求后，需要承担“翻译官”的角色，通过沟通和示例演算，帮助业务方理解指标的计算方式，并确认所选指标是否符合本次业务需求。完成对齐后，再使用 EARS（Easy Approach to Requirements Syntax） 框架，将需求转化为可验证的规格。下文采用四类常用模式：

普遍型（Ubiquitous）—— 始终成立的规则，用来确定核心指标定义

事件驱动型（Event-Driven）—— 触发条件明确的规则，用来定义刷新与告警

状态驱动型（State-Driven）—— 系统在特定状态下的行为，用来定义边界场景

异常处理型（Unwanted）—— 不期望情况发生时的处理规则，用来消灭”隐性假设”

这套格式的核心价值在于：每一条 EARS 需求都是可验证的。测试工程师可以直接将其转化为测试用例，开发工程师可以据此设计异常处理逻辑——从需求到测试，不再需要”意会”。

4.3 第三步：智能衔接 —— 用 Data Agent 打通业务域与中台

前两步解决的是”说什么”的问题。第三步要解决的是”谁来做、怎么做”——尤其是在联邦制组织中，各业务 Domain 的数据分析师深谙业务语义，但未必熟悉中台的全部技术规范（命名约定、分区策略、安全标签、数据质量断言标准等）。将这部分规范知识的人工传递和逐条审查，替换为 Data Agent 自动执行，是这套体系中 AI 发挥最大作用的环节。

整体架构分为三层：业务域负责输入业务语义，Data Agent 负责规范落地与智能预处理，中台执行层负责最终的工程实现与运行监控。三层之间的协作关系如下图所示：

[图 2]

Data Agent 的核心工作流通过 Amazon Step Functions 状态机编排，依次执行五个动作：

1. 需求解析：通过 Amazon Bedrock 上的基础模型读取 EARS 需求文档，提取数据源表、输出指标、刷新频率和异常处理规则，形成结构化任务描述。
2. 规范校验：调用存储在 Amazon Bedrock Knowledge Bases 中的平台规范库，自动检查字段命名是否合规、数据源访问权限是否已授权、安全分类标签是否完整标注。
3. 代码生成：借助 Kiro CLI 生成 AWS Glue ETL 脚本草稿，并自动附加 Great Expectations 数据质量断言模板，覆盖主键唯一性、非空约束、值域范围等基础检查项。
4. 血缘影响分析：查询平台已采集的数据血缘关系，识别此次变更可能波及的下游报表和指标，并在需求单中自动附注影响范围。
5. 路由与通知：将代码草稿、规范检查报告、影响分析结果打包，通过 Amazon SNS 通知责任开发工程师进行人工复核，再进入正式开发流程。

这一步的意义，不是让 AI 替代数据开发，而是把规范传递的工作从”人找人确认”变成”Agent 自动预处理”，让开发工程师拿到的任务包从一开始就是符合中台规范的，大幅减少评审中发现的低层次问题。

4.4 第四步：质量内建 —— 让每个环节自带检验能力

前三步建立了从语义到需求再到开发任务的规范链路。第四步要保证这条链路的最终输出是可信的——不是靠验收时的人工抽查，而是让质量保障嵌入到每一个开发节点。

核心工具组合为三层：

• SQLFluff：SQL 代码风格与语法规范自动检查，集成在代码提交阶段（Pre-commit Hook），在代码进入评审前就完成基础规范校验
• Great Expectations（GX）：数据质量断言框架，由开发工程师在自测阶段生成断言报告，测试工程师复用断言模板库执行回归测试，覆盖全表全流程的完整性、准确性与一致性
• Amazon CloudWatch + Amazon EventBridge：生产环境的调度监控与数据质量告警，当分区数据量异常或指标同比突降时，自动触发 SNS 通知，进入标准化运维响应流程

五、开发与交付全流程

一个符合 AI-Ready 标准的数据项目，其完整交付流程分为两大阶段，核心原则是：前半段做正确的事（Do the Right Things），后半段把事情做正确（Do the Things Right）

5.1 需求与方案阶段

5.2 开发与交付阶段

① 技术方案评审：开发组长主导，重点评审数据模型合规性（主键唯一性、字段命名规范）、核心计算逻辑、性能可行性。提前发现架构设计缺陷，是这一环节最大的 ROI 所在。

② 研发自测：开发工程师完成 ETL 实现后，使用 Great Expectations 自动生成数据质量断言报告，覆盖数据完整性、格式标准化、业务规则准确性和异常数据处理。

③ 代码评审：开发组长重点审查 SQLFluff 规范合规性、断言覆盖率（全表全流程）、主外键与聚合逻辑、数据血缘一致性。

④ 测试人员测试：测试工程师从独立视角补充边界测试和异常场景，复用 GX 断言模板库执行回归自动化测试，输出测试报告和缺陷跟踪记录。

⑤ 产品验收（SAT）：产品经理基于自动化测试报告快速验收，重点关注业务指标准确性和报表数据一致性，减少手动核查工作量。

⑥ 业务验收（UAT）：业务方进行端到端的业务场景验证，确认数据口径与需求申请的一致性，完成需求申请单的交付确认。

⑦ 上线监控：全员共同负责生产环境的稳定性。通过 Amazon CloudWatch Dashboard 持续监控 ETL 调度状态、数据质量指标和业务关键指标，通过 Amazon EventBridge 规则触发 SNS 告警（如分区数据量异常、指标同比突降等），建立标准化的运维响应 Runbook。

六、总结

构建 AI-Ready 数据组织，并不是一次单纯的技术升级，而是一次流程、角色与工具的整体重构。本文所介绍的框架，可以概括为四个递进的层次：

1. 概念对齐：通过指标/字段的清晰分层和规范化资产目录，消除语义模糊带来的协作摩擦
2. 需求结构化：通过 EARS 框架将”一句话需求”转化为可验证的规格，让每一条需求都能被测试
3. AI 增强协作：通过 Strands Agents 构建 Data Agent，并利用 Amazon Bedrock AgentCore 部署运行，将平台规范的落地从人工传递转变为智能自动化
4. 全流程质量内建：通过 SQLFluff、Great Expectations 与 AWS 监控服务的组合，将质量保障从事后检验前移到每一个开发环节

这套框架不预设组织规模和技术成熟度，可以按模块独立落地：从规范指标资产目录开始，再引入 EARS 需求流程，最后逐步构建 Data Agent 能力——每一步都有独立的业务价值，也都是下一步的基础。

➡️ 下一步行动：

相关产品：

• Amazon Bedrock — 用于构建生成式人工智能应用程序和 Agent 的端到端平台
• Amazon EventBridge — 大规模构建事件驱动应用程序
• Amazon SNS — 发布/订阅和推送通知
• Amazon Step Functions — 分布式应用程序的可视工作流
• Amazon Bedrock AgentCore — 加快 Agent 投入生产的速度

相关文章：

• AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第四篇
• Add web search and browsing to your agents with Amazon Bedrock AgentCore
• Habby 游戏借助 AWS DevOps Agent 实现智能运维最佳实践
• Data for AI：明其所耗，知其所因！让每一分 Token 消耗都可量化的全栈实践
• 从自建 Elasticsearch 迁移到 Amazon OpenSearch Service 实践（二）：向量索引迁移与 Amazon Bedrock 集成

七、参考资料

1. Modern Data Architecture Rationales on AWS
2. Evolving Data Architectures: From Kimball to Medallion to AI-Ready Platforms
3. Dimensional Modeling Techniques — Kimball Group
4. Great Expectations — 开源数据质量框架
5. Easy Approach to Requirements Syntax (EARS)
6. Strands Agents
7. Amazon Bedrock AgentCore
8. AWS Step Functions — 工作流编排

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用