AI 进化 AI：从 Loopy Era 到把 Skill 成功率从 56% 拉到 92%

我们正在进入一个很实在的新阶段：AI 的价值不再是“替我写一段内容”，而是“替我把系统持续跑起来，并且把系统越跑越好”。这不是口号，而是一种正在成形的工程范式。

我最近看的两篇材料，刚好把这件事讲透了：一篇是 Karpathy 在访谈里谈到的 Loopy Era、Code Agents 与 AutoResearch；另一篇则把 autoresearch 的方法迁移到 OpenClaw/龙虾的 skill 优化上，用一套评估—迭代机制，把成功率从 56% 拉到 92%。两篇合起来，给了我一个非常明确的结论：AI 进化 AI 的关键，不在“更会生成”，而在“更可验证、更可复现、更可持续迭代”。

1）Loopy Era：从“写代码”变成“表达意志 + 调度并行 agent”

Karpathy 提到一个工作方式的翻转：过去你以为自己在“写代码”，现在更接近于“向 agent 表达意志”。这背后不是情绪化的夸张，而是生产方式的变化：

• 写代码的动作在减少：不是手写一行行实现，而是把一个功能拆成任务，交给 agent 去跑。
• 并行化成为默认：不再是开一个 session 等它结束，而是多个 agent 同时工作：有人做 research，有人改代码，有人写计划，有人做测试，你负责分派与 review。
• 瓶颈从算力变成你自己：当你能调动足够多的 token 吞吐量时，系统产出上限更常由“你能不能把任务拆对、讲清楚、验收好”决定。

Loopy 的核心含义是：你不再把一次交互当成一次性完成，而是在构建一个循环系统，让工作持续自动发生。

2）AutoResearch：把“凭感觉改”变成“可重复实验”

第二篇文章最有价值的不是“把成功率拉高了”，而是把“优化 skill”这件事从玄学变成实验。

它把常见的优化方式（看起来不行→凭经验改 prompt/流程→再跑一次）改造成一个可重复的循环：

1. 先跑基线（当前成功率/通过率是多少）
2. 每次只改一个小点
3. 用一套 eval 规则打分
4. 提升就保留，变差就撤回
5. 重复，直到稳定

真正的难点在 eval。文章给了一个很硬的原则：每一条 eval 都必须是 yes/no 二元判断。不要量表、不要“看起来更自然”这种感觉题。原因很简单：量表会叠加波动，主观题会制造假信心，而二元题才能给稳定信号。

同时还有三个非常务实的约束：

• eval 建议 3~6 条：太少约束不足，太多会让系统“刷题钻空子”
• eval 要可检查：两个不同的 agent 面对同一输出，应该能打出一致结论
• 最值钱的不是最终版本，而是 changelog（进化路径）：改了什么、为什么、有没有提升、哪些尝试无效——这份“可验证的演化史”未来迁移模型/迁移平台时会直接复用

这套方法论把一句话说透了：让 AI 优化 AI 的前提，是你能把“好”写成可验证的规则。

3）两篇合起来：AI 进化 AI 的分水岭是“能不能跑闭环”

把 Loopy Era 的宏观判断和 skill 优化的微观方法放在一起，我得到一个更清晰的判断：接下来真正拉开差距的，不是谁生成得更漂亮，而是谁能把系统做成闭环。

所谓闭环，至少意味着四件事：

• 有清晰目标（要优化什么）
• 有可执行的评估（怎么判定是否变好）
• 有小步迭代机制（一次只改一个点，避免不可控波动）
• 有可回放的演化记录（changelog，知道自己为什么变好）

从这个角度看，“56%→92%”这种数字非常关键：它不是炫技，而是意味着系统开始具备工程可靠性；而可靠性，才是从“演示”走向“生产”的门槛。

4）一个可直接照抄的行动模板

如果要把某个高频 skill 变得稳定，我会按下面做：

1. 选一组典型输入（覆盖常见与最容易翻车的边缘情况）
2. 写 3~6 条 yes/no eval（尽量可检查、可计数、可回归）
3. 跑基线并记录失败类型
4. 每轮只改一个点 → 回归测试 → 提升则保留，否则撤回
5. 连续多轮稳定通过才算结束
6. 保留 changelog（这是长期资产）

一句话：只要一个东西会被反复调用，它就值得被反复测试；只要能被反复测试，它就值得交给 agent 自动优化。