用WorkBuddy维护工具“退役清单”：什么情况下该停用
工具只会越攒越多。新增时很有仪式感，停用却没人提，于是订阅在续、书签在列、流程里还留着某个早就不用了的环节。后来我给工具箱加了一份退役清单，把“不再使用”变成一件有记录的事。
触发退役的四种情况
- 被合并：新工具覆盖了它的全部常用场景，且迁移成本已经付完。
- 停更或文档失配：连续较长时间没有更新，或文档与实际界面明显对不上。
- 只在一次项目里用过：项目结束三个月内没有再次打开。
- 维护成本超过收益：需要人工同步、手工修补、或频繁处理异常。
四条都是可判定的事实，不写“感觉不好用了”。判定条件越机械，越不会因为一时不顺手误杀工具。
清单里记什么
工具名、退役日期、触发哪一条、数据是否已导出、替代方案、原链接。第三项和第四项最重要：一个是决策依据，一个是退出前的必做动作。少了“数据已导出”这一栏，退役就等于丢数据。
导出与回退这类检查项，可以照 BackendWiki 关于配置与数据处理的条目 列成固定字段；文档跟不跟得上版本，则回到工具的官方说明确认。
WorkBuddy 承担什么
三件机械活：
- 按固定字段把待退役项补齐，并标出缺“数据已导出”确认的记录；
- 每月扫一遍使用记录，列出“三个月未打开”的候选，交人工判断；
- 退役后把该工具从常用清单里移除，同时保留一条归档记录与原因。
第 3 步里的“移除但保留归档”是关键：清单的目的不是忘掉，而是不让它继续占用注意力。把扫描固定成每月流程，可参考 WorkBuddy 官方文档 的任务编排说明。
清单本身放在一个静态页面里就够，HTML 入门教程站的纯静态思路 适合这种低频更新、偶尔要查的记录。
复盘
跑了两个月，退役了五个工具，其中三个属于“只在一个项目里用过”。真正省下的不只是订阅费，还有每次翻工具箱时的犹豫。新增很容易，退出需要一套规则——这份清单就是那套规则。