转化漏斗里某一步的转化率从 62% 降到 41%，并不能直接得出“流程设计变差了”。我检查运营数据时，通常先追问三个问题：这两个数字的分母是否一致，进入这一步的用户是否可比，埋点是否准确记录了实际行为。只有先排除口径、流量和采集问题，再把异常与用户操作、页面反馈、流程规则对照，漏斗才有资格成为评估流程设计质量的证据。

一、先讲结论：漏斗负责发现异常，不负责替你定罪

1. 流程质量不是一个转化率数字

转化漏斗能把一条业务路径拆成若干连续或相关的用户动作，显示用户在哪些环节继续、停留或退出。它适合回答“哪个步骤值得查”，但不能仅凭一段转化率就回答“为什么用户离开”或“是不是流程设计错了”。

例如，提交订单到支付成功的转化率下降，可能是支付步骤多了一次确认，也可能是支付渠道故障、用户结构变化、订单金额上升，或者支付成功事件漏报。漏斗给出的首先是异常位置，不是异常原因。

评估流程设计质量，要同时看路径是否清楚、关键动作是否可完成、阻碍是否可解释、数据是否可信，以及流程最终是否达成业务目标。单看某个节点的局部转化率，容易把局部改善误当成整体改善。

2. 先按“发现、排除、解释、验证”工作

我建议把漏斗检查分成四步：先发现值得关注的节点；再排除统计口径和数据采集问题；接着用人群、渠道、设备和用户行为寻找原因；最后通过改动前后可比的数据，或条件允许时的实验，验证判断。

这个顺序看起来比“看到下降就改页面”慢，但它减少了两类浪费：把正确流程改坏，以及把数据故障当成用户体验问题。尤其在多端、多渠道和复杂业务里，先查证据边界通常比先开优化需求更省时间。

3. “质量”要放在用户目标和业务结果之间看

流程质量既不是“步骤越少越好”，也不是“所有节点转化率越高越好”。对于注册流程，减少无必要字段可能有利于完成注册；但若后续需要核验用户资格，完全取消必要信息也可能提高低质量注册，增加审核、客服或风控成本。

因此我会把结果分成两层：一层是流程内结果，例如进入下一步、完成提交、支付成功；另一层是流程外结果，例如有效线索率、退款率、履约完成率或后续留存。只有把两层连起来，才不容易被“局部数字变漂亮”误导。

二、从真实工作场景出发：漏斗为什么经常把人带偏

1. 一条报表曲线里，可能混着三种变化

假设某电商业务的支付完成率连续两周下降。运营团队看到变化后，可能先怀疑收银台步骤过多；产品团队认为是按钮位置；数据团队则发现其中一天的支付成功事件量异常偏低。三个判断都可能有道理，但只有一个可能直接对应流程问题。

我会先把“转化变了”拆成三种可能：用户实际行为改变、进入漏斗的人群改变、测量方式改变。三种变化在汇总报表里看起来相似，却需要完全不同的处理方式。页面重做不能修复事件漏报，追加投放也不能解决表单校验错误。

还有一种更隐蔽的情况：流程没有改变，业务规则或外部环境却变了。例如活动结束后流量来源恢复常态，低意向用户占比下降，整体转化反而上升；或者提高了商品价格后，高意向用户仍能下单，但支付节点出现更多犹豫。此时，时间上的先后关系不能直接当作因果关系。

2. 漏斗的起点决定你在评价谁

“商品页到支付成功”的漏斗，评价的是进入商品页的人中有多少最终支付；“广告点击到支付成功”的漏斗，则把广告吸引力、落地页、商品选择、结算和支付都纳入同一条路径。后者适合观察获客到成交的整体效率，却不适合直接评价收银台设计。

我会先问清楚本次分析的责任边界：要评估哪一段流程，起点应放在该段的入口，终点应放在该段可控制的结果。如果入口太靠前，渠道和人群因素会混进来；如果终点太靠前，局部改善可能掩盖后续损失。

3. 真正的业务路径不总是一条直线

很多用户会返回上一步、暂存后再继续、切换设备、重复提交，或者跳过某个可选步骤。把所有人强行塞进“页面一，页面二，页面三”的直线漏斗，会让未按预设顺序行动的用户看起来像流失。

