AI & Human: What's Next

Posted on

利益声明：本文不构成投资建议，不推荐任何 AI 工具购买或中转平台推广。所有内容均来自本人约 2 万美金 token 的实践经验。不同项目类别、不同编码品味可能会得出不一样的结论。

书接上回

上一篇我们聊到：AI 的知识储备远超个人，但难以唤醒；你的鉴别力边界决定了质量控制的上限；触发器永远是你自己的成长，不是 AI 的主动突破。

那接下来的问题自然是：怎么唤醒它的知识？怎么验证它给出的方案？当它的方案超出你的认知以后，你还能做什么？

要回答这些，得先理解一个前提：AI 不是一个稳定的工具，它的表现会随着对话推进而变化。Opus 4.6 给了我一种奇点临近的感觉，它已经可以对我的项目开发实现整体加速了。不是某个环节快一点，而是从架构设计到编码实现到调试部署，全链路都能帮上忙。

先打个脸：我之前以为 Opus 4.6 相比 4.5 没有很大进步，我错了，Claude 哥对不起。小任务上两者表现差别确实不大，第一印象觉得"也就那样"。但真正的差距在长上下文的指令遵循上，这只有跑十几个大型重构任务才能体会出来。小任务测不出来的东西，大任务里天差地别。换句话说，Opus 4.6 上下文长了以后"变笨"的时间点被大幅推迟了。

这个"笨"不是简单的能力退化，仔细观察会发现它有两种截然不同的表现。理解这两种"降智"的区别，是回答上面三个问题的基础。

两种降智

第一种：遗忘

上下文越长，AI 会忽略掉过去已经达成的共识和结论。你问它的时候它会意识到，但你不主动提，它就会回到错误的路线上走很远。

这个问题在学术界已经有充分研究：

  • "Lost in the Middle" (Liu et al., 2023) — 模型对上下文中间位置的信息检索率下降 30%+，呈 U 形曲线
  • NoLiMa (Adobe, 2025) — 去掉字面关键词匹配后，13 个模型中 11 个在 32K 时准确率低于 50%
  • RULER (NVIDIA, 2024) — NIAH（大海捞针）近乎满分的模型，在多针/多跳任务上显著退化

好消息是，Opus 4.6 在 1M 长上下文上改善很大。根据 Anthropic 官方技术报告（The Claude Model Spec），8 针 MRCR 测试中达到 76%（对比 Sonnet 4.5 的 18.5%）。在 500K 左右的上下文中，遗忘问题已经不太影响实际工作了。

第二种：创造力衰减

这种"降智"更加隐蔽——模型不是给出错误答案，而是给出"正确但笨"的答案。用户很难察觉到它本可以做得更好。

举两个我实际遇到的例子：

  • 带着 PyTorch + CUDA + .pth 的镜像编译一次要接近半小时。上下文短的时候，AI 会建议先在 K8s 里开一个临时 pod 把整条链路跑通了再提交代码编译镜像。但上下文长了以后，它就老老实实地改代码、编译、等半小时、报错、再改、再编译……
  • 调试视频流的时候，上下文短时 AI 会说"先给你几行 JS 代码，贴到浏览器 console 里验证一下有哪些 tracks，codec profile 是什么"。上下文长了以后，它更倾向于直接在后端代码里改来改去反复试。

这些"鬼点子"的共同特征是：跳出当前执行路径，用低成本方式先验证假设。本质上是一种元认知——"我现在做的这件事成本高、反馈慢，有没有更快的方式先确认方向对不对？"

核心洞察：能力没丢，是注意力分配的问题。 Opus 4.6 不是想不到这些方案，开一个新会话或者 /compact 压缩上下文后，它很容易就能想到。但上下文超过一半以后，这类"鬼点子"就几乎不会自发出现了。权重还在，只是没被激活。

为什么会这样

两股力量在长上下文中同向叠加，共同把 AI 推向"听话但缺乏主见的执行者"。

