数据产品 · 设计原则
六年前，我写过一篇文章，聊数据看板的设计原则。
那篇文章列了十条：必要性、准确性、全面性、洞察性、故事性、便捷性、及时性、稳定性、可扩展性、边界性。回过头看，框架意识是有的，但视野太窄——只盯着"看板"这一个产品形态。
六年过去，行业发生了结构性变化。
AI让数据产品拥有了"对话"能力；指标平台把口径治理从看板里抽出来，变成了独立的基础设施；嵌入式分析让数据不再是一个独立页面，而是长在业务流程里；实时流计算把 T+1 的惯性打碎了。数据产品，早已不只是"看板"。
所以这篇文章，我做一次系统性的升级：针对原来的十条原则，阐述一些新的理解。
一、必要性：从"简洁"到"价值定义"
原文说："谨记奥卡姆剃刀准则。"
这话今天依然对。但六年实践下来，我发现"简洁"只是表象，底下真正的问题是：你定义的价值，经不经得起检验。
一个数据产品该不该做、该做到什么程度，取决于三个问题是否回答清楚：
第一，服务于什么决策？
数据产品的终极客户不是"看数据的人"，而是"需要做决策的人"。一个看板每天有500人访问，但如果没人因为看了它而改变了行动，那它就是一个信息摆设。设计数据产品的第一步，是明确："用户看了之后，能做出什么他本来做不出的决策？"
第二，核心用户是谁，边界在哪？
原文也提了"核心用户"，但六年里我见过太多失败案例，死因不是技术，是定位模糊——既想给高管看概览，又想给运营看明细，还想给分析师做下钻，结果三端都不满意。好的数据产品，敢于说"我不服务谁"。
第三，生命周期怎么管？
原文提了"迭代规划"，但在今天更重要的是：数据产品也有"产品生命周期"。一个临时性的活动看板，和一套长期运营的指标体系，设计原则、技术架构、维护成本完全不同。在立项时就要想清楚：这是一次性的，还是长期的？如果是长期的，谁来持续维护？
名词解释｜PMF（Product-Market Fit）：产品-市场匹配。指产品恰好满足了一个真实存在的市场需求。数据产品同样需要验证PMF：你的数据产品是否真正解决了用户的决策痛点，而不是"做出来好看但没人用"。
微观层面，原文说的"不要为炫技而复杂化"仍然成立。但今天要加一条：不要为"AI化"而AI化。
过去两年，太多产品加了一个"AI助手"对话框，但用户问了两个问题就发现答非所问，反而拉低了体验。如果一个对话式入口不能比原来的筛选器更快地拿到答案，那就不要加。
二、准确性：从"数据质量"到"语义一致性"
原文说："数据质量是第一要求。"六年后的今天，这句话没错，但"数据质量"的含义变了。
过去，数据质量主要指"数值对不对"——ETL有没有跑成功，有没有丢数据。今天，更大的挑战是**"语义一致性"**：同一个指标，不同团队算出来的数不一样。
"GMV"这个指标，销售团队算的是含退款的，财务团队算的是不含退款的，运营团队算的是含优惠券面值的。三个团队三个数，每次开会先吵半小时"到底用谁的"。
这个问题的解法，行业在过去几年形成了一个明确的方向：指标平台（Metrics Platform）。
6年前在饿了么，当时我团队的PD和当时的数据开发同学一起，创造了指标管理平台OCEAN，搭配着当时覆盖全公司的数据治理项目；回过头来看真的是非常超前的产品，想想都替他们感到骄傲。当时拿着产品去找融资的我是碰了一鼻子灰，现在想来都心有不甘。
名词解释｜指标平台（Metrics Platform / Semantic Layer）：将指标定义从看板代码中抽离出来，统一管理在独立层的技术架构。所有下游应用（看板、报表、API、AI对话）共享同一套指标定义，确保"一个口径、处处一致"。
指标平台的核心价值是：指标定义集中管理，下游所有消费端（看板、报表、API、AI对话）调用的都是同一份口径。不是靠"约定"，而是靠"架构"来保证一致性。
今天要特别警惕AI生成数字的"幻觉"问题。
LLM 在做数据分析时，可能会"编造"一个看起来合理的数字——尤其在做同比、环比、趋势推断时。所以在AI驱动的数据产品中，所有LLM输出的数字，必须可追溯到底层SQL或指标API，不能让模型自由"生成"数值。这是准确性的新红线。
三、全面性：从"信息全"到"决策链路全"
原文说："信息呈现全面——量化信息、资讯信息、备注信息。"还举了股票软件的例子：数值呈现的同时，辅以行业、公司、宏观经济的资讯。
六年后来看：不再只是"信息叠加"，而是**"决策链路全覆盖"**。
一个好的数据产品，应该覆盖从"发现问题→诊断原因→制定方案→追踪效果"的完整决策链路：
**发现问题层：**异常检测、预警推送、指标异动监控。用户不需要每天打开看板巡逻，而是系统主动告诉他"哪个指标出了问题"。
名词解释｜异常检测（Anomaly Detection）：利用统计学方法或机器学习模型，自动识别数据中偏离正常模式的点或段。在数据产品中，用于自动发现指标异动（如日活突降、转化率异常升高），无需人工巡逻。现代方案多采用时间序列分解、Prophet、Isolation Forest等算法。
**诊断原因层：**下钻归因、相关性分析、根因定位。指标跌了，系统能不能自动告诉你"跌在哪里、谁导致的、是内因还是外因"？
**制定方案层：**策略推荐、AB测试设计、模拟预测。基于诊断结果，给出行动建议——这一层在今天最强有力的赋能来自LLM：它能基于数据上下文生成可执行的策略建议。
**追踪效果层：**策略上线后的效果回流、队列追踪、归因评估。做完决策之后，数据产品要能闭环——帮你看到"你上次的决策，效果怎么样"。
当时提到的"指标体系全面""量化方式全面""对比方式全面""统计周期全面""取样方式全面"，这五条仍然成立，但它们服务于上述决策链路——不是为全而全，而是每个环节的信息都要够用，让用户无需离开产品去拼凑信息。
四、洞察性：从"多维下钻"到"AI增强洞察"
原文的洞察性，核心是"下钻和上卷""趋势观察""深度提炼""信号洞察"。
这些今天依然是基本功。但过去两年，行业发生了一个质变：LLM让"洞察"从用户驱动，变成了AI驱动。
过去，洞察是这样的：用户看到一个数字异常 → 自己判断该下钻哪个维度 → 手动筛选 → 自己归纳结论。整个过程依赖用户的分析经验。经验丰富的人能挖到三层以下，经验不够的人看一眼就走了。
今天，AI可以把这个过程自动化：
系统检测到指标异动 → 自动执行多维归因（按渠道、地域、时间等维度自动下钻）→ LLM基于归因结果生成自然语言洞察（"转化率下降的主要原因是iOS端新用户的首单转化率下降23%，建议排查iOS端注册流程"）→ 推送给相关责任人。
这里面有一个关键的设计原则：AI洞察必须"可追溯、可验证"。
AI说"转化率下降原因是XX"，用户要能一键展开看到底层的SQL、数据明细、计算逻辑。不能是AI甩一个结论出来，用户只能信或不信。好的AI洞察，是"透明的"——你看得到它怎么算的，你不信可以自己验。
原文提到的"信号洞察"也升级了。过去的"信号"是阈值驱动的（跌破X就报警），今天的信号可以是机器学习驱动的——系统学会了"什么样的波动模式通常预示着问题"，不需要你提前设阈值。
五、故事性：从"分析路径"到"叙事自动化"
原文说："也可称为有'分析路径'。有体系，有对照，有顺序，有队列，有判别。"
这是十条原则里我最欣赏的一条——六年前的直觉很准。但今天，"故事性"有了全新的实现方式：LLM让数据叙事可以自动化生成。
原来的"故事性"，本质上依赖设计师预先规划好分析路径——先看什么、后看什么、什么情况下该跳转到哪里。这需要设计师对业务极度熟悉，而且一旦业务变化，路径就得重设。
今天，LLM可以做到：
**动态叙事生成。**同一个数据集，给CEO看是一套叙事（聚焦战略指标、趋势判断、风险信号），给运营看是另一套叙事（聚焦执行指标、异动归因、行动建议）。叙事路径不再写死在产品里，而是根据用户的角色和意图动态生成。
**自然语言报告。**日报、周报、月报——这些过去靠人写的"数据故事"，现在可以由AI基于数据自动生成。但它必须严格基于已验证的查询结果，不能自由发挥。
**对话式探索。**用户不再需要懂"怎么用看板"，而是直接用自然语言问："上周华东区销售为什么跌了？"系统自动完成查询、下钻、归因，用一段话回答你。
名词解释｜NL2SQL（Natural Language to SQL）：将自然语言自动转换为数据库查询语句的技术。用户说"上个月华东区销售额是多少"，系统自动生成对应的SQL查询并返回结果。LLM大幅提升了NL2SQL的准确率，使其从实验室走向生产环境，成为对话式数据产品的核心能力。
原文的五个"有"（有体系、有对照、有顺序、有队列、有判别）都还成立，但今天的升级是：**这些不再依赖人手工设计，而是AI根据数据上下文和用户意图动态编织。**设计原则从"设计好一条路"变成了"设计好一个能生成路的引擎"。
六、便捷性：从"最短路径"到"嵌入式+对话式"
原文说："让用户以最短的时间获得必要信息。以最少的步骤拿到结果。"
六年前的"便捷"，优化的是"在数据产品内部的操作路径"——减少点击次数、减少筛选步骤。今天的"便捷"，发生了范式转换：最好的数据产品，是用户根本不需要"打开"它的。
这叫嵌入式分析（Embedded Analytics）。
名词解释｜嵌入式分析（Embedded Analytics）：将数据能力直接集成到业务系统的操作流程中，而非作为独立工具存在。例如：CRM里直接看到客户健康度评分，运营后台里直接看到活动实时ROI，不需要切换到另一个BI系统。核心理念："数据在决策发生的地方"。
用户在做业务决策的地方，数据就在那里——不需要切到另一个系统去查。这比任何"看板内交互优化"都更便捷，因为它消灭了"打开数据产品"这个动作本身。
第二个范式变化是对话式交互。用户不需要学怎么用筛选器、怎么选维度、怎么配图表，直接说人话："帮我看看上个月哪个渠道的获客成本涨了最多。"系统理解意图、执行查询、返回结果。
但这里有一个设计陷阱要警惕：对话式不等于万能。
对于高频、标准化的查询（如每日核心指标概览），固定看板比对话更快——一眼扫完，不用打字。对话式交互的定位应该是：覆盖长尾的、非标准的、临时的分析需求，而不是替代所有固定报表。
原文提到的"多渠道覆盖"（PC端、移动端、信息push）也升级了。今天的推送不只是"发个通知"，而是主动推送洞察——不是告诉你"DAU跌了，自己去看"，而是直接推送"DAU跌了3.2%，主要原因是iOS端新用户留存下降，已生成归因报告，点击查看"。
七、及时性：从"T+1够用"到"实时+事件驱动"
原文说："及时并不意味着数据都要实时。时滞的匹配很重要。"
这句话在今天依然正确，但行业的"时滞基准线"已经大幅前移了。
六年前，大部分看板是 T+1 的——今天看昨天的数据，大家觉得正常。今天，如果你做一个电商大促活动看板还是T+1，运营会疯。实时流计算已经从"高端能力"变成了"基础要求"。
但原文的核心洞察——"时滞的匹配"——仍然是最重要的设计原则。不是所有数据都需要实时，关键是数据的及时性要匹配业务决策的时效性。
战略层的指标（如市场份额、用户满意度），月度更新就够了，强行做实时是浪费。战术层的指标（如活动ROI、转化漏斗），需要小时级。执行层的指标（如大促GMV、库存水位），需要秒级。
今天新增的一个维度是事件驱动。不再是"每隔5分钟刷一次"，而是"有事件发生时才推送"。用户完成了一笔高额订单、某项指标跌破阈值、系统检测到异常模式——这些"事件"触发数据的主动推送，而不是被动等待用户来查。
原文提的"迭代及时"也升级了。今天的数据产品迭代，不只是"加需求、排期、上线"的传统节奏，还可以通过**特性开关（Feature Toggle）**做灰度发布——新功能先给一小部分用户用，验证效果再全量。数据产品本身也应该是数据驱动的：用使用数据来指导产品的迭代优先级。
八、稳定性：从"系统稳定"到"架构韧性"
原文提了四条：数据质量稳定、产品可用性稳定、架构稳定、团队稳定。
前两条不变。第三条"架构稳定"在今天有了全新的含义。
六年前的"架构稳定"，是说系统改起来别太伤筋动骨。今天的含义是：在技术栈快速迭代的环境下，架构要有"韧性"（Resilience）——不是不变，而是能吸收变化。
具体来说，过去六年的行业实践形成了几个共识：
解耦的分层架构。数据采集层、存储层、计算层、指标层、消费层，各层独立演进。换一个BI工具，不应该影响底层数仓；换一个计算引擎，不应该影响指标定义。这叫可组合数据架构（Composable Data Architecture）。
名词解释｜可组合数据架构（Composable Data Architecture）：将数据系统拆分为独立、可替换的模块化组件，各层通过标准接口连接。核心理念：不绑定单一厂商的全家桶，每个环节可以独立选型和替换。与传统的"大一统平台"思路相对，更适合技术快速迭代的环境。
**数据可观测性（Data Observability）。**不只是"管道跑没跑成功"，而是对数据的完整性、新鲜度、分布变化、模式变更做全方位监控。一个字段突然多了30%空值，系统自动报警，而不是等用户发现数据不对了才回头查。
名词解释｜数据可观测性（Data Observability）：借鉴软件工程中"可观测性"概念，对数据管道和数据质量进行持续、自动化的监控。覆盖五个维度：新鲜度（数据是否按时更新）、分布（数值分布是否异常）、量级（数据量是否突变）、模式（表结构是否变更）、血缘（数据来源可追溯）。
**数据SLA（Service Level Agreement）。**像软件服务一样，数据产品也要有服务等级协议：数据几点前更新完？可用性99.9%还是99%？查询响应时间P99是多少？把"数据稳不稳定"从模糊感觉变成可量化的承诺。
原文的第四条"团队稳定"——在今天的流动环境下，靠人留不住，要靠知识沉淀。指标口径文档化、数据血缘可追溯、架构决策有记录，这样换人了知识不丢。
九、可扩展性：从"功能扩展"到"平台化+生态"
原文说："功能具备扩展性，可以适配更多场景。产品有嵌入性，能够与其他产品融合。"
六年前的视野是"产品自身的功能扩展"。今天的视野应该更大：数据产品应该成为"平台"，让生态来扩展。
具体有三个层次：
**第一层：API优先。**所有的指标、维度、查询能力，都应该有API暴露出来。不只是给内部看板用，而是任何系统、任何AI Agent都可以调用。这是"数据即服务（Data as a Service）"的基础。
**第二层：Headless BI。**把"数据能力"和"展示层"解耦。数据能力（指标定义、查询引擎、权限管控）是后端服务，展示层（看板、报表、对话界面、嵌入式组件）是前端消费者。换展示层不影响后端，加新的展示形态不影响数据能力。
名词解释｜Headless BI："无头BI"，即BI系统的数据层（指标定义、查询引擎、权限管理）与展示层（图表、看板、交互界面）分离。数据能力通过API提供，前端展示可以是任何形态：传统看板、嵌入式组件、对话界面、甚至AI Agent。核心价值：数据能力一次建设，多形态消费。
**第三层：数据市场（Data Marketplace）。**让数据产品的消费者不只是"用数据"，还能"发现数据"——有什么数据可用、数据质量如何、怎么申请权限。这把数据产品从"我给你做什么你就用什么"变成"你自己来找你需要的"。
AI Agent 时代的扩展性还有一个新维度：你的数据产品能不能被Agent调用？
未来会有越来越多的"数据Agent"——它们自动在不同系统间跳转，收集数据、执行分析、生成报告。你的数据产品如果只有人用的界面、没有Agent可调用的接口，就等于把自己排除在了AI驱动的工作流之外。
十、边界性：从"定位清晰"到"AI边界与伦理"
原文说："产品要有明确的定位，核心用户有边界，不能大而全却没有重点。"
这条在AI时代变得更加重要，也变得更加复杂。因为AI的引入模糊了很多边界。
第一个边界：AI决策的边界。
数据产品从"看数据"进化到"给建议"，再进化到"自动执行"——这条路上，每走一步都要问：这一步该AI做，还是该人做？
好的设计原则是：**低风险、高频、标准化的决策，可以交给AI自动化；高风险、低频、非标的决策，AI提供辅助但最终由人拍板。**自动调广告预算的阈值可以AI定，但关不关一个业务线，不能AI说了算。
第二个边界：数据的边界。
什么数据该采集、什么数据不该用、用户有没有授权、数据脱敏做到什么程度——这不是"合规问题"而是"产品设计问题"。在数据产品的设计阶段就要想清楚边界，而不是上线后被审计才发现问题。
名词解释｜隐私计算（Privacy-Preserving Computation）：在"数据可用不可见"的前提下完成数据分析与计算的技术体系。包括：联邦学习（数据不动模型动）、差分隐私（在数据中加入噪声以保护个体）、安全多方计算（多方协作计算但各方数据互不可见）等。在数据产品中用于"用数据但不暴露数据"的合规场景。
第三个边界：AI能力的边界。
LLM擅长什么、不擅长什么，设计者必须清楚。LLM擅长：自然语言理解与生成、结构化数据解读、模式识别、代码生成。LLM不擅长：精确数学计算（容易幻觉）、实时信息（受训练数据截止限制）、因果推理（擅长相关但不懂因果）。
好的数据产品设计，是让AI做它擅长的，让确定性系统做它不擅长的。精确数值交给SQL引擎，自然语言解读交给LLM，两者协作而不是互相替代。
写在最后
六年前写那篇文章的时候，数据看板还是数据产品的主形态。今天，看板只是数据产品的一个子集——对话式助手、嵌入式组件、指标平台、自动化Agent，都在争夺"数据消费入口"的位置。
但十条原则的底层逻辑没有变：
必要性管的是"该不该做"，准确性管的是"数据对不对"，全面性管的是"信息够不够"，洞察性管的是"能不能看深"，故事性管的是"有没有逻辑"，便捷性管的是"用着顺不顺"，及时性管的是"够不够新"，稳定性管的是"靠不靠谱"，可扩展性管的是"能不能长大"，边界性管的是"该不该到此为止"。
变化的是每条原则的实现方式。不变的是：数据产品的终极使命，是让正确的信息，在正确的时刻，以正确的方式，到达需要做决策的人手中。