别给你的产品硬塞一个聊天框：AI功能落地实战指南

大多数送到工程师手里的AI需求，并不是要做一个全新的AI产品。它是一个已经有付费用户、积累了好几年数据库结构的成熟产品，而老板被告知要在竞争对手之前"加上AI"。推动力有时来自董事会，有时来自销售团队，有时来自续约电话里某个客户的随口一句。

第一版方案几乎千篇一律：在右下角放一个聊天助手，让用户跟产品对话。演示效果惊艳。然后几周内使用率断崖式下跌——因为用户打开这个产品不是为了聊天，他们是为了完成一件工作。

作为工程师，我觉得有意思的地方在于：模型是整个事情里最简单的一环。真正的工作量在它周围那些无聊的层：哪些数据进入、以谁的权限运行、输出落在屏幕的什么位置、模型出错或宕机时会发生什么。

从任务出发，而不是从模型出发

"我们能在哪里用上AI？"是一个错误的问题。有用的问题是：用户在这个产品里反复做、又慢又烦琐或容易出错的，是哪个任务？

那些持续有效的候选场景有一个共同形状：

• 总结某个冗长的东西：用户在行动之前必须读完的讨论串、记录历史或录音。
• 从混乱信息中填充结构化字段：把上传的文件、邮件或笔记映射到你已有的表单里。
• 起草初版回复或报告，由人来编辑和审批。
• 分类和路由：把新进来的条目分到正确的队列或类别。
• 找到那个东西：理解意图的搜索，而不只是关键词匹配。

上述每一项都对应一个你今天就能测量的现有工作流。这给了你一个基线，而基线是你判断这个功能是否真的起了作用的唯一方式。

作者自己的应用 LectureNotes AI 是个干净的案例，尽管它从第一天就有AI。没有人录课是为了跟模型聊天，他们想要的是能拿来复习的笔记。转录文本、要点提炼和结构化大纲都服务于这一个任务，其中没有任何一个是聊天窗口。

为什么要有评估集。 AI功能的输出是概率性的，同一个prompt在不同模型、不同版本下结果会漂移，而且供应商会悄悄更新背后的模型。没有固定的评估集，团队就无法判断某次改动是真正的改进还是退步，也无法在模型行为变化时及时发现。做法是从自己产品里挑30到50个真实输入，为每一个预先写出"什么才算好输出"的判定标准，形成可重复运行的基准。它同时也是回归测试，让"换更便宜的模型"这类决策变成一次配置修改加一次评估运行，而不必提心吊胆地重写。

没人放进估算里的数据工作

成熟产品被设计来把数据展示给人看，而不是交给模型。这个落差就是大部分开发时间消耗的地方。

组装上下文是普通工程，而且是工作量的主体。 对于"总结这个客户的历史"这个需求，得有人来决定哪些记录算历史、回溯多久、哪些字段重要、哪些该排除。在一个已经运行了几年的产品里，这些数据散落在多张表、几个服务和至少一个第三方工具里。检索质量对答案质量的决定性远超模型选择。

AI功能必须遵守你已有的权限体系。 这是要重点划线的一条。如果一个用户打不开某条记录，助手就不能总结它、引用它，也不能让它泄漏到搜索答案里。诱人的捷径是给AI功能一个拥有广泛读权限的独立服务账号，因为这样建起来更快。不要这么做。要以请求用户的身份、通过产品其余部分使用的同一权限层来获取上下文。

代码示例展示了这个"同一权限层、安静失败"的形态：AI面板复用产品自己的访问层，绝不阻塞它所在的页面。里面有两个关键点。第一，不存在通往数据库的特权路径，所以AI功能里的权限bug在结构上就不可能发生，而不是靠代码审查来防止。第二，慢或失败的供应商返回 null 而不是卡住屏幕。产品在这个功能存在之前就能用，当这个功能不可用时它应该继续能用。

清楚数据被允许流向哪里。 如果你的客户签了数据处理条款的合同，把他们的记录发给模型供应商可能被覆盖，也可能不被覆盖。在建之前就要搞清楚。如果没被覆盖，有可行的方案：零留存供应商条款、特定处理区域、自托管模型，或者在调用前剥离敏感字段。