架构层面：注意力稀释

简单粗暴地说：上下文越长，token 之间的注意力越"糊"[勘误1]。要形成远距离的"灵光一闪"式连接——比如在讨论镜像编译的时候突然想到可以用临时 pod——需要在特定 token 之间建立尖锐的注意力分布，而这正是长上下文削弱的。

2025 年有三篇论文（Scalable-Softmax, ASEntmax, Critical Attention Scaling）从机制层面分析并尝试解决这一问题[勘误2]。GSM-Infinite (2025, ICML) 也发现数学推理能力随上下文长度单调衰减[勘误3]。

更值得注意的是 "Context Length Alone Hurts" (Du & Tian, 2025) 的发现：即使模型完美检索到了所有信息，推理性能仍下降 13.9%-85%（取决于任务复杂度和上下文长度）。这说明不是找不到，而是用不好。

训练层面：对齐压力

RLHF/对齐训练在短上下文中表现为"靠谱"，在长上下文中表现为"死板"：

  • 模型被奖励的是完成当前步骤，而不是质疑"这个步骤本身是否最优"
  • 人类标注员更容易给"逻辑连贯、稳步推进"的回答高分，而"突然跳到一个完全不同的方向"容易被标为不相关
  • 长对话中 sycophancy（讨好倾向）累积，模型越来越顺着当前路径走

训练数据和标注员的水平上限也会体现在编码习惯中。比如 AI 特别喜欢做防御性编程：参数是数组，它会自动判断是否是数组，不是的话 wrap 进一个数组里；参数不对的时候不去修复 call site 的传参，而是在实现里打各种补丁。

这些"鲁棒性"在训练中被奖励，但在工程实践中是隐藏 bug 的蟑螂窝。好的系统设计应该是 fail-fast：恰当隔离错误，主动抛出无法处理的严重异常，交给上层决策，而不是在每一层都吞掉错误装作岁月静好。

在涉及资金、高功率输出、机械臂运行的场景下，异常停机的代价可能只是生产暂停，但吞掉异常继续运行可能导致财产甚至生命危险。

上下文本身就是隐性 SOP——对话中积累的执行历史形成了一条隐含的路径，模型的注意力越来越多地分配给"延续这条路径"而非"评估是否应该换路径"。

那为什么人类工程师不会这样？因为人类思维的工作方式恰恰相反。

对比人类工程师

人类工程师的"创造力"本质上是并行探索 + 跨路径迁移——你在调 K8s 的时候突然想到"等等，我先在浏览器里验证一下 codec"，这不是线性推理，是两条思路之间的意外碰撞。

优秀的工程师会同时维护多条尝试路径，这些路径不完全隔离，甚至会互相促进影响。只要能达成最终结果，过程不会固定遵循一个模式——除非被 SOP 或安全生产要求约束。

而 autoregressive 架构一次只生成一个 token，一次只走一条路。即使是 Chain-of-Thought 也是串行的，不是真正的并行探索。这恰好是当前架构最弱的地方。

架构的硬伤短期改不了，但我们可以用协作方式来补偿。

理解了特性后，怎么协作

理解了降智的机制，回到开头的三个问题。先说唤醒。

唤醒：像专家一样对话，而不是像写小作文

我看到有人教写 prompt 的方法论：要像写小作文一样长篇大段、有逻辑地输出，要尽可能详细。

我的经验正好相反。

高手之间交流不需要长篇大论的铺垫。特别是同领域专家之间，三句话就点到位了，甚至都不需要提背景，只讲关键路线选择，剩下的对方自己就脑补出来了。就算没点到位，对面一问一答，也就心领神会了。

对大模型也一样。废话说多了浪费 token，也浪费人的脑力。不如 2-3 句话：

  • 第 1 句讲背景：为当前项目集成视频水印功能
  • 第 2-3 句讲关键路线：考虑选择 FFT 或者 DFT 类似方案，为了防止高频降噪，考虑在低频域插入特征

