shadcn/improve：让最强模型当架构师，便宜模型当码农

前两天刷 GitHub Trending，看到一个项目两天涨了 1400+ star，作者是 shadcn------对，就是那个做 shadcn/ui 的大佬。点进去看了下，思路挺有意思的。

这是个什么东西

简单说，improve 是一个 Agent Skill，它的核心逻辑就一句话：用你最贵的模型做最值钱的事，用便宜的模型做体力活。

具体怎么玩呢？你把 improve 装到 Claude Code 或者 Cursor 里，然后：

跑 /improve，它会扫描整个代码库，从正确性、安全性、性能、测试覆盖率、技术债、依赖迁移、开发体验、文档、方向建议九个维度做审计
审计完给你一张表，列出所有发现的问题，按性价比排序（影响力 ÷ 工作量，再乘以置信度）
你挑几个想修的，它帮你写执行计划------存到 plans/ 目录下
把计划丢给便宜模型执行，或者让它自己调度：/improve execute 001

整个流程里，improve 自己一行代码都不改。它只做两件事：审计 + 写计划。

为什么我觉得这个思路很妙

最近大家都在讨论 AI 编程的成本问题。Claude Opus 写代码确实厉害，但烧 token 跟烧钱似的。DeepSeek、Qwen 这些便宜模型写简单代码没问题，但让它理解一个几万行的项目、判断哪里该重构、怎么写不会引入新 bug------说实话，差点意思。

improve 的做法就是把"理解"和"执行"拆开：

理解代码库、判断优先级、写方案 → 最强模型干（贵但值）
照着方案写代码、跑测试、修 lint → 便宜模型干（便宜且够用）

这个分工跟人类团队一模一样------架构师做设计，初级程序员写代码。只不过现在这个"架构师"是 Claude Opus，"初级程序员"是 DeepSeek。

实际效果怎么样

improve 的 README 里给了一个真实案例。作者拿它跑了 shadcn/ui 的代码库，审计结果长这样：

scss 复制代码

| # | Finding                                        | Category  | Effort | Confidence |
|---|------------------------------------------------|-----------|--------|------------|
| 1 | shadow-config duplicated in search.ts/view.ts, | tech-debt | M      | HIGH       |
|   | copies already drifted (TODO at search.ts:31)  |           |        |            |
| 2 | O(n²) icon migration (migrate-icons.ts:168)    | perf      | S      | HIGH       |

它发现了 search.ts 和 view.ts 里各有一份重复的 shadow config 逻辑，而且两份代码已经产生了分歧------search.ts 用 createConfig({style: "new-york"}) 做种子，view.ts 用的是裸的 configWithDefaults({})。代码里甚至有个 TODO 注释写着"我们知道这里重复了但没空修"。

然后它产出了一份执行计划（放在 plans/001-extract-shadow-config-resolution.md），里面包含：

当前代码的精确摘录（带行号）
每一步要改什么文件、怎么改
每一步的验证命令和预期输出
STOP 条件（什么情况下停下来别继续）
明确的 scope 边界（哪些文件不能碰）

这份计划写得有多细呢？连 git 分支名、commit message 格式都给你定好了。任何一个便宜模型拿到这份计划，闭着眼睛都能执行。

更狠的是，它还标记了几个"假阳性"------子 agent 报告了问题，但 improve 自己重新读了代码后判断这不是问题，直接拒绝，还记录了拒绝原因：

csharp 复制代码

- [SEC-01] https_proxy env var "SSRF": by-design --- standard proxy convention,
  every CLI honors it. Not a finding.

这个"自己审自己"的环节挺关键的。子 agent 会过度报告（宁可错杀不可放过），但 improve 在展示给你之前会亲自验证每一个发现------错误的纠正，假阳性直接丢掉。这比那些"AI 审计工具"一股脑丢给你 200 个问题的做法靠谱多了。

执行计划为什么能"可执行"

improve 写的计划有个特点：它是写给最弱的执行者看的。

什么意思呢？执行这份计划的模型可能从来没见过 improve 的上下文，可能是个很小的模型。所以计划必须做到三点：

