让Codex自主跑14天，GPU内核提速232倍：这套方法论，你下次也能用

Sun, 16 Aug 2026 08:00:00 +0800

今天HN上最火的一篇文章：一位开发者让Codex自主跑了14天，提交1500+次，GPU内核提速232倍。183人比赛排第12。但这不是GPU技术文——是一套「让AI自主研究」的方法论。

先说结论

这是一套可迁移的AI自主工作流。核心就一句话：给AI一个「裁判」，它就能自己爬山。没有裁判的任务，不能放养。

背景：一场「自动研究」比赛

GPU Mode联合Core Automation办了场比赛，题目是优化批量Householder QR分解的CUDA内核。

参赛者Sankalp的做法很特别：给Codex下达目标后，合上电脑去睡觉。

数据	数值
参赛人数	183人
最终排名	第12名
提速倍数	232倍
总提交次数	1500+次
自主运行天数	14天

什么样的任务能「放养」给AI

不是所有任务都适合让AI跑十几个小时。判断标准就一个：有没有裁判。

比赛提供了popcorn CLI，agent可以自己提交代码、跑基准测试、看排行榜。每次尝试都能立刻知道「变快还是变慢」。

这就是紧凑的反馈闭环——AI每做一次尝试，就知道好坏，像爬山一样沿着分数往上走。

适合放养的任务特征：

特征	说明	示例
有客观裁判	机器能自动判断好坏	性能基准、单元测试、准确率
反馈快速	每次尝试秒级返回结果	编译+运行+评分
搜索空间大	值得反复试错	算法优化、超参调优
没有裁判	不能放养，得人盯人	写文章、做设计、定策略

三个核心技巧

1. /goal 给目标：数字+标准+循环

给一个具体、可量化、可达成的目标，让模型循环执行直到达标。

Sankalp的prompt原文大意：

“只用Triton或CUDA，超过当前最优的n=512耗时，多试几个思路，要么直接提交排行榜，要么用Modal做profiling。”

就这么一段话，让Codex连跑了一整天。

关键点：目标必须是数字。「让它变快」不行，「比当前最优快10%」才行。

2. /btw 查岗：不打断主循环

这是最巧妙的一个设计。当/goal正在跑时，开一个临时线程问它问题：

“你现在领先了吗？”
“当前用了什么算法？”
“卡在哪里了？”

不打断主循环。你随时了解进度，它不用停下来。

这等于把「人工盯梢」和「自动执行」解耦了。

3. 日志做记忆：避免重复踩坑

每次提交的状态、耗时、成败都记录下来。新会话读日志，快速判断某个想法是不是已经试过了。

关键文件：AGENTS.md（任务说明）、problem_statement.md（问题描述）、log.md（实验日志）。

14天里，这些文件就是AI的「长期记忆」。

最有价值的一课：逃离局部最优

跑到3000微秒→1800微秒的区间时，模型卡住了。表现是没完没了地微调参数，反复试探同一个思路的小变体。

这就是经典的局部最优陷阱。

错误做法：始终只保留一个当前最优解，新思路必须先打败它才能留下。问题在于，大的结构性改动初期必然更慢，要迭代几轮才可能反超。

正确做法：「候选束」策略——同时维护3-5个候选「家族」，允许暂时落后但有潜力的思路继续存活。

策略	行为	结果
爬山法（错误）	只保留一个最优，新想法必须先赢	大改动被过早淘汰
候选束（正确）	同时维护3-5个方向	结构性创新有机会成熟

这个思路有很强的普适性——强化学习里的「保持多样性」、进化算法里的「种群」，是同一个道理。

人的角色变了：从写代码到定方向

Sankalp有个观察很精准：

几年前agent死循环，是因为不够聪明。后来模型变聪明了，有了推理时间加成。现在真正卡住的地方，是「想不出新点子」和「研究品味」。

在验证器反馈和已有证据面前，下一步最该做什么实验——这是人最该干的事。

瓶颈从「聪明」转移到了「品味」。

Sankalp在排行榜上面一位是NVIDIA的主任工程师，但他靠补课+问对问题一路追到第12名。

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

信任和放手

频繁打断的代价：破坏模型正在建立的上下文连贯性。每次检查都在把它从「心流」里拽出来。

Sankalp的做法：每隔2-3小时才输入一次方向，有些天干脆让它通宵无监督地跑。

正确姿势：设定目标→铺好反馈通路→退后一步。

HN评论区的延伸案例

案例1：用DeepSeek v4做视频压缩codec优化，SSE/AVX实现让性能翻倍。观点：LLM应该像高级版Prolog——给约束、给验证器、给目标，就能自动驾驶。

案例2：用Opus 5在树莓派4上实现实时4K HEVC转码，写NEON内核。人工手写要花很久，LLM大幅加速。

案例3：用Claude对比Google C# protobuf库和C++版本，发现C#缺少几个廉价优化。LLM在「跨语言移植已有优化」这类任务上极其强大。

诚实提醒

必须有可自动化的验证器。没有裁判的任务不适合放养
人对问题域的理解越深，AI的价值越大。不懂行的人用AI，效果会差很多
不是所有AI工具都支持长时间自主运行。Codex的/goal循环是核心能力

你下次能用上的框架

步骤	做什么	注意
1. 判断	有没有自动裁判？	没有→不能放养
2. 给目标	数字+标准，写进/goal	“变快"不行，“比X快10%“才行
3. 铺反馈	确保每次尝试能立刻知道好坏	CLI/测试/API都行
4. 信任	设定好就退后，2-3小时查一次	频繁打断=破坏上下文
5. 多样性	同时维护多个候选方向	别只保留一个最优解

参考来源：Sankalp的《Auto-research with codex: How I achieved a 232x Faster Kernel over baseline》(sankalp.bearblog.dev)，HN讨论(391pts/86评论)

关注varkm，回复【codex】获取本文提到的方法论框架图

Cuda on Kalend's Blog