有一段时间我帮朋友做模拟面试，问的都是同一个问题：这个功能明天上线，第一个一万用户来了，你打算怎么撑住。多数人从模型能力讲起，讲参数、讲榜单、讲它有多聪明。很少有人主动说成本，说延迟，说这个需求本身可能就不该做。
我后来越来越确信，AI 产品经理的分水岭不在懂不懂模型，而在有没有把约束当成设计的一部分。模型边界这个词听起来像技术考核，实际考的是一个人愿不愿意承认物理限制。
约束不是障碍，是设计的起点
上下文窗口是最容易被轻描淡写的东西。它的实际含义是输入和输出共享一块空间，不是一个可以无限扩容的容器。这意味着写提示词的时候得先留出回答的预算，而不是把能塞的都塞进去。
我见过太多方案死在提示词写得太满上：系统提示、几个示例、检索回来的五段材料全部堆进去，留给模型回答的位置所剩无几，输出在中途被截断，前面所有精心设计一起作废。奇怪的是这种问题在测试时不明显，因为测试用的输入总是短的。
多轮对话里那种聊到后面它忘了最初要求的情况，原因通常也在这里。窗口满了，最早的指令被裁掉，模型开始按最近几轮的语气自己发挥。这不是模型变笨，是设计的时候没有给它留位置。真正的解法在产品层：控制轮数、把关键约束重复注入、或者在合适的时候开一个新会话。
所以当有人问我五百页的 PDF 怎么总结，我不太相信扔给长上下文模型这个答案。长上下文的调用很贵，而且文档中段的信息最容易被忽略，这一点在实践中反复出现。分段总结再合并，或者先用检索定位到相关章节，是我更愿意选的路线。它更啰嗦，工程上更麻烦，链路更长也更容易出错，但它可控，出错时能定位到具体是哪一段。
延迟是第二件事。
传统 web 产品里两百毫秒的差别基本感知不到，大模型不一样。要区分首字延迟和整体生成时间：前者决定用户觉得它有没有在听，后者决定他愿不愿意等完。这两个指标对应的设计手段完全不同，前者靠流式输出和小模型，后者靠任务异步化和进度反馈。
实时语音这类场景，首字超过半秒就会显得迟钝，只能上小模型或者量化过的模型，接受它偶尔答得笨一点。反过来，离线生成周报、跑一份研报，等三十秒甚至几分钟都是合理的，这时候用大模型换质量才划算，界面只要把进度说清楚，用户是愿意等的。
两个场景共用一套选型，一定有一边是错的。我见过把离线任务的那套大模型搬到实时对话里的方案，评估会上没人反对，上线后用户的第一反应是“它是不是卡了”。
并发是最后一块，也是最容易被演示掩盖的。单人测试永远流畅，一千个人同时进来就是另一回事：排队、限流、供应商那边的速率上限，还有账单。我不太相信上线再说这种态度，因为扩容的钱和降级的体验，最后都要产品来背。
这一块真正要做的是提前想清楚降级顺序：缓存命中优先，其次小模型，再次排队，最后才是拒绝。顺序定下来，工程才知道该在哪儿加东西；顺序没定，压力一来就是随机崩溃。
幻觉不是 bug
我面试时最怕听到一句话：我们会通过微调来消除幻觉。这句话暴露的不是技术细节，而是对模型工作方式的理解。
模型的输出是概率采样，它在预测下一个 token，不是在查数据库。这个机制给了它泛化和创造力，也决定了它没法承诺百分百的事实准确。把它当成 bug 去修，方向就错了；把它当成一个需要被管理的特性，才有可能设计出能上线的东西。
判断标准是容错率，不是模型好坏。写营销文案、做头脑风暴，幻觉几乎等于灵感，我甚至会希望温度调高一点。医疗建议、金融合规这类场景，容错率接近零，就不能让模型自由发挥，得把它的生成限制在可信材料里，再叠一层人工复核。
拿捏这个度，靠的不是技术判断，是对业务后果的了解。同一条错误答案，出现在推荐语里是笑话，出现在理赔结论里是事故。所以我在设计功能时会先问：这个输出错了，最坏的结果是什么，谁来承担。
另一个被高估的是推理深度。让它梳理财报里的战略描述，它做得很好；让它根据现金流算一个内部收益率，它大概率会给出一个语气非常自信的错误数字。这不是模型不够强，是让一个语言模型去做算术。
我倾向的做法是换架构而不是换模型：把计算交给代码执行器或者专业工具，模型只负责判断该调用哪一个。它的角色从答题的人变成分诊的人。这个转变听起来不性感，但它是很多方案能不能落地的分界线。
同样的道理，有些事根本不该交给模型。日期格式校验、金额范围判断、必填项检查，这些用规则写出来是几行代码，确定、快、免费；交给模型反而引入了不确定性。拿着锤子找钉子是这个岗位最典型的失误，而它通常表现为一句“让模型自己判断就行”。
算不过账的方案我不提
有一类需求技术上完全可行，商业上必死：用最强的模型处理每一次高频调用。
月费九块九的工具，用户一天触发几十次推理，边际成本会迅速吞掉整个生命周期的收入。这不是模型贵，是选型没有分层。意图识别、文本分类这种事，小模型甚至规则就够；只有真正复杂的推理才值得路由到贵的那一档。
我比较认先大后小这条路：早期用强模型验证需求、攒数据，跑通之后再蒸馏或换成小模型。它的问题是需要时间，前期成本不好看，团队也会有人质疑为什么不一开始就优化。但它把不确定性放在了最便宜的那一段，这在我看来是值得的。
反过来，一味追求最强模型同样是一种浪费。如果任务只是从简历里抽姓名和电话，用千亿参数的模型不仅贵，还因为体积大而更慢。性能过剩和性能不足一样，都是选型失误。
用户的感受也不由榜单决定。没人会因为背后用了最强的模型而留下，但很多人会因为等了三秒而离开。首字延迟这种事，在评审会上排在最后，在真实使用里排在最前。
合规是另一条红线，而且往往是 B 端产品的生死线。把带个人身份信息的原始数据直接发到公有云 API，这件事我不做。更现实的做法是在送出之前先脱敏，把敏感字段换成占位符，回来再还原。麻烦，慢，日志难看，但数据不出域这件事没什么可商量的。
另一条路是私有化。把开源模型部署在自己的机器上，数据完全可控，代价是能力通常落后前沿一两个版本，而且运维、扩容、故障处理全落到自己头上。这不是纯技术选择，是在为确定性付钱：什么时候升级、什么时候不升级，由自己决定。
还有一项很少被提起的成本：模型版本会变。一个调了很久的提示词，可能在供应商升级之后突然不好用，语气变了，遵循指令的方式也变了。这类漂移没有告警，只能靠回归测试和监控慢慢发现。我把它算进维护成本，而不是当成意外。
与之配套的是评估。靠“读起来通顺”来判断优化有没有效，等于没有判断。我的做法是攒一小批固定的题目，每次改动都跑一遍，离线看命中率和引用是否正确，线上则盯采纳率、转人工率这类能反映真实结果的指标。这套东西搭起来很枯燥，但它是唯一能让讨论从感觉回到事实的办法。
兜底比能力清单更能说明水平
如果只能问一个问题，我会问：模型答不出来的时候，你的产品做什么。
答转人工是及格的，但不够。我更想看分层：置信度高的时候直接输出；中等的时候不硬答，改成澄清，或者给出几个可能的方向让用户选；低到某条线以下才切断，交给规则或者人。这套分层的价值在于，它把大量“差一点就对”的回答变成了一次有效的追问，而不是一次错误。
人机切换最容易出问题的地方是上下文。用户点了转人工，还要重新排队、重新复述一遍问题，这种体验比一开始就没有 AI 更糟。所以切换的时候应该把对话摘要一起递过去，用户端只看到一句正在连接，不需要重来。触发条件也不该只是用户点按钮，连续两轮没解决、或者语气明显变差，都该主动切。
放到具体场景里，我的思路大概是这样：知识性问题默认走检索，让答案有出处，规则变了只改文档；语气和意图交给小模型，它不需要背知识，只需要学会怎么说话；剩下那部分复杂长尾再路由给大模型或者人。这样大部分请求是便宜且可追溯的，贵的那一档只处理真正需要的部分。
这套结构不漂亮，链路长，要维护的东西多。但它把不确定性关在了最小的范围里，出问题时也知道该看哪一段。
还有一层是诚实。模型不知道就说不知道，同时给一条能找到答案的路径，这比编一个像模像样的答案要好。编造带来的信任损失，很难靠后面几次正确回答补回来。
我判断一个 AI 产品是否成熟，看的是它在边界上的样子，不是它在演示里的样子。
聊到这一步，我基本能感觉出对方有没有真的上线过东西。不是看他会不会说 RAG、量化、蒸馏这些词，而是看他提到失败时的语气：是把它当成一次需要解释的意外，还是当成设计的一部分。
我自己也没有一套完整的答案。每次聊完，我更想知道的往往是对方上一次上线踩了什么坑，而不是他记住了多少个指标。
评论