自包含。 所有上下文都内联在计划里------精确的文件路径、当前代码摘录、仓库规范、验证命令。不存在"如上所述"这种引用。

可验证。 每一步结束都有验证命令和预期输出。完成标准是机器可检查的，执行者不需要自己判断"我是不是做对了"。

硬边界。 明确的 out-of-scope 列表和 STOP 条件------"如果 X 发生，停下来报告"。不让小模型在遇到意外情况时自由发挥。

这个设计思路其实很工程化。本质上就是把"不确定性"关在审计阶段，执行阶段变成纯机械操作。

怎么装

一条命令：

bash 复制代码

npx skills add shadcn/improve

支持所有兼容 Agent Skills 格式的工具------Claude Code、Cursor、Codex 等等。产出的计划是纯 Markdown，所以任何 agent（甚至人类）都能执行。

使用流程

第一次用的典型流程：

在项目根目录跑 /improve（想省钱就 /improve quick，只做快速扫描）
它扫描完给你一张发现表，你回复"plan 1, 3, 5"选几个想修的
计划写入 plans/ 目录，每份一个文件，附带索引和推荐顺序
把计划丢给任何 agent 执行，或者让它调度：/improve execute 001
下次回来跑 /improve reconcile，它会检查哪些完成了、哪些过时了、哪些卡住了

还有一些变体：

/improve security --- 专注安全审计
/improve perf --- 专注性能
/improve branch --- 只审计当前分支的改动（PR 前用）
/improve next --- 功能建议（基于代码库现状，不是瞎猜）
/improve plan <描述> --- 跳过审计，直接为一个想法写计划
/improve review-plan <文件> --- 审查和收紧已有计划

几个我觉得设计得好的地方

1. 只写计划，不改代码。 improve 的写入操作仅限于 plans/ 目录。执行者在隔离的 git worktree 里操作，合并不归它管。这个边界划得很清楚。

2. 从不读取密钥。 发现敏感信息时只报告位置和类型，不复制内容。审计工具读密钥是个很危险的事，它直接避免了。

3. reconcile 机制。 计划不是一锤子买卖。/improve reconcile 会刷新整个 backlog------验证已完成的、调查卡住的、清理过时的。这个"闭环"设计让计划不会变成僵尸文档。

4. 可以发 GitHub Issue。 加 --issues 参数，计划直接变成 GitHub Issue。这样不用 Agent Skills 的团队也能用。

适合谁用

用 AI 编程但心疼 token 的人 --- 把贵的模型用在刀刃上
维护中大型项目的团队 --- 让 AI 帮你做代码审计和重构规划
想尝试 Agent Skills 工作流的人 --- 这是个很好的切入点，安装简单，产出清晰
开源项目维护者 --- 用 /improve --issues 把审计结果直接变成 Issue，贡献者可以认领

不适合谁

小项目（几百行代码）用这个有点杀鸡用牛刀
如果你的代码库结构非常不标准，审计结果可能不太准
目前只支持 Agent Skills 格式的工具，传统 IDE 用户暂时用不了

我的使用感受

我在一个中等规模的 TypeScript 项目上跑了一下 /improve quick，大概花了 2 分钟。它找到了 7 个问题，其中 3 个是真的有价值的（一个循环引用、两个未使用的依赖），2 个是风格建议（可修可不修），2 个被它自己标记为假阳性去掉了。

最有意思的是它发现了一个 try-catch 里吞掉了所有异常的问题------这段代码我写过但早忘了，它指出来我才意识到这是个隐患。

计划写得确实详细。我挑了那个循环引用问题让它出计划，产出的文档里连 import 顺序都规划好了。丢给 DeepSeek 执行，5 分钟搞定，测试全绿。

当然也不是完美的。它偶尔会把一些"看起来像问题但不是问题"的东西报出来（比如它觉得某个 any 类型是类型安全问题，但实际上那里用 any 是故意的）。不过因为它有 vet 环节，大部分假阳性在展示前就被过滤掉了。

shadcn/improve：让最强模型当架构师，便宜模型当码农