最近一年我作为主创角色参与了一个内部代号为“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 Experiment，MVE）。这里我把其中一个最完整的案例，从设计到复盘全流程讲清楚，方便读者直接对照模仿。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”的过程也变成一段平淡而扎实的验证之旅。
最近一年我作为主创角色参与了一个内部代号为“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 Experiment，MVE）。这里我把其中一个最完整的案例，从设计到复盘全流程讲清楚，方便读者直接对照模仿。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”的过程也变成一段平淡而扎实的验证之旅。