够了。剩下的让 AI 自己展开。

反面案例：我见过有人给 AI 写一整屏的 prompt，项目背景、技术栈版本、团队规模、历史决策原因、未来规划……全部塞进去。结果 AI 的回复也是一整屏的废话，把你的背景复述一遍，再加上一堆不痛不痒的"建议"。信息密度越低，AI 的产出质量越低。

但这里有一个前提：你自己的认知水平决定了 AI 产出的上限。

低水平的认知写出来的低水平 prompt，只能换来 AI 低水平的产出。你说不出"考虑 FFT/DFT 方案，低频域插入特征"这种话，AI 就只会给你一个最朴素的明文水印方案。AI 拥有的知识远超任何个人，但它需要你用正确的钥匙去开门，而这把钥匙就是你自己的专业认知。

所以"像专家一样对话"的真正含义不只是简洁，而是你得先成为专家。AI 放大的是你已有的能力，而不是凭空创造能力。

再举一个实战案例。AI 给视频加 mask 模糊后，直接把原始的 m3u8 播放列表复制过去了——完全没意识到重新编码会改变字节偏移量。我自己一开始也不确定：可变比特率编码下，mask 处理到底会不会影响输出体积？跟一个做音视频的朋友讨论了一轮，他认为不会，我认为会。实验验证后确认：文件体积缩小了，i 帧位置全变了，原始 m3u8 的 byte range 指向完全错误。

但 Opus 4.6 的恢复能力让我意外。我只问了一句："你原样 copy 过去了？"——它就自己反省出整条错误链，并给出了正确方案（用 FFmpeg HLS muxer 直接输出新的 m3u8）。Codex 做不到这一步，不把推理过程喂给它，它猜不到 mask 后再编码会导致偏移量变动。

这里有一层值得点透的意思："像专家一样对话"不要求你在每个子领域都比专家强，而是你得有足够的认知密度去形成正确的怀疑。你不需要确定 m3u8 偏移量一定会变，你只需要怀疑"这样直接 copy 真的对吗？"然后一句话问出来，AI 自己就展开了。但注意，能产生这个怀疑本身就需要一条推理链：mask 模糊改变了画面内容 → 可变比特率编码下信息熵变了 → 输出体积变了 → 字节偏移量对不上。这条链上任何一环的认知缺失，都不会触发那个怀疑。门槛从"你得知道答案"降到了"你得能怀疑"，但"正确的怀疑"本身仍然需要认知基础。

但"像专家一样对话"只解决了信号质量问题——用高密度的输入唤醒高质量的输出。还有一个信号覆盖问题：你不知道该往哪个方向问，再精准的提问也覆盖不到盲区。

对此有一个补充策略：无方向审计。不带预设地问 AI"你认为当前方案缺少哪些维度"，然后逐条追问。这不能保证覆盖所有盲区，AI 也有可能编造维度来显得有用，但至少比只沿着自己已知的方向提问要好。

再说验证。

验证：主动对抗创造力衰减

既然知道长上下文会让 AI 失去创造力，就应该主动对抗。核心策略是：适时停下来，由人类主导对当前路线做审计。

具体操作：

  1. 当你感觉 AI 开始"沿着惯性走"的时候，停下来
  2. Fork 当前会话，或者开一个新会话
  3. 用 /compact 压缩上下文，让 AI 带着精简过的记忆重新审视当前方案
  4. 让 AI 先自行审计一遍：当前路线有没有更好的替代方案？有没有可以低成本验证的假设？

本质上，这是用人类的元认知能力弥补 AI 在长上下文中的注意力分配缺陷。人类负责"该不该这么做"，AI 负责"怎么做"。

工程原则：让机器替你验证

怎么验证 AI 给出的方案？编程领域有一个天然优势：编译器、类型系统、测试套件，这些验证工具不依赖人类的主观判断。你的鉴别力有上限，但机器化验证没有。前提是：代码本身得遵循一些基本原则。

