工具管理也需要产品化：一次候选池设计的真实经历

工具管理也需要产品化：一次候选池设计的真实经历

做 jianfei-github 管理闭环的时候，我卡在一个看似简单的问题上——工具列表里的东西越来越多，但每次要用的时候，找不到、不敢删、不知道哪些还活着。

这不是存储问题，是管理问题。

问题是怎么浮出来的

起因很朴素。我在维护一组 GitHub 相关的自动化工具，日常有新增、有迭代、有废弃。起初用一份 README 记录，后来发现 README 跟不上变化——谁改了参数没更新文档，谁废弃了还留着入口，新来的人根本分不清哪些能用。

更麻烦的是「候选池」这个概念始终没落地。有些工具我知道有用，但还没正式纳入管理流程；有些是实验性的，跑通了一次就搁置了；还有些是被替代了但旧版本还有人依赖。这些东西混在一起，既不是正式工具，也不是彻底的垃圾，需要一个中间状态。

但「中间状态」怎么定义？谁来决定一个候选工具该保留还是淘汰？依据是什么？

从直觉到证据

第一次尝试是给每个工具加标签：active、candidate、deprecated。加完发现没用——标签是主观判断，今天觉得是候选，明天可能就忘了为什么这么标。

真正有效的做法是给每个状态绑定证据。一个工具被标为 candidate，必须同时记录：它的来源（谁提的、什么场景需要）、它的验证状态（跑过没有、结果怎样）、它的保留理由（为什么现在不能删但也不能转正）。

这个过程让我意识到，工具管理和产品管理是一回事。你管理一个工具池，就像管理一个产品的需求池——每一条都需要来源、优先级、验证记录和决策依据。没有这些，列表就是一锅粥。

关键决策

最终的方案是三件事：

第一，候选池和正式池物理隔离。 不是同一份列表加标签，而是两个独立的清单，候选要「毕业」才能进正式池。这迫使你在转移时做一次明确的审查。

第二，每条候选必须有来源证据。 谁提出的、什么场景触发的、有没有实际使用记录。没有来源的候选直接清理，不留模糊地带。

第三，保留建议必须可追溯。 一个候选工具保留超过一定周期还没转正，系统自动标记为待审查。不是无限期搁置，而是强制决策节点。

写在后面

回头看，这件事的核心教训是：管理工具和管理产品没有本质区别。凡是有列表的地方，就需要来源追踪、状态流转和决策依据。靠感觉维护的列表，迟早会烂掉。

jianfei-github 的候选池机制上线后，工具清理效率提高了很多。不是因为我们更勤快了，而是因为规则替我们做了大部分判断——有证据的保留，没证据的淘汰，模糊的定期审查。

工具管理也需要产品化，这不是过度设计，是最低限度的秩序。