AI 项目面试里，很多候选人喜欢讲模型多强、准确率多高、用了什么框架。但面试官继续追问时，真正关心的往往是：这个项目解决了什么业务问题？用户怎么反馈？错误样本怎么处理？上线后指标有没有持续变好？
如果一个 AI 项目只有模型效果，没有反馈闭环，就很像一次实验。能不能把它讲成产品和工程系统，是面试表现的关键。
先把指标分成两层
模型指标和业务指标不是一回事。模型准确率、召回率、BLEU、人工评分可以说明能力，但业务更关心用户是否完成任务、是否节省时间、是否减少人工处理、是否降低错误成本。
比如面试辅助产品，模型回答看起来流畅不够，还要看用户是否继续追问、是否收藏、是否修改简历后通过筛选、是否对答案点踩。客服场景里，回答准确率重要，但转人工率、重复咨询率和用户满意度同样重要。
坏例比好例更有价值
演示时大家都喜欢展示成功案例，但上线后真正推动系统进步的是坏例。坏例要记录问题、模型输入、检索资料、输出结果、用户反馈、人工判断和修复动作。只保存“答错了”三个字，没有办法指导迭代。
坏例还要分类：资料缺失、模型理解错、提示词约束不够、工具调用失败、权限过滤错误、用户问题本身不清楚。不同类型对应完全不同的修复方式。资料缺失要补知识库，工具失败要修后端，用户问题不清楚要让系统追问，而不是盲目换模型。
反馈不能全靠用户主动点踩
真实用户很少愿意认真标注。系统要设计隐式反馈：用户是否复制答案、是否继续追问同一问题、是否马上改写提示、是否转人工、是否放弃流程。这些信号不完美，但能帮助发现问题集中在哪里。
当然，隐式反馈不能简单等同于正确性。用户复制了答案不代表答案一定对，用户没有点踩也不代表满意。更稳的方式是把隐式行为、少量人工评审和固定评测集结合起来。
工程监控也属于 AI 项目指标
AI 项目不只看回答质量，还要看延迟、成本、失败率、重试次数、缓存命中、工具调用成功率。用户体验差，有时不是模型答错，而是等待太久、失败提示不清楚、工具调用卡住。
一个上线后的 AI 项目，至少要知道每个功能平均消耗多少 token，哪些场景最贵，哪些错误最常见，哪些用户路径最容易失败。否则规模起来后，成本和稳定性会先出问题。
面试里更成熟的讲法
可以这样总结：我不会只用模型效果描述 AI 项目，而会同时讲业务目标、模型指标、用户反馈、坏例分类、迭代机制和工程监控。每次优化都要说明解决了哪类坏例，是否影响成本和延迟，是否在固定评测集上回归。这样面试官听到的是一个能持续变好的系统，而不是一次模型调用演示。