命名

非常重要，定期让 AI 审计所有命名规范，不要自己发明名字。

人类工程师能记住"这个函数叫 processMatrix 但其实干的是流量分发"——大脑会自动建立名实不符的映射。但 agent 不会。每开一个新 session，它都会老老实实按名字理解语义，然后在同一个坑上反复栽倒。

老板爱叫什么"流量矩阵""裂变增长"我管不了，但这些命名污染一旦渗入代码，就是给 agent 埋雷。好的命名让 AI 和人类都能快速建立正确的心智模型，坏的命名只有人类能靠记忆力硬扛，agent 扛不住。目标是：让 agent 在任何新 session 中都能顾名思义。

功能设计

保持通用简单，不要特立独行。你的商业模式和程序逻辑没有那么独特——你大概率不是地球上第一个想到这套方案的人。与其自己拍脑袋设计一套扭曲的实现，不如把方案描述发给 agent，问它：这套方案叫什么名字？有没有成功案例？有哪些可以借鉴的？然后让 agent 按照业界标准模式去实现，而不是你脑洞里的特殊版本。

举个例子：设计用户登录系统，密码禁止明文保存。如果你没听说过 bcrypt，可能会给 agent 描述一套自创方案——先 MD5 再 SHA256 再 ECC，私钥硬编码到配置里。停。先把你的方案发给 agent，问它业界最佳实践是什么。AI 会告诉你 bcrypt/scrypt/argon2，还会指出你方案的缺陷：迭代次数太少、ECC 私钥保存不当、所有密文产出自同一规则无法抗并行彩虹表攻击。

多听取来自 agent 的不同意见。 AI 的知识广度远超个人，不要只把它当执行者，也让它当审稿人。

模块化

你思路中真正独特的部分，通过组合标准模块来实现，而不是去修改（扭曲）标准化实现本身。模块之间尽可能独立，避免过多交叉。有独特需求就用几个简单模块叠加——做加法而不是做乘法。功能叠加是线性增长，功能交叉是组合爆炸。一个函数干三件事，agent 理解错任何一件都会全盘出错。

状态收敛

  • 有限状态，不做无限状态：状态空间越小，AI 越不容易走偏。这和围棋的道理一样，棋越下到后面，棋盘上的空间越小、状态越少，局势越收敛，评估越精确。好的软件设计应该让 agent 面对的也是一个不断收敛的状态空间
  • 要收敛不要发散：引导 AI 向确定性收敛，而不是无限展开可能性

对于 AI 的编码坏习惯（比如前面提到的防御性编程），实践中有效的做法是：给 AI 制定明确的编码风格 rule，然后定期做无定向审计。所谓无定向审计，不是带着具体问题去查，而是随机抽检代码，看 AI 有没有偷偷跑偏。我的经验是（仅限 Opus 4.6 1M），制定 rule 以后 AI 遵循得还不错，上下文长了会有些风格上的小偏差，但路线上不太会偏离了。

说到底，这些原则在没有 AI 的时代就是好的工程实践。但以前你可以"先欠着"——反正人类同事能靠默契和记忆力填坑。

有了 agent 以后，技术债务的成本被急剧放大了：每一个误导性的命名、每一个纠缠不清的模块、每一个没有文档的隐式约定，都会让 agent 反复犯错、浪费 token、产出垃圾代码。任由 agent 在烂代码上堆砌新代码，不出一周项目就维护不动了。

重构：AI 时代的可持续开发

技术债务会被放大，但还债的工具也变强了。

反过来说，AI 恰恰是重构的最佳搭档。

以前你懒得写的模板代码、玩不转的类型体操，现在都可以扔给 agent，反正烧的是 token，不是自己的脑细胞。如果老代码已经被 opaque type 等类型约束保护过了，AI 重构出偏差的可能性也不大。类型系统本身就是一道护栏，编译器会替你拦住大部分错误。