这不意味着所有流程都要做成复杂的路径图。我的原则是：先用最简单的漏斗发现问题；只有当分支、回访或跨端行为确实影响判断时，再按必要粒度拆路径。模型复杂度应服务决策，而不是为了显得分析精细。

三、常见误区：看起来是在分析漏斗，实际上是在跳过验证

1. 把“流失”直接翻译成“用户不喜欢”

漏斗中的流失，通常只是某个统计窗口内没有观察到下一步事件。它不一定意味着用户不喜欢当前页面，也可能意味着用户稍后回来、换设备继续，或在业务规则允许的情况下直接完成了另一条路径。

对“流失”的解释必须附带边界：统计的是用户、会话、订单还是事件？观察窗口是当天、七天还是整个生命周期？是否把重复操作去重？这些问题没有答案时，“用户在此处离开”只是一个未经校验的报表描述。

2. 把行业平均值当作本业务的及格线

外部转化率看起来能提供判断标准，但不同网站、客单价、渠道结构、用户意图、归因方式和统计周期之间往往不可直接比较。脱离定义的“行业平均值”，容易制造精确感，却未必提供可执行的判断。

如果团队需要外部对标，我会要求同时说明来源、样本范围、采集时间、分母口径和业务类型。无法满足这些条件时，优先建立自己的历史基线，并与同渠道、同人群、相近周期比较。基线不是永恒标准，但通常比来路不明的平均数更贴近实际决策。

3. 只看百分比，不看样本量和绝对人数

小样本下，一个用户的变化就可能显著改变转化率。假设一个流程版本有 20 人进入、10 人完成，完成率是 50%；下一个版本有 22 人进入、9 人完成，完成率约为 41%。表面上下降近九个百分点，但这还不足以说明设计一定变差。

在报告中，我会把分子、分母和转化率放在一起，并观察变化持续时间、波动范围和人群分布。流量不足时可以先把结论标记为“观察信号”，继续收集数据，而不是急着做确定性判断。

4. 把平均转化率当成所有用户的共同体验

一个总体数字可能同时包含新老用户、不同设备、不同渠道和不同地区。整体平稳，不代表所有人都平稳；整体下降，也不代表每个群体都变差。某个高流量人群的变化可能掩盖小但关键的人群问题。

分群也不是切得越细越好。过度切分会让样本变小、比较变多，增加偶然波动被误判的机会。我通常先从有业务解释力的维度开始，例如渠道、设备、新老用户、版本和流程路径，再根据异常证据决定是否细化。

5. 只优化掉点最大的阶段

掉点最多的阶段不一定最值得优化。若某环节本来就是合理筛选，例如资格确认或地址有效性校验，取消它可能让进入下一步的人变多，却让后续无效订单、退单或人工处理增加。

评估时要看这个节点承担的业务功能。流程步骤可能带来摩擦，也可能减少风险、帮助用户决策或提高后续成功率。优化不是机械地删除步骤，而是判断这一步的价值能否以更低成本实现。

6. 把上线后的变化直接归因于改版

如果新页面上线后转化率上升，不代表上升一定由新页面造成。同期可能出现了流量来源变化、促销活动、价格调整、季节性波动或数据口径更新。只比较上线前后一段时间，通常只能得到相关性证据。

当改动影响大、流量足或业务风险较高时，优先使用随机分组实验或其他可比对照；条件不允许时，至少检查同时间段、同渠道、同人群和同口径，并把结论表述为“与变化同时发生”，不要写成已证明的因果关系。

四、专业判断逻辑：先定义，再量数，再解释

1. 从业务目标选终点，不从现成事件名选终点

搭漏斗前，我会先把业务目标写成一句能判定真假的话，例如“用户提交的申请通过有效性校验”，而不是“用户点击提交按钮”。点击是行为信号，业务目标可能是成功保存、审核通过或完成履约，两者不能混为一谈。

确定终点后，再倒推关键动作。每一个阶段都应能回答：用户做了什么、系统记录了什么、这个动作为什么是完成流程所必需的。若某个步骤只是页面曝光，却无法说明它与目标结果的关系，就要谨慎把它设成必经节点。

2. 给每一步写清楚进入条件、完成条件和去重规则

可操作的漏斗定义，不应只写事件名称。以申请流程为例，“进入填写页”可以定义为页面成功加载并展示核心表单；“提交申请”可以定义为服务端收到有效提交；“申请通过”则要区分提交成功和审核通过。

