这两年AI智能体有多火不用我多说，身边做技术、做产品的人几乎都在看。但我也发现一个很有意思的现象：很多团队从选型到上线，恨不得只花两周时间——模型定了、框架选了、Demo跑通了，就兴冲冲推到业务侧，结果后台数据显示日活个位数，业务方礼貌性地用了一次，然后就没有然后了。“AI智能体选急了，上线为啥没人用”，这个问题说出来很扎心，但几乎每个冲在一线的人都遇到过。尤其典型的是那种“老板拍板要快、技术栈要新、场景要大”的项目——选型的时候焦虑到天天刷榜单，上线之后静悄悄到像上了个寂寞。我见证过不止一次，从满怀期待到彻底凉透，中间的周期可能连一个月都不到。这事到底是因为技术不行，还是因为一开始就想错了？我跟几个踩过坑的朋友聊了很多次，也复盘过自己参与的几个项目，最大的感受是：选型急不是最要命的，真正致命的是没人真正想清楚“用户为什么会用”这个问题。这篇文章我不讲那种高大上的趋势分析，也不列几百字的产品功能清单，就聊聊一个AI智能体从“选型到上线”这个链路里，最容易翻车的几个环节，以及我们后来是怎么一步步把“没人用”变成“有人愿意天天用”的。适合正在做或刚准备做AI应用的技术负责人、产品经理，还有那些被领导拍桌子催上线的兄弟们。1. 先别怪用户，这一波“选型焦虑”是怎么来的1.1 典型症状：先有工具，后有场景很多团队做AI智能体，流程是反的。先是某天老板参加了一个峰会，回来说“AI智能体这东西我们必须得有”，然后技术团队就开始紧锣密鼓地选型——大模型用哪家？Agent框架用哪个？要不要上RAG？向量库用哪款？等工具链全定下来、Demo也跑通了，才开始到处找业务方问：“你们有什么场景需要AI帮忙的？”这就是典型的“先有锤子再找钉子”。我参与过的一个项目就是这样，平台选了最新最强的模型，支持多轮对话、工具调用、知识库问答，开发同学肝了一个月，上线之后发现业务方反馈“我们最需要的不是聊天机器人，而是 Excel 表格整理”。那一刻所有人都是懵的。不是模型能力不够，是压根没搞清楚什么样的业务环节真正值得用Agent去替代或增强。1.2 为什么“快速上线”会成为惯性说句公道话，不是团队不愿意好好想，是外部压力真的很大。行业里天天有人发“AI落地案例”，各种大厂每天都在堆人工智能应用，管理层看到竞争对手上了智能体，就会催自己团队也赶紧上，不然显得落后。“来不及了，先上再说”成了默认选项。于是大家都在一条错误的道路上抢跑。算法同学熬夜调Prompt，产品同学赶着出页面，业务方连需求文档都还没看明白就被拉去开评审会。最终的结果是可以预见的：一个没有经过真实场景验证、没有考虑用户习惯、没有想清楚成本收益的“半成品”被仓促推向内部或外部用户。我特别理解这种处境，但你得明白——上线速度从来不等于落地质量。真的要赶工，也应该是在验证清楚了“做对的事”之后再去拼速度，而不是对着空气挥拳。1.3 被忽略的前置问题：你根本没说清“成功长什么样”还有一类团队，不是没问“用户为什么用”，而是压根没定义“什么叫有用”。一个AI智能体上线之后，到底是要达到多少使用率才算成功？是帮用户节省了多少时间？还是把某类工单的处理时长从十分钟压到了一分钟？这些目标在立项时没有量化，上线后用起来才发现——“好像有点用，但说不清哪里有用”。更离谱的是，有些项目拿“对话次数”“提问总数”当成核心指标。结果就是产品经理设了个欢迎语“你有什么问题都可以问我”，用户不知道该问什么，随便试了两句发现答案一般，就再也不打开了。如果你连“用户用得爽长什么样”都描述不出来，那你怎么让用户用得爽？2. 上线没人用，别急着怪用户2.1 伪需求的坑：痛点到底是谁的痛点做过B端项目的应该都有同感：很多看起来特别像“痛点”的需求，其实是我们想象出来的。举个最常见的例子：客服智能体。做之前想得很美——用户不用排队等人工了，机器人先接住问题，答不了的再转人工，多高效。实际上呢？我见到的某个电商客服项目，用户上来直接输入“人工客服”，甚至发了一串表情包，机器人怎么绕都绕回到人工入口。用户根本没有耐心去跟一个“不太聪明”的机器人解释自己遇到的问题，他们只想要一个能解决问题的人。这就是伪需求最典型的特征：从业务方和管理层的角度看，确实省了成本；但站在实际使用者这一端，体验并没有变得更省事，反而多了一道“拦路虎”。真正值得上智能体的场景，必须有一个非常明确的“当下最优解”和“人工处理的核心痛点”。不是简单地“用户问—机器答”这种表层需求，而是“用户在处理某个具体任务时，卡在了哪个环节、浪费了多少时间”。2.2 交互负担：让用户学习“和AI对话”本身就是门槛另一个经常被人忽视的问题，是交互方式的门槛。很多智能体产品默认用户会“像和人聊天一样”使用它，但实际上一大半用户根本不知道该怎么和AI表达需求。你提供一个空荡荡的对话框，用户第一反应是：我要干嘛？尤其在企业内部场景，大家早就习惯了“按钮+表单”的软件交互方式。你让他们去对着一块空白区域打字描述需求，他们脑子里会先冒出一堆问号：要怎么写？直接说要数据可以吗？说一半能不能撤回？我之前参与过一个面向销售团队的智能体，核心功能是帮他们自动整理客户沟通纪要。技术上做得没问题，但上线两周后台数据显示，80%的账号一次都没有点进去过。后来我们回访了几个使用者，他们说“我知道有这个工具，但不知道怎么用它，也不知道它能帮我整理到什么程度”。问题不在于产品难用，在于你让用户凭空想象“它能做什么”，而不是主动告诉他们“你照着这个流程点就能得到什么”。后来我们改了一版，在入口首屏直接预置了三个示例场景按钮，比如“上传今天的通话录音”，用户只要点击、上传，剩下的全自动完成。使用率立刻上来了。2.3 信任崩塌：一次幻觉毁掉全部好感大模型幻觉这事，做应用的人没有不知道的。但在智能体产品里，我们经常低估了幻觉对使用意愿的杀伤力。我自己测过一个知识库问答智能体，用户问的是“公司年假制度中，入职满一年可以享受几天年假”，智能体从一个错误来源里摘了一段“入职满两年可享受15天年假”的内容给了用户。结果那个用户拿着这个答案去找HR对质，最后发现AI理解错了文档版本。这件事传开之后，整个团队在内部的口碑直接崩了。后面不管智能体答得多准，用户都会多留一个心眼，遇到稍微重要一点的场景绝对不用，宁可用自己效率低一下的方式来处理。这给我最大的教训是：宁可让AI说“我不知道”，也不要让它一本正经地胡说八道。在技术兜底上，必须限制置信度低的回答直接拒绝，而不是硬编一段看似合理的答案。信任建立起来非常慢，但崩塌只需要一次。2.4 价值感失灵：为什么“省时间”用户不买账还有一种情况，是产品确实帮用户省了时间，但用户自己感觉不到“价值”。比如某个内部文档检索智能体，原来找一个合同模板要花五分钟翻文件夹，现在十秒钟就出来了。省下了四分多钟，在个人感受上却微乎其微——因为用户不觉得“找模板”是一件事，他们觉得这只是某个大任务中间的一个小动作。真正让用户觉得“这东西离不开了”的时刻，往往不是“帮我省了一点小时间”，而是“帮我完成了一件原本必须花一整块时间做的事情”。比如自动生成数据分析报告、自动整理周报的摘要、自动把录音变成结构化会议纪要。这些事情有明确的“起止点”和“完成感”，用户用完会觉得“省了一个小时”。如果你的智能体只会在每个环节上帮用户省几秒，那它在用户心里的存在感就约等于零。3. 正确的选型框架：场景优先，技术匹配3.1 场景筛选四问法聊聊我们后来是怎么把流程掰回来的。现在每看到一个候选场景，我们都会先做一轮四问过滤，通过之后再谈技术选型。第一个问题：这个场景的发生频次有多高？智能体要被用户记住，至少得做到一周用两三次。一个“每月可能用一次”的场景，做得再好也容易被遗忘。第二个问题：如果做成了，对用户的整体效率提升是否明显？这里说的不是“省几个点击”，而是“省掉一次完整的来回沟通”或“打掉一个半小时的重复劳动”。第三个问题：答错/做错的代价有多大？如果AI出错可能导致严重损失，那就必须慎重，要么加强人审环节，要么先放着不做，不要一上来就啃硬骨头。第四个问题：现有的传统工具或人工方式是不是已经够用了？如果流程已经足够顺滑，硬加一个智能体只会增加负担，不可能有人用。我把这四个问题做成了一张评估表，每次内部评审候选场景时就逐条打分，任何一个问题答不上来的，一律不做。这套流程看着简单，但真的能挡掉一堆“自我感动”型项目。3.2 技术选型的关键考量：模型能力边界得贴着场景走确定场景之后，再回头去看技术选型，思路会清晰很多。模型能力不必追求“全都要最强”。一个只做分类、抽取的结构化数据场景，用轻量级模型就够了，非要上个超大参数量模型，成本高不说，推理慢还会影响用户体验。一个真正需要复杂推理、多步规划的智能体场景，再考虑更高级的模型和更复杂的Agent编排。RAG和微调的选择也一样。我见过有人给模型做微调，只是为了让它学会公司内部的术语解释——这用RAG完全能解决，微调又贵又容易过拟合。反过来，如果你需要模型模仿某种特定写作风格或专业判断逻辑，且这类要求高度稳定，微调才更合适。回到那位被叫去“选型焦虑”的朋友身上，我给他的建议是：先拿一个真实场景的最小样本，用市场上最好的API快速验证可行性和上限值；如果API方案都做不到及格线，那就别指望微调能救回来，果断换个场景。只有在验证通过之后，才值得考虑自建模型、私有化部署这些重投入方案。3.3 成功指标前置：上线前就定义好“什么算有用”另一个很关键的动作，是在项目启动那天就把“什么叫成功”写下来。不要只写“上线了”这种里程碑，要写“谁来用、多久用一次、用完之后能省多少时间/多少钱”。举一个比较实际的例子：一个内部工单分类智能体，我们的成功定义是“一线运营人员处理单个工单的平均时长从8分钟降到5分钟以内，且智能体推荐分类的采纳率不低于80%”。有了这两个数字，后续的每一次迭代、改版、调优都有方向可以参考。后来我们每天晚上看实时数据，如果分类准确率掉到阈值以下，立刻切回人工兜底，同时回过来调Prompt或修RAG链路。没有这种前置指标，出了问题连“修什么”都不知道。4. 从冷启动到迭代：一条亲测可行的落地路径4.1 只选三个种子用户，拒绝大而全很多团队做AI产品喜欢搞“全员开放”，但这对新上线的智能体来说几乎是灾难。人一旦多了，各种奇奇怪怪的问题全涌进来，模型答得不够好，口碑一下子就崩了。我们的做法反其道而行：首期只选三个高潜力种子用户/团队。条件很简单——他们日常处理的任务正好落在你做的那一个场景里，且他们对外界新工具有开放心态，愿意给反馈。第一个周，我们的核心工作基本就是盯这三个人用产品，观察他们从哪一步卡住，在哪一句话上犹豫了，哪一个功能点完全没被发现。问题收集够了，就当场改版，改完再让他们体验。这个过程看着“规模小”，实际上是最快的优化方式。三个人的深度反馈，比三百个人的沉默点击有价值得多。4.2 灰度设计的三个关键配置第二批放开之前，我们花了点时间把灰度机制搭好，有三个配置很关键。一是功能开关和权限白名单。确保只有被选中的用户能看到智能体入口，其余人打开页面一切照旧。这样做的好处是，即使出现了比较严重的体验问题，影响范围也能被控制住。二是完整链路日志和埋点。从用户进入入口、输入问题、等待响应、点击采纳到最终提交反馈，每一步都要有记录。日志的粒度越细，后面复盘问题就越容易。三是“人工兜底”的交替方案。每一条AI生成的结果背后，都要有明确的人工接管路径，保证AI模型抽风时用户不会被晾在那里。这项配置在灰度期尤其不能省。有一次我们在灰度时发现某个渠道进来的一批问题命中率跌到了60%，就是因为及时切了人工兜底，业务方才没有产生大面积的负面情绪。后来才发现是那批问题的表述方式里包含大量行业黑话，RAG召回环节没接住。4.3 上线第一周盯住这四个数据第一周的数据要不要每天看？要。但看什么数据很讲究，四个数据是我们后来固定下来的。第一个是完整体验率，即有百分之多少的用户不是问一句就走，而是完成了从进入到拿到结果的全流程。一进来看到界面不知道怎么操作直接退出的，说明入门引导有问题。第二个是次日回头率。主动回访进入第二次、第三次的比例。这个数据很诚实，如果一次体验没让用户觉得“值得再来”，第二天基本不会有人回访。第三个是AI输出被采纳的比例。用户拿到结果之后是直接用了，还是删掉重来？这个决定着你这个智能体到底是不是真的好用。第四个是意图识别失败率，即有多少提问被模型明确判定为“不知道”或“不匹配”。你搜集到这些“漏网之鱼”，就能不断补充和维护RAG来源。4.4 建立“说出来不丢人”的反馈通道说实话，用户不愿意用，很多时候是因为“提了意见也没用”。所以我们在灰度期开通了一个非常轻的反馈通道——不算工单系统、不占绩效指标，只有一个简单的入口表单：“刚刚那个结果哪里不对，一句话说明就行”。刚开始的反馈大部分是抱怨，比如“这个答案跑偏了”“完全没有我要的内容”。但我们坚持每条都看、每条都回复，哪怕只是说“收到，下个版本会优化”。坚持了两周之后，反馈质量明显提高，用户开始愿意写几十字的问题描述了。这也是一个活水：你愿意听，用户才愿意说；用户愿意说，产品才有机会真正变好用。5. 上线后没人用：典型问题排查实录5.1 用户说“用不上”，其实是入口和场景的错位如果产品上线后用户反馈“用不上”，我通常不急着改功能，而是先去看埋点数据：他们到底是从哪一步开始流失的？有一回我们做内部报销政策问答智能体，功能上完全没问题，但消息弹窗入口藏在企业后台的第三个菜单里。很多人压根就没发现那个入口，一直以为这个智能体还没上线。把入口提到主页搜索框旁边之后，使用率翻了两倍。很多“没人用”的系统，本质上不是用户不愿意用，而是他们根本不知道“这个东西在哪里可以用”。另一个反直觉的点是：入口离用户的工作流越近越好。最好把智能体嵌入他们每天必用的那个页面，而不是做成一个独立的站点。5.2 用户说“不敢用”，幻觉问题怎么兜底“不敢用”比“用不上”要棘手得多，因为核心问题是信任。解决信任问题不能靠嘴上承诺“我们的模型准确率高”，要靠工程手段兜底。我推荐的做法是三层防线。第一层是在Prompt里做好边界约束，明确告诉模型“不要编造，没有依据就回复不知道”。第二层是在RAG链路里设置置信度阈值，检索证据的相关性评分不够高就直接拒绝回答，不让模型自己硬凑。第三层是在输出端加“参考来源”展示，用户点开能看到答案是从哪份文档里来的，心里就有底了。幻觉不可能到零，但通过这三层，可以把“一本正经胡说八道”的概率压到极低。用户只要有过几次“答案有据可查”的体验，信任感会慢慢回来。5.3 用户说“不划算”，算账方式错了有时候用户说“不划算”，真不一定是在否定产品价值，而是他们算错了账。比如前面提到的记账场景，用户说自己手动整理也就二十分钟，何必还要打开你那个系统。但从管理视角看，每周全体销售花在这事上的时间加起来是几十个小时。这个账，一线使用者没有感知，管理层可能也还没有量化。所以你需要做一件事：在正式推广时，别只讲“AI多聪明”，要给业务方算一笔“时间会计”——每个用户每周节约多少分钟，乘以人数、乘以周数，一年下来相当于增加了多少有效工时。把价值翻译成管理层关心的语言，项目才能站得住脚。5.4 团队自己先失去信心，怎么止损最让人觉得可惜的，其实是团队内部先失去信心，导致一款本来有机会做好的产品被仓促砍掉。我不止一次看到，AI智能体一上线，数据没起色，领导层就断言“这方向不行”，直接停掉整个项目。其实很多问题在两周之内可能就能修复，关键是要有一套“留观期”机制，在此期间集中火力修Main问题。我们的做法是：灰度数据出来后，给自己定一个最低兑现线——比如“第二周完整体验率达到30%且采纳率达到60%”。一周结束时拉数据，如果没达到，就认真复盘是场景选错了、模型能力不够，还是交互没做好。是交互问题就改产品，是场景问题就果断放弃。放弃不可怕，可怕的是用一次失败的数据直接宣判一个方向“没有可能性”，然后错过了本该有的迭代窗口。我在实际项目里摸索出来的体会是：AI智能体能不能被接受，从来不是模型参数单方面的能力问题，而是产品有没有长在用户行为和业务习惯上。技术再强，如果找错了场景、设计太重、没有信任兜底，数据难看是必然结果。最后再讲一个很多人容易忽略的操作细节：灰度期不要总盯着“有多少人访问”，而要多看“有多少人再次访问”。一个智能体的第一版体验完全可以不完美，但只要有足够的理由让用户愿意回来第二次、第三次，后面的打磨空间就会非常可观。反过来，哪怕首次体验流畅到让人惊叹，只要用户没有动力再打开，这个产品迟早还是会被遗忘。
这两年AI智能体有多火不用我多说，身边做技术、做产品的人几乎都在看。但我也发现一个很有意思的现象：很多团队从选型到上线，恨不得只花两周时间——模型定了、框架选了、Demo跑通了，就兴冲冲推到业务侧，结果后台数据显示日活个位数，业务方礼貌性地用了一次，然后就没有然后了。“AI智能体选急了，上线为啥没人用”，这个问题说出来很扎心，但几乎每个冲在一线的人都遇到过。尤其典型的是那种“老板拍板要快、技术栈要新、场景要大”的项目——选型的时候焦虑到天天刷榜单，上线之后静悄悄到像上了个寂寞。我见证过不止一次，从满怀期待到彻底凉透，中间的周期可能连一个月都不到。这事到底是因为技术不行，还是因为一开始就想错了？我跟几个踩过坑的朋友聊了很多次，也复盘过自己参与的几个项目，最大的感受是：选型急不是最要命的，真正致命的是没人真正想清楚“用户为什么会用”这个问题。这篇文章我不讲那种高大上的趋势分析，也不列几百字的产品功能清单，就聊聊一个AI智能体从“选型到上线”这个链路里，最容易翻车的几个环节，以及我们后来是怎么一步步把“没人用”变成“有人愿意天天用”的。适合正在做或刚准备做AI应用的技术负责人、产品经理，还有那些被领导拍桌子催上线的兄弟们。1. 先别怪用户，这一波“选型焦虑”是怎么来的1.1 典型症状：先有工具，后有场景很多团队做AI智能体，流程是反的。先是某天老板参加了一个峰会，回来说“AI智能体这东西我们必须得有”，然后技术团队就开始紧锣密鼓地选型——大模型用哪家？Agent框架用哪个？要不要上RAG？向量库用哪款？等工具链全定下来、Demo也跑通了，才开始到处找业务方问：“你们有什么场景需要AI帮忙的？”这就是典型的“先有锤子再找钉子”。我参与过的一个项目就是这样，平台选了最新最强的模型，支持多轮对话、工具调用、知识库问答，开发同学肝了一个月，上线之后发现业务方反馈“我们最需要的不是聊天机器人，而是 Excel 表格整理”。那一刻所有人都是懵的。不是模型能力不够，是压根没搞清楚什么样的业务环节真正值得用Agent去替代或增强。1.2 为什么“快速上线”会成为惯性说句公道话，不是团队不愿意好好想，是外部压力真的很大。行业里天天有人发“AI落地案例”，各种大厂每天都在堆人工智能应用，管理层看到竞争对手上了智能体，就会催自己团队也赶紧上，不然显得落后。“来不及了，先上再说”成了默认选项。于是大家都在一条错误的道路上抢跑。算法同学熬夜调Prompt，产品同学赶着出页面，业务方连需求文档都还没看明白就被拉去开评审会。最终的结果是可以预见的：一个没有经过真实场景验证、没有考虑用户习惯、没有想清楚成本收益的“半成品”被仓促推向内部或外部用户。我特别理解这种处境，但你得明白——上线速度从来不等于落地质量。真的要赶工，也应该是在验证清楚了“做对的事”之后再去拼速度，而不是对着空气挥拳。1.3 被忽略的前置问题：你根本没说清“成功长什么样”还有一类团队，不是没问“用户为什么用”，而是压根没定义“什么叫有用”。一个AI智能体上线之后，到底是要达到多少使用率才算成功？是帮用户节省了多少时间？还是把某类工单的处理时长从十分钟压到了一分钟？这些目标在立项时没有量化，上线后用起来才发现——“好像有点用，但说不清哪里有用”。更离谱的是，有些项目拿“对话次数”“提问总数”当成核心指标。结果就是产品经理设了个欢迎语“你有什么问题都可以问我”，用户不知道该问什么，随便试了两句发现答案一般，就再也不打开了。如果你连“用户用得爽长什么样”都描述不出来，那你怎么让用户用得爽？2. 上线没人用，别急着怪用户2.1 伪需求的坑：痛点到底是谁的痛点做过B端项目的应该都有同感：很多看起来特别像“痛点”的需求，其实是我们想象出来的。举个最常见的例子：客服智能体。做之前想得很美——用户不用排队等人工了，机器人先接住问题，答不了的再转人工，多高效。实际上呢？我见到的某个电商客服项目，用户上来直接输入“人工客服”，甚至发了一串表情包，机器人怎么绕都绕回到人工入口。用户根本没有耐心去跟一个“不太聪明”的机器人解释自己遇到的问题，他们只想要一个能解决问题的人。这就是伪需求最典型的特征：从业务方和管理层的角度看，确实省了成本；但站在实际使用者这一端，体验并没有变得更省事，反而多了一道“拦路虎”。真正值得上智能体的场景，必须有一个非常明确的“当下最优解”和“人工处理的核心痛点”。不是简单地“用户问—机器答”这种表层需求，而是“用户在处理某个具体任务时，卡在了哪个环节、浪费了多少时间”。2.2 交互负担：让用户学习“和AI对话”本身就是门槛另一个经常被人忽视的问题，是交互方式的门槛。很多智能体产品默认用户会“像和人聊天一样”使用它，但实际上一大半用户根本不知道该怎么和AI表达需求。你提供一个空荡荡的对话框，用户第一反应是：我要干嘛？尤其在企业内部场景，大家早就习惯了“按钮+表单”的软件交互方式。你让他们去对着一块空白区域打字描述需求，他们脑子里会先冒出一堆问号：要怎么写？直接说要数据可以吗？说一半能不能撤回？我之前参与过一个面向销售团队的智能体，核心功能是帮他们自动整理客户沟通纪要。技术上做得没问题，但上线两周后台数据显示，80%的账号一次都没有点进去过。后来我们回访了几个使用者，他们说“我知道有这个工具，但不知道怎么用它，也不知道它能帮我整理到什么程度”。问题不在于产品难用，在于你让用户凭空想象“它能做什么”，而不是主动告诉他们“你照着这个流程点就能得到什么”。后来我们改了一版，在入口首屏直接预置了三个示例场景按钮，比如“上传今天的通话录音”，用户只要点击、上传，剩下的全自动完成。使用率立刻上来了。2.3 信任崩塌：一次幻觉毁掉全部好感大模型幻觉这事，做应用的人没有不知道的。但在智能体产品里，我们经常低估了幻觉对使用意愿的杀伤力。我自己测过一个知识库问答智能体，用户问的是“公司年假制度中，入职满一年可以享受几天年假”，智能体从一个错误来源里摘了一段“入职满两年可享受15天年假”的内容给了用户。结果那个用户拿着这个答案去找HR对质，最后发现AI理解错了文档版本。这件事传开之后，整个团队在内部的口碑直接崩了。后面不管智能体答得多准，用户都会多留一个心眼，遇到稍微重要一点的场景绝对不用，宁可用自己效率低一下的方式来处理。这给我最大的教训是：宁可让AI说“我不知道”，也不要让它一本正经地胡说八道。在技术兜底上，必须限制置信度低的回答直接拒绝，而不是硬编一段看似合理的答案。信任建立起来非常慢，但崩塌只需要一次。2.4 价值感失灵：为什么“省时间”用户不买账还有一种情况，是产品确实帮用户省了时间，但用户自己感觉不到“价值”。比如某个内部文档检索智能体，原来找一个合同模板要花五分钟翻文件夹，现在十秒钟就出来了。省下了四分多钟，在个人感受上却微乎其微——因为用户不觉得“找模板”是一件事，他们觉得这只是某个大任务中间的一个小动作。真正让用户觉得“这东西离不开了”的时刻，往往不是“帮我省了一点小时间”，而是“帮我完成了一件原本必须花一整块时间做的事情”。比如自动生成数据分析报告、自动整理周报的摘要、自动把录音变成结构化会议纪要。这些事情有明确的“起止点”和“完成感”，用户用完会觉得“省了一个小时”。如果你的智能体只会在每个环节上帮用户省几秒，那它在用户心里的存在感就约等于零。3. 正确的选型框架：场景优先，技术匹配3.1 场景筛选四问法聊聊我们后来是怎么把流程掰回来的。现在每看到一个候选场景，我们都会先做一轮四问过滤，通过之后再谈技术选型。第一个问题：这个场景的发生频次有多高？智能体要被用户记住，至少得做到一周用两三次。一个“每月可能用一次”的场景，做得再好也容易被遗忘。第二个问题：如果做成了，对用户的整体效率提升是否明显？这里说的不是“省几个点击”，而是“省掉一次完整的来回沟通”或“打掉一个半小时的重复劳动”。第三个问题：答错/做错的代价有多大？如果AI出错可能导致严重损失，那就必须慎重，要么加强人审环节，要么先放着不做，不要一上来就啃硬骨头。第四个问题：现有的传统工具或人工方式是不是已经够用了？如果流程已经足够顺滑，硬加一个智能体只会增加负担，不可能有人用。我把这四个问题做成了一张评估表，每次内部评审候选场景时就逐条打分，任何一个问题答不上来的，一律不做。这套流程看着简单，但真的能挡掉一堆“自我感动”型项目。3.2 技术选型的关键考量：模型能力边界得贴着场景走确定场景之后，再回头去看技术选型，思路会清晰很多。模型能力不必追求“全都要最强”。一个只做分类、抽取的结构化数据场景，用轻量级模型就够了，非要上个超大参数量模型，成本高不说，推理慢还会影响用户体验。一个真正需要复杂推理、多步规划的智能体场景，再考虑更高级的模型和更复杂的Agent编排。RAG和微调的选择也一样。我见过有人给模型做微调，只是为了让它学会公司内部的术语解释——这用RAG完全能解决，微调又贵又容易过拟合。反过来，如果你需要模型模仿某种特定写作风格或专业判断逻辑，且这类要求高度稳定，微调才更合适。回到那位被叫去“选型焦虑”的朋友身上，我给他的建议是：先拿一个真实场景的最小样本，用市场上最好的API快速验证可行性和上限值；如果API方案都做不到及格线，那就别指望微调能救回来，果断换个场景。只有在验证通过之后，才值得考虑自建模型、私有化部署这些重投入方案。3.3 成功指标前置：上线前就定义好“什么算有用”另一个很关键的动作，是在项目启动那天就把“什么叫成功”写下来。不要只写“上线了”这种里程碑，要写“谁来用、多久用一次、用完之后能省多少时间/多少钱”。举一个比较实际的例子：一个内部工单分类智能体，我们的成功定义是“一线运营人员处理单个工单的平均时长从8分钟降到5分钟以内，且智能体推荐分类的采纳率不低于80%”。有了这两个数字，后续的每一次迭代、改版、调优都有方向可以参考。后来我们每天晚上看实时数据，如果分类准确率掉到阈值以下，立刻切回人工兜底，同时回过来调Prompt或修RAG链路。没有这种前置指标，出了问题连“修什么”都不知道。4. 从冷启动到迭代：一条亲测可行的落地路径4.1 只选三个种子用户，拒绝大而全很多团队做AI产品喜欢搞“全员开放”，但这对新上线的智能体来说几乎是灾难。人一旦多了，各种奇奇怪怪的问题全涌进来，模型答得不够好，口碑一下子就崩了。我们的做法反其道而行：首期只选三个高潜力种子用户/团队。条件很简单——他们日常处理的任务正好落在你做的那一个场景里，且他们对外界新工具有开放心态，愿意给反馈。第一个周，我们的核心工作基本就是盯这三个人用产品，观察他们从哪一步卡住，在哪一句话上犹豫了，哪一个功能点完全没被发现。问题收集够了，就当场改版，改完再让他们体验。这个过程看着“规模小”，实际上是最快的优化方式。三个人的深度反馈，比三百个人的沉默点击有价值得多。4.2 灰度设计的三个关键配置第二批放开之前，我们花了点时间把灰度机制搭好，有三个配置很关键。一是功能开关和权限白名单。确保只有被选中的用户能看到智能体入口，其余人打开页面一切照旧。这样做的好处是，即使出现了比较严重的体验问题，影响范围也能被控制住。二是完整链路日志和埋点。从用户进入入口、输入问题、等待响应、点击采纳到最终提交反馈，每一步都要有记录。日志的粒度越细，后面复盘问题就越容易。三是“人工兜底”的交替方案。每一条AI生成的结果背后，都要有明确的人工接管路径，保证AI模型抽风时用户不会被晾在那里。这项配置在灰度期尤其不能省。有一次我们在灰度时发现某个渠道进来的一批问题命中率跌到了60%，就是因为及时切了人工兜底，业务方才没有产生大面积的负面情绪。后来才发现是那批问题的表述方式里包含大量行业黑话，RAG召回环节没接住。4.3 上线第一周盯住这四个数据第一周的数据要不要每天看？要。但看什么数据很讲究，四个数据是我们后来固定下来的。第一个是完整体验率，即有百分之多少的用户不是问一句就走，而是完成了从进入到拿到结果的全流程。一进来看到界面不知道怎么操作直接退出的，说明入门引导有问题。第二个是次日回头率。主动回访进入第二次、第三次的比例。这个数据很诚实，如果一次体验没让用户觉得“值得再来”，第二天基本不会有人回访。第三个是AI输出被采纳的比例。用户拿到结果之后是直接用了，还是删掉重来？这个决定着你这个智能体到底是不是真的好用。第四个是意图识别失败率，即有多少提问被模型明确判定为“不知道”或“不匹配”。你搜集到这些“漏网之鱼”，就能不断补充和维护RAG来源。4.4 建立“说出来不丢人”的反馈通道说实话，用户不愿意用，很多时候是因为“提了意见也没用”。所以我们在灰度期开通了一个非常轻的反馈通道——不算工单系统、不占绩效指标，只有一个简单的入口表单：“刚刚那个结果哪里不对，一句话说明就行”。刚开始的反馈大部分是抱怨，比如“这个答案跑偏了”“完全没有我要的内容”。但我们坚持每条都看、每条都回复，哪怕只是说“收到，下个版本会优化”。坚持了两周之后，反馈质量明显提高，用户开始愿意写几十字的问题描述了。这也是一个活水：你愿意听，用户才愿意说；用户愿意说，产品才有机会真正变好用。5. 上线后没人用：典型问题排查实录5.1 用户说“用不上”，其实是入口和场景的错位如果产品上线后用户反馈“用不上”，我通常不急着改功能，而是先去看埋点数据：他们到底是从哪一步开始流失的？有一回我们做内部报销政策问答智能体，功能上完全没问题，但消息弹窗入口藏在企业后台的第三个菜单里。很多人压根就没发现那个入口，一直以为这个智能体还没上线。把入口提到主页搜索框旁边之后，使用率翻了两倍。很多“没人用”的系统，本质上不是用户不愿意用，而是他们根本不知道“这个东西在哪里可以用”。另一个反直觉的点是：入口离用户的工作流越近越好。最好把智能体嵌入他们每天必用的那个页面，而不是做成一个独立的站点。5.2 用户说“不敢用”，幻觉问题怎么兜底“不敢用”比“用不上”要棘手得多，因为核心问题是信任。解决信任问题不能靠嘴上承诺“我们的模型准确率高”，要靠工程手段兜底。我推荐的做法是三层防线。第一层是在Prompt里做好边界约束，明确告诉模型“不要编造，没有依据就回复不知道”。第二层是在RAG链路里设置置信度阈值，检索证据的相关性评分不够高就直接拒绝回答，不让模型自己硬凑。第三层是在输出端加“参考来源”展示，用户点开能看到答案是从哪份文档里来的，心里就有底了。幻觉不可能到零，但通过这三层，可以把“一本正经胡说八道”的概率压到极低。用户只要有过几次“答案有据可查”的体验，信任感会慢慢回来。5.3 用户说“不划算”，算账方式错了有时候用户说“不划算”，真不一定是在否定产品价值，而是他们算错了账。比如前面提到的记账场景，用户说自己手动整理也就二十分钟，何必还要打开你那个系统。但从管理视角看，每周全体销售花在这事上的时间加起来是几十个小时。这个账，一线使用者没有感知，管理层可能也还没有量化。所以你需要做一件事：在正式推广时，别只讲“AI多聪明”，要给业务方算一笔“时间会计”——每个用户每周节约多少分钟，乘以人数、乘以周数，一年下来相当于增加了多少有效工时。把价值翻译成管理层关心的语言，项目才能站得住脚。5.4 团队自己先失去信心，怎么止损最让人觉得可惜的，其实是团队内部先失去信心，导致一款本来有机会做好的产品被仓促砍掉。我不止一次看到，AI智能体一上线，数据没起色，领导层就断言“这方向不行”，直接停掉整个项目。其实很多问题在两周之内可能就能修复，关键是要有一套“留观期”机制，在此期间集中火力修Main问题。我们的做法是：灰度数据出来后，给自己定一个最低兑现线——比如“第二周完整体验率达到30%且采纳率达到60%”。一周结束时拉数据，如果没达到，就认真复盘是场景选错了、模型能力不够，还是交互没做好。是交互问题就改产品，是场景问题就果断放弃。放弃不可怕，可怕的是用一次失败的数据直接宣判一个方向“没有可能性”，然后错过了本该有的迭代窗口。我在实际项目里摸索出来的体会是：AI智能体能不能被接受，从来不是模型参数单方面的能力问题，而是产品有没有长在用户行为和业务习惯上。技术再强，如果找错了场景、设计太重、没有信任兜底，数据难看是必然结果。最后再讲一个很多人容易忽略的操作细节：灰度期不要总盯着“有多少人访问”，而要多看“有多少人再次访问”。一个智能体的第一版体验完全可以不完美，但只要有足够的理由让用户愿意回来第二次、第三次，后面的打磨空间就会非常可观。反过来，哪怕首次体验流畅到让人惊叹，只要用户没有动力再打开，这个产品迟早还是会被遗忘。