当然，这里有一个诚实的前提：大规模重构主要适用于新项目，或者你从一开始就在维护的项目。老项目、遗留系统，agent 改完了你敢上线吗？我不敢。兼容性问题、隐式依赖、没有测试覆盖的暗角——这些是 agent 无法感知的雷区。

但对于新项目，我认为"大规模重构"应该常态化。不是等到代码腐烂了才重构，而是把重构作为日常开发的一部分。关键在于形成一个正向循环：反复重构 → 降低技术债务 → 减少代码量 → agent 理解成本更低 → 下一次重构更顺利。这才是 AI 辅助开发的可持续路径。

但这个循环能转起来有一个前提：架构必须由人来设计。agent 的视野越局限，效果越好。设计的时候就别让它过度感知框架全貌和其他模块的实现细节，只给它当前任务所需的最小上下文。如果放手让 agent 自己做顶层架构决策，结果大概率是一坨屎。

这不是空谈，我亲身经历了反面案例。

反面教材：让 agent 写文档管文档

我老板是化学出身，没有软件架构背景，不知道如何往"收束"的方向约束 agent。他过去的做法是让 agent 生成大量 markdown 设计文档——架构文档、功能文档、逻辑流程文档——然后在 rule 文件中严格要求 agent 每次修改代码都必须检查设计文档是否一致。

听起来很合理，实际上是一场灾难：

  1. 上下文长了 agent 会忽略 rule。尤其是在长调试/反馈周期里，多种修复方案来回切换，反复修改甚至等待部署验证结果，agent 某次改完代码后就忘了更新对应的 markdown 文档
  2. 文档与代码不一致后产生连锁反应。开启新 session 时，新的 agent 读到过时的设计文档，被其中的错误概念先入为主，做出错误实现。而 rule 文件中又没有覆盖这种情况：当 agent 发现设计文档与实际代码行为不符时，应该更新文档而不是按文档改代码
  3. 文档越堆越长，反噬上下文。最长的设计文档接近千行，一个新功能横跨 2-3 个模块，agent 需要先读完项目背景和框架的千行 markdown，上下文已经逼近普通模型的降智边缘。文档本应降低认知负担，结果却在消耗最宝贵的资源——上下文窗口
  4. 降智效应被人为放大。回忆前文讨论的创造力衰减：上下文越长，AI 越倾向于沿惯性走、越缺乏跳出当前路径的能力。千行 markdown 文档直接把 agent 推入了降智区间——等于自己给自己挖坑

所以让 agent 编写和维护 markdown 文档，在过去一年里起到了完全相反的效果——甚至在今天的 Opus 4.6 上也是如此。代码本身就是最好的文档，类型签名就是接口契约，测试用例就是行为规范。与其维护一份随时可能过时的 markdown，不如把精力花在让代码自解释上。

老板的后端重启了六次。而我自己的后端项目，AI + 人类协作维护了一年，在 Opus 4.6 的协助下现在已经能做超大规模的重构了。这在去年底还完全不可能，稍微大一点的模块 Opus 4.5 都能给搞砸；但是 Opus 4.6 1M 开始不一样了。

说到底，有了 agent 我还是跟以前一样设计架构、主导重构。我的工作方式没变，变的是速度——agent 替我做了我想做但以前嫌麻烦的事。差别不在于用不用 AI，而在于谁在掌舵。

到这里，开头三个问题中的前两个（怎么唤醒、怎么验证）有了初步回答。第三个问题，当 AI 的方案超出你的认知以后怎么办，目前的答案是：人类掌舵，AI 执行。架构由人设计，验证靠工程基础设施，审计靠人类的元认知。

但这个答案能持续多久？

CCC = AlphaGo 的棋盘？

说实话，我也跟风嘲笑过 Claude's C Compiler（CCC），认为它只不过是拙劣地模仿"人类开发编译器"这一行为，而不是在开发编译器本身。

但我现在有一个很疯狂的想法。