至少要明确以下口径：统计对象是什么，分子与分母是什么，用户可以重复进入多少次，跨会话如何连接，观察窗口多长，事件发生时间按客户端还是服务端记录。口径不一定只有一种，但同一轮比较必须保持一致。

3. 分清用户漏斗、会话漏斗和业务对象漏斗

用户漏斗回答“有多少用户推进到下一步”；会话漏斗回答“一次访问中有多少会话完成”；业务对象漏斗回答“有多少订单、线索或申请进入下一状态”。它们各自适合不同问题，不能把一种统计单位的分母与另一种统计单位的分子拼在一起。

例如，用户可能在同一天提交两笔订单。按用户统计时，这个人只算一个；按订单统计时，两笔订单分别进入漏斗。要评价页面是否让用户完成操作，可以看用户或会话；要评价订单支付与履约，更适合以订单作为业务对象，并明确订单状态的变化逻辑。

4. 先检查数据是否可靠，再讨论设计质量

我会优先核对事件是否触发、属性是否完整、前后端状态是否一致、事件是否重复，以及数据延迟是否改变了观察窗口。一个重要原则是：前端按钮点击只能证明用户尝试操作，未必证明系统已成功完成业务动作。关键结果尽量以可靠的业务状态为准。

如果某个节点突然出现异常，先查版本发布时间、埋点变更、接口错误和数据回传延迟。尤其是“前一步人数正常、下一步人数骤降”的断崖形状，既可能是流程阻碍，也可能是阶段事件没有被正确记录。需要用日志、抽样订单或业务状态核对。

5. 计算阶段转化时，保持同一统计对象和观察规则

在最简单的相邻阶段漏斗中，阶段转化率可以表示为：进入下一阶段的统计对象数 ÷ 进入当前阶段的统计对象数。这个公式并不复杂，真正容易出错的是分子、分母是否来自同一批对象，以及下一阶段是否限定在同一观察窗口内。

如果用户可以跳步或返回，团队还要决定采用严格顺序漏斗还是宽松路径漏斗。严格漏斗要求依次发生指定事件，适合检查明确的必经流程；宽松漏斗允许中间存在其他行为或路径，更适合描述真实用户旅程。选择哪一种，取决于要回答的问题，而不是工具默认设置。

6. 采用“异常，原因，证据，验证”的判断链

我会把每个结论写成四部分。第一部分是观察到的异常，如“移动端新用户在地址确认阶段转化下降”；第二部分是候选原因，如键盘遮挡按钮或地址校验提示不清；第三部分是证据，如错误日志、页面录屏和该群体重复修改次数；第四部分是验证，如调整提示后观察有效提交率和后续履约率。

这样的写法能把事实与推断分开。没有证据时，原因应标为假设；没有验证时，优化结果应标为初步观察。对于跨部门协作，这种表达也更有用，因为产品、研发、运营和数据可以围绕同一条证据链行动，而不是围绕各自的直觉争论。

五、案例推演：一次支付转化下降，怎样避免先改错地方

1. 先把情景和数据边界说清楚

下面的案例是为说明排查方法而构造的情景模拟，不是某家企业的真实经营数据，也不是行业基准。假设一个线上零售流程包含“商品详情访问，发起结算，提交订单，支付成功”四个阶段，团队发现最近一周的整体支付完成率下降。

从这组模拟数据看，值得调查的至少有两处：详情页到结算入口的转化，以及订单提交到支付成功的转化。它们可能对应不同问题，不能因为最终支付是业务目标，就把所有注意力都放在最后一步。

2. 先检查“支付成功”是否真的被正确记录

我会先抽取一段订单样本，对照支付平台回调、服务端订单状态和分析报表中的成功事件。若订单已经支付，但事件没有进入报表，优先处理采集链路；若报表中有成功事件，但订单状态没有更新，则要调查重复回调或错误映射。

另外要确认支付完成窗口。用户离开收银台后可能通过短信、银行应用或其他方式完成支付，成功回传也可能延迟。如果报表只统计离开当前页面前的行为，就可能把延迟成功记成流失。窗口应该根据业务实际设定，并在不同周期保持一致。

3. 再拆分渠道、设备和用户类型

