laily
146182c1b9
把一次会话复盘中确认的浪费动作固化为硬规则，面向 DeepSeek Flash / DeepSeek V4.1 Flash：先验证再实现、搜索必须有边界、只在被要求的范围内动作 （改项目外目录先问）、命令一次写对、测试按影响面、要求与实测冲突时报告并 等待确认而不擅自改需求。 不设运行时模型判定，只在 description 与正文标记适用范围，避免留出「模型标识 不匹配就不遵循」的逃生口。真实案例与代价放在 references/anti-patterns.md。
3.2 KiB
3.2 KiB
浪费案例与正确做法
本 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 增加或收紧一条规则。