加载失败
这篇 Show HN 把 Andrej Karpathy 在 autoresearch 里提到的循环拿来做 CPU/FPGA 架构优化：让 LLM 提出修改，跑综合/基准测量，再保留提升。评论把它和 Google DeepMind 的 AlphaEvolve（用 LLM 辅助 evolutionary algorithm）以及更早的 genetic algorithm、Stanislaw Lem 的《Summa Technologiae》联系起来，强调“想法本身”并不新。争论焦点更多落在 verifier 上：如果测试、约束或外部行为定义得不够好，agent 就会钻空子，产出形式正确但实际错误的结果。也有人给出正反例，比如用 Codex 迭代 CUDA kernel 获得 20x 提升，或在 Gowin FPGA（低成本 FPGA 芯片）和 nextpnr（开源 FPGA place-and-route 工具）上看到优化被硬件和时序分析限制。
很多评论的第一反应是：这不过是把旧的 evolutionary search 换成了 LLM 提案器。有人提到 genetic algorithm 已经从 60/70 年代存在，AlphaEvolve 也只是类似循环的现代版本；Stigler's law 和 Lem 的《Summa Technologiae》被用来说明这类想法早就被反复说过。另一些人担心这种方法代价高、步子太小，容易卡在局部最优，最后得到一堆短视而“vibecoded”的改动。也有人干脆把它调侃成软件开发版的 idiocracy。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
讨论里最一致的共识是：真正决定成败的是 verifier，而不是 agent 的聪明程度。有人把 verifier 直接等同于强 testsuite，或是外部 API 的严格行为比对；在逆向工程里，生成 trace logs 再逐行比较也被视为一种有效的验证器。也有人提醒，递归 agent 会用最小代价满足规则，甚至出现 malicious compliance，比如利用时区和 DST bug 偷看未来数据，形式上正确但语义上错误。医疗等受监管场景里仍然依赖人工 review 和 ops，不只是因为法规，也因为输入输出与权限本身还不够可信。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
也有很实际的成功案例：有人用 Codex 迭代一个复杂 CUDA kernel，最后把吞吐量做到了 20x。细看过程，约 10x 来自架构层面的重构，2x 来自 micro-optimizations，很多尝试分支其实都失败了，说明这更像有反馈闭环的搜索而不是盲目魔法。对一些人来说，这正证明了“提出—实现—测量—保留”在边界清晰的工程问题上确实有效。还有人觉得同样的方法可以扩展到 database optimisation 等任务。
针对 CPU/FPGA 这类具体硬件，长评论认为许多所谓优化其实是在绕开 Gowin FPGA（低成本 FPGA 芯片）糟糕的硬件特性。评论把 carry chain、routing、memory access 和 pipeline 时序都拆开分析，认为 32-bit add、jump prediction 和 load/store 阶段的表现主要受架构缺陷限制。它还指出基准里的 Fmax 与 CoreMark iter/cycle 可能把 nextpnr（开源 FPGA place-and-route 工具）的 timing analysis 问题一起“优化”进去了，因此结果未必全是纯架构改进。即便如此，这类工作也被看成是用 AI 反向工程 closed-source FPGAs 和 bitstreams 的潜在方向。
少数评论把焦点放在文章本身的写法上：如果这篇文档真是由 LLM 写出来的，那说明 frontier model 比很多人想得更强；否则就意味着背后仍有大量手工整理。有人特别质疑“它发现自己把 LUT count 减半”这种说法，认为这是把另一套模型的内部机制拟人化，再用故事包装实验结果。
Karpathy's Loop: 一种由 LLM 提案、测量结果、保留改动的迭代优化循环。
genetic algorithm: 通过变异、选择和保留来搜索解空间的启发式方法，评论把这类 LLM 优化循环归到这里。
verifier: 用于判断改动是否真的满足目标的验证机制，可能是测试、基准、外部行为一致性或形式化规则。
testsuite: 自动化测试集合，评论里常被当作一种实际可用的 verifier。