假设整体支付完成率下降，分群后发现桌面端变化不大，移动端明显下降；进一步看，移动端问题集中在某个系统版本，并伴随支付失败提示增加。这个证据链比“整体转化下降，所以收银台需要重做”更具体，但仍然只是定位方向，不是最终因果结论。

随后我会检查对应版本的页面变化、支付接口错误率、失败类型和用户重试行为。如果错误集中在一个支付渠道，工作重点应是渠道兼容或异常处理；如果没有技术错误，但用户在费用确认后退出，则应继续检查费用说明、配送信息和支付前的额外步骤。

4. 用阶段数据定位范围，用行为证据解释机制

漏斗通常能告诉我们“哪里变了”，错误日志能告诉我们“系统发生了什么”，页面录屏、客服反馈或用户访谈则有助于理解“用户为什么这么做”。三类证据互相补足，避免只凭某一种数据讲完整故事。

例如，若支付失败率上升与接口错误同步，且错误集中在某种设备，优先排查兼容性；若接口稳定，但用户在选择配送方式时频繁返回，可能是运费、时效或信息展示带来的犹豫；若同一群体从未进入结算，问题更可能在商品信息、库存或购物动机。这里的“可能”很重要，后续仍需验证。

5. 把结果写成可以执行的排查单

完成初步分析后，我不会只写“支付环节体验差，建议优化”。更可执行的结论应说明：异常人群是谁、异常从何时开始、具体阶段是什么、数据口径如何定义、已排除哪些技术因素、还剩哪些原因假设，以及下一步通过什么证据验证。

• 观察事实：移动端某类新用户在提交订单后的支付成功率下降，下降时间与版本更新时间接近。
• 已核实事项：报表口径未变，服务端订单状态与成功事件抽样核对一致。
• 候选原因：支付页面兼容性、失败提示、支付方式可用性或费用展示变化。
• 下一步行动：对照设备错误日志、支付失败原因和页面版本，再确定是否需要界面或技术改动。
• 验证结果：同时观察支付完成率、失败率、退款率和后续订单有效性，避免只看局部节点。

六、从异常到验证：把漏斗结论变成可靠的流程改动

1. 一次只提出能被证伪的核心假设

“让页面更好用”无法直接验证；“移动端新用户在地址填写时频繁因格式校验失败而退出，改为即时展示格式示例后，有效提交率会提高”则包含了人群、环节、机制和预期结果。

好假设不保证正确，但应该允许被数据推翻。如果改动后提交率没有变化，团队就可以检查问题是否真在格式校验，或样本量、实施范围是否足以观察效果，而不是把任何结果都解释成“用户体验有所提升”。

2. 选择验证方式时，考虑影响范围和可控程度

对于高风险、广覆盖、影响收入或合规的改动，随机分组实验通常更适合评估因果效果，但前提是分组可靠、用户体验没有互相污染，且样本和观察时间能够支持判断。实验条件不成熟时，不要为了形式上的“做实验”而忽略数据质量。

如果只能做前后比较，应尽量选择相同口径、相近周期和可比人群，并记录同期促销、价格、渠道预算、产品版本等变化。前后比较可以提供运营判断依据，但证据强度通常低于设计良好的对照实验。

3. 同时设定主指标、护栏指标和观察周期

主指标回答“改动希望改善什么”，例如有效提交率；护栏指标回答“不能以什么代价换取改善”，例如无效申请率、退款率、客服咨询量或后续履约率。没有护栏指标，流程可能只是把摩擦推迟到下一阶段。

观察周期应覆盖用户完成流程的合理时间，也要考虑业务波动。如果订单通常不会在进入流程后立即完成，只看几个小时的数据可能低估转化；如果业务受周末或促销影响，短周期也可能把自然波动误当作改版效果。

4. 关注绝对增量，而不只关注百分比变化

转化率从 20% 增加到 22%，是增加 2 个百分点，也可以说相对增加 10%；两种表达都可能正确，但回答的问题不同。讨论业务价值时还应估算实际增加的有效用户、订单或收入，并扣除成本、退款、无效申请和额外人工处理。

例如，优化后多获得的提交如果大部分无法通过审核，表面转化上涨并不一定带来更多有效结果。反过来，某一步转化没有明显上涨，但错误率下降、客服咨询减少，也可能是有价值的流程改进。指标应贴近决策，不应只追逐容易变动的数字。