什么是"以请求用户的身份运行"。 很多AI功能在设计时会把模型调用放在一个独立的后端服务里，这个服务为了图省事，往往用一个拥有宽泛读权限的服务账号去访问数据库。这在演示阶段看不出问题，但它制造了一条绕过产品权限体系的"特权路径"：任何能触达该接口的请求，都可能读到本不该被该用户看到的记录。正确做法是把"当前请求用户"的身份和权限上下文一路透传到数据访问层，让AI功能复用产品其余部分早已实现的那套鉴权与过滤逻辑。这样权限收敛就有了结构性保证，而不是依赖每次代码审查去发现遗漏。

零留存供应商条款与区域处理。 主流模型供应商除了默认的数据保留策略外，通常还提供企业级的"零留存"选项，承诺不存储也不用于训练客户的请求数据，代价往往是更高的单价或额外的合同流程。区域处理则要求推理发生在特定司法辖区（如欧盟境内），以满足数据本地化合规。自托管开源模型是另一条路径，把数据完全留在自己的基础设施内，但需承担推理成本与运维负担。选择哪条路径应在动工前依据客户合同条款确定，而不是上线后才发现不满足要求。

把它放在工作已经发生的地方

放置位置是决定还有人继续使用AI功能的单一最大因素。有效的模式是把输出放进用户已经在的那个屏幕里，在他们需要的那个时刻：

• 他们刚打开的记录顶部的摘要面板。
• 从上传文档预填的表单字段，在确认前视觉上标记为建议。
• 现有回复框旁边的"起草回复"按钮，而不是一个独立的工具。
• 在他们正要点的下拉框里已经选好的建议类别。

每个案例里，现有工作流保持完整，用户保持在控制之中。如果AI错了，他们用修正自己错误的方式修正它。如果AI对了，他们省了时间，没有学任何新东西。

一个通用聊天助手可以在之后赢得一席之地，一旦你知道人们实际会问什么问题。它几乎从不是正确的第一个功能。

为出错而设计

每个AI功能有时都会产出糟糕的输出，所以把这一点当作正常代码路径，而不是边缘情况。

• 建议就应该看起来像建议。 预填字段在人工确认前保持视觉上可区分。没有任何生成内容会静默地变成事实记录。
• 不可逆操作始终由人把关。 读取和建议是低风险的。发送、删除、付款或修改他人数据是另一个产品，有不同的规则。
• 给用户一键"这是错的"。 这几乎不花什么成本，却把每次失败变成一个有标注的样本。

成本随使用量增长，而非随席位

普通功能的成本大约相同，不管客户一个月用一次还是整天用。AI功能不是这样。每次总结和每次起草都是一次计费调用，你最重的用户可能比最轻的用户贵很多倍。

在上线前，按每个活跃用户每月现实使用量算一下数。如果数字难看，修复方案是架构层面的：在记录变化时生成一次摘要，而不是每次页面浏览都生成；只发送任务需要的上下文；把窄任务路由到更小的模型。

按用量计费与按席位计费的区别。 传统SaaS大多按席位收费，一个客户无论用得多还是用得少，边际成本几乎不变，所以定价和利润可以提前算清。AI功能打破了这个模型：每次总结、每次起草都是一次真实计费的模型调用，重度用户产生的成本可能是轻度用户的好几倍。这意味着毛利会随着使用强度而不是客户数量波动。应对思路通常是架构层面的：在记录变化时才生成一次摘要并缓存，而不是每次页面浏览都重新生成；只把任务真正需要的上下文发给模型，避免整表整库地塞；把窄任务（如分类、路由）路由到更小更便宜的模型，把大模型留给真正需要复杂推理的场景。

像发布任何有风险的功能一样发布它

1. 先建一个小型评估集。 从你自己产品里取30到50个真实例子，每个都写好什么叫好输出。每次改prompt或换模型都跑一遍，这样你能区分改进和退化。
2. 在功能开关后面发布：内部用户，然后几个友好客户，然后所有人。
3. 衡量任务，而不是点击。 任务耗时下降了吗？用户接受建议还是重写了？一个月后他们还在用吗？打开面板一次是好奇，不是采纳。
4. 上线后继续观察。 供应商会在你脚下更新模型，你的数据也会漂移。

把所有模型调用路由到一个内部接口、prompt放在配置里，也是值得的。这样尝试更便宜或更好的模型就是一次配置修改加一次评估运行，而不是重写。

我会先做什么

挑一个缓慢、重复的任务。用用户自己的权限获取干净的上下文喂给模型。把输出精确放在用户已经工作的地方，让它安静地失败，然后测量它是否粘住了。一个人们持续使用的功能胜过五个他们试过一次的。