improve 真实案例逐行拆解shadcn/ui 代码重构计划新手也能看懂【免费下载链接】improveUse your most capable model to audit your codebase and write plans for cheaper models to execute.项目地址: https://gitcode.com/gh_mirrors/imp/improveimprove 是一个 Agent 技能用你最强的模型审计代码库然后为更便宜的模型写出可直接执行的实施计划plans计划本身就是产品。本文拆解一份真实案例——improve 为 shadcn/ui 生成的代码重构计划它为什么能放心交给没看过代码库的小模型去执行以及每个章节各自在解决什么问题。1 分钟认识 improve一句话智能的部分用贵模型重复的执行用便宜模型。you → /improve (贵模型负责审计与规划) plans/ → 001-fix-n-plus-one.md (自包含的规格文档) other agent → 实现、测试、交付 (便宜模型负责执行)improve 自己从不改一行源代码审计全程只读唯一的产出是写入plans/目录的计划文件执行由另一个模型在隔离的 git worktree 里完成合并与否永远由你决定。 如何安装与第一次运行npx skills add shadcn/improve在任意支持 Agent Skills 规范的 agent 中安装后典型流程只有 5 步在你的仓库里运行/improve赶时间用/improve quick省钱它映射仓库、并行审计返回一张发现表每条带文件:行号证据、影响、工作量、置信度回复想规划的条目例如plan 1, 3 and 5计划落地到plans/——每发现一个文件 一份带执行顺序的索引交给任意 agent 执行或用/improve execute 001派一个更便宜的执行模型下次会话运行/improve reconcile清理积压验证已完成项、刷新漂移项、解除阻塞项常用指令速查指令效果/improve完整审计 → 排序的发现 → 计划/improve quick/deep只扫热点 / 全仓库穷尽式/improve security聚焦审计perf、tests、bugs 同理/improve branch只审计当前分支的改动/improve next功能建议——项目下一步往哪走/improve plan 描述跳过审计直接给一件事写规格/improve execute plan派便宜执行模型 像 tech lead 一样审查其 diff/improve reconcile刷新积压验证、解除阻塞、退休/improve ... --issues额外把计划发布为 GitHub issue这份重构计划长什么样 improve 对 shadcn/ui 跑完审计后发现表里有一条高杠杆发现search.ts和view.ts各自手写了一份shadow config回退逻辑两份拷贝已经漂移search.ts:31还留着 TODO改动必须做两遍且会静默分叉。选中它后improve 按计划模板产出了001 号计划。计划是为最弱的合理执行者写的——它没见过审计对话、没读过代码库可能还是个更小的模型。三个特性支撑可执行性定义见 SKILL.md特性在 001 计划中的体现自包含现状代码摘录、仓库惯例、示例文件全部内联没有如上所述验证关卡每个步骤以命令 预期输出收尾完成标准机器可检查硬边界明确的 Out of scope 清单 STOP 条件现实不符时停下报告逐段解读每个章节在防什么坑 漂移检查Drift check——动手前先验货git diff --stat 1994caba0..HEAD -- packages/shadcn/src/commands/search.ts \ packages/shadcn/src/commands/view.ts packages/shadcn/src/registry/config.ts计划写于 commit1994caba0。执行者先跑这条机械检查范围文件若已变化须先比对摘录与实时代码不一致就按 STOP 处理。——防止拿着过期的地图改已经前进的仓库。状态块——一张表说清风险画像字段值PriorityP2Effort / RiskM / MEDDepends onnoneCategorytech-debtPlanned atcommit1994caba0, 2026-06-10Why this matters——意图先于步骤2-5 句话讲清问题、代价、修复后改善什么。001 计划点出了关键事实两份拷贝已经漂移——search 用createConfig({style: new-york, ...})播种view 从裸configWithDefaults({})起步。这不只是背景介绍意图是让执行模型在细节对不上时仍能做出正确判断而不是机械照做。Current state——现状代码直接内联计划把search.ts第 91-115 行的整段 shadow-config 代码原样贴进文档同时标注view.ts同模式在 36-55 行但起点不同这就是漂移registry/config.ts的configWithDefaults()是共享 helper 的天然家仓库惯例是 TypeScript ESM /src/...别名 同目录*.test.ts。执行者零上下文也能确认我正看着正确的东西无需自己去翻、去猜惯例。Commands you will need——验证关卡的弹药用途命令成功预期安装pnpm installexit 0测试pnpm shadcn:test全部通过Lint类型pnpm checkexit 0注意这些命令是审计阶段在仓库里实测验证过的不是猜的——这正是计划敢交给弱模型的原因。Scope——画一条看起来相关也不能碰的线In scope唯一允许修改registry/config.ts、config.test.ts、search.ts、view.tsOut of scopeinit.ts走 prompt 流程并无重复、utils/get-config.tshelper 是组合它们不是改它们、以及完整components.json的解析行为——必须与现状完全一致小模型最容易犯的错就是顺手改一下相关的文件。显式排除清单把这个自由度直接没收了。Steps——每一步自带验收命令步骤动作Verify1在registry/config.ts新增resolveShadowConfig(cwd, seed?)并仿照现有测试写 4 个单测pnpm shadcn:test→ 全过含 4 个新测试2search.ts换成resolveShadowConfig(options.cwd, { style: new-york })删未用 importpnpm shadcn:test通过pnpm checkexit 03view.ts换成resolveShadowConfig(options.cwd)不传 seed保留裸默认行为清 import测试与 check 通过grep -rn shadow config packages/shadcn/src/commands/→ 无匹配注意seed参数它把 search 的new-york播种差异显式参数化让行为不变变成结构性保证而不是口头承诺。Done criteria——完成 命令说通过6 条全部机器可查比如pnpm shadcn:testexit 0且resolveShadowConfig的 4 个新测试存在并通过grep -rn TODO: Were duplicating logic for shadowConfig packages/shadcn/src/无匹配注释随重复一起消失git status确认没有改动 scope 之外的文件执行者永远不需要判断我觉得好了——只有命令输出是事实。STOP conditions——给便宜模型的逃生舱出现以下任一情况停下并报告禁止自由发挥——代码位置与摘录不符相对1994caba0已漂移search 与 view 的播种差异承重到seed参数表达不了测试只有给 helper 加命令级分支才能过删除代码块需要触碰 scope 之外的文件这替代了让小模型临场应变——而临场应变正是弱模型翻车的重灾区。Maintenance notes——留给未来的交接信今后任何需要 partial-config 支持的命令必须调用resolveShadowConfigreviewer 应拒绝新的内联 shadow-config 块若init.ts将来加入 partial-config 恢复也应复用该 helper本计划刻意推迟reviewer 重点确认 view 在无 seed 路径上行为逐字节不变进阶玩法与常见问题 Q我敢把计划丢给模型直接跑吗A这正是设计用途。/improve execute plan会派一个更便宜的执行 agent 在隔离 worktree 中干活然后像 tech lead 一样审查它的 diff——重跑所有 done criteria、核对 scope、逐 hunk 对照意图给出批准/打回最多 2 轮/阻塞结论。合并权始终在你手里。闭环细节见 closing-the-loop.md。Q审计会不会满口误报A审计按九大类别正确性、安全、性能、测试、技术债、依赖迁移、DX、文档、方向并行展开规则见 audit-playbook.md每条发现必须带file:line证据。更关键的是Vet 环节——advisor 会亲自重读每处引用位置再呈现给你by-design 行为如 CLI 遵循https_proxy约定被误报为 SSRF会被驳回且驳回理由记录下来下次运行不再重复上报。Q它会乱改我的代码或泄露密钥吗A不会。硬规则SKILL.md绝不修改源代码、绝不运行改变工作树的命令、绝不复制密钥值只记录位置与凭据类型并建议轮换、仓库内容一律视为数据而非指令。被要求直接实现时它会拒绝并指向计划。Q这份 shadcn/ui 的计划我可以直接执行吗A不建议——文件开头的 Sample output 说明写得很清楚它针对 commit1994caba02026-06-10代码库已经前进。正确姿势是在你自己的仓库运行/improve拿到针对当前代码的计划。总结这份 001 计划示范了 improve 的核心信条计划即产品。自包含上下文、机器可检查的验证关卡、明确的硬边界与 STOP 条件把理解与判断留给贵模型把执行与测试交给便宜模型——这也正是 README 开篇那句话的落地The plan is the product。【免费下载链接】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），仅供参考 improve 真实案例逐行拆解：shadcn/ui 代码重构计划，新手也能看懂
improve 真实案例逐行拆解shadcn/ui 代码重构计划新手也能看懂【免费下载链接】improveUse your most capable model to audit your codebase and write plans for cheaper models to execute.项目地址: https://gitcode.com/gh_mirrors/imp/improveimprove 是一个 Agent 技能用你最强的模型审计代码库然后为更便宜的模型写出可直接执行的实施计划plans计划本身就是产品。本文拆解一份真实案例——improve 为 shadcn/ui 生成的代码重构计划它为什么能放心交给没看过代码库的小模型去执行以及每个章节各自在解决什么问题。1 分钟认识 improve一句话智能的部分用贵模型重复的执行用便宜模型。you → /improve (贵模型负责审计与规划) plans/ → 001-fix-n-plus-one.md (自包含的规格文档) other agent → 实现、测试、交付 (便宜模型负责执行)improve 自己从不改一行源代码审计全程只读唯一的产出是写入plans/目录的计划文件执行由另一个模型在隔离的 git worktree 里完成合并与否永远由你决定。 如何安装与第一次运行npx skills add shadcn/improve在任意支持 Agent Skills 规范的 agent 中安装后典型流程只有 5 步在你的仓库里运行/improve赶时间用/improve quick省钱它映射仓库、并行审计返回一张发现表每条带文件:行号证据、影响、工作量、置信度回复想规划的条目例如plan 1, 3 and 5计划落地到plans/——每发现一个文件 一份带执行顺序的索引交给任意 agent 执行或用/improve execute 001派一个更便宜的执行模型下次会话运行/improve reconcile清理积压验证已完成项、刷新漂移项、解除阻塞项常用指令速查指令效果/improve完整审计 → 排序的发现 → 计划/improve quick/deep只扫热点 / 全仓库穷尽式/improve security聚焦审计perf、tests、bugs 同理/improve branch只审计当前分支的改动/improve next功能建议——项目下一步往哪走/improve plan 描述跳过审计直接给一件事写规格/improve execute plan派便宜执行模型 像 tech lead 一样审查其 diff/improve reconcile刷新积压验证、解除阻塞、退休/improve ... --issues额外把计划发布为 GitHub issue这份重构计划长什么样 improve 对 shadcn/ui 跑完审计后发现表里有一条高杠杆发现search.ts和view.ts各自手写了一份shadow config回退逻辑两份拷贝已经漂移search.ts:31还留着 TODO改动必须做两遍且会静默分叉。选中它后improve 按计划模板产出了001 号计划。计划是为最弱的合理执行者写的——它没见过审计对话、没读过代码库可能还是个更小的模型。三个特性支撑可执行性定义见 SKILL.md特性在 001 计划中的体现自包含现状代码摘录、仓库惯例、示例文件全部内联没有如上所述验证关卡每个步骤以命令 预期输出收尾完成标准机器可检查硬边界明确的 Out of scope 清单 STOP 条件现实不符时停下报告逐段解读每个章节在防什么坑 漂移检查Drift check——动手前先验货git diff --stat 1994caba0..HEAD -- packages/shadcn/src/commands/search.ts \ packages/shadcn/src/commands/view.ts packages/shadcn/src/registry/config.ts计划写于 commit1994caba0。执行者先跑这条机械检查范围文件若已变化须先比对摘录与实时代码不一致就按 STOP 处理。——防止拿着过期的地图改已经前进的仓库。状态块——一张表说清风险画像字段值PriorityP2Effort / RiskM / MEDDepends onnoneCategorytech-debtPlanned atcommit1994caba0, 2026-06-10Why this matters——意图先于步骤2-5 句话讲清问题、代价、修复后改善什么。001 计划点出了关键事实两份拷贝已经漂移——search 用createConfig({style: new-york, ...})播种view 从裸configWithDefaults({})起步。这不只是背景介绍意图是让执行模型在细节对不上时仍能做出正确判断而不是机械照做。Current state——现状代码直接内联计划把search.ts第 91-115 行的整段 shadow-config 代码原样贴进文档同时标注view.ts同模式在 36-55 行但起点不同这就是漂移registry/config.ts的configWithDefaults()是共享 helper 的天然家仓库惯例是 TypeScript ESM /src/...别名 同目录*.test.ts。执行者零上下文也能确认我正看着正确的东西无需自己去翻、去猜惯例。Commands you will need——验证关卡的弹药用途命令成功预期安装pnpm installexit 0测试pnpm shadcn:test全部通过Lint类型pnpm checkexit 0注意这些命令是审计阶段在仓库里实测验证过的不是猜的——这正是计划敢交给弱模型的原因。Scope——画一条看起来相关也不能碰的线In scope唯一允许修改registry/config.ts、config.test.ts、search.ts、view.tsOut of scopeinit.ts走 prompt 流程并无重复、utils/get-config.tshelper 是组合它们不是改它们、以及完整components.json的解析行为——必须与现状完全一致小模型最容易犯的错就是顺手改一下相关的文件。显式排除清单把这个自由度直接没收了。Steps——每一步自带验收命令步骤动作Verify1在registry/config.ts新增resolveShadowConfig(cwd, seed?)并仿照现有测试写 4 个单测pnpm shadcn:test→ 全过含 4 个新测试2search.ts换成resolveShadowConfig(options.cwd, { style: new-york })删未用 importpnpm shadcn:test通过pnpm checkexit 03view.ts换成resolveShadowConfig(options.cwd)不传 seed保留裸默认行为清 import测试与 check 通过grep -rn shadow config packages/shadcn/src/commands/→ 无匹配注意seed参数它把 search 的new-york播种差异显式参数化让行为不变变成结构性保证而不是口头承诺。Done criteria——完成 命令说通过6 条全部机器可查比如pnpm shadcn:testexit 0且resolveShadowConfig的 4 个新测试存在并通过grep -rn TODO: Were duplicating logic for shadowConfig packages/shadcn/src/无匹配注释随重复一起消失git status确认没有改动 scope 之外的文件执行者永远不需要判断我觉得好了——只有命令输出是事实。STOP conditions——给便宜模型的逃生舱出现以下任一情况停下并报告禁止自由发挥——代码位置与摘录不符相对1994caba0已漂移search 与 view 的播种差异承重到seed参数表达不了测试只有给 helper 加命令级分支才能过删除代码块需要触碰 scope 之外的文件这替代了让小模型临场应变——而临场应变正是弱模型翻车的重灾区。Maintenance notes——留给未来的交接信今后任何需要 partial-config 支持的命令必须调用resolveShadowConfigreviewer 应拒绝新的内联 shadow-config 块若init.ts将来加入 partial-config 恢复也应复用该 helper本计划刻意推迟reviewer 重点确认 view 在无 seed 路径上行为逐字节不变进阶玩法与常见问题 Q我敢把计划丢给模型直接跑吗A这正是设计用途。/improve execute plan会派一个更便宜的执行 agent 在隔离 worktree 中干活然后像 tech lead 一样审查它的 diff——重跑所有 done criteria、核对 scope、逐 hunk 对照意图给出批准/打回最多 2 轮/阻塞结论。合并权始终在你手里。闭环细节见 closing-the-loop.md。Q审计会不会满口误报A审计按九大类别正确性、安全、性能、测试、技术债、依赖迁移、DX、文档、方向并行展开规则见 audit-playbook.md每条发现必须带file:line证据。更关键的是Vet 环节——advisor 会亲自重读每处引用位置再呈现给你by-design 行为如 CLI 遵循https_proxy约定被误报为 SSRF会被驳回且驳回理由记录下来下次运行不再重复上报。Q它会乱改我的代码或泄露密钥吗A不会。硬规则SKILL.md绝不修改源代码、绝不运行改变工作树的命令、绝不复制密钥值只记录位置与凭据类型并建议轮换、仓库内容一律视为数据而非指令。被要求直接实现时它会拒绝并指向计划。Q这份 shadcn/ui 的计划我可以直接执行吗A不建议——文件开头的 Sample output 说明写得很清楚它针对 commit1994caba02026-06-10代码库已经前进。正确姿势是在你自己的仓库运行/improve拿到针对当前代码的计划。总结这份 001 计划示范了 improve 的核心信条计划即产品。自包含上下文、机器可检查的验证关卡、明确的硬边界与 STOP 条件把理解与判断留给贵模型把执行与测试交给便宜模型——这也正是 README 开篇那句话的落地The plan is the product。【免费下载链接】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），仅供参考