项目记录：给常用工具做一张「替代方案」表之后

起因

某个常用工具突然调整了额度，当天就有几处流程跑不动。临时找替代时手忙脚乱，连「原来这个工具到底是干什么的」都要现想。于是做了个很笨但有用的动作：给每个常用工具配一张替代方案表。

表只留五列

「用途」那列最该写细。原来一直写「管理资料」，真到要换时才发现它实际只干了两件事，其中一件根本有更轻的替代。大词掩盖了真实依赖。

做表时参考了 Layui 镜像站 里「模块按需加载」的思路：把一套能力拆成核心与周边，核心留住，周边哪个不顺手换哪个，不必整套推倒。工具也是，真正离不开的往往只占它功能的一两成。

跑下来的观察

• 导出难度标「高」的几个，平时用得最顺，真要换却最痛；这张表提前点名了风险。
• 替代项写「够用」而非「更好」，心态稳很多，不用追求完美替代。
• 切换成本标「当天可顶」的，后来真出事时直接启用，没再慌。

适用边界

适合长期、高频、自己攒了不少内容的工具。一次性、试用型工具不必上表，硬记反而增加维护负担。另外，替代项别列太多，一个就够；列多了等于没列，真到用时还是得现挑。

小结

一张表解决的不只是「出事怎么办」，更是「我到底依赖它什么」。用途写细、替代写一个、导出难度标清，工具风险就从「突然断供」变成「早有备案」。