当分析工作从三天压缩到五分钟，关键不在于AI取代人，而在于把口径标准沉淀为可复用的资产。本文作者以产品经理视角，分享如何通过线下共识、项目宪法和四层资产架构，将数据分析流程Agent化，实现结论一致性与可追溯性。

一个人三天，五分钟

以前，关于对业绩达成评价的放款指标分析工作，都是散在各个关联团队里，由各个团队专门的分析角色负责：一个人，一轮周度分析，从准备数据到分析，再到验证后出结论，前前后后大概要三天。大家关注点不一样，各个团队的结论差异往往还要在汇报当天掰扯半天，才能对齐。

现在集中到一个人身上：我统一收口跑分析 Agent，五分钟出一致性结论。

从每团队投入三人天到集中五分钟，不是因为我更快或更权威。那三天本来就不是花在分析上——花在前置动作上：不同源数据抽取、逻辑自洽性验证、口径维度拉齐、结论修饰和建议组装，每周基本从零开始，力气全砸在不同视角下对「标准要归一」的重复劳动上。现在这些前置动作资产化了：标准一旦确立，初始数据验证完成，后续的周度分析就是按部就班的输出。人只需要看结论、做判断。

我做的，其实是把自己日常用的一套数据分析方法论，沉淀成一个可执行的套件：一套工作流、一套规范、一套可沉淀复用的资产，可以架在任何大模型上。它干的事，是把已知的分析流程嵌进 Agent 的执行里——每一步都有固定规程，每一步都有围栏，不是让模型自由探索。这是一次把分析工作 Agent 化的 PM 实践。但重点不在 Agent 化本身，而在于统一口径标准。

口径，就是一个指标的计算规则——分子是什么，分母是什么，哪些场景计入，哪些剔除。同一个「放款成功率」，在两个人嘴里可能是两个完全不同的公式。业界给这种「唯一正确的参照」起了个名字，叫 Ground Truth（简称 GT，可以理解为标准口径基线）。我做的，说到底就是两件事：先联合各方达成一致意见，再把放款分析的 GT 交到 Agent 手里。

所以我的第一步是先大事开小会——线下对齐。

资产之前，是共识

这一步为什么重要？得从一个场景说起。

构建这套的真实元动机主要还是因为每次经营分析会上，老板对指标变化质疑时，大家各执一词时的反应（懂得都懂）。我见过内部数据报表平台的现状：同一个指标，在不同部门的报表里口径不一样，结论自然各说各话。大家各自拿出刻度不一的尺子，用它量出来的同一个东西，精度再高，也不过是把真实的答案淹没在度量衡不统一的噪音里。

我自己作为产品团队负责人，本身就关注这些业绩指标，面对频繁的汇报需求，单纯靠人工来完成分析工作确实也会占用不少精力，所以为什么不尝试自动化呢。但从第一天有这个构想开始，我就把它当一个产品项目来做——还是打算把这个产品作为隐性知识 Agent 化的一个案例，尤其是作为日常经营决策的基础设施来内部推广。不过在那之前，得先把尺子统一，否则自动化只会加速产出不一致的结论。

我把指标关联的兄弟部门都拉到一起，当面确认两件事。一是口径本身——分子分母怎么算，大家得认账；二是更重要的，哪些部门能左右这个指标的变化。目标和权责要对齐：放款成功率下降，如果是资方临时调整风控策略，资金团队出面解决合作关系；放款失败，如果是客户银行卡异常，产品运营团队设计引导换卡流程。

为什么要做这个？因为分析 Agent 跑出来的是「发生了什么」「哪里变了」，而「谁来处理」，数据里算不出来。这层共识不对齐，报告做得再细，也是一堆没人认领的数字。

共识达成之后，分析方案反而灵活了：按周、按天，看趋势、看归因，都可以调。因为口径锁死了，谁跑、什么时候跑，结论都一致。

拿着这份跟各部门线下对齐的方案，最终我说服了经营分析团队和老板。

但共识只存在于会议纪要里可不行。要让 Agent 每次都照着共识来，得把它写成文件。

动手之前，先写宪法

所以老规矩，第一件事上来还是直接立项目宪法：这个项目服务的目标是什么，项目规范有哪些，AI 的角色是什么，什么能做，什么不能做。

宪法管的东西可能有点反直觉：它管操作可预期，不管分析对不对。对不对由人判断；可预期性机器能自检：文件存在哪、怎么命名、脚本执行时带什么元数据，全都留痕。出了问题能追溯，而不是「AI 自己觉得对了」。

具体形态借用了 Claude Code 的规则文件机制：一份主宪法文件，加五份规则文件，按路径自动加载。写 SQL 时，SQL 安全规则自动生效——不许 select *，不许全库扫描，先聚合再明细；写脚本时，数据查询规则生效——大结果集落盘或摘要化，不往模型上下文里硬塞；写文档时，命名规则生效——final-final.py、最新版.md、0423final.sql 这类名字直接禁掉。命名不稳定，资产基本等于白沉淀。但也不是啥都值得沉淀，宪法里还有一条规矩：不把一次性内容伪装成长期资产，临时结论不进正式资产目录，除非明确要求沉淀。

