BI 平台建设路线：从移动查看到进阶玩法分几步
很多团队做 BI，第一步就把桌面报表压缩到手机上，结果页面能打开，业务却仍要回到电脑里找明细、核口径、问数据负责人。问题不在于移动端做得不够漂亮，而在于平台还没有形成“看见问题，判断原因，采取行动”的闭环。BI 建设不宜从功能清单起步，更稳妥的路线是先明确决策场景，再建立可信报表，随后设计移动使用、治理协作，最后按条件扩展自助分析、告警或智能能力。
我建议把 BI 平台建设拆成五个阶段：明确业务决策与指标、建立可信的数据和报表、设计移动查看与后续动作、补齐治理和协作机制、按成熟度扩展进阶分析。它不是要求所有企业按固定工期依次交付，而是用来判断当前最该解决什么、下一阶段需要什么前提。
这条路线的关键不是“先简单、后复杂”，而是每一步都要形成可验证的交付。第一阶段交付的是场景和指标口径，第二阶段交付的是业务认可的数据视图，第三阶段交付的是适合移动使用的体验，第四阶段交付的是权限与维护机制，第五阶段才是更开放的分析和自动化能力。
如果一个项目只能回答“采购了什么功能”，却说不清业务要据此做什么动作，那么它更像是报表项目，还没有成为可持续运营的 BI 平台。建设顺序应由决策依赖关系决定，而不是由产品菜单决定。
设想一个零售经营负责人早上在手机上看到某区域销售额下降。他接下来通常会追问：是门店客流减少、客单价下降、缺货增加，还是订单尚未完整入库？如果移动页面只展示一个红色数字，却没有可信的更新时间、可比较的基准和可进入的明细，那么它只是把问题提前暴露，并没有缩短问题定位路径。
移动场景的价值通常在于“及时触达”和“快速判断”，复杂探索则未必适合在小屏幕上完成。一个合理的移动页面，可能只需要呈现关键变化、变化幅度、更新时间、责任范围和下一步入口；更细的切片、交叉分析和模型验证，可以留给桌面端或其他分析工作区。
同一个“销售额”，可能分别指下单金额、支付金额、扣除退款后的净销售额，或按发货日期统计的成交金额。不同团队如果没有共同定义，即使平台把图表加载得很快，会议仍会花时间争论数字为什么不同。移动端显示得越及时，口径争议反而可能越早暴露。
因此我会把“指标解释是否一致”放在移动端开发之前检查。至少要说明指标计算口径、统计粒度、数据更新时间、来源系统、过滤条件和责任人。若这些信息还不稳定，先做小范围验证，比先铺开全员移动访问更节省返工成本。
移动查看只有接入实际工作，才可能变成业务能力。比如店长看到库存异常后，是否能定位到具体商品和门店？需要联系谁？处理结果由谁记录？如果提醒没有责任人、没有处理时限、也没有复核方式，告警越多，用户越可能忽略它。
这也是我判断移动 BI 是否“好用”的一个标准：用户从发现异常到找到责任动作，中间有多少次页面切换、人工询问和重复核对。页面美观是体验的一部分，但不应盖过任务完成路径。
先看功能演示、再收集“想要什么报表”，容易把需求变成菜单式点单：销售要排名，财务要汇总，运营要趋势，最后每个人都有页面，却没有共同的指标语言。工具选型当然重要，但选型前至少要准备一两个优先业务场景、关键指标和典型用户任务，才能检验工具是否适用。
例如，团队需要的是每天追踪门店缺货并安排补货，那么数据更新频率、门店粒度、异常筛选和责任流转，比首页能放多少张图更关键。若需求是月度经营复盘，则历史口径、跨期比较和可追溯解释可能更重要。
桌面报表常以多图表、多筛选器和宽表为主，直接缩小后，用户要不断缩放、横向滚动或寻找筛选条件。移动页面应该从任务出发重新安排信息优先级：先显示结论和变化，再提供必要的筛选、明细入口与说明。
手机上的网络环境、屏幕尺寸、使用时段和操作方式，也与办公室电脑不同。建设时要验证常见设备、登录方式、权限呈现、弱网情况下的等待体验，以及用户是否能在短时间内完成目标动作。不能只用“页面可以打开”作为移动端验收标准。
自助分析的目标是减少反复排队等待，让业务人员在边界清楚的数据集上完成探索；它不等于绕过口径治理、权限审核和数据责任。若同一指标被多个部门各自复制、修改和发布，平台可能从“一个数据孤岛”变成“许多口径孤岛”。
更稳妥的做法是区分认证数据集和个人探索空间。前者由明确的负责人维护，适合正式经营沟通；后者允许业务临时验证想法，但要标明用途和限制，避免未经核验的探索结果被当作正式经营数字。
预测和 AI 辅助可以帮助发现模式、生成分析线索或降低部分查询门槛，但它们不能自动定义业务指标，也不能替代数据质量检查和业务复核。若历史数据缺字段、口径经常变化，或预测结果没有对应行动，新增智能功能只会让不确定性更难解释。
判断是否进入进阶阶段，可以先问三个问题：数据是否足以支持该场景？结果是否有人负责核验？输出是否会改变某个业务动作？只要其中一项没有答案，就应先补基础能力，而不是把“先进”当成优先级。
不是所有可视化需求都值得立项。一个场景至少要有明确的决策频率、受影响的业务范围和可执行的后续动作。比如“观察销售趋势”还不够具体；“每天发现连续两日转化率低于预设范围的门店，并由区域负责人核查活动、库存与客流”就更接近可建设的需求。
我会把场景拆成“谁在什么时间，看到什么变化，随后做什么”。如果回答不出最后一步，需求可能仍停留在信息展示层；如果需要的动作不受数据影响，那么 BI 未必是解决该问题的首选方式。
数据条件不仅是“有没有数据”，还包括字段是否完整、更新频率是否符合决策节奏、不同系统能否通过稳定键值关联、历史数据是否可比，以及异常由谁排查。比如每日补货决策需要的数据，如果只能每周更新一次，即使图表制作完成，也无法支持原先设想的运营节奏。
在正式扩展前，建议对关键指标做小范围对账：选取一段时间、几个典型业务对象，把平台口径与现有业务记录逐项核对。对不上时先查定义、过滤条件、时间边界和源数据，而不是靠调整图表展示让数字“看起来合理”。
BI 平台不是一次性交付物。数据源会变化，业务规则会调整，权限也会随人员和职责变化。如果没有明确的报表维护人、指标负责人、数据问题处理渠道和需求优先级机制，平台上线后的可信度会逐渐下降。
组织承接不必一开始就建立复杂委员会。首期可以明确到具体角色：业务指标负责人确认定义，数据团队维护数据链路，平台管理员管理访问，业务使用者反馈问题。职责清楚通常比制度文件写得很厚更有用。
不同团队的现状差异很大。数据源成熟的团队可以更快进入移动预警；指标口径混乱的团队可能需要先投入一段时间梳理定义。与其承诺“上线三个月后进入 AI 阶段”，不如规定进入条件：关键指标通过核验、用户能解释报表、异常处理人明确、权限方案可执行。
| 判断维度 | 可进入下一阶段的信号 | 暂缓扩展的信号 |
|---|---|---|
| 业务价值 | 有明确决策人、使用频率和后续动作 | 需求主要是“多做几张图”，没有使用任务 |
| 数据条件 | 口径、更新频率、来源和责任人可说明 | 关键数据缺失，或不同报表长期无法对账 |
| 组织承接 | 异常有人处理，报表有人维护，问题有反馈渠道 | 用户只负责提需求，没人负责解释和跟进 |
| 风险控制 | 权限按角色设计，敏感数据有处理规则 | 共享范围不清晰，移动访问也未纳入权限核查 |
先选一个范围可控、决策频率明确的业务场景，而不是同时接入所有部门。首期场景可以是门店经营、销售漏斗、库存异常或市场活动复盘，选择标准不是名称是否热门，而是业务是否会依据结果采取行动，以及相关数据能否在合理成本内取得。
这一阶段至少要完成场景说明、核心指标清单、指标口径、统计粒度、数据来源、更新频率和责任人。指标不必贪多，优先覆盖“结果，原因，动作”所需的信息。比如经营结果指标之外，还要有能解释变化的维度，而不是只给一个总数。
升级条件：业务负责人认可场景和指标定义；数据来源及缺口已记录；团队知道哪些数据暂时不能支持结论。
数据接入后，不要立刻把所有字段铺到页面上。先核对关键字段、时间口径、去重规则和关联关系，再围绕业务问题组织报表。报表应该让用户看出当前值、比较基准、变化范围和可追溯明细，必要时注明数据更新时间和口径解释。
验收时不要只看页面是否完成。可以挑选代表性业务对象做抽样核对，记录差异发生在哪个环节；同时邀请实际用户按真实任务操作，观察他们能否在不依赖开发人员解释的情况下找到答案。发现数字不一致，应先定位原因，再讨论是否需要调整展示。
升级条件：关键指标经过业务核验；常见问题能够追溯到来源或规则；业务人员知道报表适用范围和限制。
移动端先解决高频、短时、明确的任务。可以从关键指标摘要、异常变化、筛选范围、数据更新时间和明细入口开始。不要把所有桌面交互都迁移到手机，也不要让用户在移动端面对一屏过多图表。
若设计消息提醒，要规定触发条件、通知对象、触达时段、重复提醒规则和关闭方式。更重要的是说明提醒之后如何处理：打开后进入哪个对象、由谁负责、结果在哪里记录。没有动作闭环时，先提供定期查看或订阅可能比频繁推送更合适。
升级条件：目标用户能在常见移动场景下完成查看任务；提醒有明确责任人；移动权限与正式权限策略一致。
随着使用范围扩大，指标目录、认证数据集、权限和维护流程要逐步制度化。指标说明应能回答业务含义、计算口径、时间边界和责任人；权限设计要考虑组织角色、数据敏感程度和使用目的。对于移动端、共享链接和导出能力，也应纳入同一套风险审视。
内容运营不只是清理过时报表，还包括观察哪些内容被使用、哪些需求反复出现、哪些指标经常产生争议。报表数量增加并不自动代表价值提高；对没人使用、重复建设或没有负责人维护的内容，应设立归档和复核机制。
升级条件：正式指标有维护责任；访问规则可解释；内容变更和问题反馈有稳定渠道；团队能区分正式分析与个人探索。
基础治理相对稳定后，再依据实际需要开放自助分析。做法可以是先提供经过认证的数据集、常用维度和字段说明，限制敏感字段，并将探索结果与正式报表区分。这样既保留灵活性，也降低不同团队复制指标定义的风险。
如果用户主要在业务系统中完成工作，可以评估把分析嵌入现有流程；如果异常需要快速处理，可以评估提醒和任务流转；如果某类问题重复出现且数据足够稳定，再评估预测或 AI 辅助。每一种进阶能力都要有业务负责人、复核机制和失败处理方案。
升级条件：进阶能力能对应具体业务动作；数据和权限前提满足；结果可被核验；出现错误时有人工介入和回退办法。
下面是一个情景推演，不是某家企业的真实客户案例。设定一家多渠道经营的电商团队，负责人希望每天在移动端了解成交、退款、缺货和活动表现，并在异常出现时及时找到对应商品、渠道或责任团队。
如果一开始就做“全业务驾驶舱”，项目很可能陷入字段清单讨论。更有效的做法是先选一个可验证的问题：例如活动期间某些商品的支付转化和库存是否同步异常。围绕这个问题确定订单、支付、退款、商品、渠道和库存数据的定义，确认事件时间、统计时间和更新节奏。
团队先选取一段业务周期和一组代表性商品，把 BI 中的订单数、支付金额、退款金额与现有业务记录对照。若出现差异，分别检查是否使用下单时间还是支付时间、退款是否按发生日期回冲、取消订单是否排除、跨渠道商品编码是否能稳定关联。
在这些问题没有解释清楚之前，移动端显示精确到小数点的指标并不会增加可信度。反而应该把口径说明和数据更新时间放在用户容易找到的位置，并对暂时不能合并的渠道数据明确标注范围。
初版移动视图可以先展示成交趋势、退款变化、缺货风险和更新时间，并提供按渠道、商品或店铺查看的入口。用户看到异常后，能否定位到商品和渠道，通常比首页再增加一张装饰性图表更重要。
若团队已使用明确的补货或活动处理流程，再把异常连接到责任动作；若流程尚未统一，可先用订阅或人工复核验证提醒是否真正有帮助。不要先假设自动告警一定优于人工查看，先观察提醒触发是否准确、用户是否知道如何处理。
若团队正在评估产品，可将九数云列为候选方案之一，并从数据接入方式、指标管理、移动体验、权限粒度、更新机制、使用门槛和运维成本等维度做实际验证。相关产品信息应以官方资料和正式演示为准，可从九数云官网了解其公开信息；不能仅凭营销页面推断某项能力一定适合当前场景。
评估时我会要求候选平台用团队自己的样例数据完成一条端到端任务：从数据进入、指标呈现、移动查看，到定位明细和权限校验。演示数据能跑通不等于生产环境已验证，正式决策还要核对数据规模、接口限制、账号权限、部署要求、服务边界和持续费用。
| 验证问题 | 建议现场检查 | 为什么重要 |
|---|---|---|
| 数据能否正确连接 | 用实际字段、业务编码和时间口径进行关联测试 | 演示样例结构简单，不能代表真实数据条件 |
| 移动端是否适合任务 | 让目标用户在手机上完成查看、筛选和定位明细 | 确认实际操作路径，而不是只看页面截图 |
| 权限是否符合组织要求 | 用不同角色登录，测试可见范围和敏感字段控制 | 验证权限规则是否可理解、可维护、可审计 |
| 后续维护成本如何 | 检查指标变更、数据异常和报表维护由谁处理 | 平台上线后的工作量往往决定长期可持续性 |
不要从“全公司数据中台”或“所有部门驾驶舱”开始。挑选一个业务负责人愿意参与、使用频率明确、数据范围可控的场景，完成指标定义、数据核验、基础报表和一次用户验证。首期目标不是覆盖最多业务，而是证明团队能把一个问题从定义带到行动。
首期应把不做什么也写清楚。例如暂不支持哪些渠道、哪些历史期间不可比、哪些字段没有权限开放。明确边界能减少“为什么没有全部展示”的误解，也能保护团队不在数据准备不足时作出过度承诺。
不要马上再建一个门户。先盘点现有报表的负责人、目标用户、更新时间、指标口径、最近使用情况和重复内容。把报表分为持续使用、需要修订、重复合并和待归档几类，再访谈目标用户：他们是找不到报表、看不懂数字、数据更新不及时，还是看完不知道下一步做什么？
根据原因采取不同动作。找不到就改导航和命名；看不懂就补指标解释；数字不可信就先查数据链路；没有行动就回到业务流程重新设计。只靠培训通常不能解决数据口径不一致或页面任务不匹配的问题。
让几位目标用户在真实场景中完成一个具体任务，例如“找到今天异常门店并查看相关商品”。记录他们从打开应用到找到答案的步骤，包括筛选次数、页面切换、等待时间和需要向谁询问。观察结果比单纯收集“喜欢不喜欢”更能指出改进方向。
如果用户只想快速判断状态，移动端可能缺少摘要和异常解释；如果用户需要比较多个维度，手机未必是主要分析终端，可以保留移动查看，把深入分析放在桌面端；如果用户看到了结果却没有行动入口，则要与业务系统或现有流程协同评估。
开放自助之前，先确认哪些数据集属于正式认证、哪些字段敏感、哪些指标可直接用于经营汇报、探索结果如何标识，以及业务用户遇到数据问题时找谁。可以先在一个部门或一个主题域内试点，观察重复指标、错误筛选和权限申请的实际情况，再决定扩大范围。
自助能力也需要培训，但培训重点不是教用户记按钮，而是解释数据集适用边界、指标定义、筛选逻辑和结果验证方法。工具使用熟练度不能代替数据素养和业务判断。
选择一个可回溯、风险可控的场景做小试点，明确模型输出用于建议、排序还是自动执行。涉及高影响决策时，先保留人工确认。记录输入数据范围、结果被采纳或否决的原因，以及错误结果会造成什么影响。
如果无法定义“预测错误后怎么办”，说明自动化程度可能超过了组织的承接能力。先把模型作为分析线索，而不是直接替代业务判断，通常更容易获得信任，也更方便积累后续验证数据。
如果管理者必须在现场快速查看高频指标，而且核心口径已经稳定，可以先做范围有限的移动视图，同时保留治理任务。如果同一指标在不同部门含义不同，优先治理口径更合适。否则移动端只是更快地把争议送到更多人手上。
当组织规模较大、权限和集成要求明确、长期运维有专人负责时，全面平台评估可能值得投入。若团队还说不清具体场景、数据负责人和首期指标，先用小范围验证更稳妥。小范围不是临时拼凑，而是以真实任务测试数据、体验和治理要求。
如果指标解释成熟、业务用户具备基本分析能力、数据集有人维护，自助分析可以扩大探索空间。如果用户主要需要稳定的经营数字，且口径争议较多，先提供认证报表更有价值。二者并非对立，可以把正式决策与探索验证分层管理。
变化需要快速处置、规则相对清晰且责任人明确时，告警可能有价值。若指标波动频繁、阈值容易误报，或者团队还没有处理流程，定期复盘可能更合适。告警的成本不仅是开发，还包括用户注意力、误报处理和规则维护。
如果业务问题重复、数据稳定、输出能被验证、行动流程清楚，可以进行智能能力试点。反之，先补字段、口径、数据质量和责任机制。这里的取舍不是“创新还是保守”，而是把创新投入放在能被检验、能被纠错的场景中。
| 团队现状 | 优先行动 | 暂缓事项 |
|---|---|---|
| 数据口径不一致 | 梳理核心指标、责任人和时间边界 | 全员自助与自动化决策 |
| 报表可信但移动体验差 | 按移动任务重排摘要、筛选和明细入口 | 简单缩小桌面页面后直接推广 |
| 用户能看数但没人处理异常 | 明确负责人、处理方式和复核节点 | 增加更多提醒频次 |
| 基础成熟且需求重复 | 试点自助、订阅或智能辅助并记录效果 | 不设验证标准地扩大范围 |
报表数量、数据源数量和页面访问量可以说明平台规模，但不能单独证明业务价值。更有解释力的观察维度包括：目标用户是否持续使用、关键指标是否被理解、异常是否能定位、提醒是否产生有效处理、数据问题是否能追溯，以及内容维护是否有明确责任人。
这些指标没有适用于所有企业的统一合格线。团队可以先建立自己的基线，例如记录试点期间的任务完成情况、常见问题类型和处理耗时，再比较迭代前后变化。采集数据时要保持统计口径一致，并区分“页面打开”与“完成业务任务”。
如果只看结果指标，例如异常处理耗时是否下降，可能很难判断是哪项改动产生影响；只看过程指标，例如打开率增加，也可能忽略处理结果并没有改善。更好的做法是把两类观察配对：触达和打开属于过程，定位和处理属于任务，业务结果属于下游。
在没有足够样本时，不要急着宣称某项功能提升了效率。可以先做小样本观察，记录用户完成任务的路径和阻塞点，并说明观察范围、时间区间和限制。对外发布量化成果时，必须交代数据口径和来源。
用户说“数据不对”，可能是源数据延迟、统计口径不同、筛选条件误解，也可能是页面显示不清。复盘时应按问题类型记录：数据缺失或延迟、指标定义争议、权限受限、操作路径复杂、提醒过多、责任未明确。分类之后再决定改模型、改说明、改页面还是改流程。
平台的长期价值，往往来自一套持续纠错的机制，而不是第一次发布时的完整度。每次改动都应留下变更原因、影响范围和验证结果，尤其是指标口径变化，避免用户在不知情的情况下把新旧数据直接比较。
完成这四项后，再决定首期要做报表、移动查看、订阅还是治理工作。若问题尚未定义清楚，不要急着进入大规模选型；若口径已清楚而用户确实需要现场访问，再用真实任务验证移动端；若使用范围正在扩大，则优先补权限、责任和内容维护。
| 阶段卡片字段 | 需要写清的内容 |
|---|---|
| 目标决策 | 谁要根据哪些信息做什么决定 |
| 首期范围 | 覆盖的部门、数据、时间范围和明确不做的部分 |
| 验收证据 | 指标核验记录、用户任务结果、权限测试或处理闭环记录 |
| 升级条件 | 进入移动扩展、自助分析或智能试点前必须满足的条件 |
| 维护责任 | 业务指标负责人、数据维护人、平台管理员和问题反馈渠道 |
不是每个团队都需要预测分析，不是每个指标都需要实时刷新，也不是所有业务都适合手机上完成深度分析。真正值得投入的进阶能力，应同时满足业务有明确需求、数据能够支撑、结果有人复核、后续动作可追踪。任一条件缺失，都可以先缩小范围或暂缓。
我对 BI 建设的核心判断是：平台不是把更多数据搬到一个界面，而是让一项业务判断变得更可信、更及时、更容易执行。移动查看是触点，治理是基础，进阶分析是可选的放大器。下一步不妨先挑一个高频决策场景，写清指标口径和责任人，再用真实数据验证一条从“看见”到“处理”的完整路径。
我正在规划公司的 BI 平台，既想尽快让业务用起来，又担心一开始铺得太大、最后维护不动。我该按什么顺序建设，每一步做到什么程度，才适合进入下一阶段？
与其按产品功能排路线，不如按业务能力分成五步：定义决策场景、建立可信报表、适配移动使用、补齐治理协作、扩展自助与智能分析。它不是每家企业都必须走完的固定阶梯，而是一套帮助控制投入顺序的检查框架。第一步交付场景清单、指标口径和责任人；第二步交付经过业务核对的报表；第三步确认移动端适配了真实使用场景；
第四步明确权限、维护和问题处理机制；第五步再根据需要评估自助分析、告警或 AI 辅助。进入下一步的依据不是“上一阶段功能做齐”，而是数据可信、有人使用、问题有人负责。
我希望管理者能随时在手机上看经营数据，所以直觉上想把移动端作为第一期重点。但我不确定手机上能打开报表是否就算建设成功，也担心复杂页面缩小后反而更难用。
移动查看适合做首期入口，但不一定适合作为建设起点。先确认要支持的决策：如果管理者只需查看少量关键指标，移动端可以优先；如果问题依赖复杂筛选、跨表对比或大量明细，先把数据口径和桌面分析体验打稳，通常更稳妥。
验收时不要只测页面能否打开，还要检查手机上是否能快速找到重点、是否能识别异常、是否能进入必要的明细，以及数据权限是否与用户身份一致。若看完数据后仍不知道该找谁处理，移动报表只是把数字搬到了手机上，并没有形成业务闭环。
我看到不少团队把自助分析和 AI 当作 BI 的进阶目标，也想尽早纳入规划。但公司现在不同部门对同一个指标的理解还不完全一样，我担心能力上线后，用户只是更快地得到互相矛盾的答案。
当核心指标有明确口径、常用数据集经过认证、权限边界清晰，并且有人维护数据与回答使用问题时，再扩大自助分析范围。否则用户确实可能更自由地取数，却也更容易把不同筛选条件、不同口径的结果当成同一件事。可以先挑一个边界清楚的主题试运行：列出可用数据集、允许的分析范围和结果解释方式，再收集用户实际提出的问题。
AI 或预测分析也应遵循同样的前提，额外验证数据质量、适用场景和人工复核责任；它们是可选能力，不是 BI 建设必须抵达的终点。
我负责跟进 BI 项目，目前最容易汇报的是上线了多少张报表、接入了多少数据源，但这些数字似乎不能说明业务是否真的受益。我应该观察哪些信号，才能决定下一阶段是扩展、改造还是暂停？
把验收指标对应到建设前的问题，而不是只看报表数量。若目标是提升经营数据的可获得性，可记录目标用户的实际使用情况；若目标是减少口径争议，可统计关键指标问题是否有明确解释和责任人；若目标是更快处理异常，则追踪异常发现后是否有人接手、是否完成处理。
建议先记录现状，再在试点周期结束后用同一口径复查，不必套用未经验证的行业门槛。若访问量上升但业务动作没有变化，先检查报表是否回答了真实问题；若使用不活跃，检查入口、内容相关性和培训；若结果频繁被质疑，则优先修复口径、数据质量或权限设计，再考虑增加高级功能。
读者评论
文章把移动 BI 放在指标口径和可信报表之后，顺序比较务实。数字定义没统一时，手机端越及时，反而越容易把争议暴露出来。
异常处理漏斗的示意很直观，提醒不等于闭环。实际落地时，责任人、处理时限和复核方式确实需要一起设计。
自助分析区分认证数据集和个人探索空间，这个边界很重要，也能减少临时分析结果被误当成正式经营数据的风险。
文中强调按进入条件推进，而非按固定工期上智能功能，比较符合不同团队数据基础差异较大的实际情况。
移动页面不必复制桌面报表，优先展示变化、更新时间和明细入口更贴近使用场景。不过弱网和权限测试也不能省略。