强模型做审计，低成本模型执行计划

把最贵的模型用来理解仓库、判断问题和写方案，再让便宜模型执行，这是 shadcn/improve 的核心思路。它交付的是一组可以独立审阅、交接和验收的 Markdown 计划，源码修改交给执行代理。

对已经在用 AI 编程的开发者，这套流程值得看：它试图解决的，是换一个模型、开一个会话之后，任务背景丢失、执行范围失控、完成标准模糊的问题。不过，原文展示了流程和审计案例，没有给出成本或成功率的对照数据。

为什么把理解仓库和修改代码拆开

作者认为，强模型的价值集中在几个环节：理解代码库，判断什么值得做，以及把任务规格写清楚。执行阶段如果已经有明确路径和验收命令，就可以交给更便宜的模型。

这里真正要交付的产品，是能脱离当前会话执行的计划。

安装命令如下，它把这套流程加入支持 Agent Skills 格式的代理：

npx skills add shadcn/improve

要注意最后的 shadcn/improve：安装的是这套 skill；它输出的计划是普通 Markdown，后续接手者可以是其他代理，也可以是人。

首次运行 /improve 后，它先梳理仓库，再给出按优先级排列的问题表。用户回复类似 plan 1, 3 and 5，才把选中的问题写成计划。文件落在 plans/，每个问题一份，并附带建议执行顺序和依赖图。

这也保留了一个必要的人类判断：发现问题，不等于现在就该修。影响大但牵涉产品取舍的任务，未必比一个低成本修复更值得先做。

审计结果凭什么值得相信

流程从仓库调查开始。它会识别技术栈、项目约定，以及准确的构建、测试、lint 命令；还会读取已有的 ADR、PRD 和设计文档，包括 docs/adr/、CONTEXT.md、DESIGN.md、PRODUCT.md。

这些文件的作用，是告诉代理哪些取舍已经讨论过。否则，审计很容易把有意保留的设计重新报成问题，或者提出偏离产品方向的功能建议。

随后，多个子代理并行检查九类内容：正确性、安全、性能、测试覆盖、技术债、依赖与迁移、开发体验、文档，以及产品方向。每条发现都要提供 file:line 证据、影响、工作量和置信度；功能建议也必须引用仓库证据。

子代理的输出还要经过复核。顾问模型会亲自重读引用位置，删除误报、修正归因，并记录驳回理由，避免下次再次提出。

原文展示了一次针对 shadcn/ui 的运行：

• search.ts 和 view.ts 重复维护 shadow-config，副本已经出现差异，search.ts:31 还有 TODO。它被评为技术债，工作量 M，置信度 HIGH。
• migrate-icons.ts:168 存在 O(n²) 的图标迁移逻辑，被评为性能问题，工作量 S，置信度 HIGH。
• 一条把 https_proxy 环境变量判为 SSRF 的发现被驳回，理由是它属于标准代理约定下的预期设计。

这说明它有处理误报的机制，但还不能证明整体准确率。最终排序采用影响 ÷ 工作量，并按置信度加权；原文没有公开具体权重，因此应把它当作辅助排序，而非精确评分。

计划怎样让较小模型少走偏路

计划面向的接手者，是一个没看过顾问会话、能力可能更弱的模型。因此，任务背景必须写进文件：准确路径、当前代码摘录、项目约定、可参考的示例文件，以及验证过的命令。

每一步还要带验证命令和预期输出，完成条件尽量做到机器可检查。遇到现实与计划不一致的情况，则通过明确的范围外事项和 STOP 条件，要求执行者停止并报告。

计划不仅要写清怎么做，还要写清什么时候不能继续做。

每份计划还记录生成时对应的 git commit，供执行者修改前检查代码是否已经漂移。以下命令覆盖了从审计到执行、维护积压任务的入口：

/improve                        full audit → prioritized findings → plans
/improve quick                  cheap pass: hotspots, top findings only
/improve deep                   exhaustive: every package, every category
/improve security               focused audit (also: perf, tests, bugs, ...)
/improve branch                 audit only what the current branch changes
/improve next                   feature suggestions — where to take the project
/improve plan <description>     skip the audit, spec one thing
/improve review-plan <file>     critique and tighten an existing plan
/improve execute <plan>         dispatch a cheaper executor, review its work
/improve reconcile              refresh the backlog: verify, unblock, retire
/improve ... --issues           also publish plans as GitHub issues

要重点看 /improve execute <plan>：它会启动执行者，顾问本身仍不直接实现功能。

例如 /improve execute 001 会把便宜模型派到隔离的 git worktree 中执行。完成后，顾问重新运行验收条件，检查范围和 diff，再决定通过、退回修改或阻塞并完善计划。退回修改最多 2 轮，合并由用户决定。

下一次运行 /improve reconcile，则会检查 DONE 计划是否仍然成立、调查 BLOCKED 任务、刷新过期计划，并关闭已被其他改动解决的发现。加上 --issues，计划也能发布成 GitHub issues。

按原文约定，顾问只向 plans/ 写入文件，不执行改变当前工作树的命令；执行者在可丢弃的 worktree 中修改源码。审计涉及凭证时，只记录位置和凭证类型，不复述秘密值，并建议轮换。

我的判断

我认同它把交接质量当作主要问题。相比直接让一个代理从审计一路改到提交，独立计划更容易审阅，也便于换模型接力。相比一句笼统的 issue 描述，它补齐了代码证据、边界和验收方式。

但「强模型规划、便宜模型执行」是否省钱，目前仍是经验判断。原文没有提供模型组合、token 消耗、总耗时、返工率或对照实验。并行审计、逐条复核、执行后复验都要花成本，小任务未必值得完整走一遍。

另一个前提是仓库本身有可用的验证手段。测试覆盖不足时，命令通过只能证明现有检查通过；涉及界面交互、产品语义的修改，也未必能仅靠机器检查验收。STOP 条件能限制随意发挥，却不能替代正确的任务判断。

它适合把复杂改动变成可交接任务。对于范围清楚的小修复，直接实现并审查 diff，通常更省流程。

能拿来做什么

• 接手陌生前端或 Node 仓库时，先用 /improve quick 看热点和主要发现，再挑有证据、能验收的问题生成计划。
• 提交 PR 前运行 /improve branch，把审计范围限制在当前分支，重点检查新增逻辑、遗漏测试和性能变化。
• 准备用较小模型执行任务时，先通过 /improve review-plan <file> 检查计划是否写全路径、验证命令和停止条件，再交给执行者。
• 已经积累多份计划时，在新会话运行 /improve reconcile，先确认任务是否仍存在、代码是否已变化，再安排下一项工作。