编程问答模型分歧大，单份答案易漏约束

把同一个架构问题交给不同 AI，答案可能在关键取舍上分叉。作者向 GPT、Claude、Gemini、Grok、Llama 原样提交了 24 个问题，发现编码方案题的分歧明显多于事实题。

这项小规模研究最有用的提醒是：只有一个模型提到的细节，可能救下一次迁移，也可能就是错误。面对要长期维护的技术决策，比起再要一份流畅答案，更该找出模型在哪些地方意见不一致。

编码方案为什么更需要交叉检查

24 个问题中，有 6 个属于编码方案题。按作者的统计，事实题平均每题出现 0.33 处实质分歧，编码题则达到 2.67 处；6 个编码题里，5 个出现了「只有一个模型提出的主张或立场」。

这里的分歧不只是措辞不同，而是会影响判断的差别：有人指出迁移限制，有人只讲收益；有人推荐 REST，有人把 GraphQL 当默认选项。

作者对研究中全部 14 条独家主张做了人工检查，其中 8 条被评为所在答案组中最有价值的一句，3 条则是错误或编造。原文没有交代剩余 3 条的具体评价。

独家观点既不能因为少数就被丢掉，也不能因为新鲜就被采信。

单个聊天窗口很难揭示这一点。它会把独到的提醒和孤立的错误，都包装成一段完整、自洽的回答。

三个案例，暴露了三种不同风险

第一个是 Postgres 分区。按作者的核查，只有一个模型指出了核心设计成本：主键和唯一键必须包含分区键，因此给已有表补充分区可能需要修改 schema。其他答案讨论了收益，却没点出这项成本。

这类遗漏比语法错误更难发现。回答未必每句话都错，但如果少了决定迁移难度的约束，方案仍可能无法照做。原文没有给出数据库版本、完整表结构和迁移 SQL，不能据此直接制定实施方案。

第二个是 TypeScript 的 interface 与 type。一个模型提醒，声明合并具有两面性：同名 interface 会静默合并。它还是唯一提出用 ESLint 规则约束这一行为的模型，但原文没有提供具体规则名。

另一个模型则把支持 implements 当成必须使用 interface 的理由。作者指出，这是错误的：类也可以实现对象形状的类型别名。讨论团队规范时，这种看似熟悉的论据尤其容易混过去。

第三个是公共 API 的默认选择。3 个模型推荐 REST，1 个推荐 GraphQL。原文没有交代第 5 个模型的选择，也没给出各自依据。能确认的是，同一问题存在真实的推荐分歧，不能把其中一个答案直接当作行业定论。

三个案例分别对应遗漏成本、事实错误和方案偏好。处理方法也该不同：补查约束、验证语言行为、明确业务条件。

我的判断

我赞同作者把语法查询和架构决策区别对待。查询一个写法，单模型通常足以作为起点；决定分区策略、API 风格或类型规范时，遗漏一个前提可能影响后续维护，交叉检查更有价值。

但这仍是一项小样本研究。只有 24 个问题，其中编码题仅 6 个。原文未列出模型版本，也未解释「实质分歧」的完整判定方法，无法据此推断所有模型、所有编程任务都会出现同样比例。

作者还披露，一位评判者同时也是参测模型，并发生过一次记忆串扰事件。原文没有说明它们对结果的具体影响。此外，作者开发的 MultiO 提供最多 3 个模型并排比较、自动选择成本合适的模型，以及逐条 token 费用展示，与文章建议有直接商业关联。其试用额度为 3,000,000 tokens，无需银行卡；这属于产品披露，不能作为研究有效性的证据。

多模型比较适合发现待验证的问题，不能替代验证。

与查官方文档、做最小复现或请同事评审相比，它的优势是快速暴露不同解释。作者没有给出这些方法之间的对照数据，也没有证明增加模型数量就能降低缺陷率。因此，把它当作架构评审的补充比较合理；把它当作可靠性保证，目前依据不足。

能拿来做什么

• 制定 TypeScript 类型规范时，让不同模型分别列出 interface 和 type 的适用条件，再把争议点做成最小代码示例验证。对 ESLint 建议继续追问规则名和配置，避免停留在口号。
• 评估 Postgres 分区迁移时，要求回答明确列出主键、唯一键和 schema 变更成本，再对照实际表结构检查，别只收集性能收益。
• 为前端配套的公共 API 选择 REST 或 GraphQL 时，先写清调用方、数据获取需求和维护约束，再比较推荐理由。模型票数只能提示分歧，最终选择要由这些条件支撑。