今年AI圈子有个很明显的变化——大家不怎么讨论“哪个模型强”了，更关心的是“模型放到自己业务里到底行不行”。技术选型这种事，光看榜单没用，得拉出来溜溜。

我这两个月一直在测Gemini这个3.1版本，看看它在我们那套老旧的微服务系统里能翻出什么浪。试用的入口太多容易乱，我一般习惯从v.877ai.cn直接进，这个聚合站把常用的几个模型挂在了一起，省得来回切标签页。言归正传，聊聊专门针对Gemini 3.1 Pro搞的这套观测方法，供大家参考。

一、先想清楚你要“测”什么

很多人上来就让AI“帮我优化系统”，这跟让新来的同事“看着办”一样不靠谱。我的经验是，先把系统问题分个类，然后再看模型在每类上的表现。

我给自己定了三个维度：

• 代码理解力：能不能读懂跨模块的业务逻辑

• 重构建议质量：出的方案是能直接用，还是得大改

• 稳定性：同一段代码反复问，回答会不会飘

这三个维度一列出来，测评就比较有章法了，而不是最后来一句“感觉还行”。

二、拿老系统当试金石

我用的是公司一个跑了快四年的订单服务，30多万行代码，中间换了七八个经手人，文档早就对不上实际代码了。

第一轮测理解力。 我把整个订单模块打了个包扔给Gemini，让它画出状态流转图。说实话最开始我没抱太大希望，因为这个服务里面光“待支付”和“支付中”这两个状态的定义就有三处不一致的地方。

结果它画出来的流转图标注了这些冲突点，还把每个状态的跳转条件用表格列了出来。光这一手，至少省了我两天的文档梳理时间。

第二轮测重构建议。 我挑了一个接口让它优化。这个接口的问题是查一次订单要拼四五张表，响应时间经常飙到一秒多。Gemini给的方案是加一层Redis缓存，但是缓存策略写得很细——不是一句“加个缓存”就完事，而是具体到哪些字段该缓存、过期时间设多久、缓存穿透怎么处理。

不过最后这一步它翻了个小车。它建议用布隆过滤器来防穿透，但给的那个bloom filter的预期容量和误判率设置得不太合理，我看了下如果照它给的参数上线，误判率怕是得到5%以上。这种细节还是得人把关。

第三轮测稳定性。 同样的问题，我隔了三天再问了一遍，核心思路没变，但缓存失效策略的写法有些出入。这个倒不算什么硬伤，毕竟模型本身有随机性，但如果是用在自动化流水线上，这个偏差就得留意了。

三、搭建可量化的追踪体系

光靠主观感受不行，得有个能持续追踪的方法。我搭了一套比较土但管用的机制：

我用了个笨办法——给每次提问建个日志，记录三样东西：

1. 输入的代码片段和prompt

2. 模型给的输出

3. 我自己的评分（1-5分）

攒了两周的数据之后，就能看出一些规律了。比如它在处理嵌套超过三层的循环逻辑时，评分明显偏低，好几次都搞混了循环变量的作用域。但处理数据库层面的优化建议，几乎每次都能给到4分以上。

给个实用模板，大家可以直接拿去改：

四、跟别的模型放在一起对比

一个人测容易片面。把同一个prompt分别丢给三个不同的模型，横向对比了一下：

• 复杂SQL优化：Gemini把执行计划解释得很清楚，建议加的索引也在点子上

• 多线程代码Review：有个并发读写的问题，只有Gemini把竞态条件的触发时机讲明白了

• 架构重构：这个反而是另一个模型更敢给方案，Gemini偏保守

这件事给我的启示是：单个模型是有能力边界的，有些场景可能需要组合使用。平时用聚合导航站的好处就在于可以快速切换对比，不用挨个去记域名。

五、说点实在的

这套追踪方法用了两个月，最大的感触是：AI辅助开发跟招人一样，你得有面试标准，才能判断它合不合适。

技术上本身并不复杂。建个简单的打分模板，定期复盘一下，慢慢就能摸清楚模型在你业务场景下的优势和短板。现在2026年了，光说“这个模型很强”已经没有意义，得说得出来“在我们这种电商高并发场景下，它在哪类问题上靠谱，哪类问题上还得人盯着”。