项目下线四个月后，负责核心研发的那位同事完成了代码交接，临走前留下一份复盘文档。文档最后一句话我到现在还记得：我们不是把AI做失败了，而是把AI做成了一个需要用户迁就的工具。这句话几乎可以概括我们过去一整年走过的弯路。这份复盘针对的是一款智能助手类产品。立项的时候团队信心很足，大家觉得只要把模型做得足够大、功能堆得足够多，用户自然会留下来。但真实数据给了我们一记耳光：上线三个月，次留不到百分之八，绝大多数用户第一次打开后就不再回来。同事离职前的这次复盘，算是给项目做一个最后交代。我作为当时的技术负责人，把其中最有价值的内容整理出来，希望能给正在做类似AI产品的团队一些参考。1. 一次失败项目的复盘：产品越做越重，用户却越走越远1.1 立项时的乐观，和看不见的风险信号项目刚立项时，定位是"以多轮对话为入口，覆盖办公、学习、生活三大场景的通用智能助手"。当时大模型能力正热，大家默认认为：把模型接进来，把功能堆上去，体验自然就成了。负责核心算法的同事在方案评审会上说过一句话，我印象很深：我们要做的是一个什么都懂一点的AI，而不是只会干一件事的工具。现在回头看，这句话本身就是第一个风险信号。什么都懂一点，意味着什么场景都可能做不深。但我们当时没有正视这个问题，而是把大部分资源都投入到了"能力扩张"上。第一个版本规划了七个功能模块：对话问答、文档总结、邮件撰写、翻译润色、情感陪伴、角色扮演、代码辅助。入口是首页上方一排功能卡片，每个卡片点进去又是一个独立对话框，功能之间几乎没有联动。用户想问"帮我安排下周的产品评审会"，先得思考该点哪个卡片，然后手动填写时间、地点、参会人这些结构化信息，AI才能勉强理解。这个体验说实话很不顺滑。上线第一个月的数据立刻给了我们警示：新增用户虽然不少，但次周留存掉到百分之七左右。后台看用户路径，绝大多数人在点击第一个功能卡片、看到一段空洞的引导语之后就关闭了页面。我们那时候还在自我安慰，说用户还不习惯新产品，等我们把功能做得更完善就会好。1.2 从"用户教AI"到"AI替用户思考"我们当时的应对策略是继续加功能，试图用更多花活把用户留住。第二个月上了语音输入、截图问答、多语言互译，第三个月又上了日程提醒、订阅源聚合。版本迭代非常热闹，但每次发版之后，留存曲线都没有实质变化。真正的问题在于，我们一直没有处理好"AI替用户思考"这件事。正常用户不想面对一个空白对话框，也不愿意自己把需求拆解成一步步指令。用户真正希望的是：说一句话，AI能理解这句话背后的场景，并主动补全细节。比如"帮我跟老张约一下下周二下午的会"，理想中的AI应该自动查询日程、生成邀请文字、预设备选时间，而不是反问一句"请问您想约在几点"。这背后需要的不是更大的模型，而是一整套场景逻辑：意图识别、槽位提取、动作编排、外部工具调用。这些能力我们是在被用户反复吐槽之后才开始补的。而在此之前，我们的全部技术精力都花在了模型选型和微调上，产品上的问题被完全忽略了。1.3 我们踩中的第一个死结：不知道到底在服务谁复盘时把用户反馈重新过了一遍，发现我们犯的最根本错误是"没有锚定核心用户"。我们嘴上说着服务所有人，但每个功能都是拍脑袋设计出来的，没有一个人物画像，也没有一个典型使用场景。功能列表看着丰富，真实用户根本不知道该拿这个产品干什么。办公用户想靠它写材料，却发现生成内容太通用了；学习用户想让它做知识整理，却发现专业领域回答质量一般；生活用户进来聊了几天，发现就是个大号聊天机器人，没有持续使用价值。结果就是每个群体都只试了一下就走了。这件事给我们的教训是：通用AI助手最怕"泛而不深"。与其做十个60分的功能，不如把一个场景做成90分，让用户一想到某个任务就打开你的产品。方向没有收敛之前，一切资源投入都是浪费。2. 弯路的三根支柱：需求、评测与技术选型2.1 "新鲜感"被当成了"需求"复盘文档里，我们把项目弯路归纳成三根支柱：需求判断、评测体系、技术选型。第一根就是需求判断。当时团队判断需求的方法非常简单粗暴：开脑暴会，谁说的功能听起来有意思就排期做。"有趣的AI""能聊天的AI"这些概念很容易让人兴奋，但"有趣"不等于"有用"，更不等于"用户愿意天天用"。举个例子，我们做过一个"角色扮演"功能，用户可以跟AI扮演的历史人物或虚拟角色对话。上线第一周数据确实好看，对话时长很长，用户玩得不亦乐乎。但两周之后这个功能基本没人再碰。回头看，这只是一个新鲜感驱动的功能，它没有解决任何实际问题，用户也不会为此养成使用习惯。真正的需求应该从用户的真实任务出发。所谓的"任务"必须满足几个条件：用户会反复遇到；用户希望更快解决；AI确实能比传统工具做得更好。我们当时筛选功能时几乎没有用这些标准去卡，只凭直觉和榜单热度决定方向，最后搭起来的功能矩阵看着漂亮，核心价值却无比模糊。2.2 没有评测体系，所有优化都是自我感动第二根支柱，是评测体系的缺失。这个问题在项目中期表现得尤为明显，也直接导致团队内部开始失控。产品上线后，算法团队每次发版前，都是拉几个同学人工看几十条case，凭感觉打一个"还凑合"或者"比之前差了点"。不同的人对同一个回答的评价可能完全相反。于是团队里出现了一个很典型的场面：模型A说好，模型B说不好，两边都能拿出几条截图证明自己，谁也说服不了谁。没有客观评测体系，优化就变成闭眼开车。你可能花了三周微调模型，实际效果却比之前的版本更差，但因为没有量化指标，谁都不愿承认。更糟糕的是，没有评测集就意味着没有方向，大家今天修一个问题，明天又修另一个问题，修来修去，整体能力没有提升。我们后来才补上这套东西：建立指令测试集，覆盖核心场景；定义可量化的指标，如任务完成率、幻觉率、单轮回答质量分；每次发版做A/B对照。这个动作确实晚了一点，但依然对项目后半段起了很大作用。没有这套东西之前，所有的优化都只是自我感动。2.3 技术选型：选择了最热闹的路，而不是最省力的路第三根支柱是技术选型。我们踩了一个很多人都会踩的坑：哪个方向最热、最前沿，就往哪个方向走，而不是先想清楚自己的真实技术约束。项目初期，我们花了不少资源引入了一批大模型微调经验，还规划了分布式训练集群。但实际上，我们的用户量级根本不需要大规模分布式训练。真正的瓶颈不在模型参数，而在产品逻辑和响应效率。当时我们并没有认真评估过"用一个小模型加检索增强，能否先满足大部分需求"，而是默认认为"大模型微调才是最新方向，不做就是落后"。结果模型规模堆上去了，单次推理成本涨了，响应延迟上去了，可用户感知到的"智能程度"并没有显著提升。很多低频问题依旧答不准，高频问题也没快到让人愿意持续使用。这是一个典型的"用战术上的勤奋掩盖战略上的懒惰"的案例。技术选型不是选最先进的，而是选最匹配当前场景和资源约束的。对自己真实需求的判断不清晰，技术方向越激进，团队就越累。3. 转向"新路"的三个具体动作3.1 重新定义核心任务，先砍掉一半功能复盘之后，我们做的第一个动作是收敛。把所有功能按"用户任务频率"和"AI完成质量"两个维度重排，砍掉了角色扮演、风格转换、代码辅助等一多半功能，聚焦到"办公场景中的资料处理与写作辅助"这一个主方向。收敛让我们很痛苦，但效果立刻显现。团队不再被十几个功能分散精力，可以集中打磨一条主链路的体验。我们从用户真实任务出发重新设计了流程："发一段会议纪要，AI自动整理成待办事项，并生成提醒邮件草稿"。这件事虽小，但用户每天都会遇到，而且AI确实能帮上忙。为了让这个流程顺畅，我们做了三件事：把意图识别前置，让用户的那句话直接落到"会议纪要转待办"这个动作上；把对话流程改成固定向导，减少交互轮次；把生成结果做成可编辑模板，让用户修改成本降到最低。三个改动都不需要太多模型能力，但用户体验提升非常明显。这里面有个很重要的认知转变：AI产品的价值不是"对话更智能"，而是"任务更简单"。当用户不需要思考该怎么向AI提需求，产品才算真正入门。3.2 用"任务完成率"当北极星指标，重建评测体系第二个动作是重建评测体系，这也是我建议所有AI团队最早做的一件事。我们定义了一个北极星指标：任务完成率。所谓任务完成率，就是用户带着明确任务过来，在多轮交互之后，任务是否被成功解决。为了让指标可度量，我们把核心场景拆成了二三十个标准用例，每个用例都写好输入文本和预期产出。每次模型或产品更新，用这批用例回归一遍，打一个完成率。任务完成率之外，还配了三个辅助指标：幻觉率（AI编造内容的频率）、平均交互轮数（用户完成任务要对话几次）、响应延迟P95分位数（95%请求的响应时间）。四个指标一起看，基本能还原一个版本的真实好坏。这套体系建立之后，团队内部吵架明显少了。评审会不再是拿截图互相battle，而是对着回归数据说话。哪项指标掉了，就去查是哪次改动引起的；任务完成率提升，也能量化成具体收益。我们项目后半段做的几次关键优化，本质上都是在这套评测体系的指引下完成的。3.3 一次典型优化案例：知识问答延迟从3秒降到0.8秒评测体系跑通后，我们改的第一个硬骨头是知识问答的延迟。当时P95延迟接近3秒，用户明显觉得慢。我们把链路拆开分析，发现时间主要花在四段：意图识别、向量检索、生成模型首字返回、以及后处理。优化动作很简单，但效果非常明显。第一步，把意图识别模型从云端大模型换成本地小模型。这个任务本身比较简单，不需要大模型能力，小模型不仅速度快，成本还低了一截。第二步，调整知识库检索的召回逻辑。之前做向量检索时，召回文档数量设得很大，相关和不相关的内容都塞进Prompt里，既增加延迟又稀释注意力。我们把召回数量从十五段降到五段，同时加了一个轻量级重排步骤，只把最相关的内容交给生成模型。第三步，对高频问题做结果缓存。办公资料整理类的问题，很多用户的问法相似，我们就做了一个Embedding相似度缓存层，命中缓存就直接返回结果，完全不走生成链路。第四步，把整个链路从同步改成流式输出，用户在第一句话到达时就有反馈，感知延迟大幅下降。最终P95延迟降到0.8秒，任务完成率还提升了一截。因为Prompt更精简、干扰信息更少，生成质量自然变好。这轮优化没有用任何先进框架，纯粹是把现有链路做细致打磨。4. 复盘之后，我认为AI产品真正值得走的三条路4.1 端侧小模型加云端大模型的混合调度复盘之后，我对技术路线的一个核心判断是：不要把所有智能都塞进一个模型。更实际的做法，是让不同层级的模型各司其职。端侧小模型负责那些模式固定、响应速度要求高的子任务，比如意图识别、简单文本分类、固定格式的改写。云端大模型负责复杂推理、长文本生成、多工具编排这类高价值任务。两者之间用一个调度器根据任务复杂度动态路由。这样做的好处非常直接：大部分请求被小模型消化，平均响应更快，成本更低；大模型只处理真正需要它的请求，也能保证回答质量。对很多中小团队来说，租用云服务再配一个分布式训练集群，远不如这种"大小模型混合"的架构来得划算。我甚至认为，未来的AI应用会越来越像传统的互联网架构：前端轻量、后台厚重，中间加一层智能调度。模型不应该是唯一的主角，系统设计才是。4.2 让AI"知道自己不知道"这次复盘里让我最扎心的用户反馈是：AI一本正经地编答案。用户问一个法律条款，AI没查到，却编了一个看似合理的规定，读者如果不核对，很容易被误导。幻觉治理不能只靠"在Prompt里写请勿编造"，这句话的作用非常有限。我们最后用的组合拳是：限制知识来源。回答必须基于检索到的资料，做引用溯源；不确定时不硬答，直接说"这个内容我没有找到依据建议您核实"；对高置信度场景做答案校验，如果模型给出的关键数字或名称与资料不一致，就拒绝回答。工程上实现这些并不复杂，核心是给模型一个"可以拒绝回答"的权限。很多产品不敢让AI说不知道，怕用户觉得不聪明。但实际看，用户对一个说"我不知道"的AI的信任度，远远高于一个编造答案的AI。让AI承认自己不完美，反而更接近一个可信的助手。4.3 评测驱动的持续迭代，而不是模型驱动最后一条路，是把评测体系当成产品长期竞争力的基础设施。很多团队把AI产品的壁垒理解为"我有别人没有的模型"，但模型能力会快速追平，真正能拉开差距的，是你是否比对手更了解用户的真实任务，并且能持续快速改进。我们最后的体会是：建立一套高质量评测集，并让评测集随着产品演进不断扩充，这件事需要长期坚持。每周固定回归一次新版本，每月人工校正一轮评测集，确保用例不跟真实需求脱节。评测驱动迭代看似笨重，实际上是效率最高的方式，它让每一次技术投入都能精准落在用户体验上。5. 写给你的实操清单：立项前回答五个问题，复盘时写什么5.1 立项前必须回答的五个问题这段内容可能对正在立项的团队更有用。经历过这次失败后，我现在带新项目，立项前一定会要求当场回答五个问题：第一，我们的产品为谁解决什么问题，这个用户群体是否足够大、足够具体？第二，这个需求今天有没有替代方案，用户为什么需要换到我们这里？第三，完成这个任务，AI真的比传统工具更有优势吗？第四，衡量任务成功的指标是什么，怎么量化？第五，如果我们只有一个月的资源，先做哪一个功能？这五个问题看着很基础，但绝大多数AI项目失败，正是因为在没有想清楚答案的情况下就开工了。如果五个问题答不利索，先不要写代码。5.2 每周一次的评测评审会怎么开评测体系建立之后，我们固定每周开一次约30分钟的评测评审会。会议流程可以抄作业：第一步，回归上一周的核心用例，查看四个关键指标变化。第二步，逐个讨论指标明显波动或异常用例的原因，定位到具体模块。第三步，从新增用户反馈中挑出高价值case，决定是否纳入评测集。第四步，排定下一周的优化优先级，最多选三件事。这个会议有几个必须坚持的规则：只看数据不看感觉；任何人提出"感觉变差了"都必须附上具体case；每次迭代必须有可衡量的目标。坚持一个月，团队的执行力会有质的变化。5.3 复盘文档应该写什么如果你也在为项目做复盘，我建议文档里至少要包含四块内容：事实回顾，描述项目发生了什么，完整时间线加关键数据；根因分析，把问题和失败的原因解剖到可行动层面，而不是停留在"我们没有做好评测"这种泛泛概括；认知收获，记录团队对用户需求、技术路线、组织协作的认知转变；行动清单，写出后续可执行的具体动作，哪怕项目已经停了，经验本身也能延续价值。真正的复盘不是追责，而是把踩过的坑变成可复用的判断力。最后分享一点个人体会这次项目失败之后，我对AI产品研发的敬畏感多了很多。过去总觉得，工具越强大越能做出好产品，现在更倾向于认为，产品做得不好，往往是基本的用户洞察和工程习惯出了问题。AI只是放大了团队的判断力，你判断错了，它只会更快更确定地把你带偏。如果你正打算做类似的AI产品，我的建议很简单：一开始就把评测体系搭起来，把核心场景收敛到足够窄，然后让每一次迭代都能被用户感知到。做到这三点，哪怕模型不是最前沿的，产品也大概率能活下去。
项目下线四个月后，负责核心研发的那位同事完成了代码交接，临走前留下一份复盘文档。文档最后一句话我到现在还记得：我们不是把AI做失败了，而是把AI做成了一个需要用户迁就的工具。这句话几乎可以概括我们过去一整年走过的弯路。这份复盘针对的是一款智能助手类产品。立项的时候团队信心很足，大家觉得只要把模型做得足够大、功能堆得足够多，用户自然会留下来。但真实数据给了我们一记耳光：上线三个月，次留不到百分之八，绝大多数用户第一次打开后就不再回来。同事离职前的这次复盘，算是给项目做一个最后交代。我作为当时的技术负责人，把其中最有价值的内容整理出来，希望能给正在做类似AI产品的团队一些参考。1. 一次失败项目的复盘：产品越做越重，用户却越走越远1.1 立项时的乐观，和看不见的风险信号项目刚立项时，定位是"以多轮对话为入口，覆盖办公、学习、生活三大场景的通用智能助手"。当时大模型能力正热，大家默认认为：把模型接进来，把功能堆上去，体验自然就成了。负责核心算法的同事在方案评审会上说过一句话，我印象很深：我们要做的是一个什么都懂一点的AI，而不是只会干一件事的工具。现在回头看，这句话本身就是第一个风险信号。什么都懂一点，意味着什么场景都可能做不深。但我们当时没有正视这个问题，而是把大部分资源都投入到了"能力扩张"上。第一个版本规划了七个功能模块：对话问答、文档总结、邮件撰写、翻译润色、情感陪伴、角色扮演、代码辅助。入口是首页上方一排功能卡片，每个卡片点进去又是一个独立对话框，功能之间几乎没有联动。用户想问"帮我安排下周的产品评审会"，先得思考该点哪个卡片，然后手动填写时间、地点、参会人这些结构化信息，AI才能勉强理解。这个体验说实话很不顺滑。上线第一个月的数据立刻给了我们警示：新增用户虽然不少，但次周留存掉到百分之七左右。后台看用户路径，绝大多数人在点击第一个功能卡片、看到一段空洞的引导语之后就关闭了页面。我们那时候还在自我安慰，说用户还不习惯新产品，等我们把功能做得更完善就会好。1.2 从"用户教AI"到"AI替用户思考"我们当时的应对策略是继续加功能，试图用更多花活把用户留住。第二个月上了语音输入、截图问答、多语言互译，第三个月又上了日程提醒、订阅源聚合。版本迭代非常热闹，但每次发版之后，留存曲线都没有实质变化。真正的问题在于，我们一直没有处理好"AI替用户思考"这件事。正常用户不想面对一个空白对话框，也不愿意自己把需求拆解成一步步指令。用户真正希望的是：说一句话，AI能理解这句话背后的场景，并主动补全细节。比如"帮我跟老张约一下下周二下午的会"，理想中的AI应该自动查询日程、生成邀请文字、预设备选时间，而不是反问一句"请问您想约在几点"。这背后需要的不是更大的模型，而是一整套场景逻辑：意图识别、槽位提取、动作编排、外部工具调用。这些能力我们是在被用户反复吐槽之后才开始补的。而在此之前，我们的全部技术精力都花在了模型选型和微调上，产品上的问题被完全忽略了。1.3 我们踩中的第一个死结：不知道到底在服务谁复盘时把用户反馈重新过了一遍，发现我们犯的最根本错误是"没有锚定核心用户"。我们嘴上说着服务所有人，但每个功能都是拍脑袋设计出来的，没有一个人物画像，也没有一个典型使用场景。功能列表看着丰富，真实用户根本不知道该拿这个产品干什么。办公用户想靠它写材料，却发现生成内容太通用了；学习用户想让它做知识整理，却发现专业领域回答质量一般；生活用户进来聊了几天，发现就是个大号聊天机器人，没有持续使用价值。结果就是每个群体都只试了一下就走了。这件事给我们的教训是：通用AI助手最怕"泛而不深"。与其做十个60分的功能，不如把一个场景做成90分，让用户一想到某个任务就打开你的产品。方向没有收敛之前，一切资源投入都是浪费。2. 弯路的三根支柱：需求、评测与技术选型2.1 "新鲜感"被当成了"需求"复盘文档里，我们把项目弯路归纳成三根支柱：需求判断、评测体系、技术选型。第一根就是需求判断。当时团队判断需求的方法非常简单粗暴：开脑暴会，谁说的功能听起来有意思就排期做。"有趣的AI""能聊天的AI"这些概念很容易让人兴奋，但"有趣"不等于"有用"，更不等于"用户愿意天天用"。举个例子，我们做过一个"角色扮演"功能，用户可以跟AI扮演的历史人物或虚拟角色对话。上线第一周数据确实好看，对话时长很长，用户玩得不亦乐乎。但两周之后这个功能基本没人再碰。回头看，这只是一个新鲜感驱动的功能，它没有解决任何实际问题，用户也不会为此养成使用习惯。真正的需求应该从用户的真实任务出发。所谓的"任务"必须满足几个条件：用户会反复遇到；用户希望更快解决；AI确实能比传统工具做得更好。我们当时筛选功能时几乎没有用这些标准去卡，只凭直觉和榜单热度决定方向，最后搭起来的功能矩阵看着漂亮，核心价值却无比模糊。2.2 没有评测体系，所有优化都是自我感动第二根支柱，是评测体系的缺失。这个问题在项目中期表现得尤为明显，也直接导致团队内部开始失控。产品上线后，算法团队每次发版前，都是拉几个同学人工看几十条case，凭感觉打一个"还凑合"或者"比之前差了点"。不同的人对同一个回答的评价可能完全相反。于是团队里出现了一个很典型的场面：模型A说好，模型B说不好，两边都能拿出几条截图证明自己，谁也说服不了谁。没有客观评测体系，优化就变成闭眼开车。你可能花了三周微调模型，实际效果却比之前的版本更差，但因为没有量化指标，谁都不愿承认。更糟糕的是，没有评测集就意味着没有方向，大家今天修一个问题，明天又修另一个问题，修来修去，整体能力没有提升。我们后来才补上这套东西：建立指令测试集，覆盖核心场景；定义可量化的指标，如任务完成率、幻觉率、单轮回答质量分；每次发版做A/B对照。这个动作确实晚了一点，但依然对项目后半段起了很大作用。没有这套东西之前，所有的优化都只是自我感动。2.3 技术选型：选择了最热闹的路，而不是最省力的路第三根支柱是技术选型。我们踩了一个很多人都会踩的坑：哪个方向最热、最前沿，就往哪个方向走，而不是先想清楚自己的真实技术约束。项目初期，我们花了不少资源引入了一批大模型微调经验，还规划了分布式训练集群。但实际上，我们的用户量级根本不需要大规模分布式训练。真正的瓶颈不在模型参数，而在产品逻辑和响应效率。当时我们并没有认真评估过"用一个小模型加检索增强，能否先满足大部分需求"，而是默认认为"大模型微调才是最新方向，不做就是落后"。结果模型规模堆上去了，单次推理成本涨了，响应延迟上去了，可用户感知到的"智能程度"并没有显著提升。很多低频问题依旧答不准，高频问题也没快到让人愿意持续使用。这是一个典型的"用战术上的勤奋掩盖战略上的懒惰"的案例。技术选型不是选最先进的，而是选最匹配当前场景和资源约束的。对自己真实需求的判断不清晰，技术方向越激进，团队就越累。3. 转向"新路"的三个具体动作3.1 重新定义核心任务，先砍掉一半功能复盘之后，我们做的第一个动作是收敛。把所有功能按"用户任务频率"和"AI完成质量"两个维度重排，砍掉了角色扮演、风格转换、代码辅助等一多半功能，聚焦到"办公场景中的资料处理与写作辅助"这一个主方向。收敛让我们很痛苦，但效果立刻显现。团队不再被十几个功能分散精力，可以集中打磨一条主链路的体验。我们从用户真实任务出发重新设计了流程："发一段会议纪要，AI自动整理成待办事项，并生成提醒邮件草稿"。这件事虽小，但用户每天都会遇到，而且AI确实能帮上忙。为了让这个流程顺畅，我们做了三件事：把意图识别前置，让用户的那句话直接落到"会议纪要转待办"这个动作上；把对话流程改成固定向导，减少交互轮次；把生成结果做成可编辑模板，让用户修改成本降到最低。三个改动都不需要太多模型能力，但用户体验提升非常明显。这里面有个很重要的认知转变：AI产品的价值不是"对话更智能"，而是"任务更简单"。当用户不需要思考该怎么向AI提需求，产品才算真正入门。3.2 用"任务完成率"当北极星指标，重建评测体系第二个动作是重建评测体系，这也是我建议所有AI团队最早做的一件事。我们定义了一个北极星指标：任务完成率。所谓任务完成率，就是用户带着明确任务过来，在多轮交互之后，任务是否被成功解决。为了让指标可度量，我们把核心场景拆成了二三十个标准用例，每个用例都写好输入文本和预期产出。每次模型或产品更新，用这批用例回归一遍，打一个完成率。任务完成率之外，还配了三个辅助指标：幻觉率（AI编造内容的频率）、平均交互轮数（用户完成任务要对话几次）、响应延迟P95分位数（95%请求的响应时间）。四个指标一起看，基本能还原一个版本的真实好坏。这套体系建立之后，团队内部吵架明显少了。评审会不再是拿截图互相battle，而是对着回归数据说话。哪项指标掉了，就去查是哪次改动引起的；任务完成率提升，也能量化成具体收益。我们项目后半段做的几次关键优化，本质上都是在这套评测体系的指引下完成的。3.3 一次典型优化案例：知识问答延迟从3秒降到0.8秒评测体系跑通后，我们改的第一个硬骨头是知识问答的延迟。当时P95延迟接近3秒，用户明显觉得慢。我们把链路拆开分析，发现时间主要花在四段：意图识别、向量检索、生成模型首字返回、以及后处理。优化动作很简单，但效果非常明显。第一步，把意图识别模型从云端大模型换成本地小模型。这个任务本身比较简单，不需要大模型能力，小模型不仅速度快，成本还低了一截。第二步，调整知识库检索的召回逻辑。之前做向量检索时，召回文档数量设得很大，相关和不相关的内容都塞进Prompt里，既增加延迟又稀释注意力。我们把召回数量从十五段降到五段，同时加了一个轻量级重排步骤，只把最相关的内容交给生成模型。第三步，对高频问题做结果缓存。办公资料整理类的问题，很多用户的问法相似，我们就做了一个Embedding相似度缓存层，命中缓存就直接返回结果，完全不走生成链路。第四步，把整个链路从同步改成流式输出，用户在第一句话到达时就有反馈，感知延迟大幅下降。最终P95延迟降到0.8秒，任务完成率还提升了一截。因为Prompt更精简、干扰信息更少，生成质量自然变好。这轮优化没有用任何先进框架，纯粹是把现有链路做细致打磨。4. 复盘之后，我认为AI产品真正值得走的三条路4.1 端侧小模型加云端大模型的混合调度复盘之后，我对技术路线的一个核心判断是：不要把所有智能都塞进一个模型。更实际的做法，是让不同层级的模型各司其职。端侧小模型负责那些模式固定、响应速度要求高的子任务，比如意图识别、简单文本分类、固定格式的改写。云端大模型负责复杂推理、长文本生成、多工具编排这类高价值任务。两者之间用一个调度器根据任务复杂度动态路由。这样做的好处非常直接：大部分请求被小模型消化，平均响应更快，成本更低；大模型只处理真正需要它的请求，也能保证回答质量。对很多中小团队来说，租用云服务再配一个分布式训练集群，远不如这种"大小模型混合"的架构来得划算。我甚至认为，未来的AI应用会越来越像传统的互联网架构：前端轻量、后台厚重，中间加一层智能调度。模型不应该是唯一的主角，系统设计才是。4.2 让AI"知道自己不知道"这次复盘里让我最扎心的用户反馈是：AI一本正经地编答案。用户问一个法律条款，AI没查到，却编了一个看似合理的规定，读者如果不核对，很容易被误导。幻觉治理不能只靠"在Prompt里写请勿编造"，这句话的作用非常有限。我们最后用的组合拳是：限制知识来源。回答必须基于检索到的资料，做引用溯源；不确定时不硬答，直接说"这个内容我没有找到依据建议您核实"；对高置信度场景做答案校验，如果模型给出的关键数字或名称与资料不一致，就拒绝回答。工程上实现这些并不复杂，核心是给模型一个"可以拒绝回答"的权限。很多产品不敢让AI说不知道，怕用户觉得不聪明。但实际看，用户对一个说"我不知道"的AI的信任度，远远高于一个编造答案的AI。让AI承认自己不完美，反而更接近一个可信的助手。4.3 评测驱动的持续迭代，而不是模型驱动最后一条路，是把评测体系当成产品长期竞争力的基础设施。很多团队把AI产品的壁垒理解为"我有别人没有的模型"，但模型能力会快速追平，真正能拉开差距的，是你是否比对手更了解用户的真实任务，并且能持续快速改进。我们最后的体会是：建立一套高质量评测集，并让评测集随着产品演进不断扩充，这件事需要长期坚持。每周固定回归一次新版本，每月人工校正一轮评测集，确保用例不跟真实需求脱节。评测驱动迭代看似笨重，实际上是效率最高的方式，它让每一次技术投入都能精准落在用户体验上。5. 写给你的实操清单：立项前回答五个问题，复盘时写什么5.1 立项前必须回答的五个问题这段内容可能对正在立项的团队更有用。经历过这次失败后，我现在带新项目，立项前一定会要求当场回答五个问题：第一，我们的产品为谁解决什么问题，这个用户群体是否足够大、足够具体？第二，这个需求今天有没有替代方案，用户为什么需要换到我们这里？第三，完成这个任务，AI真的比传统工具更有优势吗？第四，衡量任务成功的指标是什么，怎么量化？第五，如果我们只有一个月的资源，先做哪一个功能？这五个问题看着很基础，但绝大多数AI项目失败，正是因为在没有想清楚答案的情况下就开工了。如果五个问题答不利索，先不要写代码。5.2 每周一次的评测评审会怎么开评测体系建立之后，我们固定每周开一次约30分钟的评测评审会。会议流程可以抄作业：第一步，回归上一周的核心用例，查看四个关键指标变化。第二步，逐个讨论指标明显波动或异常用例的原因，定位到具体模块。第三步，从新增用户反馈中挑出高价值case，决定是否纳入评测集。第四步，排定下一周的优化优先级，最多选三件事。这个会议有几个必须坚持的规则：只看数据不看感觉；任何人提出"感觉变差了"都必须附上具体case；每次迭代必须有可衡量的目标。坚持一个月，团队的执行力会有质的变化。5.3 复盘文档应该写什么如果你也在为项目做复盘，我建议文档里至少要包含四块内容：事实回顾，描述项目发生了什么，完整时间线加关键数据；根因分析，把问题和失败的原因解剖到可行动层面，而不是停留在"我们没有做好评测"这种泛泛概括；认知收获，记录团队对用户需求、技术路线、组织协作的认知转变；行动清单，写出后续可执行的具体动作，哪怕项目已经停了，经验本身也能延续价值。真正的复盘不是追责，而是把踩过的坑变成可复用的判断力。最后分享一点个人体会这次项目失败之后，我对AI产品研发的敬畏感多了很多。过去总觉得，工具越强大越能做出好产品，现在更倾向于认为，产品做得不好，往往是基本的用户洞察和工程习惯出了问题。AI只是放大了团队的判断力，你判断错了，它只会更快更确定地把你带偏。如果你正打算做类似的AI产品，我的建议很简单：一开始就把评测体系搭起来，把核心场景收敛到足够窄，然后让每一次迭代都能被用户感知到。做到这三点，哪怕模型不是最前沿的，产品也大概率能活下去。