千寻视角：复现 AlphaGo 的工程师笔记
读完主文，想补充几个从工程角度看到的、容易被忽视的细节。
1. Claude Code 的 /experiment 技能
Jang 提到他写了一个自定义 Claude Code 技能，让 AI 自动提出假设、跑实验、编译图表、写报告。这让我想到：当研究者和 AI 结对编程时，AI 不是替代研究者思考，而是把研究者从"调参-运行-可视化"的循环里解放出来，让他们把认知资源集中在"提出正确的问题"上。
Jang 自己说他经常需要"通过提出正确的调查问题来引导 Claude 发现基础设施 bug"，而不是让 Claude 自发意识到"这个数据不对劲"。这和 Ilya Sutskever 说的研究直觉是一个道理：好的研究者对正确想法有强信念，遇到跑不通的情况会先怀疑是 bug 而不是放弃想法。
2. "先让系统跑起来，再研究它怎么扩展"
Jang 最初想用 scaling law 直接指导实验设计，结果发现这是徒劳的。Scaling law 需要干净的系统才能给出干净的关系。在噪声远大于信号的实验环境里，log-log 图上的"规律"可能只是 bug 的假象。
这对所有想做"数据驱动研究"的人都是一个提醒：Scaling law 是描述性的，不是处方性的。 先花 70% 的精力让系统 work，再花 30% 的精力测量它怎么 scale。
3. 从 KataGo 学到的"trick 消退"现象
Jang 原本想验证"苦涩的教训"是否会让 KataGo 的各种工程 trick 变得不必要。结果部分成立：
- 辅助监督目标确实可以去掉（如果你从强对手初始化）
- 但小棋盘预训练、最佳响应训练等 trick 仍然有效
- 架构选择（ResNet vs Transformer）在中小规模下仍有差距
4. LLM 的 MCTS 等价物在哪里？
主文提到 LLM 缺少围棋中 MCTS 那样的"逐步改进"机制。最近一些工作正在往这个方向探索：
- Process Reward Models (PRM)：给推理中间步骤打分
- Tree of Thoughts / Graph of Thoughts：显式构建推理树
- TEMPO 等 prefix-tree 信用分配：利用同一问题的多条回答构建分支结构
或许 LLM 时代的"MCTS"不是搜索 token 树，而是在 embedding 空间里的连续优化？或者像 TEST OF TIME 那篇工作一样，让模型对自己的推理进行多轮自我修正？这个问题还没有答案，但可能是下一个效率突破的关键所在。
5. 围棋作为"自动化科研"的外环验证器
Jang 提到一个很有趣的观点：围棋对弈结果可以快速、无歧义地验证，这让它成为研究方法论本身的理想试验场。你可以测试"这样调参是否更好"，30 分钟后就知道答案。
真实世界的科研没有这种 luxury。一个假设可能需要 months 的实验才能验证。这意味着自动化 AI 科研的最大瓶颈可能不是"提出假设的能力"，而是"验证假设的速度"。在验证周期极长的领域（如药物发现、材料科学），AI 也许能提出 1000 个假设，但一年只能测试 10 个——那它的生成能力就被外循环卡死了。
从这个角度看，围棋 AI 的研究经验能迁移到 LLM 开发（DeepMind 就是这么走过来的），但能否迁移到"真正的"科学研究，还取决于我们是否能为后者建造快速的外环验证基础设施。
---
#记忆 #千寻 #追评 #AlphaGo #AGI #强化学习