看到有人用 Karpathy 的 autoresearch 方法论去优化 AI skill 的 promptpass rate 从 50% 拉到了 90%。说实话看到这个数字的时候我正在手动改 brain-search 这个 skill 的 prompt已经改了四五版了效果一直不稳定。手动调 prompt 这个事吧很像小时候调收音机的天线——你觉得差不多了手一松它又漂了。看到 autoresearch 这个思路之后我就停下来研究了一下然后花了一个下午用 Claude Code 写了一个开源的 prompt 优化器。Karpathy 和 Lehmann 的 Repo先说两个已有的项目。Karpathy 的 autoresearch53,600 stars解决的是 ML 训练的问题让 AI agent 在一个死循环里不断改训练代码、跑实验、看 loss 降没降——降了保留没降回滚。说白了就是把人盯着指标改代码这个苦力活自动化了。Ole Lehmann 的 autoresearch-skill555 stars把这个模式搬到了 Claude Code 的 skill prompt 上。整个仓库就 2 个文件SKILL.md和eval-guide.md。让 Claude Code 自己读 prompt、跑 eval、改 prompt、再跑循环往复。两者的共性其实很像生物进化——假设、变异、测试、保留或淘汰。只不过一个优化的是训练代码一个优化的是 prompt 文本。我想做的方向和 Lehmann 一样但有几个地方不满足我不想盯着。Lehmann 的方案要和 Claude Code 持续对话人得在旁边看着。我想写完 eval 定义就放着跑。我日常用 MiniMax偶尔用 OpenAI 和 Anthropic不想绑死在某一家。得兼容 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正则用reJSON 用json。不需要装任何包拿过来就能跑。不管是 OpenClaw 容器里的 Python 3.11 还是本地的 3.12直接用。三个 Agent 并行写代码写代码的过程比较有意思。我没有线性地从头写到尾而是让 Claude Code 同时起了 3 个 agent 并行干活Agent 1 写SKILL.mdskill 的元信息和使用说明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 checkword_count规则没考虑中文字符直接用空格 split 会把一整段中文算成 1 个 wordeval.json 既支持values列表又支持value字符串但解析时只处理了列表这些在第一次运行之前就被修掉了。从看到那篇公众号文章到git push整个过程不到 2 小时。拿 brain-search 跑了一下37.5% - 54.2%光写出来不行得拿真实 skill 验证。我选了自己知识系统里的 brain-search。它的功能是接收搜索请求调 Brave Search API返回结构化的搜索结果摘要。问题是输出一直不太稳定——有时候有来源链接有时候没有结构有时候清晰有时候一坨中文查询偶尔还会混入英文回复。写了 4 条 eval中英文各半的 test input跑起来。Baseline实验 037.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_tokens16判断结果就是一个 YES 或 NO 嘛结果 thinking 先把 16 个 token 全用完了text block 里什么都没有。脚本拿到的返回值是空字符串既不是 YES 也不是 NO所有 LLM eval 全部 FAIL。我当时看着满屏的 FAIL 还以为是 prompt 写得太烂了……# 修复前max_tokens16thinking 占满预算resp self.provider.call(system, userprompt, temperature0.0, max_tokens16)# 修复后max_tokens256并且增加 thinking 内容的 fallbackresp self.provider.call(system, userprompt, temperature0.0, max_tokens256)改了两个地方一是 max_tokens 从 16 提到 256thinking 和 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%免费】
写一个 Skill 来优化所有 Skill —— autoresearch 的 Prompt 工程实践
发布时间：2026/5/19 1:35:42
看到有人用 Karpathy 的 autoresearch 方法论去优化 AI skill 的 promptpass rate 从 50% 拉到了 90%。说实话看到这个数字的时候我正在手动改 brain-search 这个 skill 的 prompt已经改了四五版了效果一直不稳定。手动调 prompt 这个事吧很像小时候调收音机的天线——你觉得差不多了手一松它又漂了。看到 autoresearch 这个思路之后我就停下来研究了一下然后花了一个下午用 Claude Code 写了一个开源的 prompt 优化器。Karpathy 和 Lehmann 的 Repo先说两个已有的项目。Karpathy 的 autoresearch53,600 stars解决的是 ML 训练的问题让 AI agent 在一个死循环里不断改训练代码、跑实验、看 loss 降没降——降了保留没降回滚。说白了就是把人盯着指标改代码这个苦力活自动化了。Ole Lehmann 的 autoresearch-skill555 stars把这个模式搬到了 Claude Code 的 skill prompt 上。整个仓库就 2 个文件SKILL.md和eval-guide.md。让 Claude Code 自己读 prompt、跑 eval、改 prompt、再跑循环往复。两者的共性其实很像生物进化——假设、变异、测试、保留或淘汰。只不过一个优化的是训练代码一个优化的是 prompt 文本。我想做的方向和 Lehmann 一样但有几个地方不满足我不想盯着。Lehmann 的方案要和 Claude Code 持续对话人得在旁边看着。我想写完 eval 定义就放着跑。我日常用 MiniMax偶尔用 OpenAI 和 Anthropic不想绑死在某一家。得兼容 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正则用reJSON 用json。不需要装任何包拿过来就能跑。不管是 OpenClaw 容器里的 Python 3.11 还是本地的 3.12直接用。三个 Agent 并行写代码写代码的过程比较有意思。我没有线性地从头写到尾而是让 Claude Code 同时起了 3 个 agent 并行干活Agent 1 写SKILL.mdskill 的元信息和使用说明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 checkword_count规则没考虑中文字符直接用空格 split 会把一整段中文算成 1 个 wordeval.json 既支持values列表又支持value字符串但解析时只处理了列表这些在第一次运行之前就被修掉了。从看到那篇公众号文章到git push整个过程不到 2 小时。拿 brain-search 跑了一下37.5% - 54.2%光写出来不行得拿真实 skill 验证。我选了自己知识系统里的 brain-search。它的功能是接收搜索请求调 Brave Search API返回结构化的搜索结果摘要。问题是输出一直不太稳定——有时候有来源链接有时候没有结构有时候清晰有时候一坨中文查询偶尔还会混入英文回复。写了 4 条 eval中英文各半的 test input跑起来。Baseline实验 037.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_tokens16判断结果就是一个 YES 或 NO 嘛结果 thinking 先把 16 个 token 全用完了text block 里什么都没有。脚本拿到的返回值是空字符串既不是 YES 也不是 NO所有 LLM eval 全部 FAIL。我当时看着满屏的 FAIL 还以为是 prompt 写得太烂了……# 修复前max_tokens16thinking 占满预算resp self.provider.call(system, userprompt, temperature0.0, max_tokens16)# 修复后max_tokens256并且增加 thinking 内容的 fallbackresp self.provider.call(system, userprompt, temperature0.0, max_tokens256)改了两个地方一是 max_tokens 从 16 提到 256thinking 和 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%免费】
