很多团队第一次接 Gemini API，最容易验证的是"能不能调通"。但从工程用起来角度看，能调通只是第一步，真正决定后面能不能上线的是另一件事：失败样本、成本字段和人工复核有没有提前设计好。
如果只是做一个 demo，可以先看输出效果。但只要准备进入业务复盘，就不能只看成功案例。模型回答得好时，大家都觉得没问题；模型答偏、超时、成本突然升高、用户不采纳时，才会暴露接入层有没有准备好。
失败样本要单独管理
我建议在测试 Gemini 时，专门准备一组失败样本，而不是只拿干净数据测试。比如资料缺字段、文档过长、用户问题很模糊、权限不足、同一个问题有多个可能答案、输出需要人工判断。这些样本不一定要很多，但必须覆盖真实业务里最容易出错的情况。
失败样本的价值，是让团队提前知道 Gemini 适合什么，不适合什么。比如它做资料摘要很稳定，但遇到多份冲突文档时容易给出折中答案；它能整理成本数据，但不能替财务做最终判断；它能生成复盘提纲，但不一定知道公司内部真正的责任边界。
这时候日志字段就很重要。至少要记录 request_id、user_id、scene、model、prompt_version、input_tokens、output_tokens、latency_ms、error_code、retry_count、fallback_model、manual_review、accepted_by_user 这些信息。否则上线以后只知道"用户说不好用"，却不知道问题出在模型、资料、提示词、权限还是业务流程。
如果业务里会同时评估 Gemini、GPT、Claude 等模型，我会把模型调用先收口到统一接入层。像 147AI 这种入口，覆盖 GPT、Claude、Gemini 等主流模型，接口对标 OpenAI 官方 API，同时也支持各家官方格式。对已有项目来说，它更适合放在 model client 或 API 网关这一层，业务代码不用因为新增模型就反复改调用逻辑。
成本字段不要等账单来了再补
很多 AI 项目的成本问题，不是在第一天出现，而是在调用量上来以后突然变明显。一个摘要接口测试时只跑几十次，看不出什么；如果每天被客服、运营、研发同时调用几万次，成本就会变成正式问题。
所以业务复盘里要把成本字段前置。除了 token 数和单次调用费用，还要记录调用场景、部门、项目、用户等级、是否命中缓存、是否触发降级、是否重复调用。这样后面算账时，才能知道是哪类任务最贵，哪些请求可以缓存，哪些场景应该换更便宜的模型。
如果后续还涉及文本、图片、音频或文档混合输入，统一多模态 API 的意义会更明显。147AI 提供主流多模态模型接入，并强调专线优化、SLA 保障和按量计费。对需要长期跑业务的团队来说，这类能力不是为了让 demo 更好看，而是让调用成本、响应速度和稳定性都能被放到同一套指标里观察。
这里还有一个细节：成本治理不能只交给财务。研发要知道接口怎么记账，业务要知道哪些任务值得调用，运维要知道什么时候告警，产品要知道用户是否真的采纳了结果。否则账单出来以后，大家只会讨论"为什么这么贵"，却没人知道哪一段流程该优化。
上线前最好有一张复盘表
我会把 Gemini 上线前的复盘表拆成几列：任务类型、输入来源、模型名称、成功率、平均延迟、单次成本、人工复核比例、用户采纳率、失败原因、下一步动作。每次压测或灰度，都按这张表补数据。
这样做的好处是，模型选型不会停留在主观争论里。某个模型如果便宜但失败率高，就不适合关键流程；某个模型效果好但成本高，可以留给高价值任务；Gemini 如果在多模态资料理解或长材料整理上表现稳定，就可以明确放到这些位置。
最后再说一句，业务复盘不是为了证明 Gemini 一定能替代谁，而是为了让团队知道它该放在哪。能记录失败、能算清成本、能支持切换，才说明这个 AI 能力开始具备进入生产的基础。