看到有人用 Karpathy 的 autoresearch 方法论去优化 AI skill 的 prompt，pass rate 从 50% 拉到了 90%。

说实话，看到这个数字的时候我正在手动改 brain-search 这个 skill 的 prompt，已经改了四五版了，效果一直不稳定。手动调 prompt 这个事吧，很像小时候调收音机的天线——你觉得差不多了，手一松它又漂了。看到 autoresearch 这个思路之后我就停下来研究了一下，然后花了一个下午用 Claude Code 写了一个开源的 prompt 优化器。

Karpathy 和 Lehmann 的 Repo

先说两个已有的项目。

Karpathy 的 autoresearch（53,600+ stars）解决的是 ML 训练的问题：让 AI agent 在一个死循环里不断改训练代码、跑实验、看 loss 降没降——降了保留，没降回滚。说白了就是把"人盯着指标改代码"这个苦力活自动化了。

Ole Lehmann 的 autoresearch-skill（555 stars）把这个模式搬到了 Claude Code 的 skill prompt 上。整个仓库就 2 个文件：SKILL.md 和 eval-guide.md。让 Claude Code 自己读 prompt、跑 eval、改 prompt、再跑，循环往复。

两者的共性其实很像生物进化——假设、变异、测试、保留或淘汰。只不过一个优化的是训练代码，一个优化的是 prompt 文本。

我想做的方向和 Lehmann 一样，但有几个地方不满足：

1. 我不想盯着。Lehmann 的方案要和 Claude Code 持续对话，人得在旁边看着。我想写完 eval 定义就放着跑。
2. 我日常用 MiniMax，偶尔用 OpenAI 和 Anthropic，不想绑死在某一家。
3. 得兼容 OpenClaw 的 skill 格式，同时也能给 Claude Code、Cursor、Cline 用。

怎么做的

最终有两个核心的设计决定。

脚本驱动，不是对话驱动。 整个优化器就是一个 Python 脚本 autoresearch.py，命令行参数传进去目标 skill 文件和 eval 定义，自己跑完整个循环。agent 只需要调一次脚本就行，不用来回聊天。

python autoresearch.py \--target skills/brain-search/SKILL.md \--evals eval.json \--provider minimax \  --max-experiments 10

混合 eval。 eval 分两类——rule-based 和 LLM-as-judge。rule-based 用正则、关键词匹配、字数检查，结果确定、零成本。LLM eval 负责规则搞不定的语义判断，比如"输出是否准确反映了搜索结果"。

为什么要混合？我觉得这个很像考试出题——选择题（规则）改卷快、分数稳定，但有些东西你只能用主观题（LLM）来测。问题是主观题阅卷有波动，同一份答卷换个老师可能换个分数。所以能出选择题的地方就出选择题，把主观题留给真正需要的场景。

一个 eval.json 的例子，一条 rule 检查是否包含 URL，一条 LLM 判断输出是否有清晰结构：

{
"test_inputs": ["search for latest AI agent frameworks"],
"evals": [
{
"name": "has_source_url",
"type": "rule",
"rule": "regex",
"pattern": "https?://[^\\s]+"
},
{
"name": "clear_structure",
"type": "llm",
"question": "Is the output organized with headers, bullets, or numbered lists?",
"pass_description": "Output uses clear visual structure for easy scanning",
"fail_description": "Output is a wall of text without structure"
}
]
}

还有一个决定是零外部依赖——整个脚本只用 Python 标准库。HTTP 用 urllib，正则用 re，JSON 用 json。不需要装任何包，拿过来就能跑。不管是 OpenClaw 容器里的 Python 3.11 还是本地的 3.12，直接用。

三个 Agent 并行写代码

写代码的过程比较有意思。我没有线性地从头写到尾，而是让 Claude Code 同时起了 3 个 agent 并行干活：

• Agent 1 写 SKILL.md（skill 的元信息和使用说明）
• Agent 2 写 autoresearch.py（核心脚本，LLM provider、eval runner、实验循环）
• Agent 3 写 eval-guide.md 和 examples/ 目录下的示例 eval 文件

三个 agent 之间有自然的接口约定（eval.json 的 schema、命令行参数格式），并行写问题不大。写完之后又让一个 code-reviewer agent 做了一轮审查。

