QDKT是我最近带着一个跨职能小团队从零开始推进的AI产品代号。这个项目最让我有分享欲的不是最后做出来的那个Demo有多炫而是我们在最前期那段“什么都没有、只有一堆想法”的阶段靠一套方法硬是把模糊的念头一步步收敛成了可落地的产品定义。说白了AI产品从0到1真正决定生死的就是两个环节场景挖掘和可行性验证。场景挖错了后面做得越用力死得越快可行性没验证清楚资源砸进去连个响都听不见。我自己见过太多团队拿着大模型的能力到处找场景找来找去全是“能做但没人用”的功能或者反过来一个需求看着很痛一调研发现技术上根本稳不住。所以这篇就把QDKT从0到1过程中我们在场景挖掘和可行性验证上用的整套思路、踩过的坑、以及可以直接拿去用的模板和判断标准一次性说透。1. 内容整体设计与思路拆解AI产品的起点不应该是“我会用什么模型”而应该是“谁在什么情境下遇到了什么问题”。QDKT立项之初我们内部最激烈的争论就是到底先定技术方案还是先定场景技术背景强的同事倾向于先搭一套底座把模型接入、知识库、对话链路都跑通然后看能做什么但产品背景的同事坚持必须先回答“为谁解决什么问题”否则底座搭完了也只是个昂贵的玩具。最后我们达成的共识是场景先于技术验证先于投入。这个原则说起来简单执行起来需要一套流程去约束。1.1 首个AI产品选型的三段式推进框架我们最终把从0到1的过程拆成了三个阶段场景挖掘、可行性验证、最小验证包设计与验证。三段之间是严格的先后关系不允许跳步。场景挖掘回答“做给谁、解决什么、在什么场景下发生”产出是一份候选场景清单和优先级排序。可行性验证回答“这件事能不能做成”分别从技术、数据、成本、商业四个维度去做小成本验证。最小验证包选定最高优先级场景后用最小成本实现一个能真实运行的闭环用真实用户反馈来确认方向。为什么一定要这个顺序我举个反例我们同期有另一个项目组先花了三周用主流大模型API搭了一个通用问答机器人后来又觉得“问答太泛了”临时决定聚焦到某个垂直场景结果发现当时选的模型在该领域的专业术语理解上差得离谱底座的对话链路设计也根本不适配结构化查询几乎推倒重来。先做技术后找场景输在了起跑线上。1.2 为什么场景挖掘是最容易翻车的环节场景挖掘看起来不就是“找需求”吗但凡做过的人都知道坑全藏在细节里。最大的问题在于“伪需求”——表面看用户说想要实际他并不愿意为它改变习惯也不愿意付钱。典型的伪需求长这样用户说“要是有个智能助手帮我把报表做了就好了”但真把报表自动生成摆在他面前他又说“格式不对、不够直观、我还是自己拉数据吧”用户说“痛点很大”但追问“现在你怎么解决的”他说“我多花半小时手动处理”说明现有替代方案成本还没到不可忍受的程度需求是面向“某类用户”的但这类用户在你的目标群体里占比极低支撑不起产品的最小闭环。场景挖掘阶段的真正任务不是收集需求而是给需求“去伪存真”筛出那些高频、强烈、且现有方案严重不足的场景。1.3 可行性验证为什么必须前置很多AI产品死在半路不是因为模型不行而是因为数据拿不到、效果不稳定、单次调用成本太高导致商业模型算不过来、或者关键干系人根本不买账。这些问题如果在场景挖掘之后、投入开发之前集中验证一遍淘汰成本极低一旦进入开发任何一项翻车都意味着真金白银的损失。QDKT在可行性验证阶段有个硬性要求每个候选场景必须列出“关键假设”然后设计最小实验去验证这些假设。假设不成立的场景直接砍掉不拖泥带水。这一条规则帮我们省下了至少两个整月的开发资源。2. 场景挖掘实操把模糊需求收敛为高价值场景场景挖掘的输出质量决定了后续一切工作的天花板。QDKT在这个阶段用了两周时间做了三件事广泛收集、深度访谈、量化打分。2.1 场景来源的三条主要渠道第一条渠道是目标用户访谈。这里的关键不是问“你想要什么AI功能”而是观察和询问用户当前的工作流程找到流程中最耗时、最易错、最让人烦躁的环节。第二条渠道是数据分析。尤其是做企业服务类AI产品工单记录、客服会话、操作日志、搜索记录都是金矿。我们团队分析了一家合作公司的客服会话记录发现约有35%的提问集中在“修改密码、查余额、办业务”这三类高频重复问题上这就是一个清晰可量化的场景入口。第三条渠道是内部提效需求。很多AI产品最早的种子用户就是内部团队。我们当时调研了内部多个小组发现资料查找类需求特别普遍。表面看这是“搜索工具”的需求但往深了挖本质是“知识分散、缺乏统一检索入口”的问题这就决定了产品形态不能只是一个搜索框而是一套知识整合方案。2.2 真伪需求辨识的四个判断维度拿到一堆原始需求后我们套用了一套四维过滤器每个维度打分低于阈值的直接淘汰。第一维是频率。这个需求多久发生一次一天一次是高频一周一次是低频。AI产品最怕低频需求因为用户对低频工具的依赖度极低很难养成使用习惯。第二维是痛感强度。现有解决方案让用户有多痛苦可以用一个粗暴的问题来测如果这个功能明天上线你愿意在今天的工作中主动使用它吗愿意且主动才是强痛点。第三维是可支付性。用户或客户是否愿意为此买单是愿意付99元/月还是要求免费才用这直接决定商业模式的成立与否。第四维是数据可达性。AI产品需要数据支撑才能运行你能否合法、合规、可持续地获取所需数据这是很多团队最容易事后踩雷的一点——场景很痛但数据根本拿不到或者数据质量差到无法建模。QDKT早期筛掉了一个“自动生成会议纪要”的场景频率和痛感都达标但数据可达性不过关——会议录音涉及大量隐私合规问题而且不同会议室的音频质量差异巨大最终果断放弃。2.3 场景优先级打分模型一套可直接套用的FBS评估法面对十几条看起来都“有点意思”的候选场景不能靠拍脑袋选需要量化排序。QDKT用的是FBS打分法维度如下维度权重说明Frequency 频率30%场景发生的频次越高分越高Pain 痛感30%用户对现有方案的满意度越低分越高Business 商业潜力20%付费意愿、市场规模评估Support 数据与资源20%数据可得性、合规性、技术可行性的综合评估每项按1-5分打分加权求和。四个维度中Frequency和Pain是最核心的加起来占比60%因为我们坚信一个产品连“高频”和“刚需”都占不上后面就基本不用聊了。我们跑完这套打分后的结果挺有意思排名第一的不是最初呼声最高的“智能客服助手”而是“内部知识库智能检索”。原因在于知识检索在频率和痛感上得分都很高而且数据资源完全在握。后来我们把这个结果拿给一位做企业服务多年的朋友看他说了一句很扎心的大实话“企业内部找资料这个痛点比你们想象的还要痛。”3. 可行性验证四维验证矩阵的完整打法场景挖掘选出的最优场景不代表就一定能做成。可行性验证要回答的是在真实约束条件下这个产品是否能以可接受的成本、达到及格线以上的效果、并建立可持续的商业闭环。QDKT在实践中把可行性验证拆成四个维度形成一个四维验证矩阵。3.1 技术可行性验证模型能力边界与效果基线技术验证最容易犯的毛病是“用理想环境代替真实环境”。很多功能在标准测试集上表现不错但放进真实场景里就崩掉了原因多半是数据分布不一致。QDKT在这一步做了一件事从真实业务数据中抽一批有代表性的样本用现成模型做一次基线效果测试。具体操作上我们会把真实场景的输入样例分类整理——比如知识库检索场景就把问题按照“简单事实型、流程指引型、多条件复合型、模糊意图型”分类每类挑10-20条真实问题然后跑一遍模型看回答是否正确、是否完整、是否稳定。这里要特别提醒一个容易被忽略的点模型输出的稳定性比单次准确率更重要。同一道题跑十次如果五次答对五次答错这个能力就不适合直接上生产。QDKT当时测试时发现某个主流API在处理某种长尾格式的问题时答非所问的概率接近20%这个结果直接让我们否掉了“直接API调用不做兜底”的轻量方案转而决定在应用层加一道规则校验确保模型输出异常时能及时拦截。这个决策后来在真实使用中挽救了无数尴尬场面。3.2 数据可行性验证拿数比建模难十倍对于AI产品数据就是生产资料。技术验证可以造假但数据验证造不了假。QDKT在数据维度重点考察三件事数据是否可得、数据质量是否够用、数据合规是否站得住。数据可得性是否有稳定、可持续的渠道获取数据是需要用户手动导入还是系统可以自动回流数据质量样本是否覆盖足够多的边界情况是否存在严重偏差清洗成本有多高数据合规数据来源是否合法合规涉及个人信息是否需要脱敏有没有超范围收集的风险这一环节千万不要只听销售或商务口头的“数据有”一定要拿到真实样本自己看。QDKT踩过一个坑合作方说“我们有几十万条业务知识文档”结果实际开放出来的数量只有几千条而且大部分是几年前的过期内容根本没法支撑问答质量。后来我们改了策略任何数据承诺都要求先开放一个最小可用样本验证通过再继续谈全量。3.3 成本可行性验证把账算到每一块钱AI产品的成本不是“模型调用费”那么简单要算全成本账。QDKT做了一个成本结构表覆盖了以下条目推理成本每次核心操作的API调用或本地推理成本存储与带宽成本向量数据库、对象存储、日志系统的花费标注与评测成本测试集标注、效果评测所需的人力成本运维与监控成本线上告警、日志分析、故障处理的人力占用兜底人工成本模型搞不定时需要人工介入处理的成本这个最容易漏算。算完这五类成本再回到商业侧看定价和ROI。我们当时算了一笔账一个自动化处理场景平均每次处理能节省一名客服约5分钟的时间假设客服月成本6000元左右每月的自动化处理量达到800次时就能覆盖当月的技术调用成本。这个数字给了我们信心因为调研中预估的真实月处理量远高于800次。3.4 商业可行性验证用最小访谈探测真实付费意愿技术、数据、成本都过了最后一道关是商业。商业验证不靠精美的PPT推演要靠真实客户访谈。QDKT的做法是定向访谈目标客户群不聊功能聊痛点不聊技术聊费用。具体问题线设计成四个层次现在遇到这个问题怎么解决花了多少时间/多少钱现状确认如果这个问题彻底消失对你意味着什么价值感知有一个产品能帮你自动化处理这件事你愿意一个月付多少钱价格锚点什么条件下你会立刻决定用什么条件下你坚决不用决策条件这套访谈最关键的产出不是“客户说愿意付钱”而是“客户愿意付多少钱、在什么条件下付”。如果一个场景客户普遍只愿意付几十块而你的单次处理成本高居不下商业模式就根本不成立。QDKT在商业验证后做了一个重要调整目标客户从“中小企业通用客服”调整为“特定行业内有高频重复业务处理的团队”后者的付费意愿和接受度远高于前者。4. 最小验证包设计与执行用最小成本逼近真实闭环可行性验证通过后就进入最小验证包阶段。这个阶段的定位是不做完整产品只做一个“像那么回事”的真实闭环拿给真实用户用观察真实反馈。4.1 最小验证包的三个设计原则第一个原则是“窄而深”。只覆盖场景链条中最核心的一两个环节不要追求面面俱到。我们做内部知识库检索的最小验证包时明确限定只支持“文档检索摘要生成”两件事不碰对话式多轮交互不碰权限管理。第二个原则是“有真实数据”。验证包必须用真实业务数据跑不能拿精心挑选的测试样例演示。第一版验证包直接接入了两个真实业务知识库哪怕覆盖范围小但胜在真实。第三个原则是“可观测反馈”。从用户点击、停留时长、提问内容、采纳比例几个维度采集数据确保验证结束后能回答“用户在多大程度上愿意用、用得顺不顺、卡在哪”。4.2 执行周期与分工参考QDKT这个阶段总共花了三周时间规模是1名产品、1名后端开发、1名算法工程师。这个团队配置很务实——算法工程师负责模型调用和效果调优后端开发负责数据接入和接口封装产品负责场景定义、测试反馈搜集和迭代排期。第一周梳理数据源、清洗数据、做向量化索引、搭起检索链路。 第二周接入模型生成能力做回答稳定性处理和兜底规则。 第三周邀请内部目标用户试用每天收集反馈、快速修问题。这里分享一个经验最小验证包不要追求“技术完美”要追求“场景闭环”。哪怕中间有些步骤是人工模拟的——比如自动检索不出来时允许用户手动补关键词——只要整体体验能反映产品核心价值就可以上线验证。人工兜底不可怕可怕的是为了演示效果过度美化。4.3 第一轮用户反馈与踩坑实录用最小验证包做完首轮验证QDKT拿到了一些特别有价值的反馈也踩了几个值得记录的坑。第一个坑检索结果是“准确但没用”。系统检索出来的文档虽然相关但太长、太分散用户没时间逐篇阅读。解决思路是给每篇文档生成一段结构化摘要并直接提取关键结论。这个改进让用户采纳率提升了一倍。第二个坑模型输出“一本正经地胡说八道”。模型在找不到答案时会强行编造一个看似合理的回答这在知识库场景是致命的。我们后来在应用层加了一道强制规则模型自信度低于阈值时放弃生成回答明确提示“未找到相关内容建议转人工”。这个规则让错误回答率降到了极低水平。第三个坑用户的使用习惯没有养成。第一周用户还会因为新鲜感试用第二周就明显懈怠了。后面我们在用户使用路径里加了一个轻量入口把工具嵌到用户原有工作流里而不是让用户额外打开一个新系统使用频次才稳定下来。5. 常见问题与排查技巧实录从场景挖掘到最小闭环QDKT走完了整个0到1链路过程中遇到的典型问题基本都在这儿了。整理成问题速查表方便以后做同类项目直接翻| 问题 | 典型症状 | 排查思路 | 预防手段 | | --- | --- | --- | --- --- | | 伪需求伪装成真需求 | 用户访谈时都说好上线后没人用 | 追问“今天遇到这个问题怎么处理的”观察实际工作流 | 坚持FBS打分交给量化标准 | | 数据获取比预期难得多 | 谈好的数据接口迟迟不开或者数据质量极差 | 小样本测试先行拒绝空头承诺 | 合同里写清数据交付节点未交付有违约约束 | | 模型输出不可控 | 同一问题答案时好时坏 | 做多轮一致性测试统计方差 | 应用层加强制兜底规则不裸奔调用模型 | | 效果在演示时好用实际上线崩 | 场景和数据过于理想化 | 用真实样本重新评测 | 最小验证包直接接入真实数据 | | 成本测算漏项 | 上线后账单超出预期 | 把人工兜底和运维成本纳入成本表 | 按五类成本逐项预估 | | 内部干系人不支持 | 项目推进处处受阻 | 关键角色介入太晚 | 可行性验证阶段就做干系人访谈 |再补一条容易被忽略的经验AI产品0到1阶段文档记录和过程复盘的重要性不亚于写代码。我们每做完一次用户访谈都会在当天完成访谈纪要归档每调整一次方案都要在需求池里同步更新决策原因。这些记录看起来占时间但等复盘时回看当初为什么选这个场景、为什么否定那个方案清清楚楚。6. 后续扩展思路QDKT首轮验证跑通后我们马上又启动了第二轮场景探索。这次的方法比第一次成熟得多因为手里已经有了一个可复用的流程场景挖掘→可行性验证→最小验证包→真实反馈→迭代扩展。每个新场景都能沿着这个流水线快速走一遍而不是每次都从零摸索。往后可以考虑的方向主要有三个。一个方向是把验证过的能力产品化做成可配置的标准模板让同行业的其他团队也能快速接入另一个方向是把知识库检索扩展到更多数据类型比如表格、图片、外部链接扩展场景覆盖面还有一个方向是把单点工具升级为工作流自动化让AI不仅能回答问题还能主动触发后续处理动作。我个人在做完QDKT之后有一个特别深的体会AI产品从0到1最大的门槛从来不是技术门槛而是“决策门槛”——你怎么在一个信息不全、时间有限的状态下做出一个大概率正确的取舍。场景挖掘和可行性验证这两步本质上是把“赌运气”变成“讲方法”。如果你也正在做AI产品或者正准备立项真心建议把一半的精力放在这两件事上后面会顺很多。 
长河君 · 2026/10/19 9:41:18 · 阅读 1.2k AI产品从0到1：场景挖掘与可行性验证全流程实战
QDKT是我最近带着一个跨职能小团队从零开始推进的AI产品代号。这个项目最让我有分享欲的不是最后做出来的那个Demo有多炫而是我们在最前期那段“什么都没有、只有一堆想法”的阶段靠一套方法硬是把模糊的念头一步步收敛成了可落地的产品定义。说白了AI产品从0到1真正决定生死的就是两个环节场景挖掘和可行性验证。场景挖错了后面做得越用力死得越快可行性没验证清楚资源砸进去连个响都听不见。我自己见过太多团队拿着大模型的能力到处找场景找来找去全是“能做但没人用”的功能或者反过来一个需求看着很痛一调研发现技术上根本稳不住。所以这篇就把QDKT从0到1过程中我们在场景挖掘和可行性验证上用的整套思路、踩过的坑、以及可以直接拿去用的模板和判断标准一次性说透。1. 内容整体设计与思路拆解AI产品的起点不应该是“我会用什么模型”而应该是“谁在什么情境下遇到了什么问题”。QDKT立项之初我们内部最激烈的争论就是到底先定技术方案还是先定场景技术背景强的同事倾向于先搭一套底座把模型接入、知识库、对话链路都跑通然后看能做什么但产品背景的同事坚持必须先回答“为谁解决什么问题”否则底座搭完了也只是个昂贵的玩具。最后我们达成的共识是场景先于技术验证先于投入。这个原则说起来简单执行起来需要一套流程去约束。1.1 首个AI产品选型的三段式推进框架我们最终把从0到1的过程拆成了三个阶段场景挖掘、可行性验证、最小验证包设计与验证。三段之间是严格的先后关系不允许跳步。场景挖掘回答“做给谁、解决什么、在什么场景下发生”产出是一份候选场景清单和优先级排序。可行性验证回答“这件事能不能做成”分别从技术、数据、成本、商业四个维度去做小成本验证。最小验证包选定最高优先级场景后用最小成本实现一个能真实运行的闭环用真实用户反馈来确认方向。为什么一定要这个顺序我举个反例我们同期有另一个项目组先花了三周用主流大模型API搭了一个通用问答机器人后来又觉得“问答太泛了”临时决定聚焦到某个垂直场景结果发现当时选的模型在该领域的专业术语理解上差得离谱底座的对话链路设计也根本不适配结构化查询几乎推倒重来。先做技术后找场景输在了起跑线上。1.2 为什么场景挖掘是最容易翻车的环节场景挖掘看起来不就是“找需求”吗但凡做过的人都知道坑全藏在细节里。最大的问题在于“伪需求”——表面看用户说想要实际他并不愿意为它改变习惯也不愿意付钱。典型的伪需求长这样用户说“要是有个智能助手帮我把报表做了就好了”但真把报表自动生成摆在他面前他又说“格式不对、不够直观、我还是自己拉数据吧”用户说“痛点很大”但追问“现在你怎么解决的”他说“我多花半小时手动处理”说明现有替代方案成本还没到不可忍受的程度需求是面向“某类用户”的但这类用户在你的目标群体里占比极低支撑不起产品的最小闭环。场景挖掘阶段的真正任务不是收集需求而是给需求“去伪存真”筛出那些高频、强烈、且现有方案严重不足的场景。1.3 可行性验证为什么必须前置很多AI产品死在半路不是因为模型不行而是因为数据拿不到、效果不稳定、单次调用成本太高导致商业模型算不过来、或者关键干系人根本不买账。这些问题如果在场景挖掘之后、投入开发之前集中验证一遍淘汰成本极低一旦进入开发任何一项翻车都意味着真金白银的损失。QDKT在可行性验证阶段有个硬性要求每个候选场景必须列出“关键假设”然后设计最小实验去验证这些假设。假设不成立的场景直接砍掉不拖泥带水。这一条规则帮我们省下了至少两个整月的开发资源。2. 场景挖掘实操把模糊需求收敛为高价值场景场景挖掘的输出质量决定了后续一切工作的天花板。QDKT在这个阶段用了两周时间做了三件事广泛收集、深度访谈、量化打分。2.1 场景来源的三条主要渠道第一条渠道是目标用户访谈。这里的关键不是问“你想要什么AI功能”而是观察和询问用户当前的工作流程找到流程中最耗时、最易错、最让人烦躁的环节。第二条渠道是数据分析。尤其是做企业服务类AI产品工单记录、客服会话、操作日志、搜索记录都是金矿。我们团队分析了一家合作公司的客服会话记录发现约有35%的提问集中在“修改密码、查余额、办业务”这三类高频重复问题上这就是一个清晰可量化的场景入口。第三条渠道是内部提效需求。很多AI产品最早的种子用户就是内部团队。我们当时调研了内部多个小组发现资料查找类需求特别普遍。表面看这是“搜索工具”的需求但往深了挖本质是“知识分散、缺乏统一检索入口”的问题这就决定了产品形态不能只是一个搜索框而是一套知识整合方案。2.2 真伪需求辨识的四个判断维度拿到一堆原始需求后我们套用了一套四维过滤器每个维度打分低于阈值的直接淘汰。第一维是频率。这个需求多久发生一次一天一次是高频一周一次是低频。AI产品最怕低频需求因为用户对低频工具的依赖度极低很难养成使用习惯。第二维是痛感强度。现有解决方案让用户有多痛苦可以用一个粗暴的问题来测如果这个功能明天上线你愿意在今天的工作中主动使用它吗愿意且主动才是强痛点。第三维是可支付性。用户或客户是否愿意为此买单是愿意付99元/月还是要求免费才用这直接决定商业模式的成立与否。第四维是数据可达性。AI产品需要数据支撑才能运行你能否合法、合规、可持续地获取所需数据这是很多团队最容易事后踩雷的一点——场景很痛但数据根本拿不到或者数据质量差到无法建模。QDKT早期筛掉了一个“自动生成会议纪要”的场景频率和痛感都达标但数据可达性不过关——会议录音涉及大量隐私合规问题而且不同会议室的音频质量差异巨大最终果断放弃。2.3 场景优先级打分模型一套可直接套用的FBS评估法面对十几条看起来都“有点意思”的候选场景不能靠拍脑袋选需要量化排序。QDKT用的是FBS打分法维度如下维度权重说明Frequency 频率30%场景发生的频次越高分越高Pain 痛感30%用户对现有方案的满意度越低分越高Business 商业潜力20%付费意愿、市场规模评估Support 数据与资源20%数据可得性、合规性、技术可行性的综合评估每项按1-5分打分加权求和。四个维度中Frequency和Pain是最核心的加起来占比60%因为我们坚信一个产品连“高频”和“刚需”都占不上后面就基本不用聊了。我们跑完这套打分后的结果挺有意思排名第一的不是最初呼声最高的“智能客服助手”而是“内部知识库智能检索”。原因在于知识检索在频率和痛感上得分都很高而且数据资源完全在握。后来我们把这个结果拿给一位做企业服务多年的朋友看他说了一句很扎心的大实话“企业内部找资料这个痛点比你们想象的还要痛。”3. 可行性验证四维验证矩阵的完整打法场景挖掘选出的最优场景不代表就一定能做成。可行性验证要回答的是在真实约束条件下这个产品是否能以可接受的成本、达到及格线以上的效果、并建立可持续的商业闭环。QDKT在实践中把可行性验证拆成四个维度形成一个四维验证矩阵。3.1 技术可行性验证模型能力边界与效果基线技术验证最容易犯的毛病是“用理想环境代替真实环境”。很多功能在标准测试集上表现不错但放进真实场景里就崩掉了原因多半是数据分布不一致。QDKT在这一步做了一件事从真实业务数据中抽一批有代表性的样本用现成模型做一次基线效果测试。具体操作上我们会把真实场景的输入样例分类整理——比如知识库检索场景就把问题按照“简单事实型、流程指引型、多条件复合型、模糊意图型”分类每类挑10-20条真实问题然后跑一遍模型看回答是否正确、是否完整、是否稳定。这里要特别提醒一个容易被忽略的点模型输出的稳定性比单次准确率更重要。同一道题跑十次如果五次答对五次答错这个能力就不适合直接上生产。QDKT当时测试时发现某个主流API在处理某种长尾格式的问题时答非所问的概率接近20%这个结果直接让我们否掉了“直接API调用不做兜底”的轻量方案转而决定在应用层加一道规则校验确保模型输出异常时能及时拦截。这个决策后来在真实使用中挽救了无数尴尬场面。3.2 数据可行性验证拿数比建模难十倍对于AI产品数据就是生产资料。技术验证可以造假但数据验证造不了假。QDKT在数据维度重点考察三件事数据是否可得、数据质量是否够用、数据合规是否站得住。数据可得性是否有稳定、可持续的渠道获取数据是需要用户手动导入还是系统可以自动回流数据质量样本是否覆盖足够多的边界情况是否存在严重偏差清洗成本有多高数据合规数据来源是否合法合规涉及个人信息是否需要脱敏有没有超范围收集的风险这一环节千万不要只听销售或商务口头的“数据有”一定要拿到真实样本自己看。QDKT踩过一个坑合作方说“我们有几十万条业务知识文档”结果实际开放出来的数量只有几千条而且大部分是几年前的过期内容根本没法支撑问答质量。后来我们改了策略任何数据承诺都要求先开放一个最小可用样本验证通过再继续谈全量。3.3 成本可行性验证把账算到每一块钱AI产品的成本不是“模型调用费”那么简单要算全成本账。QDKT做了一个成本结构表覆盖了以下条目推理成本每次核心操作的API调用或本地推理成本存储与带宽成本向量数据库、对象存储、日志系统的花费标注与评测成本测试集标注、效果评测所需的人力成本运维与监控成本线上告警、日志分析、故障处理的人力占用兜底人工成本模型搞不定时需要人工介入处理的成本这个最容易漏算。算完这五类成本再回到商业侧看定价和ROI。我们当时算了一笔账一个自动化处理场景平均每次处理能节省一名客服约5分钟的时间假设客服月成本6000元左右每月的自动化处理量达到800次时就能覆盖当月的技术调用成本。这个数字给了我们信心因为调研中预估的真实月处理量远高于800次。3.4 商业可行性验证用最小访谈探测真实付费意愿技术、数据、成本都过了最后一道关是商业。商业验证不靠精美的PPT推演要靠真实客户访谈。QDKT的做法是定向访谈目标客户群不聊功能聊痛点不聊技术聊费用。具体问题线设计成四个层次现在遇到这个问题怎么解决花了多少时间/多少钱现状确认如果这个问题彻底消失对你意味着什么价值感知有一个产品能帮你自动化处理这件事你愿意一个月付多少钱价格锚点什么条件下你会立刻决定用什么条件下你坚决不用决策条件这套访谈最关键的产出不是“客户说愿意付钱”而是“客户愿意付多少钱、在什么条件下付”。如果一个场景客户普遍只愿意付几十块而你的单次处理成本高居不下商业模式就根本不成立。QDKT在商业验证后做了一个重要调整目标客户从“中小企业通用客服”调整为“特定行业内有高频重复业务处理的团队”后者的付费意愿和接受度远高于前者。4. 最小验证包设计与执行用最小成本逼近真实闭环可行性验证通过后就进入最小验证包阶段。这个阶段的定位是不做完整产品只做一个“像那么回事”的真实闭环拿给真实用户用观察真实反馈。4.1 最小验证包的三个设计原则第一个原则是“窄而深”。只覆盖场景链条中最核心的一两个环节不要追求面面俱到。我们做内部知识库检索的最小验证包时明确限定只支持“文档检索摘要生成”两件事不碰对话式多轮交互不碰权限管理。第二个原则是“有真实数据”。验证包必须用真实业务数据跑不能拿精心挑选的测试样例演示。第一版验证包直接接入了两个真实业务知识库哪怕覆盖范围小但胜在真实。第三个原则是“可观测反馈”。从用户点击、停留时长、提问内容、采纳比例几个维度采集数据确保验证结束后能回答“用户在多大程度上愿意用、用得顺不顺、卡在哪”。4.2 执行周期与分工参考QDKT这个阶段总共花了三周时间规模是1名产品、1名后端开发、1名算法工程师。这个团队配置很务实——算法工程师负责模型调用和效果调优后端开发负责数据接入和接口封装产品负责场景定义、测试反馈搜集和迭代排期。第一周梳理数据源、清洗数据、做向量化索引、搭起检索链路。 第二周接入模型生成能力做回答稳定性处理和兜底规则。 第三周邀请内部目标用户试用每天收集反馈、快速修问题。这里分享一个经验最小验证包不要追求“技术完美”要追求“场景闭环”。哪怕中间有些步骤是人工模拟的——比如自动检索不出来时允许用户手动补关键词——只要整体体验能反映产品核心价值就可以上线验证。人工兜底不可怕可怕的是为了演示效果过度美化。4.3 第一轮用户反馈与踩坑实录用最小验证包做完首轮验证QDKT拿到了一些特别有价值的反馈也踩了几个值得记录的坑。第一个坑检索结果是“准确但没用”。系统检索出来的文档虽然相关但太长、太分散用户没时间逐篇阅读。解决思路是给每篇文档生成一段结构化摘要并直接提取关键结论。这个改进让用户采纳率提升了一倍。第二个坑模型输出“一本正经地胡说八道”。模型在找不到答案时会强行编造一个看似合理的回答这在知识库场景是致命的。我们后来在应用层加了一道强制规则模型自信度低于阈值时放弃生成回答明确提示“未找到相关内容建议转人工”。这个规则让错误回答率降到了极低水平。第三个坑用户的使用习惯没有养成。第一周用户还会因为新鲜感试用第二周就明显懈怠了。后面我们在用户使用路径里加了一个轻量入口把工具嵌到用户原有工作流里而不是让用户额外打开一个新系统使用频次才稳定下来。5. 常见问题与排查技巧实录从场景挖掘到最小闭环QDKT走完了整个0到1链路过程中遇到的典型问题基本都在这儿了。整理成问题速查表方便以后做同类项目直接翻| 问题 | 典型症状 | 排查思路 | 预防手段 | | --- | --- | --- | --- --- | | 伪需求伪装成真需求 | 用户访谈时都说好上线后没人用 | 追问“今天遇到这个问题怎么处理的”观察实际工作流 | 坚持FBS打分交给量化标准 | | 数据获取比预期难得多 | 谈好的数据接口迟迟不开或者数据质量极差 | 小样本测试先行拒绝空头承诺 | 合同里写清数据交付节点未交付有违约约束 | | 模型输出不可控 | 同一问题答案时好时坏 | 做多轮一致性测试统计方差 | 应用层加强制兜底规则不裸奔调用模型 | | 效果在演示时好用实际上线崩 | 场景和数据过于理想化 | 用真实样本重新评测 | 最小验证包直接接入真实数据 | | 成本测算漏项 | 上线后账单超出预期 | 把人工兜底和运维成本纳入成本表 | 按五类成本逐项预估 | | 内部干系人不支持 | 项目推进处处受阻 | 关键角色介入太晚 | 可行性验证阶段就做干系人访谈 |再补一条容易被忽略的经验AI产品0到1阶段文档记录和过程复盘的重要性不亚于写代码。我们每做完一次用户访谈都会在当天完成访谈纪要归档每调整一次方案都要在需求池里同步更新决策原因。这些记录看起来占时间但等复盘时回看当初为什么选这个场景、为什么否定那个方案清清楚楚。6. 后续扩展思路QDKT首轮验证跑通后我们马上又启动了第二轮场景探索。这次的方法比第一次成熟得多因为手里已经有了一个可复用的流程场景挖掘→可行性验证→最小验证包→真实反馈→迭代扩展。每个新场景都能沿着这个流水线快速走一遍而不是每次都从零摸索。往后可以考虑的方向主要有三个。一个方向是把验证过的能力产品化做成可配置的标准模板让同行业的其他团队也能快速接入另一个方向是把知识库检索扩展到更多数据类型比如表格、图片、外部链接扩展场景覆盖面还有一个方向是把单点工具升级为工作流自动化让AI不仅能回答问题还能主动触发后续处理动作。我个人在做完QDKT之后有一个特别深的体会AI产品从0到1最大的门槛从来不是技术门槛而是“决策门槛”——你怎么在一个信息不全、时间有限的状态下做出一个大概率正确的取舍。场景挖掘和可行性验证这两步本质上是把“赌运气”变成“讲方法”。如果你也正在做AI产品或者正准备立项真心建议把一半的精力放在这两件事上后面会顺很多。