为什么弱模型也能执行对？improve计划模板的三大核心设计原理
【免费下载链接】improveUse your most capable model to audit your codebase and write plans for cheaper models to execute.项目地址: https://gitcode.com/gh_mirrors/imp/improve
improve 是一个开源的 AI 代码审计技能：它用最强的大模型审计代码库、写出"自包含"的实现计划，再交给更便宜、更弱的模型去执行。本文将拆解 improve 计划模板背后的三大核心设计原理，帮你理解弱模型为什么也能把事做对。
🔍 先记住一句话：计划才是产品本身。模型强弱只是表象，真正决定执行成败的，是计划的质量。
you → /improve (expensive model, advises) plans/ → 001-fix-n-plus-one.md (self-contained specs) other agent → implements, tests, ships (cheap model, executes)一、弱模型为什么会执行错？先看清"短板"在哪
在 skills/improve/references/plan-template.md 的开头，作者对执行者模型做了非常诚实的假设：
假设它擅长遵循明确指令，但不擅长填补空白、从歧义中恢复，以及判断什么时候该停下来。
翻译一下就是：弱模型不是不聪明，而是有三个致命短板：
| 短板 | 典型翻车现场 |
|---|---|
| 缺上下文 | "按上面讨论的模式写"——它根本没看上面的讨论 |
| 靠猜填补空白 | 指令含糊时自由发挥，改出一堆计划外的代码 |
| 不知道何时停 | 发现现实和计划对不上，硬着头皮继续"创造性"修复 |
所以 improve 的设计思路很反直觉：不去责怪模型，而是把"智能"前置。理解代码库、判断值不值得做、写规格说明——这些"智能会复利"的部分交给最强模型；执行交给便宜模型。
二、原理一：自包含上下文——执行者永远不需要"回忆"
模板的第一条铁律：每个计划必须完全自包含。计划里禁止出现"如上所述""参见审计报告"这类字样——因为执行者从未见过顾问会话，没见过审计过程，也没见过其他计划。
一个真实例子：仓库里的 examples/001-extract-shadow-config-resolution.md 计划，把以下信息全部内联进了文件：
- ✅ 涉及的每个文件的准确路径，以及它的作用（一句话说明）
- ✅当前状态的代码摘录（带
file:line行号标记），让执行者能确认自己看对了地方 - ✅ 仓库的代码规范，并指向一个"样板文件"照着写
- ✅ 经过实地验证的命令表（安装、测试、Lint），而不是拍脑袋猜的
给团队写计划的启发：把你的"口头共识"写进文档。凡是执行者需要靠"记得"才能完成的信息，都等于计划写废了一半。
三、原理二：验证门槛——用"命令"替代"判断"
弱模型最弱的地方是"自我评价"。问它"改好了吗"，它大概率会说"好了"。
improve 的解法是：每一步都以一条命令 + 预期输出收尾。执行者不需要判断自己是否成功，只需要跑命令、对结果。
比如示例计划里的每一步都长这样：
Verify:
pnpm shadcn:test→ 全部通过，包括新增的 4 个测试
而"完成标准"（Done criteria）更是全部写成机器可检查的清单：
- 某条命令退出码为 0
- 某次
grep不再匹配任何内容 git status确认没有改动范围外的文件
对比一下两种写法，差距一目了然：
| ❌ 弱模型友好的反面 | ✅ improve 的写法 |
|---|---|
| "确保功能正常工作" | pnpm typecheck退出码为 0 |
| "把重复逻辑抽出来" | grep -rn "旧模式" src/无匹配 |
为什么这能让弱模型执行对？因为"判断对不对"被外包给了确定性工具。执行者从"决策者"降级成了"操作员"——而操作员恰好是弱模型最擅长的角色。
四、原理三：硬边界与 STOP 条件——教会模型"什么时候该停"
这是最体现设计功力的一条。弱模型在计划与现实不符时最危险：它会自由发挥。improve 干脆把"停止"写进计划里。
每个计划都包含两块内容：
1. 明确的范围边界
- 范围内（唯一允许修改的文件）：逐一列出
- 范围外（看起来相关但千万别碰）：逐一列出，甚至解释"为什么不碰"
示例计划里就专门写了一条：init.ts虽然处理配置，但它走的是交互式流程，不属于本次重复逻辑的范畴——不要碰。
2. STOP 条件（逃生舱）
"如果出现 X，停下来上报，不要自由发挥。"
典型 STOP 条件包括：
- 当前代码与计划里的摘录对不上（代码库在计划写就之后发生了漂移）
- 某一步的验证在合理修复尝试后仍然失败两次
- 修复需要触碰范围外的文件
计划还会在头部盖上 git 提交号的"印章"，执行者开工前先跑一次机械的漂移检查——发现代码变了就触发 STOP，而不是硬执行一份过期的计划。
五、快速上手：三步把计划交给便宜模型
🚀 安装只需一行命令（支持 Agent Skills 格式的任意 agent 均可）：
npx skills add shadcn/improve典型使用流程：
- 在仓库中运行
/improve，强模型完成侦察、审计、复核，产出发现表格 - 你挑选要立计划的条目，计划落入
plans/目录，每份一个自包含文件 - 运行
/improve execute 001：它派一个更便宜的执行模型在隔离的 git worktree 里执行计划，然后像技术负责人一样审查 diff，给出"通过 / 打回修改 / 阻断"的裁决——合并与否，永远由你决定
完整流程定义见 skills/improve/SKILL.md，执行与对账机制见 skills/improve/references/closing-the-loop.md，九大审计类别清单见 skills/improve/references/audit-playbook.md。
六、自检清单：用 6 个问题检验你的计划模板
这套原理不只属于 improve。如果你要为自己的团队（或你的 AI 执行者）写交接计划，用 skills/improve/references/plan-template.md 末尾的"质量门槛"自查：
- 一个从未见过这个仓库的模型，只凭计划文件就能执行吗？
- 每个验证都是"命令 + 预期结果"，而不是"确保它能跑"？
- 每一步都点名了精确的文件和符号，而不是"相关模块"？
- STOP 条件是针对本计划的真实风险写的，而不是套话？
- 审阅者只看"为什么重要 + 完成标准"，就能理解要批准什么？
- 范围外清单存在，且解释了"为什么不碰那些看起来相关的文件"？
七、总结
为什么弱模型也能执行对？答案藏在三大设计原理里：
- 自包含上下文——把所有需要"回忆"的信息内联进文件，消灭歧义
- 验证门槛——用命令和预期输出替代模型的主观判断
- 硬边界与 STOP 条件——在现实偏离计划时，强制弱模型"停下来上报"而非自由发挥
本质上，improve 把"智能"和"执行"做了分离：最贵的模型负责理解、判断与规格，最便宜的模型负责按图施工。当计划写得足够好时，执行者的智力下限就不再是项目的天花板。
📌 更多细节可阅读 README.md 中的完整使用说明。
【免费下载链接】improveUse your most capable model to audit your codebase and write plans for cheaper models to execute.项目地址: https://gitcode.com/gh_mirrors/imp/improve
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