这轮审查发现了 7 个 bug，印象比较深的几个：

• LLM provider 的自动检测逻辑在找不到任何 API key 时会返回 None，但后续代码没有 null check

• word_count

  规则没考虑中文字符，直接用空格 split 会把一整段中文算成 1 个 word

• eval.json 既支持 values（列表）又支持 value（字符串），但解析时只处理了列表

这些在第一次运行之前就被修掉了。从看到那篇公众号文章到 git push，整个过程不到 2 小时。

拿 brain-search 跑了一下：37.5% -> 54.2%

光写出来不行，得拿真实 skill 验证。

我选了自己知识系统里的 brain-search。它的功能是接收搜索请求，调 Brave Search API，返回结构化的搜索结果摘要。问题是输出一直不太稳定——有时候有来源链接有时候没有，结构有时候清晰有时候一坨，中文查询偶尔还会混入英文回复。

写了 4 条 eval，中英文各半的 test input，跑起来。

Baseline（实验 0）：37.5% pass rate。

这个数字比我预期的低…… 仔细看 eval 细节，主要是来源 URL 的引用格式不一致（有时候有、有时候没有），以及 LLM judge 认为结构不够清晰。

实验 1-2：分数上升。 优化器分析了 baseline 的失败项，发现两个主要问题——缺少来源 URL 引用和输出缺乏结构。它自动在 SKILL.md 的 Procedure 部分添加了两条指令：一是要求每条搜索结果必须附带原始 URL（不是笼统的"注明来源"，而是给了具体的引用格式模板），二是要求用 markdown 列表组织输出。这两个改动被保留了，pass rate 提升到了 54.2%。

实验 3-5：全部回滚。 这是 autoresearch 的经典行为——容易的改进先被找到，后面的变异越来越"大胆"（比如重写整个 Procedure），效果反而变差。实验 3 试图加入"必须用中文回答中文查询"的硬性规则，结果英文查询的质量反而下降了。实验 4 和 5 做了更激进的结构性改动，分数都没超过 54.2%，全部被丢弃。

37.5% 到 54.2% 不算惊艳，但有意思的是那两个被保留的改动（URL 引用格式 + 结构化输出模板）——我之前手动调的时候一直在纠结"语气"和"详细程度"这些模糊的东西，而优化器直接瞄准了 eval 里最具体的失败项。人调 prompt 容易陷入"感觉差不多了"的陷阱，机器不会。

MiniMax 的 thinking 块，折腾了好一会儿

最折腾的一个 bug 出在 MiniMax M2.7 的 API 上。

MiniMax 支持 extended thinking——在给出最终答案之前先"想"一段。API 返回的 content 数组里会有 {"type": "thinking", "thinking": "..."} 和 {"type": "text", "text": "..."} 两种 block。

问题在于 thinking 块会消耗 max_tokens 预算。我最初给 LLM judge 调用设的 max_tokens=16（判断结果就是一个 YES 或 NO 嘛），结果 thinking 先把 16 个 token 全用完了，text block 里什么都没有。脚本拿到的返回值是空字符串，既不是 YES 也不是 NO，所有 LLM eval 全部 FAIL。

我当时看着满屏的 FAIL 还以为是 prompt 写得太烂了……

# 修复前：max_tokens=16，thinking 占满预算resp = self.provider.call(system="", user=prompt,                          temperature=0.0, max_tokens=16)# 修复后：max_tokens=256，并且增加 thinking 内容的 fallbackresp = self.provider.call(system="", user=prompt,                          temperature=0.0, max_tokens=256)

改了两个地方：一是 max_tokens 从 16 提到 256（thinking 和 answer 加起来肯定够），二是在 _extract_text 方法里加了 fallback 逻辑——如果没有 text block，就从 thinking block 里找 YES/NO。后者是保险措施，提高 max_tokens 之后实际上不会触发了。

这个 bug 在 OpenAI 和 Anthropic 上都不会出现，因为它们要么不返回 thinking block，要么 thinking 不占 max_tokens 预算。MiniMax 用的是 Anthropic 兼容协议但行为有区别，不看文档很难发现。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】