AI落地第一步：如何把模糊业务需求转化为可验证的精准问题

1. 项目概述为什么“问对问题”比“跑通模型”更难也更重要你有没有遇到过这样的场景团队花三个月搭好一个AI推荐系统上线后业务方盯着后台数据看了半天突然问“这个‘相关度分数’到底是怎么算出来的它和我们真正想提升的‘用户复购率’之间到底隔着几层逻辑”——那一刻整个会议室安静得能听见空调外机的嗡鸣。不是模型不work而是从一开始大家就没在同一个问题频道上对话。这正是标题“The Road to Credible and Value-Driven AI: Start with Asking the Right Questions.”直击的核心可信、可落地、能创造真实商业价值的AI从来不是从调参、换模型、堆算力开始的而是从一句精准、具体、可验证的提问出发的。它不是技术流程的起点而是价值判断的锚点不是工程师的单人任务而是产品、业务、法务、用户体验多方共同打磨的语言契约。我做过27个跨行业AI落地项目从制造业设备故障预测到连锁药店慢病管理提醒再到地方政府的惠民政策匹配引擎。踩过最深的坑90%都出在“问题定义”环节——比如把“降低客户投诉率”粗暴翻译成“训练一个投诉文本分类模型”却没追问“过去6个月投诉里有多少是因物流延迟引发的其中又有多少延迟本可通过提前48小时预警避免”再比如做信贷风控模型时业务方说“要更准”但没说清“更准”是指“减少坏账损失”还是“不误杀优质白名单客户”结果模型AUC涨了0.03但审批通过率暴跌22%一线销售直接罢工。所以这篇内容不是教你怎么写prompt、怎么选LoRA、怎么部署vLLM——那些是“路已铺好后如何加速”的事。我们要一起拆解的是在第一行代码还没敲之前在第一个数据表还没导入之前在第一次站会还没开之前你该用什么方法、什么框架、什么话术把模糊的业务期待拧成一句能让算法工程师点头、让法务同事签字、让老板愿意批预算的“好问题”。它适用于所有角色产品经理要拿它说服技术团队工程师要用它守住交付底线管理者凭它判断项目是否值得投入。接下来的内容全部基于真实项目中的问题定义工作表、会议纪要、被退回三次的需求文档以及我亲手划掉又重写的17版问题陈述草稿。2. 问题定义的底层逻辑从“技术可行性”转向“价值可验证性”2.1 为什么90%的AI项目死于“伪问题”所谓“伪问题”不是语法错误而是缺乏可操作的验证路径。它听起来很专业甚至带点技术光环但一旦拆解就会发现它无法被测量、无法被归因、无法被证伪。比如“提升用户体验” → 伪问题。体验是什么用什么指标定义是页面停留时长任务完成率NPS如果用户停留变长是因为卡顿这算“提升”吗“构建智能客服” → 伪问题。智能的标准是什么是回答速度准确率还是用户挂电话前没说“我要转人工”没有明确定义就无法设计评估方案。“用AI赋能业务决策” → 伪问题。赋能的具体动作是什么是生成周报是预警风险是推荐下一步动作不同动作对应完全不同的技术架构和数据需求。我在某零售企业做促销效果归因项目时最初需求是“用AI分析促销活动效果”。我和业务总监聊了三轮才把这句话掰开第一轮“效果”指什么答“就是卖得好不好。”第二轮“卖得好”怎么量化是GMV毛利还是新客获取成本答“都要看但最头疼的是每次大促后市场部说效果好运营部说库存积压财务部说毛利没涨……我们想搞清楚到底谁对谁错。”第三轮“那‘搞清楚’的交付物是什么是一份报告一个实时仪表盘还是能自动调整下一场促销预算的API”答“如果能告诉我这场‘满300减50’活动到底让多少原本只买200元的顾客多花了100元而没让多少原本买500元的顾客因此少买了200元——这个数字我们就能拍板下次预算。”最终问题被锁定为“在控制用户历史购买力、品类偏好、地域消费水平等变量的前提下量化本次‘满300减50’促销对单客客单价的增量贡献单位元置信区间≤±8元。”这个表述里藏着三个关键转变从定性到定量“效果好”变成“增量贡献元”从笼统到可控明确要控制哪些混杂变量排除干扰从模糊到可验收置信区间≤±8元是技术团队能承诺的精度也是业务方能接受的误差范围。提示判断一个问题是否“真”就问自己如果明天必须向CEO汇报结果这个答案能不能用一句话说清这句话里有没有具体数字、明确单位、清晰边界如果没有立刻退回重写。2.2 “好问题”的四维校验框架我用一张表格总结了过去五年中所有成功落地项目的初始问题陈述提炼出四个不可妥协的维度。任何一维缺失问题就存在结构性风险维度核心要求反例伪问题好问题示例为什么重要价值锚点必须直连一项可衡量的业务结果收入、成本、风险、体验指标“提升模型准确率”“将信贷审批中‘误拒优质客户’的比例从12%降至≤5%同时保持坏账率不超2.3%”避免技术自嗨确保资源投入有明确回报预期因果边界明确区分“AI干预的动作”与“期望影响的结果”并声明控制变量“用AI预测设备故障”“在停机前72小时内基于振动传感器温度数据将轴承失效的提前预警准确率Precision24h提升至≥85%排除因维护计划变更导致的误报”防止归因混乱让AB测试设计有依据数据契约问题中隐含的数据需求必须现实可得且质量可验证“用用户全行为数据优化推荐”“基于近90天APP内点击、加购、支付三级漏斗日志字段完整率≥99.2%将首页‘猜你喜欢’模块的30日复购引导率提升1.8pp”避免需求提出时数据根本不存在或ETL链路无法支撑责任闭环明确问题解决后的决策权归属与行动触发机制“生成销售预测报告”“当周销量预测偏差连续2周15%时自动触发采购建议邮件含TOP5缺货风险SKU及建议补货量由区域经理48小时内确认执行”确保AI输出不沦为PPT装饰真正驱动业务动作这张表不是检查清单而是谈判工具。每次需求评审会我会把它投影出来逐项和业务方对齐。最常卡住的是“因果边界”——很多业务方本能地想把所有相关因素打包进AI认为“越多数据越准”。但实操中增加一个噪声变量比如把天气数据强行加入电商推荐可能让模型在晴天表现更好雨天崩盘而业务根本无法解释原因。真正的专业是敢于说“这个数据我们这次不用”并给出扎实的理由。2.3 从“业务语言”到“AI可执行语言”的翻译规则业务方说的“快”工程师听的是“P95响应时间200ms”业务方说的“准”工程师要的是“F1-score≥0.82且对高价值客户群的召回率≥0.75”。翻译不是文字游戏而是建立一套双方认可的“语义字典”。我坚持三个硬性规则规则一禁用形容词启用度量单位❌ “更智能的搜索” → ✅ “将长尾查询搜索词长度≥5且月均搜索量100次的首条结果点击率从当前18.3%提升至≥25.0%”❌ “更安全的审核” → ✅ “将涉政类违规内容漏放率漏放数/总违规数从0.7%压降至≤0.1%允许误判率误判数/总正常内容数上升至0.05%”规则二所有百分比必须声明分母❌ “提升转化率30%” → ✅ “将从商品详情页进入结算页的用户中完成支付的比例从当前12.4%提升至16.1%即绝对值3.7pp”为什么因为“提升30%”可以是10%→13%也可以是1%→1.3%——后者对业务几乎无感却可能让算法团队多干两周。规则三时间窗口必须精确到小时/天❌ “实时预警” → ✅ “从传感器数据入库到预警消息推送至运维APP端到端延迟≤8秒P99”❌ “每日更新” → ✅ “模型每日03:00完成训练03:15前将新预测结果写入业务数据库供当日晨会使用”时间模糊是交付灾难的温床。我见过太多项目卡在“实时”二字上业务方以为是毫秒级工程师按分钟级设计最后上线当天业务方拿着秒表计时工程师在服务器前抓狂。这套翻译过程本质上是在画一条“信任基线”。当业务方看到“漏放率≤0.1%”时他明白这是拿0.05%的误判率换来的当工程师看到“P99延迟≤8秒”他就知道必须放弃某些复杂特征工程。问题定义完成的那一刻不是项目启动而是双方对“什么能做、什么不能做、代价是什么”达成了书面共识。3. 实操工具箱四步法手把手写出可落地的“好问题”3.1 第一步用“5Why分析法”挖出真需求附真实会议记录很多人以为问问题是发散思维其实恰恰相反——它是极致的收敛。我用丰田生产体系的“5Why”法连续追问5个为什么强制剥离情绪化表达直达根因。以下是我某次医疗AI项目的真实记录已脱敏业务方原话“我们要一个AI系统帮医生快速诊断肺癌。”Q1为什么需要‘快速诊断’A“现在三甲医院影像科每天要看200张CT医生看片疲劳早期结节容易漏诊。”Q2为什么‘漏诊’是核心痛点A“漏诊导致患者错过黄金治疗期不仅影响疗效还引发大量医患纠纷——去年我们科室因此赔了137万。”Q3为什么现有流程无法解决漏诊A“双人复核制成本太高三甲医院也做不到100%覆盖而且资深医生和年轻医生对‘磨玻璃影’的判断差异很大。”Q4为什么AI能解决这个差异A“我们希望AI成为‘永不疲倦的第二双眼睛’尤其在夜班、节假日等人力薄弱时段给出标准化初筛意见。”Q5如果AI给出初筛意见医生最需要它做什么A“不是直接给结论而是标出‘高风险区域’比如直径5mm的结节并附上3条最相关的影像学特征如分叶征、毛刺征、胸膜凹陷这样医生30秒内就能判断是否需要重点复核。”最终问题被定义为“在医生标注的肺部CT影像中定位并分割出所有直径≥3mm的结节区域对其中直径≥5mm的结节输出其分叶征、毛刺征、胸膜凹陷三项特征的置信度评分0-100要求① 结节定位召回率≥92%以放射科主任复核结果为金标准② 三项特征评分与三位副主任医师平均评分的皮尔逊相关系数≥0.85③ 单张CT处理时间≤12秒P95。”这个过程耗时2小时但省去了后续3周反复返工。关键在于第5个Why的答案直接决定了AI的输出形态——不是替代医生而是增强医生的注意力分配效率。如果停在第3个Why可能就做成一个黑盒诊断模型结果医生根本不信、不敢用。3.2 第二步用“价值流图谱”锁定AI介入点很多AI项目失败是因为把AI塞进了错误的位置。比如在供应链预测中业务方想要“更准的销量预测”但实际瓶颈不在预测模型而在销售代表手工录入的渠道订单数据存在30%的滞后和22%的错填。此时AI再准也没用。我用“价值流图谱”Value Stream Mapping来可视化业务全流程只在三个位置考虑AI介入信息断点人工需要跨5个系统查数据才能做决策的地方认知瓶颈人类处理信息的速度/精度已达极限如每秒分析100路视频流决策真空规则模糊、经验主导、新人难以复制的环节如信贷审批中的“软信息”评估。以某银行小微企业贷为例原始流程是客户经理收集材料→风控专员人工审核→主管终审→放款。我们绘制价值流图后发现73%的拒贷发生在“风控专员审核”环节其中61%的拒绝理由是“经营流水不稳定”但专员需手动打开网银截图、Excel计算近6个月波动率而银行已有API直连企业对公账户流水数据实时可取。于是AI介入点被精准锁定在“自动计算并标注经营流水稳定性指标如近6个月月均流水标准差/均值≤0.35当指标异常时高亮显示异常月份及关联交易对手供专员5秒内定位问题。”而不是泛泛而谈“用AI做风控审批”。这个介入点带来的改变是专员单笔审核时间从18分钟→3分钟拒贷理由描述准确率从64%→91%更重要的是新员工培训周期从3个月→2周——因为“稳定性指标”把模糊经验转化成了可量化的数字。注意画价值流图谱时务必邀请一线操作者如客户经理、产线工人、护士参与。管理者眼中的“高效流程”在执行者手里可能是“每天要填7个重复表格”。我曾在一个工厂项目中发现所谓“AI质检”需求根源是质检员要手写23项参数而设备PLC早已输出这些数据——AI要做的根本不是识别缺陷而是自动填表。3.3 第三步用“反事实检验表”预判落地风险写完问题陈述后别急着开发。拿出一张A4纸画四栏表格进行“反事实检验”What if not?假设条件如果不成立会发生什么我们的应对预案责任人数据质量达标字段完整率≥99%模型在上线首周因缺失“用户最近一次退货原因”字段误判32%高价值客户为流失风险启用降级策略缺失该字段时用“近30天退货频次”替代并在仪表盘红色预警数据工程师业务流程不变审批仍需人工签字法务部临时要求所有AI建议必须附带可追溯的决策路径图已预留SHAP值计算模块可在0.5秒内生成可视化路径图算法工程师用户接受度达标点击AI建议率≥40%运营人员习惯性忽略弹窗导致AI建议无人执行在CRM系统中嵌入“一键采纳”按钮采纳后自动同步至工单系统产品经理计算资源充足GPU显存≥32GB云平台临时调度故障可用显存仅剩16GB已准备轻量版模型参数量压缩40%精度损失≤0.8pp运维工程师这张表的价值在于把“可能出问题”的想象转化为“必须准备好”的动作。它强迫团队在乐观开局前先集体面对悲观现实。我在一个政务项目中正是因为提前写了“如果市民投诉量突增300%如台风天模型能否扛住并发”这一条才在上线第三天台风登陆时从容启用了预设的流量熔断异步队列方案而其他部门的系统全崩了。3.4 第四步用“三方签字确认单”固化共识所有讨论、修改、妥协最终必须落在一份《AI问题定义确认单》上由三方签字业务方签字人对该结果负责的KPI承担者如销售总监、运营VP技术方签字人对该实现负责的CTO或技术负责人合规方签字人法务或数据安全官确认无合规风险。确认单不是一页纸而是包含四个附件主问题陈述即最终版“好问题”含所有四维校验细节数据契约附件明确数据源、字段、更新频率、质量SLA、获取方式验收标准附件定义AB测试方案、基线数据、统计显著性要求、灰度发布节奏退出机制附件明确什么情况下项目可终止如连续2次迭代后核心指标无改善或合规审查未通过。我坚持一个原则没有这份签字单绝不启动任何开发工作。曾有个项目业务方口头答应所有条款但拒绝签字理由是“太正式”。我当场暂停会议说“您签的不是名字是‘如果结果不如预期我愿承担KPI未达成的责任’。如果您不确定说明问题还没想透我们继续聊。” 最终他签了而且签完主动加了一条“若模型使客服首次响应时间缩短我承诺将释放的工时用于增加1对1客户回访。”——这才是真正的价值共识。4. 高频陷阱与避坑指南那些没人告诉你的“问题定义”暗礁4.1 陷阱一“解决方案先行”综合症典型症状业务方一开口就说“我们要上大模型”“得用图神经网络”“必须部署在私有云”。这就像病人走进诊所不描述症状直接说“给我开青霉素”。我的应对三步法物理隔离请业务方暂时离开会议室我和工程师先用10分钟基于现有数据和流程列出3个不依赖新技术的改进方案如优化表单字段顺序、增加前置校验规则、重构数据看板。成本对比把每个方案的ROI投入人天 vs 预期收益做成简单表格。往往发现改一个前端校验规则能解决70%的脏数据问题成本是0.5人天而上大模型清洗数据成本是45人天收益却只有15%。技术兜底如果业务方坚持要新技术就问“如果这项技术明天失效您最不能接受哪个业务环节中断我们先保障它。”——这通常会暴露真实瓶颈。在某保险公司的项目中业务方坚持“必须用LLM做保单解读”我按上述步骤操作后发现他们真正的痛点是“理赔材料退回率高达41%因为客户上传的发票图片模糊、缺章、信息不全”。最后方案是用轻量OCR规则引擎在用户上传瞬间实时校验不合格直接拦截并提示“请拍摄清晰、带公章的发票正面”。上线后退回率降到9%投入仅2人天。LLM留着明年做“理赔进度口语化播报”再说。4.2 陷阱二“指标套娃”幻觉业务方常陷入“指标套娃”为了证明AI有效层层嵌套指标最终失去业务意义。例如目标提升用户留存 → 拆解为提升“7日留存率” → 再拆解为提升“次日打开率” → 再拆解为提升“推送点击率” → 最终AI模型优化的是“推送文案的CTR”。问题来了CTR提升了但用户点开后发现内容无关反而加速流失。破解口诀“倒推三步见血封喉”从最终业务目标如“提升年留存率”出发倒推一步什么行为直接导致留存提升如“用户在首月完成3次核心功能使用”倒推两步什么干预能促进该行为如“在用户第2次使用后精准推送第3次使用的引导任务”倒推三步AI在此环节的最小可行输出是什么如“预测用户完成第2次使用后未来24小时内使用第3次功能的概率并对概率65%的用户触发引导”。这个“三步倒推”砍掉了所有中间指标直指AI该交付的原子级动作。我在教育科技公司做“续费率提升”项目时就是靠这招把业务方从纠结“课程完课率”“练习提交率”中拉出来聚焦到“在用户学习完第5节课后预测其7日内购买进阶课的概率”模型上线后续费率提升2.3倍——因为所有资源都用在了最关键的转化节点上。4.3 陷阱三“静态问题”绑架动态业务AI项目最大的幻觉是认为业务问题是静态的。但现实是促销策略每月变监管政策季度调用户口味年年新。一个在Q1有效的“优惠券发放模型”到Q3可能因竞品跟进而失效。我的动态防护机制问题版本号每个问题陈述带版本号如V1.2每次业务规则变更必须更新版本并重新签字衰减监控在生产环境埋点监控“问题定义”中核心指标的衰减速率。例如当“预测准确率”连续30天下降斜率0.02%/天自动触发模型健康度检查季度重审会每季度召开“问题有效性评审会”只讨论一件事“这个问题今天还是不是业务最痛的点”——如果答案是否定的立即冻结项目释放资源。在某快消品公司的销量预测项目中我们设置了“基线漂移警戒线”当实际销量与预测值的MAPE连续两周18%系统自动暂停预测服务并推送分析报告。结果发现警报触发的原因不是模型坏了而是市场部临时启动了一项未同步给AI团队的线下地推活动。这反而促成了跨部门数据同步机制的建立。4.4 陷阱四忽视“人的接口设计”所有AI系统最终都通过人来使用。但问题定义时90%的团队只关注“机器输出什么”不关心“人如何接收、理解、行动”。必须回答的三个“人因问题”认知负荷这个AI建议需要用户额外思考多久才能理解如果超过8秒大概率被忽略。我们曾把一个复杂的风控评分0-1000分改成“红/黄/绿”三色灯一线审核员采纳率从33%→89%。行动路径看到AI输出后用户下一步该点哪里、填什么、找谁如果路径超过3步失败率飙升。我们在银行项目中把“AI建议提高授信额度”直接做成“一键发起额度调整申请”按钮嵌入审批页面点击即生成工单。容错空间用户误操作后能否5秒内撤回如果AI建议错了用户是否有权威渠道申诉我们在政务项目中为每个AI生成的政策匹配结果都加了“反馈此结果不准确”按钮点击后自动记录至知识库48小时内由人工专家复核并更新规则。实操心得每次写完问题陈述我都会做一次“老人测试”——找一位对该业务完全陌生的60岁以上同事比如我母亲让她用手机操作一遍AI输出的交互流程。如果她能在2分钟内完成说明接口设计合格如果她问“这个箭头是点这里吗”那就得重做。技术可以炫酷但人的理解力永远是天花板。5. 从问题到价值一个完整案例的全程复盘5.1 项目背景某全国性连锁药店的“慢病用药依从性提升”项目业务方诉求原始“用AI帮糖尿病患者按时吃药。”表面看是个典型的AI健康项目但深入聊才发现药店KPI是“慢病会员年销售额”而非“患者健康”当前依从性差的主因不是患者忘记而是“药太贵患者自行减量或停药”药店有2300万慢病会员但只有12%开通了线上购药其余88%依赖到店购药店员每天要服务150顾客根本没时间逐个提醒。5.2 问题定义四步法实战第一步5Why深挖Q1为什么依从性差影响销售额A“患者停药后病情恶化转去三甲医院开药我们失去后续复购。”Q2为什么患者觉得药贵A“医保报销比例低自费部分高而且很多患者不知道有‘长处方’政策可以一次开3个月药省去多次挂号费。”Q3为什么店员不告知长处方政策A“政策细则复杂不同城市、不同药品报销比例不同店员记不住而且顾客一问‘我能不能用’店员怕答错担责。”Q4为什么AI能解决这个信息差A“如果AI能根据顾客的医保类型、所在城市、所持药品实时算出‘本次购药自费金额’和‘若用长处方3个月总自费金额’并生成一句话建议店员照着念就行。”Q5店员最需要AI提供什么形式的支持A“最好是一个弹窗显示‘王阿姨您这次买二甲双胍自费86元如果开3个月长处方总自费210元但省了2次挂号费60元实际多花150元但能少跑2趟’——这样我直接念给她听她马上懂。”第二步价值流图谱定位绘制购药全流程后AI介入点锁定在店员扫码药品后收银系统弹出的“智能用药建议”窗口。这是唯一既接触患者、又掌握全部必要数据药品编码、医保类型、城市、历史购药记录的触点。第三步反事实检验关键假设“医保政策数据库每日更新”。预案若更新延迟4小时弹窗显示“政策数据正在同步建议参考店内公示牌”并自动推送短信给店长。第四步三方签字确认单主问题“在收银系统扫码药品后3秒内向店员弹出结构化用药建议内容包含① 本次购药自费金额② 同药品3个月长处方总自费金额③ 节省挂号费金额④ 一句话决策建议如‘推荐长处方多花150元但省2趟’。要求建议采纳率≥65%店员培训时长≤15分钟。”数据契约对接国家医保局API本地医保局备案政策库字段包括药品通用名、医保目录编码、城市编码、报销比例、起付线。验收标准AB测试对照组用纸质政策手册实验组用AI弹窗观测30天内长处方开具量提升率。5.3 关键实施细节与意外收获技术选型反常识没用大模型而是用规则引擎政策数据库。因为政策是确定性知识大模型反而会“幻觉”编造不存在的报销比例。数据冷启动方案政策库上线前用历史10万条购药记录反向推算各城市各药品的平均自费比例作为临时基线。最意外的收获弹窗上线后店员反馈“患者开始主动问‘我还能省多少’”药店顺势推出“慢病管家”服务包含定期用药提醒、三甲医院挂号协助首月付费转化率18%远超预期。最终结果项目上线6个月后该药店慢病会员年复购率提升27%长处方开具量增长3.2倍店员平均每日多服务8位慢病顾客。而整个AI模块仅用3名工程师、8周时间完成。5.4 复盘启示问题定义如何重塑项目价值这个项目成功的关键不是技术多先进而是问题定义完成了三次升维从“健康目标”升维到“商业目标”不追求“提升依从性”而追求“提升复购率”让AI价值可量化从“技术输出”升维到“人机协作”不追求“AI独立决策”而设计“AI生成话术店员自然传达”降低使用门槛从“单点功能”升维到“服务入口”弹窗不仅是用药建议更是“慢病管家”服务的触发器打开了新的营收场景。这就是标题中“Credible and Value-Driven”的真意可信是因为每一步都经得起业务逻辑推敲价值驱动是因为问题本身就长在业务增长的脉络上。6. 写在最后关于“提问”这件事的个人体会做了十多年AI落地我越来越相信一个伟大的AI系统往往诞生于一句朴素到近乎笨拙的提问。比如“能不能让仓库拣货员一眼看出这箱货该发往哪个门店”——这句话催生了AR拣货系统再比如“客户投诉说找不到客服能不能让电话一接通系统就告诉坐席这位客户过去3个月买了什么、退过几次、上次投诉啥”——这句话驱动了全渠道客户数据平台的建设。而那些堆砌着“多模态”“自监督”“联邦学习”术语的需求文档最后大多躺在服务器里吃灰。因为它们从起点就错了不是在解决人的难题而是在证明技术的精妙。所以下次当你面对一个AI项目时请放下Jupyter Notebook合上技术白皮书先做一件最“不技术”的事找一张白纸写下业务方最原始的那句话用红笔划掉所有形容词、副词、技术名词用蓝笔标出所有没说清的数字、单位、时间、责任主体最后用黑笔只写一句“我们到底要让谁在什么条件下用什么可验证的方式得到什么具体结果”这句话写出来项目就成功了一半。剩下的一半交给代码、数据和耐心。我个人在实际操作中发现最有效的提问时刻往往不在会议室而在业务现场蹲在药店柜台后看店员手忙脚乱翻政策手册站在产线旁听老师傅抱怨“这台设备响三声是小毛病响五声就得停机”或者跟着快递员跑一天记下他每单要打几个电话、查几个APP。问题不在PPT里而在真实的泥土里。把这句话刻在电脑边框上每次启动IDE前看一眼——它比任何模型调优技巧都管用。