5. 留下可复现的分析记录

流程评估不应只留在会议纪要里。建议保存漏斗定义、查询条件、版本时间、样本边界、排除项、图表快照和结论状态。下次指标变化时，团队才能判断是业务真的变了，还是分析方式、埋点定义或数据源发生了变化。

记录还应区分“已验证事实”“待验证假设”和“决策”。这样即使后来发现原假设不成立，也能追溯当时依据，避免新成员把推测误当成历史结论。对需要长期维护的流程，这份记录本身就是运营质量的一部分。

七、不同业务、不同异常，行动优先级不一样

1. 线索或申请流程：不要把“提交”当成“有效”

线索流程应至少区分访问、开始填写、成功提交、有效性核验和销售跟进结果。前端提交率提升，如果伴随联系方式无效、重复线索或跟进接通率下降，可能只是降低了填写门槛，却没有改善业务价值。

行动时优先明确有效线索定义，并将后续审核或跟进状态回连到来源和流程版本。对于需要收集个人信息的场景，还应遵循适用的内部规范和法律要求，只采集完成业务目的所需的信息。

2. 电商交易流程：分开看意向、下单、支付和履约

交易漏斗至少要区分商品浏览、加购或结算、订单创建、支付成功和履约结果。支付失败与未付款不是同一问题；下单增加也不代表履约变好；退款上涨可能说明前段信息不足或用户预期不匹配。

当问题集中在下单到支付，先核对支付可用性、失败错误、订单金额和成功回传；若集中在详情到结算，检查商品信息、库存、配送成本和入口可见性。不要把同一套“减少步骤”建议套给所有环节。

3. 注册或开户流程：减少摩擦不等于取消必要校验

注册流程可以分别观察开始注册、信息提交、验证完成、账户激活和首次关键行为。用户能创建账户，不等于用户已经理解产品或产生持续价值。若只优化注册完成率，可能新增大量未激活账户。

对身份核验、风险控制或必要同意步骤，重点应是让规则清楚、错误可恢复、等待时间可预期，而不是简单删除。可以减少重复输入、提供明确的失败原因和保存进度，但要确保改动不会降低必要的审核质量。

4. 使用量不足：先做数据质量和定性排查

如果关键阶段样本很少，不宜把细分漏斗切得过碎，也不宜仅凭短期百分比判断。此时可先核对事件、观察真实用户完成路径、查看客服和反馈记录，并把当前判断标为方向性假设。

低流量业务还可以检查任务完成率、完成时间、错误类型和流程可理解性。定性证据不能替代规模化的行为数据，却能帮助确定应该埋什么点、优先查什么环节，避免在样本有限时反复追逐随机波动。

八、取舍与边界：不是所有问题都值得用漏斗解决

1. 什么时候先追求可比，什么时候先追求完整

短期评估改版时，口径一致和人群可比往往比一次性覆盖所有复杂路径更重要。若新增了大量新事件，却无法与旧版本的定义对应，趋势可能断裂；这时宁可先保留少数稳定指标，再逐步补全路径证据。

长期建设分析体系时，则需要更完整地覆盖分支、回访、跨端和业务对象状态。两者并不冲突：先保证当前决策可比，再逐步提升模型表达能力。不要为了追求一次性完美而延迟所有可用判断。

2. 什么时候可以删步骤，什么时候应改善步骤

若某一步没有明确的用户价值或业务控制价值，且数据与用户反馈都显示它造成了额外摩擦，可以评估合并或移除。但如果这一步用于防止错误提交、解释关键费用、核验资格或保护账户安全，删除可能把成本转移到审核、客服、退款或风险处置。

对有必要保留的步骤，优化方向可以是减少重复输入、明确字段要求、提供即时反馈、保存已填内容、说明处理时长，或让失败后可以恢复。判断标准不是“少一个页面”，而是用户更容易完成任务，业务结果也没有明显变差。

3. 什么时候用实验，什么时候接受方向性证据

当决策影响大、方案存在多个版本、可稳定分组且样本足够时，实验更值得投入。若流量很低、改动紧急、用户之间容易互相影响，或随机分组会引入更高风险，可以使用分阶段上线、前后对比、相似群体对照和定性证据组合判断。

