我是一名技术文档工程师,每天和文档仓库、Markdown 文件、API 参考、风格指南和 SEO 审查打交道。我不训练语言模型,也不写 CUDA 内核。但当 Andrej Karpathy 发布他的 autoresearch 项目时,我脑子里就停不下来了。

相关代码仓库:GitHub 链接
这个想法简单得令人惊叹:
让 AI Agent 自主运行实验,测量结果,保留有效的,丢弃无效的,不断循环,直到效果足够好。Karpathy 用它来训练一个小型 GPT 模型。Agent 会修改训练代码,运行 5 分钟,检查模型是否有改善,然后决定——保留还是回退。再尝试下一个方向。如此循环往复,完全自主运行,就在他睡觉的时候。
我读着这个仓库,心想:这不是给我用的。
我不知道如何把它应用到我的工作领域——还没想到。
[备注:Andrej Karpathy 大约在 2026 年 3 月 8-9 日发布了开源项目 autoresearch]
Karpathy 仓库公开几天后,我偶然看到一个 YouTube 视频,彻底改变了我对它的理解。这位创作者(Nick Saraev)将 Karpathy 的模式完整地应用到了一个截然不同的场景:为生成白板风格图表的文生图提示词做优化。
视频发布于 2026 年 3 月 14 日。
他的方案非常优雅:
- 被优化的对象:发送给 Gemini 图像生成模型的提示词
- 度量标准:用 Claude Vision API 对每张生成图表按 4 个二元标准打分
- 循环:生成 10 张图表,打分,若得分更高则保留提示词,根据失败项改写提示词,每 2 分钟循环一次
他的 4 个评判标准极简:
- 所有文字是否清晰可读且语法正确?是/否
- 颜色是否为柔和的粉彩色?是/否
- 布局是否为线性(从左到右或从上到下)?是/否
- 是否包含任何数字或序数?是/否
10 张图表,每张 4 个问题,最高分 40 分。起点是 32/40,到第 6 轮——大约 12 分钟后——他达到了 40/40 的满分。
打动我的不是那些图表,而是一个顿悟:所需的三个要素——一个客观指标、一个自动化评测工具、以及一个可修改的对象——恰好完美对应到了提示词优化:
train.py(被修改的代码)
prompt.txt(被修改的提示词)
val_bpb(客观数值) 满分 40 分的评测得分
evaluate_bpb()(自动测试) Claude Vision 按是/否标准打分 Git 保留/回退 保留**提示词/回退到最优版本
映射完美。如果它适用于图表生成,就可以适用于任何有可测量输出的场景——包括技术文档。
我决定把它构建出来。不只是用于图表,而是用于一切:一个通用的 autoresearch Skill,能适应任何仓库、任何技术栈、任何优化目标。
我打开 Cursor,拉来 Karpathy 的仓库,读了三个关键文件(program.md、train.py、prepare.py),重温了视频,然后开始提示词编写。
我首先让 AI 深入理解这个模式——不是"仓库里有什么文件",而是实际机制:循环、保留/丢弃逻辑、变异步骤、为什么二元评估有效、为什么要从**提示词而非最近失败的提示词进行变异。
然后我说:给我构建一个适用于任何仓库的 Skill。
v1 Skill 包含 5 个阶段:
- 仓库探索 — 扫描代码库,识别语言、框架、用途
- 优化目标建议 — 根据扫描结果,推荐可优化点(测试质量、文档完整性、可访问性、SQL 模式——任何适合仓库的方向)
- 指标定义 — 根据行业**实践自动生成 4–6 个二元是/否评判标准
- 基线测量 — 运行一次提示词以建立起点分数
- autoresearch 循环 — 生成、评估、打分、保留/丢弃、变异、自主循环
它能用,但有缺陷。
我让 v1 Skill 经历了严苛的分析。以下是我在 v1 中遗漏的问题:
“变异策略描述不清。” 让 Agent "分析失败并改写提示词"太含糊了。修复:定义 6 个明确的变异算子——添加约束、添加负面示例、重构提示词、收紧模糊语言、去除冗余、添加反例。轮流使用,这样每种都能被尝试到,并记录使用了哪种,以便观察哪类变异最有效。
“没有验证集。” 每次循环随机选取不同样本,分数的变化可能反映的是样本难度差异而非提示词质量。修复:指定 3–5 个固定样本,每次循环都包含,用于苹果对苹果的比较;其余样本轮换以保证覆盖面。
“评测步骤混淆了生成者和评判者。” Claude 编写了提示词,用它生成了输出,然后在同一段对话中评判那些输出。评测时它已经知道输出"想要实现什么",会给出偏袒的分数。修复:隔离评测,只呈现原始输出和标准文本,不提供提示词上下文,像第一次见到它一样评判。
“没有处理上下文窗口限制。” 超过 20 次循环后,对话变得极长,早期循环的细节会消失,而依赖理解失败模式的变异步骤会悄悄退化。修复:在每次循环开始时从磁盘重新读取所有状态。文件是唯一可信来源,而非会话记忆。
“没有追踪样本覆盖情况。” "轮换样本"但没有记忆,可能运行了 20 次循环却从未碰到某个特定文件。修复:在 state.json 中追踪已采样的项目,优先处理未测试的项目,覆盖全部后再重复。
每条批评都带来了具体的针对性修复,Skill 在每一轮中都更加精炼。
这个经过迭代的 Skill 拥有原始图表 Skill 从未有过的功能:
- 隔离评测 — 输出在不知道生成它的提示词的情况下被评判
- 验证集 — 固定样本用于一致比较,轮换样本用于覆盖
- 结构化变异算子 — 6 种命名策略,轮流使用并记录日志
- 样本追踪 — 覆盖优先选择,不留意外空白
- 上下文窗口管理 — 每次循环从磁盘重新读取状态
- 命令评测 — 使用 shell 命令进行确定性检查(lint、编译、grep)配合 LLM 判断
- 逐条目失败检测 — 标记总是失败的条目(损坏的条目,而非糟糕的提示词)
- 对抗性重评 — 每次循环用怀疑性提示重新检查通过的输出
- 标准健康检查 — 在第 10 次运行时,标记过于简单或过于困难的标准
- 平台期突破器 — 连续 5 次无进展后,完全丢弃提示词结构,仅根据标准和失败历史从零写一个新的
- 置信度边距 — 防止小批次上的噪声被误判为进展
- 计划模式启动 — 在接触任何内容之前以只读方式扫描和规划
作为一名技术文档工程师,让我具体演示这个 Skill 如何在文档仓库上工作。假设我有一个用 Docusaurus 构建的文档站点,想要改善所有页面的 SEO 合规性。
启动方式:
对我的文档运行 autoresearch 来优化 SEO
阶段 1 — Agent 扫描:
仓库:my-product-docs 技术栈:Markdown、MDX、Docusaurus、Node.js 用途:SaaS API 产品技术文档站 发现的质量工具:markdownlint、broken-link-checker、Docusaurus 构建
阶段 3 — Agent 定义评判标准(8 页 × 5 条 = 最高 40 分):
- 页面是否有唯一且描述性的
(60 字符以内)?是/否 — 命令检测 - 页面是否有 120-160 字符的 meta description?是/否 — 命令检测
- 页面是否恰好使用了一个 H1 标题?是/否 — 命令检测
- 所有图片是否有描述性 alt 文本(非空、非"image"、非"screenshot")?是/否 — LLM 判断
- 页面是否包含至少 2 个其他文档页面的内链?是/否 — LLM 判断
阶段 4 — 基线建立:
Agent 创建 .autoresearch/ 并写入初始提示词,基线分数:24/40
数据分解:
- 标题在 60 字符以内:7/8
- Meta description:4/8(许多页面缺失或过短)
- 单一 H1:8/8
- Alt 文本:3/8(大多数图片用了通用"screenshot")
- 内链:2/8(大多数页面是孤立的)
循环运行过程:
- 第 2 轮 — 变异:添加约束。添加"Meta descriptions 必须在 120–160 字符之间。如果页面讨论 API 端点,描述必须包含 HTTP 方法和路径。"分数:28/40。保留。
- 第 4 轮 — 变异:添加负面示例。添加"不要使用 ‘image’、‘screenshot’、‘diagram’、‘figure’ 等通用 alt 文本,而应描述图片展示的内容。"分数:31/40。保留。
- 第 6 轮 — 变异:收紧语言。分数:35/40。保留。
- 第 9 轮 — 变异:添加反例,对比糟糕和良好的 meta description 示例。分数:38/40。保留。
- 第 12 轮 — 分数:40/40。保留。第 13 轮、第 14 轮也是 40/40。三次连续满分,循环停止。
最终结果:
AUTORESEARCH 完成 运行次数:14 起始分数:24/40 最终最优分数:40/40 提升幅度:66.7% 最有效的变异算子: 1. add_counterexample(2/2 保留 — 100%) 2. tighten_language(2/3 保留 — 67%) 3. add_constraint(1/2 保留 — 50%)
**提示词保存在 .autoresearch/best_prompt.txt 中,完整历史在 .autoresearch/results.jsonl。
我是一名技术文档工程师,没有创业,没有训练模型。我从一位最受尊敬的 AI 研究者那里拿到了一个想法,看了一个 YouTuber 如何从 ML 训练转化到提示词优化,然后把它"氛围编程"成我自己工作中可用的工具——文档 SEO、风格指南合规、内容质量、API 参考完整性。
这个 Skill 可能还不完美,它会继续演进。但架构是可靠的:扫描、建议、定义指标、运行循环、保留赢家、丢弃输家。
如果你在读这篇文章并想到"我可以把这个用到[我的场景]"——你是对的。这正是重点。这个 Skill 是通用的,因为这个模式是通用的。生成、评估、保留最好的、再试一次。
让我至今仍感到惊叹的是:我没有手写 Skill 中的任何一行。我用自然语言描述了我想要什么,让 AI 构建它,经过两轮批评并整合修复——全在一次对话中完成。AI 写了 Skill,AI 评审了 Skill,AI 修复了 Skill。而现在这个 Skill 本身也在用 AI 来优化 AI 生成的输出。
发布 v1 的第二天,我用它在真实项目上跑了一次——优化产品文档的 SEO 前置信息(front matter)。然后我直接撞上了一个由 Skill 设计本身制造的问题。
出了什么问题
当我说"优化文档 SEO"时,Agent 生成的初始提示词东一榔头西一棒子——标题、alt 文本、内链、meta description、可读性、关键词密度,所有和 SEO 沾边的都往里塞。我不想要这些,我只想专注于前置信息,针对我们特定的产品文档。但 Skill 没有办法捕获这种细化程度,它拿着我模糊的目标就跑出了各个方向。
根本原因:阶段 2 只问"要改善什么",从不问"要专注哪个部分",也不问"有什么约束"。
做了哪些改变
1. 三字段优化模板
阶段 2 现在先展示一个空白模板:
目标:_______________(你想改善什么?选可测量的东西。) 范围:_______________(哪个具体部分?缩小范围让提示词保持聚焦。) 背景:_______________(任何约束、惯例或产品特定细节。)
2. 以用户为先的流程
旧的阶段 2 直接生成建议让用户选择。新流程反过来:先展示空白模板问"你今天想优化什么",如果用户说"推荐一些",才生成建议。
3. 通用质量维度替代硬编码示例
新版本用 9 个通用质量维度替代了原来 6 个硬编码的仓库类型示例:
- 正确性、测试覆盖、性能、安全性、可维护性、可观察性、可靠性、开发者体验、合规与标准
4. "你的想法"作为显式选项
当 Agent 生成建议时,最后一项始终是"你的想法——用你自己的话描述任何优化目标",这个之前藏在一个容易错过的脚注里,现在作为一等选项出现在列表中。
5. 范围和背景在循环中持久存在
state.json 现在同时存储 scope 和 context 以及 target,使 Agent 在每次循环开始从磁盘重新读取状态时(它必须这样做——对话记忆不可靠),能掌握用户请求的完整画面。
Skill 文件在以下仓库中:
- Cursor 版本:复制到
~/.cursor/skills/autoresearch-universal/SKILL.md - Claude Code 版本:复制到
~/.claude/skills/autoresearch-universal/SKILL.md
打开任意仓库,切换到 Plan 模式,说"run autoresearch",看看会发生什么。
如果你是技术文档工程师,从文档 SEO 开始。如果你是前端开发者,从可访问性开始。如果你是后端工程师,从测试用例质量开始。
Skill 不在乎你在优化什么,它只在乎你能用是或否来度量它。
如果这篇内容对你有启发,欢迎关注「AI拉呱」,获取更多 AI 前沿洞察、实战教程与趋势解读。
下期将继续带来该主题的进阶拆解与实操案例,建议先收藏本文,避免错过更新。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/263431.html