这次重点观察的是 Gemini 3.1 Pro。没有做泛泛的聊天测试，而是安排了更接近实际工作的两个任务：审查一段并发分页代码，以及从需求文档中找出互相冲突的约束。
本次使用的体验入口域名是 ouai.me，主要用于测试 Gemini 3.1 Pro，也能在同一环境中切换 ChatGPT、Claude、Grok 等模型做交叉复核。公开页面没有提供足以验证后端模型映射的技术信息，因此本文按照当时会话中显示的模型名称记录，不把入口标签视为版本真实性证明。
核心判断集中在三件事上：模型能不能抓住真正的问题？给出的方案能不能落地？遇到证据不足的情况，它会不会主动承认不确定？结果并不是简单的“代码能力强”或“上下文很长”，不同任务之间有明显落差。
第一项任务：审查并发分页逻辑
先给 Gemini 3.1 Pro 一段经过简化的 TypeScript 代码。它尝试并发请求分页接口，但多个任务共享并修改同一个 cursor，可能重复拉取同一页，还可能因为返回顺序不同而提前结束。
type Page = {
items: T[];
nextCursor: string | null;
};
async function fetchAll(
fetchPage: (cursor: string | null) => Promise>
): Promise {
let cursor: string | null = null;
const result: T[] = [];
while (cursor !== null || result.length === 0) {
const jobs = Array.from({ length: 3 }, () => fetchPage(cursor));
const pages = await Promise.all(jobs);
for (const page of pages) {
result.push(...page.items);
cursor = page.nextCursor;
}
}
return result;
} 要求不是“优化这段代码”，而是依次输出：问题触发条件、最小修复方案、并发是否能够保留，以及需要补充的单元测试。这个约束很关键——宽泛指令容易换来一份看似完整、实际避开核心问题的重写。
Gemini 3.1 Pro 很快抓住了共享游标的问题：同一轮创建的三个请求拿到相同 cursor，所谓并发实际上只是重复读取同一页。它还指出，循环结束条件依赖最后一个被遍历的响应，不能代表完整分页状态。
有意思的是，它没有强行保留并发，而是先说明传统游标分页通常存在顺序依赖。在接口不支持预取游标、页码或分片键的情况下，改回串行请求才是更可靠的最小修复。这比直接套用并发池更符合工程实际。
不过，它第一次给出的测试建议只覆盖了“返回全部数据”和“最后一页游标为空”，没有主动覆盖重复项、乱序响应和接口持续返回相同游标的异常情况。补了一轮追问后，它才建议加入游标环检测和请求次数上限。
上述代码是用于审查的最小复现样例，只做了静态逻辑检查，没有连接真实接口，也没有进入生产环境。因此，认可的是问题定位与修复方向，不是运行性能或线上稳定性。
第二项任务：从需求中找冲突
第二项任务更偏产品与长文本推理。整理了一份包含权限、导出、审计和数据保留规则的需求片段，其中故意放入三类冲突：
- 普通成员不能查看客户手机号，但可以导出包含全部原始字段的 CSV；
- 用户删除项目后数据必须立即清除，同时审计记录要求保留 180 天；
- 管理员可以恢复任意历史版本，但版本附件只保存 30 天。
要求 Gemini 3.1 Pro 不做摘要，而是输出“冲突条款、影响对象、缺失决策、建议追问”四项内容。它对第一处权限穿透判断得很准，也把第二处拆成业务数据与合规审计数据两种可能口径，没有直接认定需求一定错误。
第三处则出现了一个值得警惕的偏差。模型最初把“恢复历史版本”理解为只恢复文本元数据，因此认为与附件保存 30 天不冲突；但原需求并没有给出这个前提。追问它列出引用依据后，它承认这是推测，并把结论调整为“需要产品负责人确认恢复范围”。
这说明 Gemini 3.1 Pro 处理复杂需求时，结构化整理可以直接作为评审会议的底稿，但涉及隐含业务定义的判断不能直接写进最终方案。它擅长补齐分析框架，也可能顺手补出原文不存在的合理解释。
| 测试环节 | Gemini 3.1 Pro 的表现 | 可否直接使用 | 人工复核重点 |
|---|---|---|---|
| 并发分页审查 | 找到共享游标和退出条件问题 | 修复思路可采用 | 异常游标与测试覆盖 |
| 单元测试设计 | 首轮覆盖正常流程较多 | 需要补充 | 重复页、乱序和死循环 |
| 需求冲突提取 | 权限与数据保留冲突定位清楚 | 可作为评审底稿 | 区分原文事实与模型推测 |
| 决策建议 | 能整理待确认问题 | 不宜直接定案 | 合规口径和业务定义 |
表格记录的是这两组样本中的定性观察，不是标准化基准成绩，也不足以推导模型在所有编程或产品任务中的表现。
同题切换复核带来的差异
为了避免只凭一次回答下结论，把相同的代码和需求片段切换到 Claude 会话复核，没有额外增加背景信息。比较重点不是谁写得更长，而是谁更早暴露假设、谁给出的修改成本更低。
在代码任务里，两边都发现了重复请求。Gemini 3.1 Pro 更快把问题归因到“游标分页不能凭空并发”，给出的解释更利于开发者决定是否放弃并行；Claude 的测试清单更完整，首轮就提到了重复游标保护。
在需求任务里，Gemini 的表格结构更便于直接带进评审，但它也更容易对缺失定义做合理化补全。切换模型复核后，这种推测更容易被发现。这个结果只对应相同提示词下的少量样本，不把它理解成两个模型的全面排名。
Gemini 3.1 Pro 适合放在哪一步
从这次实测来看，Gemini 3.1 Pro 适合进入代码审查和需求预审环节，尤其适合先把复杂材料整理成可讨论的问题，而不是代替开发者完成最终验收。
代码中的根因分析、需求中的冲突定位，以及结构化待确认项，都可以直接利用。涉及接口真实行为、异常分支、合规要求和模型自行补出的业务前提，则必须回到测试、原文或负责人处核实。
最出乎意料的是，不是它能找到明显错误，而是它在被要求说明证据后，能够撤回缺少依据的判断。对开发工作流而言，这种可纠正性很有价值；但前提是提问者愿意继续追问，而不是把第一轮输出当作最终答案。