深入improve五阶段工作流：Recon侦察、并行Audit审计、Vet复核与优先排序方法
【免费下载链接】improveUse your most capable model to audit your codebase and write plans for cheaper models to execute.项目地址: https://gitcode.com/gh_mirrors/imp/improve
improve是一个面向 AI Agent 的代码审计技能（agent skill）：它用你最强的模型做代码库侦察、审计、复核与优先排序，再产出一套"自包含"的实现计划，交给更便宜的模型去执行。核心思想一句话：计划即产品——强模型负责理解与判断，弱模型负责动手，improve 本身永远不改一行源码。
一、先看全景：improve 代码审计的五阶段工作流
整个工作流定义在 skills/improve/SKILL.md 中，可以概括为五个阶段：
| 阶段 | 做什么 | 关键词 |
|---|---|---|
| ① Recon 侦察 | 摸清技术栈、命令与约定 | 地图、验证命令 |
| ② Audit 审计 | 并行子代理扫描九大类别 | 证据、file:line |
| ③ Vet 复核 | 逐条重读引用代码，剔除误报 | 去伪存真 |
| ④ Prioritize 排序 | 按"杠杆率"给发现排优先级 | 影响 ÷ 成本 |
| ⑤ Plan 计划 | 写出可执行、可验收的计划文件 | 自包含、验证门槛 |
上手也简单：在仓库里对 Agent 输入/improve开始完整审计，输入/improve quick做低成本的快速扫描，选中感兴趣的结果后回复"plan 1, 3 and 5"，计划就会落盘到plans/目录。
二、阶段一 Recon 侦察：先画地图，再下判断
Recon 阶段的目标是"判断之前先摸清地盘"，它是后续所有阶段的地基，每次运行都会执行：
- 识别技术栈与关键命令：读取 README、根配置（
package.json、go.mod等）和 CI 配置，精确找出构建、测试、lint、类型检查命令——这些命令会原样进入每一份计划，成为验证门槛（verification gates）。 - 收集仓库约定：代码风格、命名、错误处理模式，让后续计划要求执行者"对齐现有风格"，并给出示例文件。
- 吸收意图与设计文档：如果仓库有 ADR（
docs/adr/）、PRD、CONTEXT.md、DESIGN.md、PRODUCT.md，Recon 会全部读入。已拍板的取舍（by-design）就不会在审计阶段被反复当成问题报出来。 - 看 git 信号：用提交历史找出正在活跃演化和已经冻结的模块。
一个值得注意的细节：如果仓库没有可用的验证命令（没有测试、构建是坏的），"建立验证基线"往往会成为发现 #1，并且在依赖顺序上排最前。
三、阶段二 Audit 审计：并行子代理 + 九大类别
这是整个工作流中"火力最猛"的一步：improve 会扇出多个只读子代理并行审计，每个代理负责一个大类，审计清单来自 skills/improve/references/audit-playbook.md：
- 正确性 / Bug
- 安全
- 性能
- 测试覆盖
- 技术债与架构
- 依赖与迁移
- DX 与工具链
- 文档
- 方向（功能建议——必须引用仓库内的真实证据，拒绝空泛的"加个 AI"式建议）
审计深度由三档控制（详见 SKILL.md 中的对照表）：
quick：只看高改动热点，产出约 6 条高置信度发现；standard（默认）：热点加权覆盖关键包，最多 4 个并行子代理；deep：全仓库逐包扫描，最多 8 个并行子代理，连低置信度的"待调查"项也纳入。
每条发现都强制携带完整要素：证据（file:line）、影响、工作量（S/M/L）、修复风险、置信度。没有证据就没有发现——"某个地方大概有 N+1 查询"不算发现，"orders/api.ts:142在循环里逐项发查询"才算。
四、阶段三 Vet 复核：子代理会过度上报，所以要"人肉"把关
为什么需要独立的 Vet 阶段？因为并行子代理天然倾向于过度上报。在把发现表交给用户之前，improve 会亲自打开每一处被引用的代码位置重新确认，重点拦截三类错误：
- 按设计行为被当成 Bug：比如遵循
https_proxy被报成 SSRF——它是标准代理约定； - 证据张冠李戴：问题是真的，但文件/行号写错了；
- 跨子代理重复上报：同一个问题被两个代理各报一次。
被驳回的发现会记录进索引的"considered and rejected"区块，下次审计不再重复上报，避免每次运行都看到同样的噪音。Vet 阶段还有一条硬规则：写计划时引用的代码摘录必须来自自己亲自读到的文件，而不能照抄子代理报告——子代理的行号是"线索"，不是"事实"。
五、阶段四 Prioritize 优先排序：用"杠杆率"决定先做什么
Vet 之后的发现按杠杆率 = 影响 ÷ 工作量，再用置信度加权排序，形成决策表：
| # | 发现 | 类别 | 影响 | 工作量 | 风险 | 证据 |
|---|
排序时还有四条平手裁决规则（来自 audit-playbook.md 的 Prioritization rubric）：
- 能"解锁"其他发现的工作（验证基线、特征化测试）上浮；
- 高置信度的安全问题浮到同等杠杆的非安全问题之上；
- 优先选择"验证路径干净"的发现——执行模型在那类任务上成功率更高；
- "不值得做"是合法结论，记录一行理由即可。
另外，方向类建议单独呈现在表格之后——"建插件系统"和"修 N+1"不该被塞进同一个排名，前者是给维护者权衡的选项，不是待修 Bug。最后由用户挑选要写成计划的条目（默认建议 Top 3–5），同时提示依赖顺序，例如"模块 X 的特征化测试必须排在 X 的重构之前"。
六、阶段五 Plan 计划：为"零上下文"的执行者写作
计划模板见 skills/improve/references/plan-template.md。每份计划都默认执行者从未见过本次会话、模型更小、只靠这份文件干活，因此有三个核心属性：
- 自包含：精确文件路径、当前代码摘录、仓库约定（含示例文件）、已验证的命令，全部内联，禁止"如上所述"；
- 验证门槛：每一步以"命令 + 预期输出"收尾，完成标准是机器可检查的，执行者无需自行判断成败；
- 硬边界与逃生舱：明确列出范围外文件，并写清 STOP 条件——"如果 X 出现，停下来上报，而不是即兴发挥"。
每份计划还会盖一个Planned at的 commit SHA，执行者动手前先跑漂移检查：范围内的文件若已变化，直接触发 STOP 条件。所有计划按推荐执行顺序编号，落在plans/目录并附一个带依赖关系和状态列的索引。一份真实的计划样例可以看 examples/001-extract-shadow-config-resolution.md。
七、闭环执行：execute 与 reconcile 让计划活起来
计划写完并不是终点，配套的闭环流程定义在 skills/improve/references/closing-the-loop.md：
/improve execute <plan>：派一个更便宜的执行者子代理在隔离的 git worktree中按计划执行，improve 则像 tech lead 一样复核：重跑所有完成标准、核对改动范围、逐块读 diff，给出 APPROVE / REVISE（最多两轮）/ BLOCK 判定。合并永远是用户的决定。/improve reconcile：跨会话清理积压——验证已 DONE 的计划、排查 BLOCKED 的障碍、刷新已漂移的 TODO、退役已被顺手修复的发现。--issues：把计划发布为 issue，自包含的计划正文无需任何改写即可被任何人或 Agent 接手。
八、新手上手清单 🧭
- 在你的仓库中运行
/improve quick，用最低成本先拿到热点发现； - 等待 Vet 后的发现表，回复"plan 1 和 3"挑选要落盘的条目；
- 阅读
plans/下的计划文件——它们本来就是写给人类评审的； - 用
/improve execute 001派便宜模型执行，或直接把计划丢给任何 Agent（"implement plans/001-*.md"）； - 下次会话跑
/improve reconcile刷新积压。
五条硬规则保证安全边界：improve 从不修改源码（唯一写入是plans/）、从不运行会改动工作树的命令、从不复现密钥明文（只记录位置与凭证类型）、被要求直接实现时会拒绝并指向计划。理解并运转这套"Recon → Audit → Vet → Prioritize → Plan"工作流，你就能把最强的模型用在杠杆率最高的地方，把重复劳动交给更便宜的模型 🚀
【免费下载链接】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），仅供参考