宪法定完，套件的骨架自然长出来了，一共四层资产：

一次周度分析，是怎么跑起来的

而有了骨架后，这套套件的工作目录长什么样、一次分析是怎么跑的？拿一轮周度分析从头走一遍。目录长这样：

数据分析/

├── CLAUDE.md # 项目宪法

├── .claude/rules/ # 五份规则文件，按路径自动加载

├── docs/

│ ├── metrics/ # 维度文档，口径唯一来源

│ ├── playbooks/ # 分析方案、执行说明、结论、精华汇报

│ └── governance/ # 目录归类规则

├── sql/ # 可复用 SQL

├── scripts/

│ ├── analyze-*.py # 分析脚本，每轮分析一个

│ └── check-*.py # 一致性校验脚本

├── prompts/ # Prompt 资产

├── templates/ # 汇报模板

├── examples/ # 填好的示例

└── data/

├── raw/ # 原始数据，保持原样不动

└── processed/ # 处理后数据与分析结果

每周一轮放款转化分析。第一步不是写 SQL，是翻 docs/playbooks/——这个主题的分析方案和执行说明早就沉淀在那儿，执行顺序写死了：先确定时间范围和枚举值，再跑大盘基线，然后资产结构单维、多维交叉下钻，再到资方节点漏斗，最后做影响归因。归因也不靠感觉，拆成两层：体量大拖累大盘的，是结构影响；转化率低拖累大盘的，是效率影响，分开说话。

连「本周」是哪一周，都不靠口头约定。方案里写死成「上上周六到上周五」的完整统计窗口；统计 T3 口径时，观测日还要再向前回推三天，避免把还没走完转化的申请混进结果。这些其实也是「白纸黑字」口径的一部分。

执行脚本放 scripts/，分两条线：analyze-* 管分析，check-* 管校验，专治「看不见的错」。命名诸如 analyze-{主题}-{日期}.py。每个脚本头上都顶着一段元数据：关联哪份分析方案、用哪个版本的维度文档、数据集是什么、输入输出在哪，一行都不能少。几周后跑的一个脚本，头部引用的仍是同一份方案、同一版维度文档——资产就是这么被复用的。这也是为什么报告里任何一个数字，往回追都能追到出处。

基础数据来自企业数据中台，通过 MCP（Model Context Protocol，Agent 连接外部工具与数据的标准协议，可以理解成「通用接口」）接入；大结果集一律落盘到 data/raw/ 或直接摘要化落盘到 data/processed，不往模型上下文里塞原始明细；本地 CSV 交给 DuckDB 算。

跑完，结论写回 {主题}-{日期}-结论.md，必须引用它出自哪份方案、哪版维度文档。最终交付物是精华汇报：核心结论 → 大盘环比 → 异常识别 → 结构归因 → 业务洞察 → 建议动作，固定闭环，最后附一页版可直接汇报话术（是的，连汇报会上怎么说都给你备好了）。

整条链路，在仓库宪法里就是一句话：维度文档 → 分析方案 → 分析脚本 → 分析结论。Agent 跑流程，资产管口径。

链路一眼能看明白。但跑通了不等于跑对了：我后来踩的坑，是藏在这链路背后的机制问题。

维度文档：最危险的是「写了但没接上」

口径资产长什么样？我的维度文档两百多行，登记了六十多个指标、二十多个分析维度：每个指标写清楚来自哪个数据集、哪个字段、字段什么含义；每个衍生比率都给出计算公式。另有一节专门写口径注意事项，外加基础数据集的映射关系——查数之前，先搞清楚该找哪个源头。

举个例子，注意事项里有这么几条：有的数据集只保留天级的滚动窗口，查询前要先确认日期覆盖，否则取到的数不全；有的金额字段单位是万元，跟别的数据集联动前不统一单位，就会犯量级错误；源头甚至有两个字段名字相近、拼法不一，不写明映射，按「正确」拼写去查永远查不到。这些规则看着琐碎，每一条背后都是实际磕过的坑。没有它们，Agent 踩不踩坑纯靠运气。

准确率也不是只有我踩过的坑。爱分析的《2026 Data+AI 厂商全景报告》已经把 Data Agent 正式纳入全景图；凤凰科技的报告、Tellius 这类厂商自产的评测，结论也一致——准确率是企业落地的核心门槛。但到底卡在哪？很多人的第一反应是模型不够强。我踩出来的答案不太一样：多数时候不是模型不聪明，是没人告诉它指标该怎么算。

报告大多停在点出症状。我做完整套东西后，把口径标准总结成三种状态：第一种，没有标准，全靠感觉；第二种，标准写了，但没接上——文档躺在某个角落，Agent 分析时根本不知道它存在；第三种，真正接上了，Agent 每一步都依据它。

最危险的是第二种。第一种至少知道自己没标准，会去找；第二种是你以为自己有了，实际上什么都没生效。