AlphaGo Zero 的进化完全不依赖人类棋谱，纯粹自己与自己对弈[勘误4]。围棋棋盘是它的训练场。

那么 CCC 是不是 Claude 的棋盘？

这个类比值得展开，因为围棋和代码作为"训练场"各有优劣。

围棋的反馈是终极二元的——输或赢，无可辩驳，无法逆转。代码世界没有这样干净的 binary 标准：代码质量是一个连续谱，"能跑"和"优雅高效"之间隔着巨大的灰度空间。从这个意义上说，围棋的反馈信号更强、更纯粹。

但围棋有一个致命的弱点：反馈路径太长。开局时落下的一手棋，要等到终局才知道输赢，而中间极难确定这手棋对全局胜负的贡献有多大——这正是 AlphaGo 需要价值评估网络（value network）的原因，它本质上是在用一个额外的神经网络来"猜测"中间状态的价值，因为围棋本身不提供这种中间反馈。

代码世界恰恰相反：短路径反馈无处不在。类型签名在你写下代码的瞬间就告诉你接口对不对；单元测试在几秒内告诉你逻辑对不对；集成测试告诉你组件之间配合得对不对。你不需要等到"终局"才知道一步走得好不好——每一步都有即时的、局部的反馈信号。这意味着 credit assignment（功劳归因）问题天然比围棋简单得多。

而编译器开发，恰恰是人类世界中最复杂、最精妙的软件工程用例之一。它对正确性的要求极其严苛，一个 codegen bug 可能导致下游所有程序产生难以追踪的错误；它对性能有极致追求，寄存器分配、指令调度、循环优化，每一步都在逼近理论最优；它对生成代码的体积也有硬约束，嵌入式场景下每一个多余的字节都是成本。

更关键的是，人类已经为编译器积累了极其完善的测试基础设施——从语言一致性测试套件到性能基准，从模糊测试到形式化验证，这些都能提供精确、可量化的反馈信号。编译器开发远比 LeetCode 算法题复杂——它不是解一个孤立的问题，而是在一个庞大的约束空间中做全局优化。然而即便是人类顶尖的编译器工程师，面对不断演进的硬件架构和语言特性，也无法声称完美解决了这个问题。

同时，编译器开发还有一个常被忽略的优势：它是一个相对封闭的任务——而封闭性，恰恰也是围棋棋盘之于 AlphaGo 的核心优势。围棋的规则是有限的、完备的，19×19 的棋盘就是整个宇宙，不存在"对手突然掀桌"或"棋子自己消失"的情况。正因为封闭，问题空间才是有限的，才可以被穷举、被学习、被征服。

现实世界中的软件工程恰恰缺少这种封闭性——需要驱动的外设、需要兼容的 legacy API、各种历史遗留的屎山代码、外部第三方和云平台的 SDK 变更、数据库约束、磁盘空间不足、网线被剪断或丢包延迟、对方服务器被拔电源甚至数据中心被炸。这些因素让反馈信号变得嘈杂、不可控、难以复现。

而编译器的输入是源代码，输出是目标代码，中间的变换规则由语言规范严格定义。整个问题域是自包含的，几乎不依赖外部世界的不确定性。

这正是它作为 AI 自我进化"棋盘"的理想之处：足够复杂、反馈足够清晰、标准足够客观、边界足够封闭。

所以我的爆论是：编译器开发，比任何其他软件工程任务都更适合用来自我训练 coding agent。 CCC 今天看起来是个笑话，但 AlphaGo Zero 从随机落子开始，3 天就超越了击败李世石的版本[勘误5]。重要的不是起点多低，而是它有没有一个能让自己不断变强的训练场。

更重要的是，编译器的反馈比人类纠偏更精准、更公正。回忆前文提到的对齐压力——人类标注员会受限于个人认知水平和知识深度，惩罚那些看起来"离谱"但可能有效的鬼点子，奖励那些"看起来合理"的防御性编程。而编译器不会。代码要么通过测试，要么不通过；生成的目标代码要么比基准快，要么比基准慢。编译器不关心你的解法是否"符合直觉"，只关心结果是否正确、是否高效。这恰恰绕过了 RLHF 中人类标注员成为瓶颈的问题。

