今天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】获取本文提到的方法论框架图