/improve 工作流：五步法让代码库持续自我进化
2026/6/25大约 10 分钟
代码写完就完了吗？
谁来持续发现安全漏洞、性能瓶颈、测试盲区？ " 如何把"改 bug"变成一个可重复、可信赖的流水线？
/improve 的答案：
Recon → Audit → Vet → Prioritize → Plan，五步把"改进"工程化。
问题：为什么代码库总是越改越烂？
绝大多数项目的真实状态：
┌─────────────────────────────────────────────────────────┐
│ 代码库的"自然熵增" │
├─────────────────────────────────────────────────────────┤
│ │
│ 时间推移： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ 上线 ──→ 加功能 ──→ 补丁摞补丁 ──→ 技术债爆炸 │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 典型症状： │
│ · 安全漏洞没人扫 │
│ · 性能退化没人察觉 │
│ · 测试覆盖率逐年走低 │
│ · 重复代码、死代码越积越多 │
│ · 依赖版本陈旧，没人敢动 │
│ · 每个 PR 都在"打补丁"，没有人在"做改进" │
│ │
│ 根本原因： │
│ · 改进 = 没有流程、没有标准、没有节奏 │
│ · "等有空再说" = 永远不会有空 │
│ · 凭感觉改 = 抓到什么改什么，抓不到的就漏 │
│ │
└─────────────────────────────────────────────────────────┘解决方案：/improve 五步工作流
核心思想：把"改进"变成一条有输入、有输出、有质量标准的流水线。
┌─────────────────────────────────────────────────────────┐
│ /improve 五步流水线 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Step 1 │──→│ Step 2 │──→│ Step 3 │ │
│ │ Recon │ │ Audit │ │ Vet │ │
│ │ 侦察 │ │ 审计 │ │ 筛查 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ↓ │
│ ┌──────────┐ ┌──────────┐ │ │
│ │ Step 5 │←──│ Step 4 │←───────┘ │
│ │ Plan │ │Prioritize│ │
│ │ 规划 │ │ 排序 │ │
│ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────┘Step 1：Recon（侦察）
Recon 是整个流水线的入口，回答一个问题：这个项目长什么样？
输入
┌─────────────────────────────────────────────────────────┐
│ Recon 的输入 │
├─────────────────────────────────────────────────────────┤
│ │
│ · 项目根目录（代码仓库） │
│ · 分支信息（当前分支、基线分支） │
│ · 历史改进记录（backlog） │
│ · 用户指定的范围（全量 / 某分支 / 某包） │
│ │
└─────────────────────────────────────────────────────────┘做什么
- 扫描项目结构（包、模块、依赖）
- 识别技术栈（语言、框架、构建工具）
- 统计规模指标（文件数、代码行数、依赖数）
- 读取历史 backlog，了解已知问题
输出
┌─────────────────────────────────────────────────────────┐
│ Recon 的输出 │
├─────────────────────────────────────────────────────────┤
│ │
│ · 项目画像（tech stack、size、structure） │
│ · 扫描范围清单（哪些包/目录纳入审计） │
│ · 已知问题清单（从 backlog 继承） │
│ · 建议的审计维度（根据技术栈自动选择） │
│ │
└─────────────────────────────────────────────────────────┘质量标准
- 完整性：不遗漏任何一级包/模块
- 准确性：技术栈识别正确，不把 React 项目认成 Vue
- 可追溯：每个结论都指向具体文件或指标
Step 2：Audit（审计）
Audit 是流水线的核心发动机，按维度逐个扫描，产出原始发现。
输入
┌─────────────────────────────────────────────────────────┐
│ Audit 的输入 │
├─────────────────────────────────────────────────────────┤
│ │
│ · Recon 的项目画像和扫描范围 │
│ · 选定的审计维度： │
│ ┌───────────────────────────────────────┐ │
│ │ · security 安全漏洞 │ │
│ │ · perf 性能问题 │ │
│ │ · tests 测试覆盖 │ │
│ │ · bugs 正确性缺陷 │ │
│ │ · deps 依赖陈旧 │ │
│ │ · style 代码规范 │ │
│ │ · arch 架构合理性 │ │
│ └───────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘做什么
- 按维度逐个扫描（不是一次性扫全部）
- 每个维度产出独立的发现列表
- 每个发现带：位置、严重度、证据、修复建议
输出
┌─────────────────────────────────────────────────────────┐
│ Audit 的输出：原始发现清单 │
├─────────────────────────────────────────────────────────┤
│ │
│ 每条发现的格式： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ id: "SEC-042", │ │
│ │ dimension: "security", │ │
│ │ severity: "HIGH", │ │
│ │ title: "SQL 注入风险", │ │
│ │ file: "src/api/user.go:88", │ │
│ │ evidence: "拼接 SQL 字符串", │ │
│ │ suggestion: "使用参数化查询", │ │
│ │ confidence: 0.92 │ │
│ │ } │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 按维度分组的发现列表： │
│ · security findings[] │
│ · perf findings[] │
│ · tests findings[] │
│ · bugs findings[] │
│ · ... │
│ │
└─────────────────────────────────────────────────────────┘质量标准
- 零误报优先：宁可少报，不可乱报
- 可复现：每条发现都能被独立验证
- 带证据：不接受"可能有问题"，必须指出具体代码位置
- 分维度：不混在一起，便于定向处理
Step 3：Vet（筛查）
Vet 是质检关，过滤误报、合并重复、标注真实严重度。
输入
┌─────────────────────────────────────────────────────────┐
│ Vet 的输入 │
├─────────────────────────────────────────────────────────┤
│ │
│ · Audit 阶段产出的全部原始发现 │
│ · 项目画像（用于判断是否适用） │
│ · 历史 backlog（用于识别重复） │
│ │
└─────────────────────────────────────────────────────────┘做什么
- 去重：合并指向同一根因的多条发现
- 过滤误报：剔除证据不足或不适用的发现
- 重评严重度：结合项目上下文调整严重度
- 交叉验证：多维度交叉印证（比如 security + bugs 同时命中）
输出
┌─────────────────────────────────────────────────────────┐
│ Vet 的输出：可信发现清单 │
├─────────────────────────────────────────────────────────┤
│ │
│ 每条可信发现的格式： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ { │ │
│ │ id: "SEC-042", │ │
│ │ status: "CONFIRMED", │ │
│ │ adjusted_severity: "CRITICAL", │ │
│ │ duplicates_merged: ["SEC-043", "SEC-051"], │ │
│ │ rationale: "用户输入直接拼接，可被注入", │ │
│ │ effort_estimate: "M" │ │
│ │ } │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ 附加输出： │
│ · 被过滤的误报列表（带原因） │
│ · 被合并的重复列表 │
│ │
└─────────────────────────────────────────────────────────┘质量标准
- 误报率 < 5%：过了 Vet 的发现必须可信
- 零遗漏：不能因为"看起来不严重"就丢掉
- 带理由：每条过滤/合并都要写清原因
Step 4：Prioritize（排序）
Prioritize 把可信发现排成一张优先级表，回答"先做什么"。
输入
┌─────────────────────────────────────────────────────────┐
│ Prioritize 的输入 │
├─────────────────────────────────────────────────────────┤
│ │
│ · Vet 阶段的全部可信发现 │
│ · 项目目标（如：上线、合规、降本） │
│ · 资源约束（人力、时间窗口） │
│ │
└─────────────────────────────────────────────────────────┘做什么
按多维度打分排序：
┌─────────────────────────────────────────────────────────┐
│ 排序维度 │
├─────────────────────────────────────────────────────────┤
│ │
│ · 严重度（severity） — 不痛的不做 │
│ · 影响面（blast radius）— 只影响自己 vs 影响全站 │
│ · 紧迫度（urgency） — 是否有上线/合规 deadline │
│ · 投入产出比（ROI） — 小改动大收益优先 │
│ · 依赖关系（dependency）— A 做了才能做 B │
│ │
│ 综合打分 = f(严重度, 影响面, 紧迫度, ROI, 依赖) │
│ │
└─────────────────────────────────────────────────────────┘输出
┌─────────────────────────────────────────────────────────┐
│ Prioritize 的输出：优先级表 │
├─────────────────────────────────────────────────────────┤
│ │
│ 排名 │ ID │ 标题 │ 严重度 │ 投入 │
│ ─────┼─────────┼───────────────────┼────────┼─────────│
│ 1 │ SEC-042 │ SQL 注入 │ CRIT │ M │
│ 2 │ PERF-07 │ N+1 查询 │ HIGH │ S │
│ 3 │ TEST-12 │ 核心链路零测试 │ HIGH │ L │
│ 4 │ BUG-09 │ 竞态条件 │ MED │ M │
│ 5 │ DEP-03 │ 依赖 CVE │ MED │ S │
│ ... │ ... │ ... │ ... │ ... │
│ │
│ 分组建议： │
│ · 本周必做（P0） │
│ · 本迭代做（P1） │
│ · 有空再做（P2） │
│ │
└─────────────────────────────────────────────────────────┘质量标准
- 可执行：每条都附带投入估算
- 有分组：不能只是一条长 list
- 考虑依赖：不把被阻塞的项排到最前
Step 5：Plan（规划）
Plan 把优先级表翻译成可执行的任务计划。
输入
┌─────────────────────────────────────────────────────────┐
│ Plan 的输入 │
├─────────────────────────────────────────────────────────┤
│ │
│ · Prioritize 阶段的 P0/P1 清单 │
│ · 项目约束（技术栈、规范） │
│ · 历史计划模板 │
│ │
└─────────────────────────────────────────────────────────┘做什么
- 为每个 P0/P1 项生成具体任务步骤
- 标注每步的验证标准（definition of done）
- 标注风险点和回滚方案
- 生成可派发给执行器的计划文件
输出
┌─────────────────────────────────────────────────────────┐
│ Plan 的输出：执行计划文件 │
├─────────────────────────────────────────────────────────┤
│ │
│ plan-2026-06-25.md： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ## Task 1: 修复 SQL 注入（SEC-042） │ │
│ │ │ │
│ │ Steps: │ │
│ │ 1. 定位 src/api/user.go:88 │ │
│ │ 2. 改用 database/sql 参数化查询 │ │
│ │ 3. 新增单元测试覆盖注入场景 │ │
│ │ 4. 运行 go vet 和 gosec 验证 │ │
│ │ │ │
│ │ DoD: │ │
│ │ · gosec 扫描无 HIGH 以上告警 │ │
│ │ · 新增测试通过 │ │
│ │ │ │
│ │ Risk: 低。仅修改查询构造方式。 │ │
│ │ Rollback: git revert 即可。 │ │
│ │ │ │
│ │ ## Task 2: 优化 N+1 查询（PERF-07） │ │
│ │ ... │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘质量标准
- 可派发：计划文件能直接交给
/improve execute - 有 DoD：每个任务都有明确的完成标准
- 有回滚：每个任务都有回滚方案
- 小步走：每个任务不超过 1 天工作量
五步合在一起：完整流水线
┌─────────────────────────────────────────────────────────┐
│ /improve 完整流水线 │
├─────────────────────────────────────────────────────────┤
│ │
│ 输入：代码仓库 + 历史 backlog │
│ ↓ │
│ ┌──────────┐ │
│ │ Recon │ → 项目画像 + 扫描范围 │
│ └──────────┘ │
│ ↓ │
│ ┌──────────┐ │
│ │ Audit │ → 原始发现（按维度分组） │
│ └──────────┘ │
│ ↓ │
│ ┌──────────┐ │
│ │ Vet │ → 可信发现（去重 + 过滤误报） │
│ └──────────┘ │
│ ↓ │
│ ┌──────────┐ │
│ │Prioritize│ → 优先级表（P0/P1/P2 分组） │
│ └──────────┘ │
│ ↓ │
│ ┌──────────┐ │
│ │ Plan │ → 执行计划（可派发） │
│ └──────────┘ │
│ ↓ │
│ 输出：plan-YYYY-MM-DD.md（交给 execute 或人工） │
│ │
└─────────────────────────────────────────────────────────┘命令矩阵：13 种用法
/improve 不只是"一条命令"，而是一个命令族。按场景选择。
审计类命令
┌──────────────────────┬────────────────────┬────────────────┐
│ 命令 │ 做什么 │ 什么时候用 │
├──────────────────────┼────────────────────┼────────────────┤
│ /improve │ 完整流水线 │ 日常改进 │
│ /improve quick │ 只扫热点，返回 │ 快速体检 │
│ │ 最优先的发现 │ │
│ /improve deep │ 穷尽扫描每个包、 │ 上线前、 │
│ │ 每个维度 │ 接手新项目 │
│ /improve security │ 只做安全审计 │ 合规、 │
│ │ │ 安全评审前 │
│ /improve perf │ 只做性能审计 │ 优化轮 │
│ /improve tests │ 只做测试覆盖 │ 补测试前摸底 │
│ /improve bugs │ 只做正确性审计 │ Bug bash 前 │
│ /improve branch │ 只审计当前分支变更 │ PR 前自查 │
└──────────────────────┴────────────────────┴────────────────┘规划类命令
┌──────────────────────┬────────────────────┬────────────────┐
│ 命令 │ 做什么 │ 什么时候用 │
├──────────────────────┼────────────────────┼────────────────┤
│ /improve next │ 功能建议、 │ 下轮规划 │
│ │ roadmap 方向 │ │
│ /improve plan <描述> │ 跳过审计，直接 │ 需求已明确 │
│ │ 为一件事写计划 │ │
│ /improve review-plan │ 强模型评审 │ 计划评审 │
│ <文件> │ 已有计划 │ │
└──────────────────────┴────────────────────┴────────────────┘执行与维护类命令
┌──────────────────────┬────────────────────┬────────────────┐
│ 命令 │ 做什么 │ 什么时候用 │
├──────────────────────┼────────────────────┼────────────────┤
│ /improve execute │ 隔离 worktree， │ 执行已批准 │
│ <计划> │ 派廉价执行器， │ 的计划 │
│ │ 完事审查 diff │ │
│ /improve reconcile │ 刷新 backlog， │ 定期维护 │
│ │ 验证完成、解除 │ │
│ │ 阻塞、退役过时的 │ │
└──────────────────────┴────────────────────┴────────────────┘典型场景：什么时候用什么？
场景 1：日常改进（每周一次）
/improve
→ 跑完整五步流水线
→ 产出本周改进计划
→ 派发给 execute 或人工处理场景 2：上线前体检
/improve deep
→ 穷尽扫描每个包、每个维度
→ 不放过任何角落
→ 上线前最后一道防线场景 3：PR 前自查
/improve branch
→ 只审计当前分支的变更
→ 30 秒内给出结果
→ 不让问题流到 main 分支场景 4：合规审计
/improve security
→ 只做安全审计
→ 产出合规报告
→ 满足审计要求场景 5：执行已批准的计划
/improve execute plan-2026-06-25.md
→ 在隔离 worktree 中执行
→ 不污染主分支
→ 完成后产出 diff，人工审查场景 6：定期清理 backlog
/improve reconcile
→ 验证已完成的任务（关闭）
→ 解除被阻塞的任务（激活）
→ 退役过时的任务（归档）
→ backlog 保持干净设计哲学：为什么是这样五步？
为什么分开，不一把梭？
┌─────────────────────────────────────────────────────────┐
│ 一把梭的问题 │
├─────────────────────────────────────────────────────────┤
│ │
│ ❌ "扫一下这个项目有什么问题" │
│ → 输出一堆混乱的发现 │
│ → 没有严重度，没有优先级 │
│ → 没有计划，无法执行 │
│ → 最后还是凭感觉改 │
│ │
│ ✅ 分五步的价值 │
│ → 每步有明确的输入/输出/质量标准 │
│ → 每步可以独立验证 │
│ → 每步可以单独运行（/improve security 只跑 Audit 的 security 维度）│
│ → 出问题可以定位到某一步 │
│ │
└─────────────────────────────────────────────────────────┘为什么是这五步？
┌─────────────────────────────────────────────────────────┐
│ 五步的内在逻辑 │
├─────────────────────────────────────────────────────────┤
│ │
│ Recon → "看清楚"（不了解项目就改进 = 瞎改） │
│ Audit → "找全"（没扫到的问题 = 定时炸弹） │
│ Vet → "筛准"（误报太多 = 浪费人力） │
│ Prioritize→ "排好"（什么都做 = 什么都做不好） │
│ Plan → "做实"（没有计划 = 改了等于没改） │
│ │
│ 缺任何一步都会出问题： │
│ · 没 Recon → 扫错范围 │
│ · 没 Audit → 漏掉问题 │
│ · 没 Vet → 误报爆炸 │
│ · 没 Prior → 抓不到重点 │
│ · 没 Plan → 无法执行 │
│ │
└─────────────────────────────────────────────────────────┘与传统代码审查的对比
┌─────────────────────────────────────────────────────────┐
│ 传统 Code Review vs /improve 工作流 │
├─────────────────────────────────────────────────────────┤
│ │
│ 传统 Code Review： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 被动：等 PR 来了才看 │ │
│ │ · 主观：靠审查者的经验和状态 │ │
│ │ · 不全面：看到什么挑什么 │ │
│ │ · 不可重复：不同人审，结果不同 │ │
│ │ · 无优先级：所有问题混在一起 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ /improve 工作流： │
│ ┌─────────────────────────────────────────────────┐ │
│ │ · 主动：自己跑，不等 PR │ │
│ │ · 客观：按维度和标准扫描 │ │
│ │ · 全面：每个维度都覆盖 │ │
│ │ · 可重复：同样输入 → 同样输出 │ │
│ │ · 有优先级：P0/P1/P2 分得清清楚楚 │ │
│ │ · 可执行：直接产出计划，不只是"发现问题" │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘收尾金句
- 代码写完不是终点，持续改进才是
- /improve：把"改进"从感觉变成工程
- 五步法：Recon → Audit → Vet → Prioritize → Plan
- 每一步都有明确的输入、输出和质量标准
- Recon：看清楚项目长什么样
- Audit：按维度穷尽扫描，找全问题
- Vet：过滤误报，只留可信发现
- Prioritize：多维度打分，排出优先级
- Plan：翻译成可执行的任务计划
- 13 个子命令覆盖日常改进、上线体检、合规审计、PR 自查全场景
- 用工程化流程替代"凭感觉改"，让代码库持续自我进化
/improve 工作流：五步法让代码库持续自我进化
从"改 bug"到"持续改进"，从凭感觉到工程化