# 浪费案例与正确做法

本 skill 的来源是一次真实会话的复盘，判定标准是「该动作对结论有没有贡献，能不能避免」，
以及用户在等结果上付出的时间。规则正文在 `SKILL.md`，本文件解释每条规则为什么存在。

## 案例 1：先实现后验证（代价最高）

- 多余动作：用户指定了新格式 `20260918T1722`，于是把生成脚本、README、契约文档、测试
  全部按该格式改完，之后才去验证排序语义。
- 结果：验证发现该格式在同一天会小于旧格式包（Debian 把字母排在标点之前），同一批文件
  全部重写一遍。
- 正确做法：拿到格式先用一条 `dpkg --compare-versions` 比对真实旧包与候选格式，确认排序
  语义成立，再动手写代码、文档与测试。一条命令的成本 vs 整套返工。
- 附带教训：验证结果只用于「向用户报告并给选项」，不代表可以替用户改需求。

## 案例 2：无边界扫描

- 多余动作：`grep -rln <模式> /home/<user>`、`find /home/<user> -maxdepth N` 用来找分支、
  查找第三份脚本副本。
- 结果：连续三次因输出过大或命中会话日志被中断，零有效产出，还占掉多轮交互。
- 正确做法：搜索限定在已知代码目录、精确路径或 `git ls-files`；`find` 先确认目标深度。
  用户家目录下的会话记录、缓存、`node_modules` 不该进入扫描范围。

## 案例 3：根因已定后继续追无关线索

- 多余动作：根因（版本精度不足 + 字符串排序）已确认后，逐仓库执行 `git branch -a`、
  翻 `packed-refs`、查看多个仓库，试图找出「是哪个项目产出的包」。
- 结果：对结论零贡献，多轮浪费。
- 正确做法：定位生成脚本（一次精确搜索即可）≠ 定位项目。需要项目信息时直接问用户，
  或只在用户指明的目录里找。

## 案例 4：主动扩大改动范围

- 多余动作：用户只要求修本仓库，却顺手把另一仓库里的 vendored 副本一起改了，还想继续
  找「是否还有第三份副本」。
- 结果：用户明确质疑越权；改动随后被撤销。
- 正确做法：改本项目之外的目录前，先判断必要性并向用户确认；用户没点名的仓库不动。

## 案例 5：自造的返工

- 排序脚本方向写反、把说明性注释写进版本号字符串导致工具报语法错误、把注释插入函数调用
  参数中间导致语法错误、时间戳算错（当地 10:00 记成 02:00）、断言方向写反。
- 每一项都多花一轮重跑。
- 正确做法：算完先打印一次确认；注释放在语句之外；小样本先跑通；结果异常先怀疑自己的
  输入，而不是先怀疑结论。

## 案例 6：测试范围失控

- 多余动作：只改了某个子目录，却跑了全量测试（数百个），随后排查其中几个与本改动无关的
  失败（失败测试只读取另一个未改动的目录）。
- 正确做法：按 diff 影响面选择测试范围；无关失败只在汇报里说明，不投入排查轮次。

## 使用方式

开工前过一遍 `SKILL.md` 的 4 问；交付前过一遍自检。发现新的浪费模式时，把案例补进本文件，
并检查是否需要在 `SKILL.md` 增加或收紧一条规则。