关键不是把每次改动都包装成严格实验，而是清楚说明证据强度。证据较弱时，先小范围验证、保留回滚能力；证据较强时，再扩大覆盖。这个取舍能避免把分析方法当仪式，也能降低大范围错误上线的成本。

4. 什么时候采用复杂漏斗，什么时候保持简单

如果一个简单漏斗已经能定位稳定问题，就不必马上引入复杂路径建模。只有当用户回访、并行步骤、跳步或跨端行为会改变业务判断时，才值得增加路径层次。复杂模型的成本包括定义、埋点、维护、解释和跨团队对齐，不是零成本。

判断复杂度是否值得，可以问一个问题：新增这层分析，是否会改变行动选择？如果无论看哪条分支，团队都要做同一件事，新增图表可能只是增加阅读负担。反之，如果分支对应不同责任团队或不同修复方式，复杂度就可能带来实质价值。

九、可直接执行的漏斗检查清单

1. 建漏斗前：先让问题可回答

• 这次要评估的是哪一段流程，责任边界在哪里？
• 业务终点是点击、提交、支付成功，还是审核通过与履约完成？
• 统计对象是用户、会话、订单、申请，还是事件？
• 每个阶段的进入条件和完成条件是否可复核？
• 重复行为、回访、跨端和跳步如何处理？
• 本次比较的观察窗口和去重规则是否一致？

2. 看结果前：先排查测量风险

• 关键事件是否在页面、客户端和服务端按预期记录？
• 是否存在漏报、重复上报、延迟回传或事件名称变更？
• 前端点击是否被误当作服务端业务成功？
• 身份识别、登录状态和跨设备连接是否影响统计单位？
• 是否能用日志、业务状态或抽样对象复核关键数字？

3. 定位异常时：避免用汇总值讲单一故事

• 异常从什么时候开始，是否与版本或运营活动同步？
• 变化集中在哪个渠道、设备、人群、地区或流程路径？
• 分子、分母和绝对人数分别怎样变化？
• 同一时期是否有价格、库存、流量预算或规则调整？
• 用户行为、错误记录和一线反馈能否支持某个原因假设？

4. 优化后：检查收益是否真实且没有转移成本

• 主指标是否对应真正的业务目标，而非方便采集的点击指标？
• 是否设置有效率、退款、错误率、人工耗时等护栏指标？
• 前后口径是否一致，比较的人群是否足够可比？
• 观察周期是否覆盖用户完成流程所需时间？
• 是否区分了确定结论、初步观察和仍待验证的假设？
• 是否记录改动、分析条件和回滚判断？

5. 把结果沉淀为团队共用的结论

建议每次检查都留下简短的分析卡片：业务目标、漏斗定义、异常阶段、样本范围、数据核验结果、候选原因、证据强度、计划动作和复核日期。它不需要做成复杂报告，但要让另一个人能够复现主要判断。

如果团队使用数据分析平台或内部报表系统，可以把指标定义、筛选条件和版本信息固定记录下来，减少不同人用同一个名称却采用不同口径的情况。工具的价值在于降低重复核对成本；它不能替团队决定统计单位、业务目标和因果边界。

十、最后的判断：先确认“数对不对”，再讨论“流程好不好”

1. 漏斗是一种排查地图，不是自动诊断器

这篇方法的核心不是多做几张图，而是让每个结论都能沿着证据链回到业务现场：哪个人群在哪个阶段发生了什么变化，数据记录是否可信，有哪些解释可以排除，准备通过什么行动验证。

当漏斗中的异常同时得到口径核验、分群对照和用户行为证据支持时，流程问题的判断才更有分量。如果只有一个汇总百分比，最诚实的结论往往不是“流程设计失败”，而是“发现了一个需要进一步核查的信号”。

2. 下一步从一条最重要的业务路径开始

你可以先选一条近期最影响业务结果的路径，不必一口气梳理所有流程。写清终点、统计单位和观察窗口，检查关键事件与服务端状态是否一致，再按渠道、设备或新老用户做第一轮对照。

找到异常后，先把原因写成待验证假设，再选择与风险相称的验证方式，并同时观察最终结果和护栏指标。真正有用的漏斗分析，不是告诉团队用户在哪里“掉了”，而是帮助团队更可靠地判断：该不该改、先改哪里、改完如何知道是否值得。

免费注册

咨询方案

扫码咨询方案