最近一年我作为主创角色参与了一个内部代号为“QDKT”的AI产品项目从最开始只有一个模糊的“要不要做AI”想法到最后跑通完整验证流程并做出可交付的Demo整个过程中的方法论沉淀比最终成品本身更有价值。前后试了三个方向砍掉了一个潜力很大但无法在六个月内达到精度要求的方向也验证了一个原本被低估的需求场景。这篇就以QDKT为引子把“从0到1设计AI产品”中最容易被跳过、却最决定生死的两个环节——场景挖掘与可行性验证——完整拆一遍。很多人做AI产品第一步是找算法、找模型、找数据恨不得第二天就出Demo。但真正决定AI产品命运的是“做对了什么场景”和“凭什么判断这个场景能做”。这两件事想不清楚后面再厉害的技术也都白搭。QDKT项目里我们吃过这个亏后来把场景挖掘和可行性验证当成独立阶段去立项管理节奏才真正稳下来。我会把整个思考链路、用到的工具框架、踩过的坑和最后沉淀下来的检查清单都写出来覆盖从场景访谈、需求梳理、技术预研、数据验证到商业可行性的完整路径适合正在做AI产品立项、想做内部AI工具落地、或者创业初期选方向的读者参考。1. 为什么AI产品最容易死在第一步场景选错的三种典型信号先说一个反常识的结论不少AI项目搁浅不是因为算法不行而是因为场景选错了。算法不行反而容易发现训练几轮loss下不去大家就知道问题在哪但场景错了会以各种“看起来挺有戏”的假象拖你几个月。1.1 伪需求信号用户说“需要”但行动上却不用QDKT项目最早的第一个候选场景是做“会议纪要点子自动抽取”当时我们访谈了十几个经常开长会的业务骨干大部分人都说“太需要了这个太痛了每次开会记不下来”。听起来需求几乎是刚需但我们忽略了两个硬信号第一他们当时已经有工作习惯——自己用手机备忘录、用录音笔、让下属会后整理。虽然他们抱怨这些方式麻烦但抱怨到“愿意换新工具”之间隔着巨大的迁移成本。第二当我们追问“如果这个工具能帮你提炼会议待办你会立刻打开它还是开会前才想起它”时绝大多人的回答都很含糊说明产品在他们工作流中并不是“高频刚需”只是“想起来很好”。这个信号后来被我总结成“三类指标”去判断伪需求用户是否愿意改变现有流程、用户是否愿意每周至少打开产品3次、用户是否愿意在团队内主动推广。三条里至少要满足两条否则场景就得回炉。1.2 伪技术信号表面是AI本质是人肉外包第二个危险信号是“技术能做”的幻觉。我们当时还评估过另一个场景——帮实习生自动写会议周报。技术上用大模型确实能在5分钟内生成完全可读的周报草稿Demo做得非常漂亮但仔细算一笔账就露馅了周报生成需要非常强的业务上下文而业务上下文藏在各个项目文档、聊天记录和邮件里这些数据根本没打通。结果就是为了生成一份合格周报系统得问用户五个问题、让用户上传三个文件、最后再手动改半天。用户实际花费的时间比直接从零写一份还要长。这就是典型的“AI没替人干活反而给人添了活”本质是人肉在给AI补上下文。一旦你的场景需要用户在每次使用前做大量人工输入/清洗/标注技术上就不可能孵化出真正的AI产品只能算一个套壳模板工具。1.3 伪边界信号做成了传统软件而不是AI产品第三种信号最隐蔽AI产品做出来之后体验和普通软件没有本质差别用户感知不到AI的存在。这种现象很容易出现在“规则能解决80%、AI只解决剩下20%”的场景里。有一次我们看上一个“合同关键条款自动提取”的方向聊下来发现用户真正在意的条款其实就是固定的十几条写死的正则加字段映射就能处理大部分模型的增量价值被压缩得很小。再加上合同格式不规范、扫描件质量差AI反而成为“不稳定因素”客户宁可接受规则引擎也不愿意接受“有时候准有时候不准”的模型。这类场景倒未必不能做但前提是必须想清楚AI的不可替代性到底在哪。如果只是把“规则能力90分”提到“模型能力92分”用户很难买单只有从60分提到90分的大跨越AI的价值才真正能被感知。QDKT后来做的一个需求筛选清单里第一项就写AI的增量价值必须超过用户感知成本的5倍。数值可能不严谨但背后的判断标准参考价值很大——不要做边际改进型AI要做跃迁式AI。2. 场景挖掘实操流程从访谈、聚类到需求优先级排序如果第一章节是我事前总结的“反面信号”那这章是QDKT最终跑通的正面方法论。我们后来能挖到那个真正值得做的场景靠的不是拍脑袋而是一套有节奏的探查流程。2.1 第一轮访谈用“情景复述法”代替“需求提问法”和用户访谈是门手艺活直接问“你希望有什么AI功能”几乎百问百错。为什么因为用户并不知道AI能做什么他们的回答基本是现有工具的简单延伸比如“能不能输入关键词自动查资料”之类。这类回答无法让你看到场景里的真实约束和机会。QDKT团队在访谈时用了“情景复述法”核心是让用户回忆过去一周里最麻烦的三个工作瞬间然后把场景细节原原本本复述出来。我们不做任何引导只追问四个固定问题你当时是怎么发现这个问题的为了处理它你花了几步、大概多久中间有什么环节最让你烦躁如果有一种方式能让你重做这一遍你最想跳过哪一步这个方法的威力在于用户不会回答“我需要的功能”而是会暴露“流程里断点在哪、成本在哪、情绪在哪”。比如当时有人复述了一个“每周四下午整理各渠道用户反馈”的瞬间讲了快20分钟里面包含了从导出、去重、归类、翻译、贴标签到做汇总表的所有细节。这比“我希望有个AI帮我做反馈分类”有价值一百倍。访谈数量方面我们以20个用户为下限30到40个为理想区间超过45个之后有效信息的边际增量会迅速递减。访谈对象要刻意混入“非典型用户”比如只见过两次面的边缘岗位员工他们的工作流程往往存在最大的“断点”和“无人维护环节”更容易挖出差异化场景。2.2 场景聚类从碎片故事到需求池访谈结束后的第一件事不是整理报告而是把所有原始记录切成一条一条的“场景卡片”。每张卡片必须包含“角色、动作、频次、痛点、现有替代方案”五个要素缺一不可。这一步我和团队经常吵——有人喜欢把痛点写得特别长有人追求简化。后面形成规则痛点必须写成“哪个环节出现什么问题导致什么结果”禁止只写“效率低”“流程乱”这种抽象描述。切完场景卡片之后做聚类我们用的工具比较朴素线下的实体便利贴加线上白板同步更新。聚类维度不是按“功能相似”去分类的而是按“底层需求相似”去分类的。打个比方“合同条款提取”和“项目周报生成”看起来不是一类功能但底层需求都是“把散落在多个源头的结构化信息汇总成一份指定格式的交付物”。这种底层需求聚类更容易映射到同一种AI技术能力上后续的可行性验证也能一套方案服务多个场景性价比极高。QDKT最终聚类出5个需求池然后我们逐条评估了四个维度业务价值、频次、AI技术匹配度、数据可得性。每个维度按1到5分打分总分最高的两个池子才有资格进入下一步的“深潜验证”。打分的具体规则在下章节展开。2.3 从需求池到问题定义一句话说清“AI替谁省了什么”需求池里的场景描述再丰富终究不能直接拿来立项。我们强制要求每个入围场景最后必须压缩成一句话“为谁在什么情境下解决什么问题用AI替代了什么动作预期带来什么可度量的变化。”用这个句式过滤之后至少筛掉一半“看起来很美”的伪需求。简单举两个QDKT里的例子好场景“为每天需要整理多平台反馈的运营人员在每周四导出原始数据后用AI自动完成去重、翻译、标签分类和汇总表填写替代原先需要2到3小时的手工整理预期把处理时间压缩到20分钟以内。”坏场景“用AI提升运营数据处理的智能化水平”这种定义没法验证、没法立项、没法做验收应该直接扔掉。这里有一个经验我反复在内部强调场景定义到“一句话可描述、可测、可复盘”时项目才算正式开始。前期访谈、聚类、打分都不产生价值只有落到一句严谨的问题定义上才真正变成资产。3. 可行性验证三层递进技术、数据与商业闭环场景挖掘完成后很多团队会激动地直接进入开发。QDKT这里专门拆了一个完整的“可行性验证”阶段前后持续六周。它的目的不是把技术做到完美而是回答三个问题能不能做出来数据够不够谁愿意用并且用得起这三层缺一不可而且必须按顺序推进——技术过不了后面的都不用谈技术过了但数据拿不到也白搭技术和数据都OK但商业模式不成立依然得换方向。3.1 技术验证拿公开数据做基准测试比用真实数据更靠谱关于技术验证我先说一个和直觉相悖的结论早期技术可行性验证用公开数据集做基准测试比直接拿用户真实数据要好。原因很简单公开数据集有公认的评测指标、有别人的SOTA结果可以做对比基准、数据质量也相对可控。而真实数据往往脏、小、不均衡会同时引入“脏数据清洗问题”和“模型能力问题”两个变量一旦结果不理想你根本分不清是数据问题还是技术路线问题。QDKT当时对入围的两个场景分别做了技术预研。其中一个涉及跨语言文本分类我们直接找了一个公开的多语言评测集做zero-shot和few-shot测试用3到4个大模型API加一个开源模型分别跑了一轮。评估标准就三个准确率、召回率、以及稳定性的方差。跑了大概两周结论非常清晰——开源的几个小模型的准确率始终在75%上下且方差很大几个外部API的准确率能上到90%但每千次的调用成本高得离谱。另一个场景涉及文档结构解析也通过公开数据集发现了现有模型在最关键的“表格跨页合并”子任务上表现很差直接改变了方案路线换成了“规则定位OCR辅助模型抽取”的混合架构。技术验证的产出不只是一个“能不能做”的结论还应该包括模型选型的备选清单、预期效果区间、训练资源的量级预估、以及对“复杂场景需要定制数据标注”的明确预判。3.2 数据验证真实场景中数据获取路径的可落地性公开数据集基准测试过了并不意味着真刀真枪就能上。第二个要验证的是“你要的数据在真实环境里到底拿不拿得到、拿全拿不到、拿多久能拿完。”QDKT在这一层有个非常值得说的案例。我们当时预判某个场景需要大约5000条标注数据才能达到可接受效果理论上标注成本和时间都可控。但当我们真正去接触数据源头的时候才发现数据分散在三个部门、两个遗留系统和一个非结构化共享网盘里其中两个系统根本没有对外API只能人工导出导出之后还需要大量去重和权限清理。我们光做数据梳理就花了两周最后发现完全合规、口径统一的数据只有不到800条。800条做一个内部Demo是够了但要想支撑线上真实流量的推理尤其在用户数据只有“单次授权、不做持久化”的合规约束下根本无法形成模型的自迭代闭环。这就是数据验证不过关的典型表现。数据验证环节我建议所有AI产品团队都要做一张“数据可得性五要素”表数据来源是否存在别默认有要实际去看。获取方式是否可持续是一次性导出还是持续同步是否有API没有的话人工导出的频率和成本。数据质量是否达标字段完整率、一致性、噪音比例。标注成本是否可承受是否必须专家标注每条的耗时是多少。合规边界是否清晰能不能存能不能用能不能二次加工。五要素里任何一个出现红色都要考虑换数据源或者重新定义问题边界。QDKT最终砍掉的第一个方向就是因为“持续获取”这一栏无法满足。3.3 商业验证谁付钱、谁改变流程、谁持续用技术能跑、数据够用只代表“能做”不代表“该做”。很多技术背景的团队把前两关走完就以为万事大吉结果根本没有想清楚谁为产品付钱。QDKT这里犯过一次典型错误——我们把“业务部门有痛点”和“业务部门愿意掏预算”划了等号。实际上痛点再多如果它刚好压在两个部门的职能边界上就会出现“谁都觉得有用但是谁都没有职责出钱”的尴尬局面。商业验证不需要做严格意义上的首发财报但至少要访谈三类人终端使用者、预算审批者、采购决策者。很多团队只访谈第一种这是巨大失误。终端使用者说“好用”不解决任何问题只有预算审批者愿意从哪个成本中心、以什么名目掏出这笔钱才是商业可行性的真正信号。另外一个更微妙的衡量维度是“业务愿意为这个AI产品改变自己的工作流程到什么程度”。通常愿意改变流程更深说明产品的不可替代性越高。QDKT验证通过的最终场景客户方承诺了一个非常关键的流程变化——以后把AI输出结果作为正式流程的一部分而不是仅在旁边做参考。正是这个承诺让我们相信这不是嘴上说说的伪需求。商业验证的最终产出是一张“价值交换设计表”里面写清楚谁为产品交付什么价值、产品为用户创造什么价值、用户为产品贡献什么数据或费用、以及这个闭环的循环周期是多长。这张表结合技术验证、数据验证的结论统一放到决策委员会面前项目是否继续就是一张纸的事。4. 最小验证实验MVE实操复盘一个A/B对照案例的全过程章节2和章节3偏框架化真正把框架磨成能力的是QDKT做的两次最小验证实验Minimum Viable ExperimentMVE。这里我把其中一个最完整的案例从设计到复盘全流程讲清楚方便读者直接对照模仿。4.1 实验设计选定场景、定义成功标准、明确对照基线我们当时选择验证的场景是前面提到过的“多平台反馈自动汇总”。整个实验环境是一个内部业务团队他们有固定的人工处理模式并且愿意把AI输出结果和人工处理结果做对比。实验周期设计为两周前一周收集人工处理的基线数据后一周让系统与人工并行处理AI输出作为影子结果不做实际决策干预。实验开始之前我们和业务方一起明确了一个非常关键的成功标准AI输出的准确率和覆盖率必须达到人工处理的85%以上且单条处理成本不能超过人工成本的十分之一。85%这个数值不是拍脑袋拍出来的而是通过前期访谈判断出来的“用户愿意接受的最低值”以及“业务现有流程波动的容忍度”。低于85%用户会觉得错误处理和审核的时间反而比人工做一遍还长高于85%从数据本身看不到显著差异就无法和业务方建立信任。实验中的对照组不是“不用AI”而是“现有流程的人工处理”实验组也不是“完整产品”而是一个“规则加模型混合、带人工固定模板输出”的粗糙脚本系统。这个MVP级别的实验装置很多组件都是临时拼凑的但拼凑并不丢人实验目标是验证关键假设不是做产品雏形。4.2 实验执行影子模式下最容易被忽视的是标注口径两周实验里我们每天收到约150条真实反馈数据AI系统跑一遍人工也照常处理一遍。这里最容易被忽视的坑在于人工标注的口径问题——如果不事先定义统一的“标签体系”、“结果格式”、“准确性判断标准”后面算法团队和业务团队就会为“AI到底算不算对”吵上一个星期。QDKT的解法是在实验首日统一做了一次“标准定义会”把AI输出结果分成三档完全正确、部分正确需要少量修改、错误。业务团队对任何一条结果给出“部分正确”或“错误”的标签时必须写明出错的具体类型漏点、错词、标签不符、格式不对等。这听起来费时但为后续分析提供了最关键的“错误指纹”。仅仅知道准确率80%解决不了任何问题知道“80%的错误是因为识别不到短链接”才能推动系统优化。执行期间还埋了一个产品层面的彩蛋——我们故意关闭了AI的“主动澄清功能”。本来设计上AI在遇到来源不明的乱码文本时应该弹出“是否补充信息来源”但实验期间我们直接把这类数据判为“无法处理”并输出提示。这个设计看似降低准确率实则是为了测试用户的容错心态他们更愿意接受“AI老实说不会”还是会更恼火“AI一声不吭做错了”。结果非常反直觉——遇到“无法处理”提示时用户会自动走回人工流程几乎没有负面反馈而AI勉强给出一个错误答案时用户的信任摧垮速度远超我们的预期。4.3 结果解读说清楚“通过/不通过/调整”的标准实验结束后的数据复盘是MVE最容易被低估的部分。QDKT当时算下来AI的准确率接近78%覆盖率92%离成功标准的85%还差一段。按很多团队的标准这就是“不通过换方向”。但我们做了更细的错误归因后发现不是模型能力真的不行而是“短链接和截图型文本”这一类占了错误的大头。如果把公开图像识别模块接入原本预计准确率能从78%上升到接近88%误差主要是单条处理速度与一定API成本。这就是“实验结果解读”中最核心的判断结果不理想的背后要区分是技术天花板还是工程短板。技术天花板意味着要换模型架构、换团队能力、换路线方向工程短板则意味着补一个模块、调一个参数、加一个接口就能解决。QDKT当时判断为工程短板于是把MVE结论写成“有条件通过”条件是新增图像识别模块后复测一次。最终复测准确率到达了86.4%。复测之后我们才正式从“验证阶段”过渡到“MVP原型阶段”整个过程用了一个半月。如果用传统立项流程大概要花三四个月才能走到这个位置而且走的还是“先建系统再试错”的路线成本完全不同。MVE的核心价值就是用最小成本试错拿到决策所需的最高置信度证据。5. 验证通过之后从Demo到可维护产品的关键转身很多人以为“MVE通过了就万事大吉”QDKT团队在通过验证之后也短暂开心了两天但紧接着就陷入另一个局Demo能跑离产品还差得远。这个转折期如果处理不好验证阶段攒下的信任会被迅速消耗干净。这章专门聊聊从Demo到产品化要做的三件脏活累活。5.1 技术债偿还把拼凑脚本重构成可以被维护的系统MVE阶段为了赶时间代码基本都是“只跑一次就扔”的程度硬编码、魔法数字、数据路径直接指向本地磁盘、模型调用没有统一网关。这些代码能在实验环境运行却绝对撑不起线上流量和灰度期间的多次迭代。QDKT重构时的顺序不是从零重写而是“边拆边建”先给所有模型调用包一层统一接口模型切换只改配置再把数据读写切到统一的存储层干掉散落的本地路径最后补上日志监控和回放机制。这里我的个人心得是重构优先级一定按照“变更频率确定顺序”——高频变动的模块最先结构化低频稳定的模块可以先维持原样。业务逻辑每天都在调的不重构你根本快不起来而半年不动的导出脚本则不必急于重写。5.2 指标体系验证阶段靠准确率上线之后靠留存和效率MVE阶段的核心指标是模型准确率和覆盖率但产品落地之后必须切换到业务指标和体验指标。QDKT建立了三个层级的产品指标效率层单条处理时间缩短多少、一次性通过率多少、信任层修正率、撤回率、对AI输出的采纳率、业务层每周用该产品的团队数、为团队节省的总工时。如果让我只选择一个北极星指标我会选“一次性通过率”——用户拿到AI输出后不做任何修改就直接采纳的比例。这个指标同时反映模型质量和用户信任兼具业务价值和技术价值。准确率只是系统的内在性能一次性通过率才是用户在真实使用中感受到的价值校准。5.3 组织协作AI产品需要“产品经理-算法工程师-业务运营”的三角角色最后是团队结构这一点往往是产品化卡壳的真正原因。MVE阶段还可以靠个人英雄主义硬扛但产品化阶段必须把三角角色配齐产品经理管场景定义和优先级算法工程师管模型效果和数据闭环业务运营管关键用户关系、标注反馈、流程推广。三者的协同节奏靠“每周事实同步会”维持不允许空谈只允许同步数据、冲突决策、确认优先级。QDKT在这个阶段遇到的最大问题是大家对“什么算真正完成”的定义不一致。产品经理觉得“功能能跑”就算完成算法工程师觉得“指标达标”才算完成业务觉得“流程跑顺”才算完成。后来我们把“产品完成定义”统一为三条指标达标、业务实际使用超过某最低周频次、用户提交的结果反馈被系统自动纳入优化循环。三条同时满足才能宣布一个版本完结这样做之后无休止的撕扯少了很多。6. 给AI产品零号位同学的四条实战建议这里分享几条我跑了QDKT项目全流程之后觉得最值得记下来的心得它们不适合当作唯一标准但在我复盘的几个案例里反复适用。第一“场景挖掘”和“可行性验证”要作为两个独立阶段分别出报告。很多团队把它们混在立项文档里一笔带过结果执行阶段照搬预判没有任何反馈和修正机制。分开出报告的好处是每份报告各有明确的验收结论每个结论都对应一次“继续、调整或终止”的阶段性决策。第二不要让算法工程师一个人去做技术验证。算法工程师的默认路径是优化模型、刷准确率他们很容易在一项技术上越钻越深忘了“我们到底为了什么验证”。技术验证的负责人应该是产品经理负责定标准、审结果、判断“够没够”算法工程师负责给出“怎么实现”的可能性空间。第三商业验证不要只访谈最终用户一定要触达采购决策人和一线考核指标制定者。很多需求最终无法落地不是产品不好而是需求没有写进任何人的KPI里。谁考核什么谁才会对什么结果负责这是一个朴素但常被忽略的逻辑。第四AI产品从0到1的“0”不是指“没有员工、没有代码”而是指“没有经过验证的业务闭环”。如果你已经验证了技术、拿到了数据、锁定了付费意愿哪怕团队只有一个人也已经站在“1”的前夜。不妨把立项仪式感弱化掉把验证仪式感提上来——每一次实验、每一个正确的否决都是项目真正的里程碑。最后再分享一个QDKT内部一直流传的判断标准AI产品走到第N天如果大家还在争论“场景是否真实”“方向要不要坚持”说明前期的场景挖掘和可行性验证是不合格的。好的验证阶段应该让决策流变得“无聊”——每一项证据都指向明确的结论决策只是顺着证据往前走而已。希望这篇整理的方法论能帮你把“从0到1”的过程也变成一段平淡而扎实的验证之旅。 
长河君 · 2026/10/20 12:57:49 · 阅读 1.2k AI产品从0到1：场景挖掘与可行性验证的实战拆解
最近一年我作为主创角色参与了一个内部代号为“QDKT”的AI产品项目从最开始只有一个模糊的“要不要做AI”想法到最后跑通完整验证流程并做出可交付的Demo整个过程中的方法论沉淀比最终成品本身更有价值。前后试了三个方向砍掉了一个潜力很大但无法在六个月内达到精度要求的方向也验证了一个原本被低估的需求场景。这篇就以QDKT为引子把“从0到1设计AI产品”中最容易被跳过、却最决定生死的两个环节——场景挖掘与可行性验证——完整拆一遍。很多人做AI产品第一步是找算法、找模型、找数据恨不得第二天就出Demo。但真正决定AI产品命运的是“做对了什么场景”和“凭什么判断这个场景能做”。这两件事想不清楚后面再厉害的技术也都白搭。QDKT项目里我们吃过这个亏后来把场景挖掘和可行性验证当成独立阶段去立项管理节奏才真正稳下来。我会把整个思考链路、用到的工具框架、踩过的坑和最后沉淀下来的检查清单都写出来覆盖从场景访谈、需求梳理、技术预研、数据验证到商业可行性的完整路径适合正在做AI产品立项、想做内部AI工具落地、或者创业初期选方向的读者参考。1. 为什么AI产品最容易死在第一步场景选错的三种典型信号先说一个反常识的结论不少AI项目搁浅不是因为算法不行而是因为场景选错了。算法不行反而容易发现训练几轮loss下不去大家就知道问题在哪但场景错了会以各种“看起来挺有戏”的假象拖你几个月。1.1 伪需求信号用户说“需要”但行动上却不用QDKT项目最早的第一个候选场景是做“会议纪要点子自动抽取”当时我们访谈了十几个经常开长会的业务骨干大部分人都说“太需要了这个太痛了每次开会记不下来”。听起来需求几乎是刚需但我们忽略了两个硬信号第一他们当时已经有工作习惯——自己用手机备忘录、用录音笔、让下属会后整理。虽然他们抱怨这些方式麻烦但抱怨到“愿意换新工具”之间隔着巨大的迁移成本。第二当我们追问“如果这个工具能帮你提炼会议待办你会立刻打开它还是开会前才想起它”时绝大多人的回答都很含糊说明产品在他们工作流中并不是“高频刚需”只是“想起来很好”。这个信号后来被我总结成“三类指标”去判断伪需求用户是否愿意改变现有流程、用户是否愿意每周至少打开产品3次、用户是否愿意在团队内主动推广。三条里至少要满足两条否则场景就得回炉。1.2 伪技术信号表面是AI本质是人肉外包第二个危险信号是“技术能做”的幻觉。我们当时还评估过另一个场景——帮实习生自动写会议周报。技术上用大模型确实能在5分钟内生成完全可读的周报草稿Demo做得非常漂亮但仔细算一笔账就露馅了周报生成需要非常强的业务上下文而业务上下文藏在各个项目文档、聊天记录和邮件里这些数据根本没打通。结果就是为了生成一份合格周报系统得问用户五个问题、让用户上传三个文件、最后再手动改半天。用户实际花费的时间比直接从零写一份还要长。这就是典型的“AI没替人干活反而给人添了活”本质是人肉在给AI补上下文。一旦你的场景需要用户在每次使用前做大量人工输入/清洗/标注技术上就不可能孵化出真正的AI产品只能算一个套壳模板工具。1.3 伪边界信号做成了传统软件而不是AI产品第三种信号最隐蔽AI产品做出来之后体验和普通软件没有本质差别用户感知不到AI的存在。这种现象很容易出现在“规则能解决80%、AI只解决剩下20%”的场景里。有一次我们看上一个“合同关键条款自动提取”的方向聊下来发现用户真正在意的条款其实就是固定的十几条写死的正则加字段映射就能处理大部分模型的增量价值被压缩得很小。再加上合同格式不规范、扫描件质量差AI反而成为“不稳定因素”客户宁可接受规则引擎也不愿意接受“有时候准有时候不准”的模型。这类场景倒未必不能做但前提是必须想清楚AI的不可替代性到底在哪。如果只是把“规则能力90分”提到“模型能力92分”用户很难买单只有从60分提到90分的大跨越AI的价值才真正能被感知。QDKT后来做的一个需求筛选清单里第一项就写AI的增量价值必须超过用户感知成本的5倍。数值可能不严谨但背后的判断标准参考价值很大——不要做边际改进型AI要做跃迁式AI。2. 场景挖掘实操流程从访谈、聚类到需求优先级排序如果第一章节是我事前总结的“反面信号”那这章是QDKT最终跑通的正面方法论。我们后来能挖到那个真正值得做的场景靠的不是拍脑袋而是一套有节奏的探查流程。2.1 第一轮访谈用“情景复述法”代替“需求提问法”和用户访谈是门手艺活直接问“你希望有什么AI功能”几乎百问百错。为什么因为用户并不知道AI能做什么他们的回答基本是现有工具的简单延伸比如“能不能输入关键词自动查资料”之类。这类回答无法让你看到场景里的真实约束和机会。QDKT团队在访谈时用了“情景复述法”核心是让用户回忆过去一周里最麻烦的三个工作瞬间然后把场景细节原原本本复述出来。我们不做任何引导只追问四个固定问题你当时是怎么发现这个问题的为了处理它你花了几步、大概多久中间有什么环节最让你烦躁如果有一种方式能让你重做这一遍你最想跳过哪一步这个方法的威力在于用户不会回答“我需要的功能”而是会暴露“流程里断点在哪、成本在哪、情绪在哪”。比如当时有人复述了一个“每周四下午整理各渠道用户反馈”的瞬间讲了快20分钟里面包含了从导出、去重、归类、翻译、贴标签到做汇总表的所有细节。这比“我希望有个AI帮我做反馈分类”有价值一百倍。访谈数量方面我们以20个用户为下限30到40个为理想区间超过45个之后有效信息的边际增量会迅速递减。访谈对象要刻意混入“非典型用户”比如只见过两次面的边缘岗位员工他们的工作流程往往存在最大的“断点”和“无人维护环节”更容易挖出差异化场景。2.2 场景聚类从碎片故事到需求池访谈结束后的第一件事不是整理报告而是把所有原始记录切成一条一条的“场景卡片”。每张卡片必须包含“角色、动作、频次、痛点、现有替代方案”五个要素缺一不可。这一步我和团队经常吵——有人喜欢把痛点写得特别长有人追求简化。后面形成规则痛点必须写成“哪个环节出现什么问题导致什么结果”禁止只写“效率低”“流程乱”这种抽象描述。切完场景卡片之后做聚类我们用的工具比较朴素线下的实体便利贴加线上白板同步更新。聚类维度不是按“功能相似”去分类的而是按“底层需求相似”去分类的。打个比方“合同条款提取”和“项目周报生成”看起来不是一类功能但底层需求都是“把散落在多个源头的结构化信息汇总成一份指定格式的交付物”。这种底层需求聚类更容易映射到同一种AI技术能力上后续的可行性验证也能一套方案服务多个场景性价比极高。QDKT最终聚类出5个需求池然后我们逐条评估了四个维度业务价值、频次、AI技术匹配度、数据可得性。每个维度按1到5分打分总分最高的两个池子才有资格进入下一步的“深潜验证”。打分的具体规则在下章节展开。2.3 从需求池到问题定义一句话说清“AI替谁省了什么”需求池里的场景描述再丰富终究不能直接拿来立项。我们强制要求每个入围场景最后必须压缩成一句话“为谁在什么情境下解决什么问题用AI替代了什么动作预期带来什么可度量的变化。”用这个句式过滤之后至少筛掉一半“看起来很美”的伪需求。简单举两个QDKT里的例子好场景“为每天需要整理多平台反馈的运营人员在每周四导出原始数据后用AI自动完成去重、翻译、标签分类和汇总表填写替代原先需要2到3小时的手工整理预期把处理时间压缩到20分钟以内。”坏场景“用AI提升运营数据处理的智能化水平”这种定义没法验证、没法立项、没法做验收应该直接扔掉。这里有一个经验我反复在内部强调场景定义到“一句话可描述、可测、可复盘”时项目才算正式开始。前期访谈、聚类、打分都不产生价值只有落到一句严谨的问题定义上才真正变成资产。3. 可行性验证三层递进技术、数据与商业闭环场景挖掘完成后很多团队会激动地直接进入开发。QDKT这里专门拆了一个完整的“可行性验证”阶段前后持续六周。它的目的不是把技术做到完美而是回答三个问题能不能做出来数据够不够谁愿意用并且用得起这三层缺一不可而且必须按顺序推进——技术过不了后面的都不用谈技术过了但数据拿不到也白搭技术和数据都OK但商业模式不成立依然得换方向。3.1 技术验证拿公开数据做基准测试比用真实数据更靠谱关于技术验证我先说一个和直觉相悖的结论早期技术可行性验证用公开数据集做基准测试比直接拿用户真实数据要好。原因很简单公开数据集有公认的评测指标、有别人的SOTA结果可以做对比基准、数据质量也相对可控。而真实数据往往脏、小、不均衡会同时引入“脏数据清洗问题”和“模型能力问题”两个变量一旦结果不理想你根本分不清是数据问题还是技术路线问题。QDKT当时对入围的两个场景分别做了技术预研。其中一个涉及跨语言文本分类我们直接找了一个公开的多语言评测集做zero-shot和few-shot测试用3到4个大模型API加一个开源模型分别跑了一轮。评估标准就三个准确率、召回率、以及稳定性的方差。跑了大概两周结论非常清晰——开源的几个小模型的准确率始终在75%上下且方差很大几个外部API的准确率能上到90%但每千次的调用成本高得离谱。另一个场景涉及文档结构解析也通过公开数据集发现了现有模型在最关键的“表格跨页合并”子任务上表现很差直接改变了方案路线换成了“规则定位OCR辅助模型抽取”的混合架构。技术验证的产出不只是一个“能不能做”的结论还应该包括模型选型的备选清单、预期效果区间、训练资源的量级预估、以及对“复杂场景需要定制数据标注”的明确预判。3.2 数据验证真实场景中数据获取路径的可落地性公开数据集基准测试过了并不意味着真刀真枪就能上。第二个要验证的是“你要的数据在真实环境里到底拿不拿得到、拿全拿不到、拿多久能拿完。”QDKT在这一层有个非常值得说的案例。我们当时预判某个场景需要大约5000条标注数据才能达到可接受效果理论上标注成本和时间都可控。但当我们真正去接触数据源头的时候才发现数据分散在三个部门、两个遗留系统和一个非结构化共享网盘里其中两个系统根本没有对外API只能人工导出导出之后还需要大量去重和权限清理。我们光做数据梳理就花了两周最后发现完全合规、口径统一的数据只有不到800条。800条做一个内部Demo是够了但要想支撑线上真实流量的推理尤其在用户数据只有“单次授权、不做持久化”的合规约束下根本无法形成模型的自迭代闭环。这就是数据验证不过关的典型表现。数据验证环节我建议所有AI产品团队都要做一张“数据可得性五要素”表数据来源是否存在别默认有要实际去看。获取方式是否可持续是一次性导出还是持续同步是否有API没有的话人工导出的频率和成本。数据质量是否达标字段完整率、一致性、噪音比例。标注成本是否可承受是否必须专家标注每条的耗时是多少。合规边界是否清晰能不能存能不能用能不能二次加工。五要素里任何一个出现红色都要考虑换数据源或者重新定义问题边界。QDKT最终砍掉的第一个方向就是因为“持续获取”这一栏无法满足。3.3 商业验证谁付钱、谁改变流程、谁持续用技术能跑、数据够用只代表“能做”不代表“该做”。很多技术背景的团队把前两关走完就以为万事大吉结果根本没有想清楚谁为产品付钱。QDKT这里犯过一次典型错误——我们把“业务部门有痛点”和“业务部门愿意掏预算”划了等号。实际上痛点再多如果它刚好压在两个部门的职能边界上就会出现“谁都觉得有用但是谁都没有职责出钱”的尴尬局面。商业验证不需要做严格意义上的首发财报但至少要访谈三类人终端使用者、预算审批者、采购决策者。很多团队只访谈第一种这是巨大失误。终端使用者说“好用”不解决任何问题只有预算审批者愿意从哪个成本中心、以什么名目掏出这笔钱才是商业可行性的真正信号。另外一个更微妙的衡量维度是“业务愿意为这个AI产品改变自己的工作流程到什么程度”。通常愿意改变流程更深说明产品的不可替代性越高。QDKT验证通过的最终场景客户方承诺了一个非常关键的流程变化——以后把AI输出结果作为正式流程的一部分而不是仅在旁边做参考。正是这个承诺让我们相信这不是嘴上说说的伪需求。商业验证的最终产出是一张“价值交换设计表”里面写清楚谁为产品交付什么价值、产品为用户创造什么价值、用户为产品贡献什么数据或费用、以及这个闭环的循环周期是多长。这张表结合技术验证、数据验证的结论统一放到决策委员会面前项目是否继续就是一张纸的事。4. 最小验证实验MVE实操复盘一个A/B对照案例的全过程章节2和章节3偏框架化真正把框架磨成能力的是QDKT做的两次最小验证实验Minimum Viable ExperimentMVE。这里我把其中一个最完整的案例从设计到复盘全流程讲清楚方便读者直接对照模仿。4.1 实验设计选定场景、定义成功标准、明确对照基线我们当时选择验证的场景是前面提到过的“多平台反馈自动汇总”。整个实验环境是一个内部业务团队他们有固定的人工处理模式并且愿意把AI输出结果和人工处理结果做对比。实验周期设计为两周前一周收集人工处理的基线数据后一周让系统与人工并行处理AI输出作为影子结果不做实际决策干预。实验开始之前我们和业务方一起明确了一个非常关键的成功标准AI输出的准确率和覆盖率必须达到人工处理的85%以上且单条处理成本不能超过人工成本的十分之一。85%这个数值不是拍脑袋拍出来的而是通过前期访谈判断出来的“用户愿意接受的最低值”以及“业务现有流程波动的容忍度”。低于85%用户会觉得错误处理和审核的时间反而比人工做一遍还长高于85%从数据本身看不到显著差异就无法和业务方建立信任。实验中的对照组不是“不用AI”而是“现有流程的人工处理”实验组也不是“完整产品”而是一个“规则加模型混合、带人工固定模板输出”的粗糙脚本系统。这个MVP级别的实验装置很多组件都是临时拼凑的但拼凑并不丢人实验目标是验证关键假设不是做产品雏形。4.2 实验执行影子模式下最容易被忽视的是标注口径两周实验里我们每天收到约150条真实反馈数据AI系统跑一遍人工也照常处理一遍。这里最容易被忽视的坑在于人工标注的口径问题——如果不事先定义统一的“标签体系”、“结果格式”、“准确性判断标准”后面算法团队和业务团队就会为“AI到底算不算对”吵上一个星期。QDKT的解法是在实验首日统一做了一次“标准定义会”把AI输出结果分成三档完全正确、部分正确需要少量修改、错误。业务团队对任何一条结果给出“部分正确”或“错误”的标签时必须写明出错的具体类型漏点、错词、标签不符、格式不对等。这听起来费时但为后续分析提供了最关键的“错误指纹”。仅仅知道准确率80%解决不了任何问题知道“80%的错误是因为识别不到短链接”才能推动系统优化。执行期间还埋了一个产品层面的彩蛋——我们故意关闭了AI的“主动澄清功能”。本来设计上AI在遇到来源不明的乱码文本时应该弹出“是否补充信息来源”但实验期间我们直接把这类数据判为“无法处理”并输出提示。这个设计看似降低准确率实则是为了测试用户的容错心态他们更愿意接受“AI老实说不会”还是会更恼火“AI一声不吭做错了”。结果非常反直觉——遇到“无法处理”提示时用户会自动走回人工流程几乎没有负面反馈而AI勉强给出一个错误答案时用户的信任摧垮速度远超我们的预期。4.3 结果解读说清楚“通过/不通过/调整”的标准实验结束后的数据复盘是MVE最容易被低估的部分。QDKT当时算下来AI的准确率接近78%覆盖率92%离成功标准的85%还差一段。按很多团队的标准这就是“不通过换方向”。但我们做了更细的错误归因后发现不是模型能力真的不行而是“短链接和截图型文本”这一类占了错误的大头。如果把公开图像识别模块接入原本预计准确率能从78%上升到接近88%误差主要是单条处理速度与一定API成本。这就是“实验结果解读”中最核心的判断结果不理想的背后要区分是技术天花板还是工程短板。技术天花板意味着要换模型架构、换团队能力、换路线方向工程短板则意味着补一个模块、调一个参数、加一个接口就能解决。QDKT当时判断为工程短板于是把MVE结论写成“有条件通过”条件是新增图像识别模块后复测一次。最终复测准确率到达了86.4%。复测之后我们才正式从“验证阶段”过渡到“MVP原型阶段”整个过程用了一个半月。如果用传统立项流程大概要花三四个月才能走到这个位置而且走的还是“先建系统再试错”的路线成本完全不同。MVE的核心价值就是用最小成本试错拿到决策所需的最高置信度证据。5. 验证通过之后从Demo到可维护产品的关键转身很多人以为“MVE通过了就万事大吉”QDKT团队在通过验证之后也短暂开心了两天但紧接着就陷入另一个局Demo能跑离产品还差得远。这个转折期如果处理不好验证阶段攒下的信任会被迅速消耗干净。这章专门聊聊从Demo到产品化要做的三件脏活累活。5.1 技术债偿还把拼凑脚本重构成可以被维护的系统MVE阶段为了赶时间代码基本都是“只跑一次就扔”的程度硬编码、魔法数字、数据路径直接指向本地磁盘、模型调用没有统一网关。这些代码能在实验环境运行却绝对撑不起线上流量和灰度期间的多次迭代。QDKT重构时的顺序不是从零重写而是“边拆边建”先给所有模型调用包一层统一接口模型切换只改配置再把数据读写切到统一的存储层干掉散落的本地路径最后补上日志监控和回放机制。这里我的个人心得是重构优先级一定按照“变更频率确定顺序”——高频变动的模块最先结构化低频稳定的模块可以先维持原样。业务逻辑每天都在调的不重构你根本快不起来而半年不动的导出脚本则不必急于重写。5.2 指标体系验证阶段靠准确率上线之后靠留存和效率MVE阶段的核心指标是模型准确率和覆盖率但产品落地之后必须切换到业务指标和体验指标。QDKT建立了三个层级的产品指标效率层单条处理时间缩短多少、一次性通过率多少、信任层修正率、撤回率、对AI输出的采纳率、业务层每周用该产品的团队数、为团队节省的总工时。如果让我只选择一个北极星指标我会选“一次性通过率”——用户拿到AI输出后不做任何修改就直接采纳的比例。这个指标同时反映模型质量和用户信任兼具业务价值和技术价值。准确率只是系统的内在性能一次性通过率才是用户在真实使用中感受到的价值校准。5.3 组织协作AI产品需要“产品经理-算法工程师-业务运营”的三角角色最后是团队结构这一点往往是产品化卡壳的真正原因。MVE阶段还可以靠个人英雄主义硬扛但产品化阶段必须把三角角色配齐产品经理管场景定义和优先级算法工程师管模型效果和数据闭环业务运营管关键用户关系、标注反馈、流程推广。三者的协同节奏靠“每周事实同步会”维持不允许空谈只允许同步数据、冲突决策、确认优先级。QDKT在这个阶段遇到的最大问题是大家对“什么算真正完成”的定义不一致。产品经理觉得“功能能跑”就算完成算法工程师觉得“指标达标”才算完成业务觉得“流程跑顺”才算完成。后来我们把“产品完成定义”统一为三条指标达标、业务实际使用超过某最低周频次、用户提交的结果反馈被系统自动纳入优化循环。三条同时满足才能宣布一个版本完结这样做之后无休止的撕扯少了很多。6. 给AI产品零号位同学的四条实战建议这里分享几条我跑了QDKT项目全流程之后觉得最值得记下来的心得它们不适合当作唯一标准但在我复盘的几个案例里反复适用。第一“场景挖掘”和“可行性验证”要作为两个独立阶段分别出报告。很多团队把它们混在立项文档里一笔带过结果执行阶段照搬预判没有任何反馈和修正机制。分开出报告的好处是每份报告各有明确的验收结论每个结论都对应一次“继续、调整或终止”的阶段性决策。第二不要让算法工程师一个人去做技术验证。算法工程师的默认路径是优化模型、刷准确率他们很容易在一项技术上越钻越深忘了“我们到底为了什么验证”。技术验证的负责人应该是产品经理负责定标准、审结果、判断“够没够”算法工程师负责给出“怎么实现”的可能性空间。第三商业验证不要只访谈最终用户一定要触达采购决策人和一线考核指标制定者。很多需求最终无法落地不是产品不好而是需求没有写进任何人的KPI里。谁考核什么谁才会对什么结果负责这是一个朴素但常被忽略的逻辑。第四AI产品从0到1的“0”不是指“没有员工、没有代码”而是指“没有经过验证的业务闭环”。如果你已经验证了技术、拿到了数据、锁定了付费意愿哪怕团队只有一个人也已经站在“1”的前夜。不妨把立项仪式感弱化掉把验证仪式感提上来——每一次实验、每一个正确的否决都是项目真正的里程碑。最后再分享一个QDKT内部一直流传的判断标准AI产品走到第N天如果大家还在争论“场景是否真实”“方向要不要坚持”说明前期的场景挖掘和可行性验证是不合格的。好的验证阶段应该让决策流变得“无聊”——每一项证据都指向明确的结论决策只是顺着证据往前走而已。希望这篇整理的方法论能帮你把“从0到1”的过程也变成一段平淡而扎实的验证之旅。