想象这样一个场景：你给 Codex 下达一个目标，把一段 GPU 上的矩阵分解代码优化到比基线快一百倍，然后合上电脑去睡觉。第二天早上醒来，它已经自己提交了几百个版本、跑完了上千次性能测试，还留了一份日志，告诉你哪些思路走通了、哪些是死路。这听上去像科幻，但真的有人这么干过，并且在 183 人的比赛里拿到了第 12 名，最终把基线速度提升了 232 倍。

这位开发者叫 Sankalp，参加的是 GPU Mode 联合 Core Automation 举办的「自动研究」主题比赛，题目是优化一个批量 Householder QR 分解的 CUDA 内核。内核优化听起来很硬核，但他写下的复盘里，最有价值的并不是 GPU 那部分数学，而是一套「把 Codex 当自动驾驶用」的方法论。我把其中最通用、也最能迁移到日常任务里的几块拆出来，讲给你听。

什么样的任务，才值得放手让 AI 自主跑#

不是所有任务都适合交给 Codex 连跑十几个小时。Sankalp 能这么干，有一个前提：比赛提供了 popcorn CLI，让 agent 可以自己提交、跑基准、看排行榜，而且反馈是逐 shape 给出的，外加一个总的几何平均耗时。换句话说，存在一个客观、快速、可自动化的「打分器」。

有了打分器，agent 就拥有了一个紧凑的反馈闭环。每一次尝试都能立刻知道「这次变快还是变慢」，于是可以像爬山一样，沿着分数一路往上爬。十四天里，他提交了超过一千五百次。

我自己用 Codex 的体会也印证了这一点：判断一个任务能不能「放养」，先问一句，有没有一个机器能自动判断好坏的「裁判」。有裁判，闭环才成立；没裁判，就得人盯人。

先学到「能问出好问题」，再让它跑#

一个容易被忽略的细节是，Sankalp 在让 Codex 干活之前，自己先把 QR 分解的基础补了一遍，跟 Claude 反复讨论、看视频建立直觉。他的原话我特别喜欢：你对一个东西了解得越深，就越能给模型下好指令，因为你把「未知的未知」变成了「已知的未知」。

这句话点破了一个常见误解。很多人以为让 AI 自主干活，人就可以彻底撒手不管。恰恰相反，你对问题域的理解越深，能喂给模型的方向就越值钱。Sankalp 自嘲是「不被看好的那一个」，他排行榜上面一位是 NVIDIA 的主任工程师，但这不妨碍他靠补课加问对问题，一路追到第 12 名。

领域知识没有因为 AI 而贬值，它只是换了个去处，从「亲手写代码」挪到了「指引方向」。

把 Codex 用满的三个技巧#

真正让 Codex 长时间自主运转的，是三个具体技巧。

第一，用 /goal 给目标。你可以给一个具体、可量化、可达成的数字目标，让模型循环执行，直到达标。Sankalp 的经验是，「数字目标加具体标准」最有效。他举了个例子：只用 Triton 或 CUDA，超过当前最优的 n=512 耗时，多试几个思路，要么直接提交排行榜，要么用 Modal 做 profiling。就这么一段话，让 Codex 连跑了一整天。

第二，用 /btw 或 /side 查岗。这是我最喜欢的一个细节。当 /goal 正在跑的时候，你可以开一个临时线程问它问题，比如「你现在领先了吗」「当前活跃提交用了什么算法」，而不会打断主循环。这等于把「人工盯梢」和「自动执行」解耦了，你能随时了解进度，却不用让它停下来。

第三，用日志做记忆。AGENTS.md、problem_statement.md、log.md，把每一次提交的状态、耗时、成败都记下来。这样未来新开的会话能读日志，快速判断某个想法是不是已经试过了，避免重复踩坑。

最难的一课：学会信任和放手#

Sankalp 反复提到的一个教训是，他总是忍不住频繁查看 agent 的状态，但正确的做法是「相信它，让它干活，只在它卡住时才扶一把」。

他每隔两三个小时才输入一次方向，有些天干脆让它通宵无监督地跑。频繁打断的代价，是破坏模型正在建立的上下文连贯性，等于每次检查都在把它从「心流」里拽出来。真正该做的，是设定好目标、铺好反馈通路，然后退后一步。

逃离局部最优，才是高手与新手的分水岭#

整篇复盘最精彩的部分，是他在 3000 微秒到 1800 微秒这个区间遇到的瓶颈：模型陷入了局部最优，表现为没完没了地微调参数、反复试探同一个思路的小变体。

他给出的解法叫「候选束」（beam of candidates）。过去他犯了一个「蠢错误」：始终只保留一个当前最优解，任何新思路都要先打败它才能留下。但一个大的结构性改动，初期几乎必然跑得更慢，要迭代几轮之后才可能反超。单一最优的爬山法，会把这些「暂时落后但潜力更大」的方向过早淘汰。

于是他把策略改成：同时维护三到五个候选「家族」，允许那些暂时落后、但触动了独立成本的思路继续存活，几轮之后再决定合并还是淘汰。

这个思路有很强的普适性，它解决的其实是「探索与利用」的经典权衡，跟强化学习里「保持多样性」、进化算法里的「种群」是同一个道理。

他还用了几个辅助手段：人肉方向盘（在模型卡住太久时亲自出手转向）、鼓励模型冒险（「说出来你可能不信，这招真的管用」）、用更强的模型当顾问（比如用无头模式调用 Claude 命令行来产生更多样的 idea）。他还观察到一个有意思的差异：Claude 常常跑几轮就放弃，搬出「我们已经穷尽了所有优化」的借口，而 Codex 更倔，更愿意死磕。

我的判断：瓶颈正在从「聪明」转移到「品味」#

Sankalp 有一句观察我很认同。几年前 agent 陷入死循环，是因为不够聪明、知识不够；后来模型变聪明了，又有了强化学习和推理时的思考时间加成；而现在，模型真正卡住的地方，是「想不出新点子」和「研究品味」，也就是在验证器反馈和已有证据面前，下一步最该做什么实验。

这其实给人类重新定了位。在那场比赛里，人不再是写代码的执行者，而是负责提问、设定目标、在关键节点注入方向的「策略师」。当模型的「智商」不再是瓶颈，「知道往哪个方向使劲」这件事，反而成了最稀缺、也最值得人去补的一环。

回到开头那个 232 倍：它当然离不开 blocked Householder、WY 表示、CUDA graph 这些硬核优化，但支撑这一切的，是一套「闭环加好问题加信任加多样性」的工作流。这套东西，你下一次让 Codex 干一件需要反复试错的活时，就能用上。

参考来源：https://sankalp.bearblog.dev/autoresearch/ （Sankalp 的《Auto-research with codex: How I achieved a 232x Faster Kernel over baseline》，本文据此提炼核心方法并加入独立分析）