过去一年里我参加的不少方案评审会有一个感受特别强烈一旦“AI”这两个字出现在汇报材料里很多人原本的技术判断力就开始短路。面对一个号称“基于大模型”的需求分析工具有人盯着PPT上的漂亮架构图就直接拍板面对一个在本地跑通小Demo就宣称“效果惊艳”的质检系统验收组差点一路绿灯。技术圈子好像突然回到了“拿着锤子找钉子”的时期只是这次锤子变成了“人工智能”。我并不是反对用AI恰恰相反我觉得越是这种“人人都在讲AI”的时期越需要一套能帮人回归理性的判断方法。这几年我一边带项目一边做评审把大量被吹上天的方案、被轻松吹掉的方案以及最后实际落地效果不错的方案放在一起对比慢慢沉淀出一个非常朴素、但每次都能在关键决策时拉我一把的框架。我把这套框架叫“AI三问”。1. AI三问从哪来一套给技术方案“祛魅”的检查框架事情还得从一次失败的选型说起。某公司要做一个“智能合同审核”系统当时考察了市面上好几家供应商。有一家做得很“唬人”演示的时候用几份典型的合同现场标错了三处条款演示人员很流畅地说“这是模型在提示风险”。在场负责人觉得“哇这就是我要的智能感”差点直接签合同。我们后来拿了一份带少量异常条款的真实合同样本去试结果系统把正常条款标红了一大片反而真正有问题的条款漏了好几条。为什么差距这么大因为演示数据是供应商反复喂养过的真实数据的分布完全不一样。这次经历让我意识到一个问题人一旦被技术的“概念感”拽住就会不自觉地跳过最基础的问题——这个方案到底在干什么它凭什么能成立它的效果有没有可验证的支撑所以我后来每次评审AI相关方案都会强制自己问三个问题也就是“AI三问”第一问这个方案到底要解决什么问题第二问它为什么要用这种方式来解决第三问它凭什么说自己是有效的三个问题表面看平平无奇但你真的把每一问拆开、刨根问底时绝大部分包装过度的AI方案会当场露出马脚而真正扎实的方案会越问越清晰。这背后的逻辑其实很简单任何技术方案本质上都是一条“目标—路径—证据”的链条。“AI三问”正好对应这三个环节——先锚定目标再审视路径最后验证证据。三个环节任何一个断掉整个方案就不成立。这就像你出差要先知道目的地再决定坐高铁还是飞机最后还要看实际到没到站。顺序不能乱缺一不可。技术判断力听起来很玄说到底就是能不能把这条链条完整地走一遍。2. 第一问这个方案到底要解决什么问题多数AI项目翻车不是死在技术实现上而是死在目标定义上。这一问的目的就是把对方口中玄乎的“智能”“赋能”“闭环”等词汇翻译成可以测量、可以验证的业务语言。2.1 把“AI话术”翻译回“业务语言”很多方案在讲目标时是非常模糊的。比如“我们希望构建一套智能风控体系全面提升业务效率”“我们打算用AI重构用户画像系统实现精细化运营”。听起来都对但你追一句“具体提升谁的效率从多少提升到多少在什么时间段内拿什么指标来衡量”就会发现对方开始含糊。翻译回业务语言就是要把结论落到可感知的对象上。举个例子有个真实落地的项目对外宣称叫作“智能客服工作台”内部的目标其实只有三个客服平均响应时长从90秒降到40秒以内常见咨询的自动解决率从20%提升到45%质检抽检覆盖率从5%提升到100%。这三句话一出来后续的模型选型、数据准备、验收标准全都有了锚点。我在实际操作中养成了一个习惯任何AI项目启动前先让人用三句话把目标写清楚每句话都必须包含“谁、从什么值、变成什么值”。写不出来就说明需求还没想清楚这时候上什么AI都是白搭。注意如果你的目标本身是“提升用户体验”这种完全不可测量的方向别急着往下谈。先陪他们把“用户体验”拆成“平均操作步骤数”“页面停留时长”“二次来访率”这类可观察的关键指标再回到AI方案。否则后面所有效果评估都是自说自话。2.2 警惕“伪需求”和“伪AI”“AI三问”第一问还有个重要作用就是识别“伪需求”。我见过不少决策者把“用AI”本身当成需求典型表述是“领导让各部门拿出AI场景”“同行都在做智能XX我们不做显得落后”。这种“为了AI而AI”的需求根子就不正。另一种“伪AI”更加隐蔽它把原本用规则就能解决的问题硬包装成需要AI解决的问题。举个例子某个“智能表格自动分类”工具声称用到了深度语义模型实际上它只是用关键词和正则规则在匹配。不是说规则方案不好而是对方明明用了规则却要你按AI项目的高成本、高复杂度去接受它。这时候第一问就应该拆穿你告诉我你解决的是“语义理解”问题但实际上你的方案只覆盖了“关键词匹配”的粒度这两者的业务边界根本不一样。怎么拆还是拿目标来比。如果问题只是在固定几个类目之间做文本归档传统规则和统计方法完全够用没必要上大模型。一旦对方说“能理解任意自然语言表达”你就让他列举“任意”的边界在哪里覆盖不了哪些语料。这么一追伪需求就会露馅。2.3 目标定义怎么才算合格我一般会按照三个层次来检查对方的目标定义是否过关检查层次合格标准不合格表现场景真实性目标来自真实业务流程相关人员能描述具体痛点目标是“借鉴”行业报告业务方自己都说不清痛点指标可量化有基线值、目标值、统计口径“提升”“优化”等定性描述无数据支撑范围有边界明确覆盖哪些场景、不覆盖哪些场景声称“全场景覆盖”“任何数据都能处理”这三个层次逐一过完第一问才算结束。很多人在这一步就已经不想再聊下去了——为什么因为他们没想明白后面自然也答不上来。3. 第二问它为什么要用这种方式来实现第一问锚定了目标第二问审视路径。说白了就是你说你要解决“响应时长从90秒降到40秒”的问题那你为什么选择“微调一个大语言模型人工兜底”的组合而不是直接用“知识库检索规则分流”3.1 技术选型必须能讲出“所以然”技术路径没有绝对的对错但必须有站得住的理由。最常见的通病是“因为别人都在用大模型所以我们也要用”这属于拿结论倒推论据等于没回答。合格的回答至少应该包含三个维度数据的可得性要完成任务需要哪些数据数据规模够不够标注成本能不能接受如果连领域训练数据都没有所谓“微调大模型”就是空中楼阁。成本与收益的匹配算力成本、推理延迟、开发周期、维护人力这些和业务收益放在一起算总账值不值得用AI或者值不值得用这么重的AI。方案的容错空间模型答错了会造成什么后果是容忍度很高的辅助场景还是容错率很低的业务核心链路容错空间决定了技术路径的复杂度上限。有一回我评审一个“智能排班”方案对方用了序列到序列模型效果展示图很好看。我就问了一句你们训练数据里有多少种班型员工约束条件是怎么编码进去的对方支支吾吾说约束条件目前还没完全纳入模型。实际上这种问题用带约束的优化算法规则清晰、结果可解释却非要用黑盒模型硬套属于典型的技术路线错配。真正的问题不是“模型效果差”而是“在错误的路径上投入了不必要的资源”。3.2 识别“套壳式创新”和“包装式堆砌”第二问在实践中还有一个高频用途就是识别“套壳项目”。套壳不一定等于完全无效但往往意味着团队没有核心技术能力遇到边界问题只能干瞪眼。识别套壳有几种信号一是演示环境与真实环境的数据差异极大但对方无法解释训练数据的来源和覆盖度二是所有核心模块都外包或调用商用API但对外宣称“自研大模型”三是当评委追问某个具体技术细节时对方只能用“神经网络学习到了规律”这类笼统说法搪塞。我并不是说调用API不行。商业API在很多场景下反而是最优解。我反感的是“明明只是集成却按自研去包装”。这种包装不仅抬高预期还会让后续的故障排查、效果调优、成本控制完全失控。技术判断力的一部分就是把“集成”和“自研”分清楚然后根据不同能力档次去匹配不同预期。3.3 用反证法给技术路径“做体检”“AI三问”的第二问我常建议用一种简单的反证法来推进假设不用AI纯规则和传统工程能不能解决如果传统方案能做到80分AI方案能做到85分但成本和复杂度翻了三倍那这超出预算的5分价值有多大反过来如果传统方案只有55分AI方案能到85分那引入AI就有足够理由。反证法还能帮助团队找到真正不可替代的技术节点。比如说合同审核里“条款对比”用规则就能做好但“语义风险识别”必须靠模型理解。这时候技术路径设计的重点就应该是模型能力而不是花大量精力去优化规则模块。把资源用对地方方案才经得起追问。实操心得我让评审对象画一张“技术栈依赖图”——只画数据从哪里来、处理节点有哪些、每个节点用什么方法、下游依赖什么。这张图一画出来很多逻辑漏洞自己就藏不住了。有人画的图里最核心的语义判断环节写了“调用外部API”但汇报材料里却写着“自研智能引擎”这种矛盾一眼就能抓出来。3.4 技术路线是否有演进空间第二条同时要看方案的“成长性”。人工智能技术迭代速度很快今天选的技术栈明天可能就有更轻量的替代方案。一个合格的技术路线应该留出模块化替换的空间而不是把整个项目的命根子绑在一套封闭的架构上。我自己在做架构决策时会问三个子问题数据层能不能独立出来模型层能不能切换不同的模型提供方业务层能不能在模型失效时降级到规则兜底如果三个回答都是“是”那这个技术路线就算不稳定至少也是健康的。如果任何一个回答是“否”就得警惕它是不是一个“铁板一块”的封闭系统一旦某个环节需要变更整个项目就要推倒重来。4. 第三问它凭什么证明自己有效第一问解决了“做什么”第二问解决了“怎么做”第三问解决的是最容易被忽略的“怎么证明”。AI领域有个老毛病用演示代替测试用故事代替数据。第三问的目的是逼着所有人从“我觉得它有效”走向“有证据表明它有效”。4.1 评估指标要与真实目标“对齐”很多AI团队汇报效果时张口就是“准确率95%”“模型精度提升8%”但你深挖之后会发现这个准确率是在一个极其干净的数据集上算出来的标注口径和真实业务场景根本不一致或者他们报的是“二元分类准确率”但实际业务里误判的代价远远高于漏判真正要看的指标是“精确率”和“召回率”的加权组合。指标对齐不复杂只要回到第一问的量化目标里去。第一问说“要把响应时长从90秒降到40秒”那第三问的评估就该重点看“线上真实对话的平均响应时长分布”而不是模型在离线测试集上的“首轮命中率”。指标一旦对齐整个验证逻辑就闭环了。我习惯用一张表来做对齐检查业务目标指标方案给出的评估指标数据来源计算口径是否对齐客服响应时长降50%在线请求平均响应时长生产日志抽样从用户发送到首次回复的间隔对齐合同审核风险识别率风险条款检出准确率/召回率人工复核标注仅覆盖特定合同类型部分对齐4.2 构建“证据链”而不是“演示漏斗”演示环境有一个最大的问题它是为了让方案显得优秀而设计的不是为了让方案接受检验而设计的。真正可靠的验证证据至少应该包括五类离线评估结果使用与训练集不同来源的留出集数据进行测试并报告细分场景的结果。线上灰度/小流量实测在真实业务环境里跑一小段时间观察和统计真实用户反馈。回归测试每更新一版模型跑一遍历史的典型用例看看有没有“修好一个场景、毁掉三个旧场景”。人工复核记录抽查模型输出结果保留标注过程和争议处理的标准记录。失败案例分析宁可主动讲模型哪些地方不行也比藏着掖着强。最怕的是方案方只能告诉你“它很好”却说不清“它哪里不好”。这五类证据凑齐了方案的判断才有支撑。只给一个演示视频或一份精美的效果截图这在“AI三问”的框架里是不合格的。注意我在评审时一定会问“失败样本在哪里”。如果对方说“我们模型基本不犯错”那基本可以判断这个团队没有做过充分的线上压力测试或者根本不敢面对失败样本。真正跑过真实场景的人一定知道模型在长尾场景、异常输入、跨时段数据上都会出现哪些问题这些细节是编不出来的。4.3 复现实验亲手测一测第三问还有一个很重要的落地动作复现。别光听供应商或内部团队报数字拿一份真实业务数据按他们描述的流程跑一遍。这里要关注三个点可复现性同一个输入同样的代码和配置两次运行结果是不是稳定的如果结果波动很大那模型的可靠性就要打问号。输入敏感性稍微改变一下输入措辞、格式、标点或噪声效果会不会断崖式下跌好的模型应该有一定鲁棒性。人机协作边界模型输出之后流程中的人能方便地纠正错误吗纠错成本高不高这些测试不一定需要复杂的工程环境用小型验证脚本就能完成。我测试过不少项目最后发现“说得好听”和“跑得起来”完全是两码事。有一个号称准确率超过90%的文档解析工具我拿了一份扫描件做了下旋转校正结果解析率直接掉了一半。原因是它的训练数据全是规整的文档截图根本没考虑工业生产里的低质量扫描场景。4.4 长期有效性效果不会永远不变最后一个容易被忽略的维度是时间。AI模型上线时的效果和运行半年后的效果往往有明显差异原因包括业务数据分布漂移、用户输入习惯变化、外部环境变动。第三问还应该包含一个“随时间复盘”的意识以及持续监控和定期再训练的重要环节。我在方案评审时会让对方回答两个问题模型性能下降时监控指标是什么由谁来触发再训练流程如果对方答不上来说明这个所谓“AI系统”还只是一个一次性的实验品谈不上一个可持续运行的产品。技术判断力的高级表现就是能看到方案在时间维度上的健康状况而不只是看它在演示当天的状态。5. “AI三问”怎么组合起来实战一个评审案例的全过程理论讲完拿一个我实际参与过的评审案例来做一次全流程拆解。某公司拿来了一个“智能文档处理系统”说要帮财务部门自动识别发票信息、合同关键要素和报销单并且自动填写审批表单。他们来的时候信心满满因为内部两版模型对比测试“效果提升很大”还额外准备了一整套Demo环境。5.1 第一问直接卡住我先问了一个最简单的问题“你们自动识别之后回填到审批表单的准确率要达到多少错误识别是人工修正还是直接写入系统”对方明显愣了一下回答说准确率预期是95%以上但是修正方式还没最终确定。我又问了一句“你们说的95%是字段级别的准确率还是整张单据完全无差错的准确率”对方犹豫了很久说是字段级别。这两个口径在业务上的差距是天壤之别后面的验收标准也完全不同。第一问的要求就是让目标回归业务真实场景。他们从“技术指标还不错”退回到“我们要让财务审核人员少录字段、少返工”这时候整个系统的目标才开始真正清晰起来。5.2 第二问暴露逻辑问题接下来看技术实现他们用了“通用文档解析模型票据模板匹配规则”的混合方案。表面看组合合理但我追问了一个数据问题发票和合同这两类单据在版式上有本质差异发票结构相对统一合同版式千奇百怪你们的模型是同一个还是分开训练的他们说是同一个而且训练数据里合同占比只有20%。那问题就来了占业务量80%的合同训练数据却只有20%模型在合同场景下的泛化能力凭什么保证这一点单看总体的“准确率95%”是暴露不出来的。一旦把数据构成和技术路线放在一起审视逻辑短板就非常清晰。5.3 第三问逼迫补证据最后我说“你们带来真实合同样本了吗我想现场抽20份直接跑一下识别结果。”对方带来了测试集但那是他们自己挑过的“友好样本”。我坚持从他们公司的历史档案里随机抽了20份其中有几份带有手写批注、模糊章印、套版偏移。结果他们的系统在20份里只有11份能在不改动任何参数的情况下全字段识别正确剩余9份出现不同程度的字段遗漏而他们的报表明细里却写着“识别准确率96.7%”。这个实验做完评审结论呼之欲出不是这套系统不能用而是它目前只能用在“干净样本”上离真实业务的“脏乱样本”还有距离。后面团队补充了数据增强方案、细分场景测试报告、人工复核的兜底流程又迭代了一个多月终于达到能被业务方接受的水平。事实上这个系统最终是落地成功的但它的成功建立在把“AI三问”里面的三个问题全部重新回答了一遍之后而不是第一版汇报那个“看起来很完美”的方案之上。5.4 一张实用的“技术判断力检查模板”结合上面的实战我把自己在用的问题清单整理出来分享给经常需要做技术评审、选型和内部评估的同行。可以直接复制到你们的评审文档里用三问核心提问关键观测点不合格信号第一问解决什么问题具体对象是谁从多少值变到多少值边界在哪里有基线值、目标值、统计口径有真实业务场景支撑只有“提升”“赋能”等定性表述第二问为什么这样实现数据从哪来为什么选这个模型/方案成本收益怎么算技术选型与数据条件匹配能说出对比替代方案的理由堆砌新技术但讲不清理由或过度包装第三问凭什么证明有效离线测试、线上灰度、失败样本、回归结果在哪里有可复现实验、真实证据链、人工复核记录只有Demo演示无失败案例分析这张表不是用来刁难人的而是让评审双方都站在同一套标准下面说话。它倒逼方案方把思考节奏放慢把“自以为懂”变成“真懂”。6. 技术判断力的误区与我的实战体会“AI三问”听起来很基础但真正坚持执行并不容易因为人在面对新技术时会不自觉地放松警惕。我把最容易踩的几个坑单独拿出来说一说。6.1 三个常见的判断误区第一个误区是把“准确率”当成免死金牌。准确率只是众多指标中的一个脱离业务场景看准确率就像只看一道菜的热量却不管它好不好吃。同样是95%准确率在“垃圾邮件过滤”里可以用在“医疗分诊建议”里就完全不够看。判断技术方案永远要回到“代价”和“收益”的权衡上。第二个误区是迷信“越大越好”“越新越好”。参数规模大、模型版本新这些技术在特定场景里确实有优势但技术判断力不是追新能力而是匹配能力。预算有限、数据有限、实时性要求高的时候一个轻量级模型可能是远比顶级大模型更优的选择。第三个误区是拿“别人都在用”当理由。我见过一些团队引用头部公司的成功案例来为自己的方案背书但每个公司的数据基础、组织协作方式、业务约束完全不同。别人能做成的事不代表在你们的土壤里就能长出来。正确的做法是把别人的逻辑链条拆开看再映射回自己的目标、路径和证据。6.2 用日常小练习来训练判断力技术判断力不是天生的它需要反复练习。我分享两个低成本但很有效的小习惯。第一个习惯是“方案快审”。每周找一个外部或内部的AI方案只用五分钟问一遍“AI三问”它要解决什么为什么用这种方式证据链完整吗不需要深入分析只需要快速暴露自己的判断盲点。坚持一年你对方案的敏感度会明显提升。第二个习惯是“复盘式拆解”。任何一个项目结束后不管是成功还是失败都拿“目标—路径—证据”三条线重新过一遍当初的目标定得对不对路径选择有没有更好的可能证据链里哪个环节最薄弱这种复盘做多了你会发现很多踩坑的教训是有共性的而且完全可以提前避免。6.3 关于技术判断力的最后一句心里话技术判断力在我的理解里不是什么天赋而是一种纪律。它逼迫你在别人狂热的时候保持追问在别人盲从的时候保持怀疑在别人只给你看演示的时候坚持要看证据。这种纪律不一定让你成为最先吃到红利的人却能保证你不为大量注定翻车的项目买单。“AI三问”不是什么高深理论它就是我工作台边上常年贴着的一张便利贴。每次拿到一个所谓“智能方案”我不急着评价它的模型选型有多先进也不急着看它的架构图有多完整而是先安静地问自己三个问题这到底要解决什么问题为什么用这种方式凭什么说它有效三个问题走完该不该做、做到什么程度、怎么验收心里的答案自然就摆在那里了。最后再分享一个小技巧这三问完全可以顺手用到自己团队的工作汇报里。每次要向上级或者评审委员会讲解你的AI项目时提前把这三问的答案写好讲出来会自信很多。别怕暴露技术细节的不足真实的、经得起追问的方案哪怕它不完美也比一个用名词堆出来的“完美故事”更值得信任。
