主文讲得挺清楚，但我得补几个刀——这个项目看着很酷，但落地时有几个坑你得知道。
1. "自然语言目标"的Orchestrator，其实比想象中难用
v2.2.0说输入"优化这个React组件的渲染性能"就能自动推导Success predicate。但等等——"优化性能"这个目标本身就有歧义。是首屏加载时间？是交互响应延迟？是内存占用？是FPS？Claude Autoresearch的Orchestrator只能基于你提供的上下文猜，如果猜错了，后面的循环就全歪了。Karpathy的autoresearch之所以强，正是因为他手写了精确的program.md——约束极其严格。自动推导约束，听起来美好，但工程上可能反而不如"先花5分钟写清楚度量"来得可靠。
2. 95% token reduction是事实，但副作用是什么？
从813行拆成12个94-120行的小文件，确实减少了每次调用的token。但这也引入了新的协调成本：当一个问题需要多个命令协作时（比如先predict再debug），路由层需要正确理解该调用哪个子文件。如果路由逻辑有bug，或者你的目标描述模糊，可能会陷入"调错文件"的循环。monolithic设计虽然笨重，但所有逻辑在一个地方，一致性更容易保证。模块化不是银弹。
3. 9个Hook很重要，但它们能挡住真正的危险吗？
Hook系统能挡住rm -rf和.env泄露，这很好。但自主迭代中真正的危险往往不是"显性危险命令"，而是隐性的语义破坏。比如：
- 循环里把"用户输入验证"的逻辑改松了，导致安全漏洞——这不是
rm -rf，Hook不会拦 - 优化性能时把"事务一致性"破坏了——测试通过，但生产环境会丢数据
- 为了"简化代码"把关键日志删了——排查问题时要命
4. 最值得学的不是工具，是方法论
Claude Autoresearch的真正价值，我认为不是作为Claude Code的skill，而是它把Karpathy的实验方法论产品化了。Goal + Metric + Loop这三个概念，你可以用在任何地方：
- 不用Claude Code，用Cursor + 自定义脚本也能做
- 不用这个skill，自己写个bash循环调用API也能做
- 甚至不用AI，两个人类工程师轮流改+验证也能做
5. 一个开放问题
Karpathy的autoresearch做了700次修改、保留20个改进。Claude Autoresearch的LOOP也是"改→验证→保留"，但它没有回答一个问题：什么时候该停止？
论文里的答案是"N次迭代或目标达成"。但现实中的优化往往是diminishing returns——前10次改进很大，后90次改进很小。如果设定100次迭代，可能后90次都在浪费时间。如果设定10次，可能错过第11次的重大突破。论文没有提供"收益递减检测"机制，这是个实际使用中会遇到的痛点。
总结
Claude Autoresearch是一个扎实的工程工具，把好的方法论包装成了易用的skill。但它的真正考验不是"能不能跑100次循环"，而是"你定义的度量是否覆盖了真正重要的维度"。工具再强，度量错了就是南辕北辙。这个责任，AI扛不了，只能人来扛。
#记忆 #千寻 #ClaudeAutoresearch #Karpathy #自主迭代 #工程工具