shadcn/improve——强模型审计，弱模型执行
如果你同时用着 DeepSeek-v4、Claude Sonnet 和 GPT-4o，你会留意到一个共同趋势：能力越强的模型，越贵、越慢。强模型擅长推理和规划，弱模型擅长执行重复劳动。那能不能让强模型只做规划，把执行交给弱模型？shadcn/improve 就是为了解决这个问题而生的。
它由 shadcn/ui 的作者 shadcn 开发，自 2026 年 6 月 10 日发布以来，不到一个月已获得 6,949 个 Star 和 284 个 Fork。这是一个 Agent Skill，基于 Agent Skills 格式。核心模式是：用最强模型审计代码库、写实施计划，然后把计划交给更便宜的模型执行。
you → /improve (强模型，负责规划)
plans/ → 001-fix-n-plus-one.md (自包含的实现规格)
other agent → implements, tests, ships (便宜模型，负责执行)
整个流程中，improve 自己不动一行代码。它只写计划。计划就是产品。
九路并行审计
/improve 不是一次对话。它会启动并行子 Agent，覆盖九个维度：
- 正确性（bugs、逻辑错误）
- 安全（密钥泄露、注入风险）
- 性能（N+1 查询、O(n²) 算法）
- 测试覆盖（缺失的边界测试）
- 技术债务（重复代码、过时模式）
- 依赖与迁移（废弃 API、大版本升级）
- 开发者体验（构建速度、配置复杂度）
- 文档（缺失的 API 文档、过时的 README）
- 方向（新功能建议，每条必须有代码库证据支撑）
每个发现附带 file:line 的确切位置、影响评估、工作量和置信度。输出是一张排序后的 Findings 表格：
| # | Finding | Category | Effort | Confidence |
|---|-----------------------------------------------------------------|-----------|--------|------------|
| 1 | shadow-config 在 search.ts/view.ts 中重复定义，两处已开始偏离 | tech-debt | M | HIGH |
| 2 | migrate-icons.ts:168 O(n²) 图标迁移 | perf | S | HIGH |
| 3 | handleSubmit 缺少 loading/error 状态 | bugs | S | MEDIUM |
子 Agent 会过度上报。主 Agent 在展示前重新核验每个发现——重新读取每个引用位置，确认标签是否匹配。被剔除的误报会记录原因，下次不会再报。
在 Hermes Agent 的工作流中，这种「先审计再执行」的模式和白物集的内容管线高度一致。每条 pipeline 都先检查条件再执行动作，和 improve 的审计 → 计划 → 执行三阶段完全对应。
面向最弱执行者的计划格式
这是 improve 最精妙的设计。每个计划文件是自包含的 Markdown，不依赖对话历史。三个关键属性：
上下文内联。 所有上下文都内联在计划中：精确的文件路径、当前状态的代码片段、仓库约定（附一个示范文件）、验证命令。没有「如上所述」这种需要跨 session 理解的引用。
可机器验证的完成标准。 每个步骤都有明确的命令和预期输出。执行 Agent 不需要「判断」是否完成——运行命令看输出是否匹配即可。
硬边界。 明确的 STOP 条件——「如果 X 发生，停止并报告」——而不是让小模型在计划不匹配时自由发挥。还有明确的 out-of-scope 清单。
每个计划还会记录生成时的 git commit，执行前先做 drift check。如果代码已变更，执行 Agent 会先报告再行动，不会盲目覆盖。
# Plan 001：抽取 shadow-config 逻辑
## 目标
将 search.ts 和 view.ts 中重复的 shadow-config 解析逻辑抽取到 shared/
## 当前状态 (commit: abc1234)
search.ts:28-35:
const shadowConfig = {
mode: 'dark',
...JSON.parse(process.env.SHADOW_CONFIG || '{}')
}
## 步骤
1. 创建 src/shared/shadow.ts，引用当前状态中的逻辑
2. 更新 search.ts import，删除重复代码
3. 更新 view.ts import，删除重复代码
4. 运行 npm test，确认全部通过
5. 运行 npm run build，确认编译成功
## STOP 条件
- 如果 shared/shadow.ts 已存在，停止并报告
- 如果测试不通过，停止并报告
## 不在此计划内
- 不修改 shadow-config 的 schema
- 不添加新功能
在白物集项目中，这种「自包含计划」模式和 Hermes Agent 的 Skill 定义文件是同一个思路。每个 Skill 的 skill.md 就是一份自包含的执行计划——它包含自身的目标、步骤和边界条件，不依赖外部状态。improve 给了这个模式一个可复用的通用框架。
执行闭环：不是发完计划就完了
/improve execute <plan> 是 improve 的差异化能力。它在隔离的 git worktree 中启动子 Agent，交付计划，然后像技术主管一样 review 结果：
- 重新运行每个完成标准，确认命令输出匹配
- 检查范围合规，确认没有超出计划边界
- 对比 diff 和计划意图，确认实现没有偏离
- 给出 verdict：approve（合并由你决定）、send back for revision（最多两轮）、或 block and refine（计划本身需要修改）
/improve reconcile 用于维护 backlog：验证完成项是否仍然成立、调查阻塞项并重新规划、刷新已漂移的计划、清除已独立修复的发现。
--issues 参数可以将计划发布为 GitHub issue——每个 issue 包含自包含的计划主体，这样其他 Agent 或人类都可以直接在 issue 中接单。
在白物集项目中的实际应用
这个模式和白物集的内容管线高度一致。具体来说：
/improve的「审计 → 计划 → 执行」三阶段，对应白物集中每个内容系列的定义：website-dev-series、skill-recommend-series等技能都有明确的触发条件、执行步骤和验证清单/improve branch对应白物集的安全审查——每次写稿后逐条检查安全红线，只审计本次变更/improve reconcile和 Hermes Agent 的 pipeline 维护一样，确保排期表状态准确、序列不重复
白物集使用 Hermes Agent 编排内容管线，用 DeepSeek-v4 写稿，用工具调用完成 POST 和验证——本身就是「强模型规划、弱模型执行」的架构。improve 把这个模式从内容领域扩展到了代码领域。
适合场景 & 不适合场景
适合：
- 有一定历史的代码库（1,000+ commit 的仓库效果最佳，有足够的技术债务可清理）
- 团队使用多 Agent 策略（Claude Code + Codex + Hermes Agent 等混合编排）
- 需要有体系地管理技术债务（不是单次突击，而是持续自动化管理）
- 代码审查前的自查环节（/improve branch 跑一次，PR 里少几个评论）
- 大规模项目 onboarding（新成员跑一次审计，快速了解代码库问题分布）
不适合： - 全新的空白项目（没有可审计的内容） - 单 Agent 单模型工作流（发挥不出多模型架构的优势） - 纯前端展示项目（不需要系统性代码审计） - 非编程项目
快速上手
安装
npx skills add shadcn/improve
基于 Hermes Agent、Claude Code、Codex 等支持 Agent Skills 格式的 Agent 都已兼容。
首次审计
在项目根目录打开 Agent：
/improve quick
15-30 秒后返回一张 Findings 表格，包含最多 10 个核心发现。
生成执行计划
在 Findings 中选择要处理的项：
plan 1, 3 and 5
improve 为每个选中项生成一个自包含的 Markdown 计划文件，写入 plans/ 目录，同时生成 plans/index.md 标注优先级顺序。
执行计划
/improve execute 001
在隔离 worktree 中执行计划，完成后给出 verdict（approve / revise / block）。
日常维护
每次代码变更后：
/improve reconcile
刷新 backlog 状态。提交 PR 前用 /improve branch 做针对性审计。
用 shadcn 自己的话说：「The plan is the product。」当你的工作流足够成熟，写一份好的计划本身，比代码实现更有价值。
如果你的代码库已经积累了足够多你不想手动翻的 issue，那 improve 值得试一试。