BI 平台里最容易被误判为“已经完成”的工作，往往是仪表盘页面已经上线：图表齐全、颜色统一、筛选项也能点击，但业务负责人仍要回到表格里核数，开会时还要先确认“这个指标到底怎么算”。这类问题通常不是图表画得不够漂亮，而是需求、口径、数据和使用任务没有连成一条可验证的流程。本文从业务问题出发，拆解 BI 平台从需求梳理到仪表盘验收、运营迭代的完整路径，并用一个明确标注为情景模拟的销售经营案例说明如何落地。
我判断一个 BI 项目是否设计到位，不先看图表数量，也不先看首页是否足够“丰富”，而是先问：目标用户进入页面后，要回答什么问题？回答之后准备采取什么动作？如果这两个问题说不清，页面再完整，也可能只是把原有报表搬进了新工具。
一条可用的 BI 流程，通常包含业务问题、目标用户、指标定义、数据准备、分析模型、仪表盘呈现、权限与交互、任务验收和持续维护。它们不是彼此独立的模块，而是前后相依的工作链：前面把指标定义错了，后面的图表只会更快、更直观地展示错误。
本文的核心判断是：仪表盘质量，取决于它能否帮助特定用户完成特定决策任务，而不是页面上有多少张图。因此，设计顺序应当是先明确业务任务，再确认指标和数据，最后决定图表与布局。
把目标用户放到页面前，给他一个真实任务，例如“找出本月业绩下滑最明显的区域，并判断主要变化来自订单量还是客单价”。如果他必须切换多个页面、导出数据、自己重新计算，或者无法确认口径，那么问题就不只是视觉层级，而是整个分析链路还没有闭合。
我建议在项目立项时写出一句可验证的交付目标：例如“区域负责人能在一张页面中查看月度目标完成情况，并按区域和产品定位主要差异”。这比“建设销售驾驶舱”更具体，因为它说明了用户、任务、范围和判断对象。
下面的流程完成率是情景模拟，用于说明需求信息逐步明确后，哪些设计输入会变得可执行，不代表行业基准或任何平台的真实项目数据。
管理者、分析人员和一线业务人员看数据的目的通常不同。管理者需要快速识别整体状态和需要关注的异常；分析人员需要拆解原因、做对比和追查变化；一线人员则更关心与自己负责的任务直接相关的信息。把三类需求未经筛选地叠加到一页，往往会得到一张谁都能找到一点内容、但谁都不容易完成任务的页面。
这不是说每个角色都必须拥有完全独立的仪表盘，而是要明确页面的信息层级和访问路径。总览页优先回答“现在是什么状态”，分析页帮助回答“变化发生在哪里”，明细页再处理“具体是哪条记录”。如果用户必须在总览页直接看见所有明细，页面就很容易变成密集的数据墙。
“销售额”听起来简单，但它可能按下单时间、支付时间或发货时间统计，也可能包含或排除退款、取消订单、税费和内部订单。不同团队若使用各自的定义，同一个名称就会对应不同数字。仪表盘上线后才讨论口径，通常会把数据争议误认为系统错误。
我会要求关键指标至少写清业务含义、计算逻辑、时间口径、统计对象、数据来源、刷新周期和负责人。并非每个次要字段都要经过复杂治理，但核心指标必须有一个可以追溯的定义位置。只把公式写在开发者脑中，不能算完成指标管理。
实时数据并不总是更有价值。若销售团队每天上午开经营会，数据在会前稳定刷新，小时级更新可能已经足够；若库存团队需要处理短周期缺货风险，较长刷新延迟就可能影响行动。应先明确决策时间窗，再评估数据链路能否支持，而不是先承诺“实时”。
仪表盘还应显示更新时间或统计截止时间。用户看到一个数值，却不知道它对应昨天、两小时前还是上周，很难判断是否应该据此行动。更新说明不是装饰性文字，而是帮助用户判断数据适用范围的必要信息。
常见验收方式是检查图表是否加载、筛选器是否生效、页面是否符合视觉规范。这些检查有必要，但不够。真正的业务验收还需要让目标用户执行任务：例如比较两个期间、定位差异最大的区域、找到异常订单，并确认下一步处理方式。
如果用户找得到图，却解释不了它；或者看到了异常，却不知道还能从哪里继续拆解，页面仍然没有完整支持决策。验收对象应当是“任务能否完成”，而不是“页面是否按设计稿上线”。
项目会议里经常先讨论“这里用折线图还是柱状图”，但图表类型只是表达手段，不是需求本身。趋势分析、目标比较、构成拆分和异常定位，适合的表达方式并不相同。若业务问题还没确定，提前挑图只会让团队围绕样式做选择，而不是围绕信息需求做判断。
我的做法是先把任务写成动词：比较、追踪、定位、解释、监控或核验。比如“追踪每周订单量变化”与“比较不同区域的目标完成率”是两种任务，前者关注时间变化，后者关注对象差异。任务明确之后，图表选择才有依据。
一张页面容纳几十个指标，不等于分析能力更强。指标太多会提高阅读成本，也会让关键变化被次要信息淹没。比起一次塞入所有可用字段，我更倾向先设置少量核心指标，再把支持追查的维度放进下钻或明细路径。
减少指标不是删掉业务信息，而是把信息放到合适层级。用户首先需要知道是否偏离目标，随后才决定要不要查看区域、产品、渠道或客户明细。若所有层级同时出现，页面缺少阅读顺序，用户只能靠经验自己筛选重点。
筛选器数量过多，会给用户带来组合选择负担。更重要的是，多个筛选条件可能互相影响，导致用户不清楚当前结果到底基于哪些范围。应优先保留高频、能改变决策结论的筛选条件，并在页面上清楚显示当前筛选状态。
如果某个筛选器只在少数分析场景中使用，可以放入分析页或高级筛选中，而不是让所有用户进入页面后先面对一排控制项。功能可用与默认可见，是两个不同的设计选择。
实时刷新会涉及数据链路、计算资源、缓存策略和业务定义等约束。更高频率也可能让同一场会议中的数字不断变化，反而增加解释成本。应该先问“决策需要多新鲜的数据”，再确定刷新周期，并把实际更新时间展示出来。
如果数据源本身每天批量同步，页面做成秒级刷新也不会让底层数据更及时。刷新频率应由数据产生、处理和使用的实际节奏共同决定，而不是只看产品界面上的配置选项。
指标口径可能改变，组织结构可能调整，数据源也可能新增或替换。没有维护责任人的仪表盘，容易逐渐出现同名不同义、页面重复、权限过期和数据延迟未说明等问题。上线是运营的开始，不是数据治理的终点。
至少需要明确谁维护指标定义、谁处理数据异常、谁批准权限变更，以及多久检查一次页面是否仍然服务当前业务。维护机制可以很轻量，但不能完全没有。
需求访谈时，我会把“我想看什么数据”继续追问三层：谁要看？在什么场景下看？看到结果之后要做什么？这样能把笼统需求转成分析任务，也能帮助团队排除“暂时觉得有用、但没有实际动作”的内容。
可以用一张需求卡片记录结果：业务问题、目标用户、决策频率、所需时间范围、关键比较对象、异常后的处理动作。若某项需求说不清用户和动作，先放入待确认区，不必立即纳入首版范围。
指标字典不需要一开始就做成庞大系统，但至少要覆盖首版中的核心指标。每项指标应有稳定名称、业务解释、计算方法、统计范围、时间口径、数据源、刷新周期和责任人。跨部门使用的指标，还要记录业务确认人。
一个容易忽略的细节是区分“指标名称”和“展示标签”。页面上可以把名称写得简洁，但定义文档需要足够精确。例如，展示标签可以写“净销售额”，定义中则要说明退款如何处理、按哪个时间字段归属、是否排除内部订单。
数据模型的任务是提供可靠、可复用的分析基础；仪表盘的任务是呈现与业务任务相关的信息。若把这两类验收混在一起，页面看似正常时，底层的重复记录、日期关联错误或口径偏差可能被忽略。
数据侧先核对字段关系、时间粒度、重复记录、缺失值和历史口径变化。页面侧再检查阅读顺序、指标解释、筛选逻辑、交互路径和异常状态。两套检查清单可以相互关联，但不应互相替代。
数据表的字段顺序通常是为了存储或录入方便，不适合直接变成仪表盘布局。页面应先呈现用户最需要的判断信息，再提供趋势或对比，最后进入异常和明细。具体顺序要根据业务任务调整，不必机械套用统一模板。
常见的组织方式是：顶部放核心状态和统计周期；中部呈现趋势、目标差距或关键对象对比；下方提供异常定位和明细入口。只有当这条阅读路径能自然支持任务时，才值得采用。
验收时可以给目标用户三项任务：找出变化、解释差异、定位明细。记录用户完成任务时是否理解指标、是否能找到正确入口、是否需要导出后重算。若问题集中在同一处，就能判断是页面层级、指标定义还是数据准备造成的。
这一过程不要求大规模用户研究。首版可以邀请少量目标角色参与任务走查，重点是观察他们如何理解页面，而不是向他们解释“设计原本想表达什么”。如果必须由设计者讲解才能看懂，通常说明页面还需要调整。
我更建议把 BI 项目拆为“需求与指标确认，数据验证，页面原型，可用版本，业务验收，稳定运营”几个阶段。每阶段都有清楚的输入和退出条件，便于在口径未定或数据不可信时及时暴露风险，而不是等到页面制作完成才返工。
下表列出常见交付物与检查重点。它不是所有组织都必须照搬的项目制度，而是一种减少遗漏的工作顺序。
| 阶段 | 核心交付物 | 进入下一阶段前检查 |
|---|---|---|
| 需求澄清 | 用户、业务问题、决策场景、首版范围 | 每项核心需求都能对应到明确用户和任务 |
| 指标定义 | 指标清单、口径说明、责任人 | 关键指标的计算范围、时间口径和来源已确认 |
| 数据验证 | 数据源映射、字段关系、质量检查记录 | 关键数值能与可信来源进行抽样核对 |
| 页面设计 | 页面结构、图表、筛选与追查路径 | 每个主要区域都服务于一个明确的分析任务 |
| 业务验收 | 任务走查记录、问题清单、修复优先级 | 目标用户能独立完成关键任务并理解结果 |
| 持续运营 | 维护人、刷新说明、反馈与变更机制 | 指标和页面变化有责任人及可追溯记录 |
下面的销售案例用于展示设计方法，所有数字均为情景模拟数据，不是客户实测结果，也不代表任何 BI 平台的性能或收益。实际项目应使用经业务确认的数据，并按自身口径计算。
假设一家多区域经营的企业提出需求：“希望有一张销售仪表盘，方便管理层看经营情况。”这句话还不足以进入开发，因为它没有说明销售额的定义、查看周期、用户任务，也没有说明管理层发现异常后需要追查到什么层级。
经过澄清，首版目标可以改成：“区域负责人每周查看目标完成情况；当某区域与目标差距扩大时，能够按产品和渠道拆分差异，并核对相关订单明细。”这段话已经提供了用户、频率、判断任务和追查方向，可以据此设计指标与页面。
随后把需求拆成三类。第一类是必须回答的问题：目标完成率、订单趋势和区域差异。第二类是用于解释变化的分析维度：产品、渠道、时间。第三类是暂缓内容：尚未确认口径的毛利分析，以及目前没有稳定数据来源的预测指标。暂缓不是拒绝需求，而是避免把未定义内容伪装成确定结果。
这个示例中，团队需要先决定订单额是按下单、支付还是发货日期归属，取消订单是否排除，退款是否冲减，以及目标值按月还是按周拆分。若不同系统使用不同时间字段，时间维度还需要与业务确认采用哪个口径作为正式统计口径。
核心指标可以包括订单金额、订单数量、目标完成率和退款金额。页面标签要能让业务快速理解，指标说明则补足详细规则。对于目标完成率，还要明确分子和分母对应的时间周期，否则周度页面可能用月目标作分母，造成解释偏差。
首屏顶部可以呈现当期订单金额、目标完成率和统计截止时间。中部安排订单趋势与区域目标差距，帮助用户识别变化发生在何时、何地。页面下部提供产品与渠道拆解，并设置进入订单明细的路径，用于核对具体记录。
筛选器优先考虑时间、区域和产品。若渠道筛选是高频分析条件，也可以加入；若只在少数复盘中使用，可以放在进一步分析区域。筛选器应明确当前选择，且交互后要能判断数据范围是否发生变化。
假设某月整体订单金额比目标低，用户首先需要知道差距有多大；接着查看区域对比，发现差距主要集中在两个区域；然后按产品拆分，判断差异是否由特定产品造成；最后进入订单明细核对记录。下面的模拟数据展示“先看总体、再定位来源、最后核验记录”的分析链路。
验收任务可以这样设计：请区域负责人找出本月低于目标的区域，判断订单金额下降主要对应哪个产品，再打开明细核验一笔订单。观察重点不是用户是否点击了所有图表，而是他能否理解统计周期、正确识别差异、沿页面提供的路径完成追查。
如果用户能看见差距，却无法拆分原因，说明缺少必要的对比维度；如果能拆分，却无法核验订单，说明明细路径或权限设计有问题；如果同一数值与原有经营报表不一致，则应先检查口径和数据映射，而不是立刻调整页面呈现。
不同团队的问题可能完全不同。有的团队数据来源较少，主要需要快速构建业务分析页面；有的团队已有统一数据模型，重点在权限、治理和复用；也有团队仍在手工拼表阶段，首要任务可能是稳定数据接入和口径管理。选平台之前，先把当前约束说清楚，比按功能列表逐项打分更有效。
我会从数据源接入、数据处理方式、指标复用、交互分析、权限控制、刷新机制、协作与维护成本几个方面做验证。具体能力应以平台当前版本、实际配置和服务条款为准，不能只凭宣传页面或演示环境做判断。
如果团队正在比较适合业务分析与仪表盘搭建的工具，可以把九数云列入候选，并通过官网了解其当前产品信息：九数云官网。我不建议仅凭“功能很多”或单次演示就作采购判断，更稳妥的方式是拿一项真实业务任务，使用脱敏样例数据进行验证。
验证时重点检查：目标数据源能否按计划接入；关键指标是否能按已确认口径计算；业务用户能否完成筛选、对比和追查；权限是否符合组织边界；刷新延迟是否满足决策时间窗；上线后由谁维护数据和页面。对平台能力的具体结论，应以实际试用、合同约定和官方文档为依据。
试点范围不必很大。可以选择一个业务部门、几项核心指标和一个明确的使用任务，例如周度销售复盘。先把口径与数据准备好，再制作最小可用页面，邀请目标用户独立完成任务，记录卡点和修订成本。
这种方式能暴露演示环境里不容易发现的问题：字段质量是否稳定、筛选组合是否符合习惯、指标刷新能否赶上会议时间、用户是否理解定义、权限边界是否实际可用。选型结论应来自这些任务验证，而不是功能名称的数量。
同一项功能是否有价值，取决于团队是否具备使用它的条件。例如，灵活的数据连接能力不能替代数据源治理；丰富的可视化选项不能替代指标设计；权限配置能力也不能替代组织侧的数据分级规则。选型表里应分别记录平台能力、当前配置要求和团队维护责任。
如果组织缺少专职数据团队，维护成本与学习成本可能比某些高级分析功能更重要；如果已有成熟数据仓库和治理体系，平台与现有模型的衔接、权限继承和复用方式则更值得重点验证。
先不要急着扩展图表数量。挑出业务影响最大的少数核心指标，建立定义、计算逻辑、时间范围、数据源和负责人，再用一页原型验证业务是否认可。优先解决“同名数字不一致”，通常比增加更多分析维度更能减少沟通成本。
取舍上，可以暂缓不影响首个决策任务的次要指标；但不要为了赶上线，把关键指标定义留到后续。无法确认口径的数字可以标注为试算或暂不展示，不能把不确定性藏在页面背后。
先列出每张表的来源、更新频率、字段含义和维护人，并检查业务键、时间字段、重复记录与缺失值。然后选一个范围可控的业务问题，验证数据链路是否能稳定支持分析。若底层数据每天都要人工修补，页面越多，后续维护负担越大。
取舍上，首版可以减少跨系统指标和复杂模型，先把单一场景的数据质量做稳。不要一开始追求覆盖所有部门；若组织结构、主数据或订单定义尚未统一，过早做全域总览很可能只是把不一致汇总到同一屏幕。
先观察用户任务，不要立即重做整套页面。挑选使用者最常提出的三个问题，检查他们是否能在现有页面找到答案，再记录需要导出、重复计算或询问他人的步骤。低使用率可能来自内容不相关、口径不可信、更新太慢、权限不足，也可能只是入口不明显，原因不同，处理方法也不同。
取舍上，删除长期不服务任务的组件可能比新增图表更有效。但对低频而关键的风险监控，不能仅凭点击次数判断其价值；还要结合业务责任、发生频率和未及时发现的后果评估。
先确认大屏是用于会议展示、日常监控还是异常处置。会议展示重视阅读顺序和可解释性；日常监控需要明确更新时间和告警条件；异常处置则必须提供进一步定位与责任分工。不同任务不应只用屏幕尺寸来区分。
取舍上，大屏可以减少细节、强化关键状态，但不能把“视觉冲击”当成业务价值。若页面只能展示整体数字，却无法说明变化来自哪里，它适合概览，不适合独立承担分析工作。
首版可以围绕一个用户群、一项核心决策、少量关键指标和有限的数据源展开。选择范围时优先考虑业务价值、数据可用性和维护能力的交集，而不是只挑领导最容易看见的主题。
取舍时可把需求分为“必须支持当前决策”“有价值但可后续补充”“目前缺数据或定义”的三类。前两类不是简单按重要性排序，第三类则要明确补齐条件和责任人，避免长期停留在口头承诺中。
指标定义通常由业务责任人确认，数据链路由数据或技术人员维护，页面结构和使用反馈则需要产品或业务分析角色跟进。小团队可以由同一人承担多个职责，但最好把责任写清楚，否则数据异常出现时容易互相等待。
至少应明确：谁批准指标口径变化，谁处理数据刷新失败，谁调整访问权限，谁受理页面需求，谁判断旧页面是否下线。责任人不一定意味着复杂审批，而是保证问题能够找到明确的处理入口。
当数据缺失、刷新延迟或出现异常跳变时，页面要帮助用户区分“业务真的变化了”和“数据暂时不可用”。例如，在适当位置显示统计截止时间；若当前数据未完成刷新，应明确提示，而不是留一个看似正常的旧数值。
关键指标还可以建立核验方式：定期抽查源数据、与业务系统总数对照、检查历史同期变化是否符合已知业务事件。具体频率应根据指标重要性和数据风险决定，不能把所有字段都按同样成本维护。
上线后的需求常常会持续增加。收到反馈时，先记录发生场景、用户任务、现有障碍和预期行动，再判断是口径问题、数据问题、页面问题还是新增需求。这样可以避免把所有问题都转换成“再加一张图”。
迭代优先级可以综合业务影响、发生频率、修复成本和风险。偶发但可能影响重大决策的问题，未必应该排在高频但无实际影响的样式调整之后；同样，长期无人使用的页面也应检查是否需要合并、重构或下线。
业务变化后，旧页面可能不再匹配当前组织结构和管理节奏。复核时可以问：目标用户还在使用吗？原来的决策任务是否变化？核心指标是否发生定义变更？数据来源和权限是否仍然有效？页面上的筛选条件是否仍有价值？
复核不一定需要大型审计。每个迭代周期或业务复盘节点做一次轻量检查，就能减少重复页面、过期口径和无人维护的报表。关键是把维护纳入 BI 流程，而不是等到用户投诉才处理。
如果上述问题中有多项无法回答，优先补齐需求和数据定义，不要急着堆叠更多视觉组件。仪表盘的易用性，往往在页面绘制之前就已经被决定了。
第一，页面是否对应一个真实且清晰的业务任务？第二，用户是否能理解数字代表什么、数据何时更新？第三，发现变化后，是否有合理路径去解释和核验？这三项都成立，仪表盘才可能从“展示页面”变成业务工具。
对 BI 项目而言，图表美观、加载稳定和交互顺畅都重要，但它们解决的是呈现与使用问题，无法替代需求澄清、口径治理和数据验证。流程设计的价值，就是在投入大量开发和维护之前，把这些依赖关系提前暴露出来。
如果你正在规划新项目，先找一位目标用户，写下他最常遇到的一项业务判断，再确认涉及的指标定义、数据来源和后续行动。然后做一页最小原型，邀请用户在不听讲解的情况下完成任务，记录卡点并迭代。
如果你已经有仪表盘，就选一个使用频率高或争议较多的页面，核对指标口径、刷新说明和追查路径。不要先问“还能加什么图”，先问“用户现在不能独立完成什么判断”。这通常是找到 BI 流程改进点最快、也最不容易走偏的起点。
我准备给团队搭一套 BI 仪表盘，但不确定应该先接数据、选平台，还是先画页面。我担心一开始就做错顺序，后面指标和页面都要返工，想知道一套更稳妥的流程是什么。
建议从“谁要做什么决策”开始，而不是先接数据或挑图表。先写清使用者、决策场景、查看频率和希望采取的行动。例如，销售负责人可能需要判断目标是否落后、差距集中在哪些区域，以及下一步该追查什么。
可以按这条顺序推进：业务问题与用户 → 指标定义 → 数据来源和质量检查 → 页面信息结构 → 图表与交互 → 权限配置 → 用户验收 → 上线维护。每一步都应有可检查的产物：需求清单、指标字典、数据核对记录、页面草图和验收任务。若需求或指标尚未确认，先画正式页面通常只会把不确定性包装得更漂亮。
我做过几张仪表盘，图表和筛选项加得越多，业务同事反而越难找到重点。我想知道页面究竟应该放多少信息，阅读顺序又该怎么安排，才能让人看完知道下一步做什么。
先把页面当作一条阅读路径，而不是一块展示画布。可以从“整体是否正常”开始，再呈现趋势或目标对比，最后提供定位异常的维度和明细入口。比如销售经营页可以依次呈现核心业绩指标、按周变化、区域差异，再让用户筛选区域查看相关明细。一个实用的删减测试是：对每张图问“用户看完它会做什么判断或追问？
”如果答案只是“多看一个数据”，而它不能支持决策、比较或追查，就应考虑移除或放到下钻页。筛选器也只保留高频条件；低频维度可以通过下钻处理，避免首屏挤满控件。具体图表数量没有通用标准，重点是用户能否按预期顺序完成任务。
我遇到过仪表盘上的销售额和业务系统导出的数字不一致，团队花了不少时间争论哪个才是对的。我原以为是图表显示出了问题，现在想知道更常见的原因是什么，以及上线前应该检查哪些口径。
数字不一致未必是图表错误，常见原因包括统计对象不同、时间范围不同、退款或取消订单的处理不同、去重规则不同，以及数据刷新时间不同。例如，“销售额”可能按下单时间统计，也可能按支付时间统计；若口径没有写明，两边都可能算得正确，却回答了不同问题。
建议为核心指标建立指标字典，至少记录名称、业务定义、计算规则、统计时间、过滤条件、数据来源、刷新频率和负责人。上线前选一段明确的时间范围，抽取少量记录逐笔核对源数据与仪表盘结果，并同时检查筛选条件是否一致。差异若来自延迟或业务规则，应在页面标出更新时间与口径说明，不能只靠口头解释。
我过去验收报表时，主要看页面有没有加载、数字有没有显示，结果上线后还是有人继续手工导表。我想知道除了检查页面和数据，还有什么办法能判断仪表盘是否解决了真实问题，也想减少上线后的反复修改。
把验收从“页面是否完成”改成“用户能否完成任务”。给目标用户一个真实但范围明确的问题，例如“找出本月表现低于目标的区域，并确认差异主要出现在哪个时间段”，观察其能否理解指标、找到筛选入口并得出正确结论。若用户必须问开发人员指标是什么意思，或绕回源系统才能回答问题，仪表盘就还没有通过业务验收。
上线前至少核对四类内容：关键数字与源数据是否一致、筛选和钻取是否按预期工作、不同角色看到的数据是否符合权限、刷新时间和空值状态是否清楚。上线后记录用户反馈与重复出现的查询需求，按影响范围排序迭代。实际使用情况应结合平台日志、用户反馈和业务任务完成情况判断；单看访问次数，无法证明页面真正有用。
读者评论
文章把仪表盘验收从“图表是否正常”转向“用户能否完成任务”，这个区分很实用，尤其适合需求容易停留在做看板的项目。
指标口径需要明确时间字段、退款处理和统计范围，文中举的销售额例子说明了同名指标为何也可能对不上。
按管理者、分析人员和一线人员区分使用场景，有助于避免把所有信息堆进一张页面；总览、分析和明细分层的思路比较清楚。
文中的漏斗和反馈分类都注明是情景模拟，这一点重要，避免读者把示例数字误当成行业调查结论。
上线后还要维护指标、权限和刷新说明，这部分提醒到位；如果能进一步补充维护频率和责任分工示例，会更便于落地。