如果 AI 能通过这类封闭、复杂、反馈密集的任务进行自我进化——不断写代码、编译、调试、修复、优化——那"协作伙伴"这个关系，可能只是一个过渡阶段。

当前阶段，即便是 Opus 4.6 这样的最强模型，放手让它主导的结果依然是屎山，前文老板的案例已经说明了这一点。人类的架构设计、路线判断、定期审计，目前仍然不可或缺。

但如果真的出现一个 "Claude Zero"——像 AlphaGo Zero 抛弃人类棋谱那样，通过编译器这块棋盘纯靠自我对弈训练出来的模型——它还需要人类掌舵吗？我不知道。

但至少在现在，理解它的认知特性、找到有效的协作方式，仍然是我们能做的最重要的事。上一篇说恐怖直立猿低估了自己。这一篇想说的是：正因为有智慧，才更该学会驾驭这个前所未有的工具，而不是被它的光环吓退，也不是盲目信任它的输出。

勘误

正文为了可读性做了简化甚至偏见性表述，以下是更严谨的说明。

[勘误1] "上下文越长，注意力越糊"

正文的说法是一个方便的直觉，但机制上不完全准确。Softmax 对 query-key 点积做归一化——如果新增的 token 与当前 query 无关，理论上它们的注意力权重会趋近于零，不会显著稀释相关 token。真正的问题更微妙：(a) 当上下文中存在大量语义相近但不完全相同的 token 时，注意力在它们之间的区分度下降；(b) 多头注意力中每个 head 的有效覆盖范围有限，长上下文中部分 head 可能"失焦"。Scalable-Softmax (2025) 等工作正是从 softmax 的温度缩放和熵控制角度解决这个问题，而非简单的"概率质量被均摊"。

[勘误2] "从机制上验证了这一点"

Scalable-Softmax、ASEntmax、Critical Attention Scaling 这三篇论文的主要贡献是提出改进方案（如温度缩放、稀疏注意力等），而非单纯验证长上下文注意力稀释问题的存在。它们的存在间接说明问题是真实的，但说"验证"不够精确。正文已改为"分析并尝试解决"。

[勘误3] GSM-Infinite 的适用范围

GSM-Infinite 测试的是数学推理任务（GSM8K 的长上下文变体），其"推理能力随上下文长度单调衰减"的结论严格来说只在数学推理领域得到验证。将其直接推广到所有类型的推理需要谨慎，但结合 "Context Length Alone Hurts" 等其他研究，长上下文对推理能力的负面影响应当是普遍存在的。

[勘误4] AlphaGo 演进路线

AlphaGo 系列的演进为：AlphaGo Fan（2015，击败樊麾）→ AlphaGo Lee（2016，击败李世石）→ AlphaGo Master（2017，60 连胜）→ AlphaGo Zero（2017，纯自我对弈）。其中只有 AlphaGo Zero 完全不依赖人类棋谱数据，从随机初始化开始纯靠自我对弈训练。此前版本均使用了人类对弈数据进行监督学习预训练。原文"AlphaGo 后期"的说法模糊了这条演进线，容易让读者误以为是同一个系统的渐进改进，实际上 Zero 是架构和训练方法的根本性重新设计。

[勘误5] "3 天就超越了击败李世石的版本"

这个说法来自 DeepMind 原论文（Silver et al., 2017），数据本身没有问题。但需要注意 AlphaGo Zero 训练时使用了单台机器配备 4 块 TPU，并非家用级别的算力。"3 天"容易给人"轻松碾压"的印象，实际上是专用硬件密集投入的结果。此外，3 天超越的是 AlphaGo Lee（击败李世石的版本），完整训练 40 天后才超越所有前代版本。