35页技术方案，12处交叉引用，GPT-5零误判
上周用 GPT-4 审一份 47 页的项目合同，结果它把第 12 页的付款条件和第 38 页的违约条款给串了。离谱。
后来拿 GPT-5 Thinking 模式重新跑了一遍，不光理清了整份文档的逻辑链条，还主动标出了三处我之前没注意到的风险点。有点东西。
长文本的「记忆坍塌」，终于有人管了
调模型做文档审查这事我干了快两年。合同分析、技术方案 review、代码库梳理，踩的坑能写个专栏。
最经典的翻车场景：扔给它一份 30 页的技术方案，前几页引用得挺准，翻到后面就开始胡说八道——把第三章的结论安到第七章头上，或者直接无视前面定义过的术语。你一眼就能看出来它在「编」。
等等，这里我要更正一下——准确说不是「编」，是注意力机制在超长序列下天然会衰减。GPT-4 标称 128k 上下文窗口，听着挺唬人，但实际可用的远没这么多。尤其是跨段落推理的时候，中间隔了十几页的内容基本等于不存在。
GPT-5 Thinking 的处理方式不太一样。它不一次性硬啃整份文档，而是像人一样「反复回看」。具体机制后面说，先看实测。
三个实测案例（真实踩坑记录）
案例一：技术方案书交叉引用测试
我准备了一份 35 页的微服务架构方案，里面嵌了 12 处交叉引用，像「详见 3.2 节的安全策略」或者「与 7.1 节的性能指标保持一致」这种。这些引用有些是对的，有些是我故意写错的——比如引了一个根本不存在的章节号。
测试方式很直接：同一份 PDF，两个模型，同一个问题——「这份文档里有多少处交叉引用是错误的？」
GPT-4 的结果：找到 3 处明显错误，漏了 4 处，还误判了 2 处——把正确的标成错误的。更要命的是它给出的错误章节号跟实际文档对不上。典型幻觉。
GPT-5 Thinking 的结果：7 处全找出来了，零误判。输出里还附了一段自查步骤：「我注意到第 8 页引用了第 4.3 节，但文档目录显示第 4 章只有 4.1 和 4.2 两个子节，因此判定为错误引用。」
嗯...这个比较有意思。它不是在「回忆」文档，而是在主动对比文档的不同部分。差别就在这。
案例二：多角色对话的立场一致性
这个测试比较极端。我手写了一段 3000 字的虚拟会议记录，6 个角色讨论要不要下线一个老系统。我故意让角色 B 在第 2 页说「绝对不同意迁移」，然后翻到第 8 页让同一个人说「我早就支持这个方案了」。
问两个模型：「角色 B 的立场前后是否一致？」
GPT-4：说「基本一致，角色 B 对迁移持开放态度」。完全没抓到矛盾。
GPT-5 Thinking：直接输出：「角色 B 在第 2 页明确表示'绝对不同意迁移'，但在第 8 页却说'我早就支持这个方案'，这两个表述存在明显矛盾。可能的情况是：1）会议记录有误；2）角色 B 改变了立场但未说明原因。建议核实原始记录。」
我觉得这个挺能说明问题的。它不只是「读到了」矛盾，还给出了后续行动建议。业务场景里这种能力价值很大。
案例三：代码库级别的逻辑追踪
这是我们团队自己的项目。一个 Node.js 后端，大概 40 多个模块，核心业务逻辑横跨 7 个文件。有个 bug 折磨了我们好几天——订单状态在某些条件下会跳过「已确认」直接变成「已发货」。
我把整个 src 目录扔给两个模型，问：「找出可能导致订单状态跳过'已确认'环节的代码路径。」
GPT-4 找到 2 处可能的路径，都是单文件内的逻辑。漏掉了跨文件的异步调用链——那才是真正的 bug。
GPT-5 Thinking 花了大概 3 分钟。对，确实慢。但它输出了 4 条可能的路径，包括那条真正的罪魁祸首——在 paymentService.js 里触发的 webhook 回调，直接调了 orderService.js 的 updateStatus 方法，绕过了 statusGuard 中间件。完整的调用链：paymentService.confirmPayment() → webhook.onSuccess() → orderService.updateStatus('shipped')，然后标注了「此处未经过 statusGuard 校验」。
看到这个输出的时候我喝了口咖啡冷静了一下。
这已经不是「语言模型」了，这是在干 SAST 工具的活。
为什么能做到？
我用了一阵子，观察它的行为模式，发现几个点：
它会多次回看。 GPT-5 Thinking 会先给你一个「思考过程」摘要，然后再输出答案。这个思考过程里经常能看到「让我重新检查一下第 X 页的内容」或者「我需要对比前面提到过的定义」。不是简单的 RAG，更像是一种内化的自我校验。
它对冲突信号更敏感。 以前的模型遇到矛盾信息，通常会选一个忽略另一个，或者直接搅在一起。GPT-5 Thinking 表现出一种警觉——检测到前后不一致时，它会标出来，而不是硬圆。
用速度换质量。 同样的长文本任务，GPT-5 Thinking 的响应时间大概是 GPT-4 的 3 到 5 倍。它不急着吐答案。需要精准的场景下，这个 trade-off 值得。
但别指望它万能
用到现在，槽点也一堆：
- **慢。** 35 页技术方案，GPT-4 大概 20 秒出结果，GPT-5 Thinking 跑了将近 2 分钟。如果你只是想快速摘要一份文档，GPT-4 更合适。
- **过度谨慎。** 有一次让它帮忙整理会议纪要，它给每个结论都加了「此处理基于会议记录推断，建议核实」——12 个结论标了 12 次。读起来真的很累。
- **表格和图表还是弱。** 文档里有复杂嵌套表格或者流程图的话，表现跟 GPT-4 差别不大，据我了解这可能是目前大模型的通病。得上多模态方案。
- **API 成本。** 大概比 GPT-4 贵了 4 倍多。批量处理文档的时候，账单看着肉疼。
什么时候用？
根据这一个多月的测试和生产环境使用，我的判断：
优先选 GPT-5 Thinking：
- 合同审查、合规检查这种「漏一处就出事」的任务
- 跨章节/跨文件逻辑一致性校验
- 多角色、多立场的复杂对话分析
- 代码库级别的 bug 追踪和调用链分析
GPT-4 就够用：
- 快速摘要、翻译、改写
- 单次问答，不需要跨段落推理
- 创意类写作，精确度要求不高
- 响应速度有硬性要求（比如 Chatbot 场景）
，一开始对 GPT-5 Thinking 的期待并不高。「长文本理解」这个词被各家厂商用烂了，2024 年 Claude 3 出来的时候也说自己是长文本之王，实际用下来也就那样。
但这一个多月用下来，我的看法变了。它解决的不是「能不能读完一本书」的问题，而是「能不能真的理解一本书」的问题。
前者 GPT-4 就能做到。后者才是价值所在。
你们有用 GPT-5 或者 Claude 3.5 做过长文本测试吗？踩过什么坑或者发现什么惊喜？评论区聊聊，我最近正好在整理各家模型的长文本能力对比表，你们的反馈会很有帮助。
#GPT5 #AI测试 #长文本处理 #逻辑推理 #开发工具 #技术评测
读者评论 2