一个很简单的想法：把「想」和「做」分开。

想——理解代码库、判断优先级、写详细规格——这件事需要最强的推理能力，比如 DeepSeek v4 PRO 或 GPT-5。做——照着规格改代码、跑测试、提交——不需要那么强的模型，便宜模型完全够用。DeepSeek v4 Flash 的性价比就很好。

这恰好是我们日常面对的问题。白物集每天有几十次 agent 操作：修复 bug、重构代码、添加功能。每次都让最强模型跑全部工作流，成本太高。每次都让便宜模型全权决策，又可能出现方向性错误。我们需要的正是「分拆」——一个模型想，另一个做。

shadcn/improve（8,600+ stars，MIT 协议）就是这个想法的直接成品。它本身是一个 agent skill，装在任何支持 Agent Skills 格式的 Coding Agent 里就能用。它的作者是 shadcn——没错，就是 shadcn/ui 的创造者，这确保了工具的设计品位和工程质量。

核心亮点

全自动代码审计，分级输出

/improve 跑一次，并行派出 9 个子 agent，分别覆盖 correctness、security、performance、test coverage、tech debt、dependencies、DX、docs、direction 九个维度。每个发现都带 file:line 证据、影响评估、预估工作量、置信度。输出不是噪音列表，而是按 leverage（impact ÷ effort，加权置信度）排序的表格，你只需要勾选要处理的项。

生成真正可执行的 plan

大多数工具写的「计划」只有它自己读得懂。improve 的 plan 专门为最弱的执行者设计——一个从没见过审计会话，可能更小更便宜的模型。三个设计原则保证可执行性：

• 自包含：所有上下文内联到 plan 里——精确文件路径、当前代码摘录、仓库约定的范例、已验证的构建命令。没有「见上文所述」这类跨上下文引用，避免小模型迷失在上下文碎片中。
• 验证门：每一步结尾都有一个命令和它的期望输出。完成标准是机器可检查的，执行者不需要自己判断是否完成。
• 硬边界：明确的 out-of-scope 清单，和 STOP 条件——「如果 X 和计划不符，停下来报告」——防止小模型在不可预见的情况下自由发挥。

结果是一个可版本化的 markdown 文件，记录了 git commit hash，任何 agent 或人类都可以拾取执行。

闭环：不只是写计划，还要验证执行

Plans 不是 fire-and-forget。/improve execute 001 在隔离的 git worktree 中启动执行 agent，完成之后自动做 review：重新跑每个完成标准、检查 scope 合规性、对比 diff 与原始计划。返回 verdict：approve（merge 由你决定）、revision request（最多 2 轮）、或 block + 建议 refine。

还有一个重要的 reconcile 命令——处理跨 session 的 backlog：验证已完成的 plan 是否在后续变更中被破坏、调查阻塞的 plan 并寻找替代路径、刷新因代码漂移而过期的 plan、剔除已独立修复的发现。这保证了计划的半衰期不会因为代码一直在变而成为垃圾。

白物集中的实际应用

improve 的 workflow 和我们现有的操作习惯几乎完美对齐。

我们每天和多个模型打交道。DeepSeek v4 Flash 执行具体任务又快又好——写代码、修 bug、跑测试——但在「全面理解整个代码库，判断什么值得做，排出优先级」这件事上，我们需要更强的前端规划。

一个真实的例子：白物集 API 从 Express 切换到 Astro SSR 后，首页文章按 b.id - a.id（数据库自增 ID）排序，而旧 .md 文件 ID 在 100-144 之间，新 API 文章 ID 只有 40 多，导致最新发布的内容排在页面最末尾，被 .slice(0, N) 完全切掉。

这种问题需要一个「全局性理解」才能发现——它不在任何一个页面或组件中，而是跨系统的排序逻辑问题。improve 的 9 维度审计恰好能抓住跨模块的 correctness 和 DX 缺陷。先 /improve 出分类发现，选中排序问题让最强模型写 plan，然后把「把 b.id - a.id 替换为按 published_at 排序」的精确指令交给便宜模型执行，一步到位。

再看 Zod v4 的兼容性问题。POST /api/v1/content/ingest 返回 500 INTERNAL_ERROR，日志显示 TypeError: Cannot read properties of undefined (reading 'map')，根因是 ECS 上 errors.js 用了 zodErr.errors.map()（Zod v3 的 API），而 Zod v4 只有 zodErr.issues。这种问题在 audit 阶段就会被标记为 correctness 类发现，并附带精确的文件和行号。

improve 的 execute 机制对此特别契合——它在隔离 worktree 中运行，不怕改坏生产环境。review 通过后手动 merge，安全性和可控性都在。

还有一个隐蔽的场景：跨 session 的 backlog 管理。白物集管线每天有多个 cron 产出文章，发现的问题常常来不及立即修复，分散在不同的 session 中。improve 的 reconcile 命令能自动检查之前标记的修复是否已被后续变更覆盖，或者是否已经被外部 PR 顺带修掉。这省去了维护 TODO 列表的麻烦——plan 本身就是活的任务跟踪器。

日常使用中，最频繁的命令反而是 /improve branch。提交 PR 之前跑一次，它只审计当前分支改动的内容，不会把整个仓库的存量问题都列出来。这恰好适合我们的工作流：每次只改一件事，确认没有引入新的问题再合入。

适合与不适合

适合： - 代码库全面审计和技术债清扫 - 大型重构前的完整规划 - 多 agent 协作流水线（一个 agent 出 plan，另一个执行） - PR 前的 scope 检查（/improve branch） - 代码健康度的周期性巡检 - 跨 session 的 backlog 管理

不适合： - 紧急 bug 修复（写 plan 的开销超过直接改，小 bug 不值得） - 简单的一次性任务 - 团队不接受代码 review 前置规划的工作流 - 单人或单 agent 场景不如直接写（没有「多级模型」配置）

快速上手

# 安装
npx skills add shadcn/improve

# 快速审计
/improve quick

# 查看发现列表，回复编号
# "plan 1, 3 and 5"

# 检查生成的 plan
cat plans/001-*.md

# 交给执行者
/improve execute 001

总结

shadcn/improve 的价值不在于代码分析本身有多深——很多工具也能做审计。它的独特之处在于强制了一个高质量的工作流：把「思考」和「执行」拆成两个角色，各自使用最优成本的模型。

这种「plan-inspect-execute-verify」的模式可以扩展到代码之外。任何需要先理解全局、再拆解步骤、然后分步执行的任务——系统架构设计、文档重构、数据迁移——都可以用这个思路来组织。当你发现一个问题需要花 5 分钟判断但花 10 秒钟改的时候，就应该考虑把判断和执行拆开了。