laily
44cee4be91
用户默认在赶时间：每个动作、每次追问、每段输出都要能缩短拿到结果的时间。 先给结论再给背景、独立命令一次发出、能自查的不问用户、同一事实不重复、 无关线索不展开、同一路径两轮无产出就换方法。 同时划清边界：省掉的是多余动作与多余追问，不是必要确认——要求与实测冲突、 越界改动、破坏性操作仍须先问。规则编号顺延为 1-7，README 与案例文件的 判定标准同步更新。
57 lines
3.3 KiB
Markdown
57 lines
3.3 KiB
Markdown
# 浪费案例与正确做法
|
||
|
||
本 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` 增加或收紧一条规则。
|