从「写了」到「接上」，我的做法是三个声明：在宪法里声明这份维度文档是唯一口径源，任何分析必须先从它取口径；写进工作流规则，分析方案里的维度必须来自维度文档，禁止直接定义未登记的衍生指标；再落到元数据留痕，每个分析脚本的文件头，必须写清楚关联哪份分析方案、哪个版本的维度文档。

没什么高深工程。但从那以后，Agent 的每个数字都有出处。

如果说项目宪法管 AI 怎么操作，这份维度文档管的就是数字按什么标准算——它是这个业务的「口径宪法」。

口径写了不等于用上。准确率的命门不在模型聪不聪明，而在标准有没有真正接进执行链路。

口径漂移：牵一发而动全身

以为写完维度文档就完事了？我也以为。然后就踩了这个项目里最难察觉的坑。

贷中二次风控后的放款成功率，口径原本明确且相对稳定。后来业务新增了两类场景——一类虚增了分母，成功率显著下降；另一类虚增了分子，曲线呈现虚假繁荣。

这两类变化不触发任何报错。SQL 照常跑，脚本照常出数，报告照常生成——只是数字悄悄变了味。脚本出错好歹会叫——异常抛出来，有人去处理；口径出错是不出声的，恰恰因为一切运行正常，你连怀疑的机会都没有。源头动一寸，下游全漂一尺。

分母一变，后面所有基于它算出来的东西——资方排序、节点归因、环比对比——全部跟着漂。你看到的是业务波动，其实是尺子本身变了。

坑踩完，我补了两样东西。一样是给维度文档加上「变更与退出」条款：什么新场景要计入口径、什么时候旧场景要退出、谁来确认、如何留痕——口径是活的文档，不是纪念碑。另一样是一组一致性校验脚本：比如其中一个专门核对分母——同一天、同一场景、同一金额分层、同一定价下，二次风控通过金额在各资方之间应该对得上；对不上，就是数据或口径出了问题，先拦住再说。就是前面说的那排 check-*，专治这种「看不见的错」。

这背后是一条架构原则：要精确的交给脚本，要理解的交给大模型。分母对不对齐，是零容差的事，别让模型猜；数字为什么降了，是推理的事，交给模型发挥。脚本出错是 Bug，可复现可修复；模型出错是 Bad Case，走归因治理。两类失败分开走，出了问题不扯皮。

维度文档不是一劳永逸的宪法，而是跟着业务漂移同步更新的活文档。

AI 给的洞察，可能是废话

文档活了，口径有人盯了，看起来可以松口气。但说实话，还有一层我没法打包票，也是这套东西挺尴尬的一个边界。

分析结论里的数字基于真实数据，可以反复核验；但业务洞察那一栏是另一回事——基本都是 AI 根据有限数据推论出来的：每句听着都在理，真去追，又哪句都验证不了、证伪不了，可能全是废话。

举个例子，有段时间放款规模和成功率双双下降。AI 的洞察给出的归因，要么是资方收紧风控，要么是系统链路异常。听起来都挺像那么回事。实际原因，是阶段性的市场波动，和公司战略打法转向。

这两样，都不写在数据表里。

仅凭数据没办法完全还原真相。AI 看到的只是业务留在数据表面的结果，而业务为什么这么做——策略变了、合作变了、市场变了——它一概看不到。根因很明确：套件还没接入企业知识库，缺上下文输入，也缺少必要的其他非数字化数据的支撑。

数据是业务的脚印，但脚印不是业务本身。

所以这套东西的边界很清楚：它解决「把可信的数字高效跑出来」，不解决「替人做判断」。接入企业知识库，让 AI 看到数据之外的业务上下文，是我还想做的下一步。

哪些照搬，哪些重建

如果你也想给自己的业务做一套，方法论直接照抄：宪法先行的顺序、四层资产结构、精确交给脚本理解交给模型的分工、变更与校验机制——这些和行业无关。跨行业要调整的，只有数据接入这一环：通过 MCP 接入企业内部数据中台，拿到基础数据。

不可复制的只有一件事：定义你自己行业和领域的分析维度、指标和口径。那是你业务的 GT，没人替你写得出来。

这一路走下来，我从头到尾做的就是两件事：先让所有人认同一把尺子，再把这把尺子沉淀成一个可执行套件——一套工作流、一套规范、一套可沉淀复用的资产。模型年年换，套件越攒越值钱。

模型谁都能调用，口径只能在自己的业务里长出来。

如果你也想把手头的分析工作 Agent 化，我的建议是别从选模型开始。先把你的第一份维度文档写出来。

参考：

1. 爱分析《2026 Data+AI 厂商全景报告》：在线阅读，官网报告入口：https://ifenxi.com/research/report
2. 凤凰网科技《2026 年 3 月 Data Agent 产品：从技术能力到落地效果》：原文链接
3. Tellius《AI Analytics Platforms 2026: 12 Tools Compared》：厂商报告（注：系厂商自产内容，仅作厂商视角参考）