翻一下自己的插件目录：三十多个扩展、十几个命令行工具、四套笔记应用。真正常用的，用一只手数得过来。剩下的不是没用过，而是每个都只学了 20%——知道它能干什么，不知道它在这套工作流里该干什么。工具堆叠的真实成本不在安装，而在每次打开时重新判断"这个该用哪个工具"的那两秒。
收敛不是极简主义，是把有限的学习预算集中到少数工具上，让边际收益真正兑现。
1. 工具堆叠的三种成本
| 成本 | 形态 | 摊在什么时候 | 是否可感知 |
|---|---|---|---|
| 学习 | 每个工具停在入门水平 | 每次遇到边界情况都要查文档 | 低，因为分散 |
| 切换 | 上下文重建、格式转换 | 每次任务切换 | 中，但被归因为"忙" |
| 维护 | 升级、改配置、修坏掉的集成 | 不定期，集中爆发 | 高，但被当成意外 |
三种成本叠加后是复合损失：n 个工具、每个掌握 20%，可用能力不是 n × 20%，而接近 20%——能力来自"在同一工具里把常用路径连成肌肉记忆"，这一层只有专精才产生。
# 三十天真实使用面：只统计实际执行的命令，不统计装了什么
$ awk '{print $1}' ~/.bash_history | sort | uniq -c | sort -rn | head -30
$ ls ~/.config | wc -l # 配置目录数 ≈ 曾经认真配过的工具数
2. 收敛的判据
| 判据 | 通过条件 | 不通过的典型表现 |
|---|---|---|
| 近一月使用次数 | 每周至少一次进入主路径 | 只在"那次要做 PDF"时用过 |
| 是否替换了原有工具 | 明确替代了某个旧工具 | 与旧工具并存，二选一靠心情 |
| 能否被一条命令替代 | 替代后损失可忽略 | 它做的事别处做不了 |
| 是否有专属场景 | 场景可一句话描述 | 场景与另一个工具重叠 |
| 学习投入是否已回本 | 已过"查文档才能用"阶段 | 每次用都要翻 help |
最容易挂的是"与旧工具并存"。并存不是过渡而是长期状态：维护成本按并集算，收益按交集算。
3. 三个层级与数量上限
| 层级 | 定义 | 建议上限 | 超限后的处理 |
|---|---|---|---|
| 必需 | 断了就没法工作 | 5–7 个 | 不设限，但每个必须过"回本"判据 |
| 加速 | 让常见任务快一倍以上 | 5 个以内 | 新进一个，必须淘汰一个 |
| 尝鲜 | 正在评估、尚未决定 | 3 个以内 | 到期未转正即卸载 |
上限的作用不是限制数量，而是强迫排序：没有上限，所有工具都会滑进"必需"，因为"暂时还用得上"永远成立。
# 层级标签写在工具清单里，不写在脑子里
必需：shell, editor, git, ssh, jq
加速：fzf, ripgrep, tmux, direnv
尝鲜：试用截止 12-01 —— 新终端模拟器
4. 同一职能只保留一个，以及例外
| 职能 | 保留一个的理由 | 允许两个的例外条件 |
|---|---|---|
| 编辑器 | 快捷键与插件生态不可迁移 | 一个终端内、一个 GUI，场景互斥 |
| 搜索 | 索引与排除规则重复维护 | 一个全文、一个结构化查询 |
| 版本控制前端 | 心智模型冲突 | 一个命令行、一个图形化查历史 |
| 笔记 | 检索与链接模型不同 | 一个速记入口、一个长期库，且有明确流转规则 |
例外要满足两条：场景互斥（不在同一次任务里来回切），且有流转规则（数据从哪进、到哪去）。"两个都挺好用"不算例外，那是没做决定。
5. 配置的可迁移性
收敛的前提是"换台机器能复原"。配置不能复原时，工具越多，重建成本越高，于是人会倾向于不换机器——工具链反过来锁住了环境选择。
# 最小可迁移集：只版本化入口与清单，不版本化工具自身状态
$ tree -L 1 ~/dotfiles
dotfiles/
├── shell/ # rc 文件与 alias
├── editor/ # 配置，插件清单而非插件本体
├── tools.list # 需要安装的工具清单（可一键装）
└── bootstrap.sh # 恢复入口
插件本体、缓存与索引不进版本库：体积大、平台相关，且能由清单重建。恢复脚本的目标是"一条命令回到可用"，不是逐字节还原。
6. 插件与扩展的边际收益递减
| 插件数量区间 | 边际收益 | 边际负担 | 净效果 |
|---|---|---|---|
| 少量（个位数） | 高 | 低 | 明显变快 |
| 中等 | 中 | 中 | 打平 |
| 偏多 | 低 | 高（加载、冲突、升级） | 变慢，且行为不可预期 |
| 过多 | 接近零 | 很高 | 开始怀疑"是不是编辑器的问题" |
# 启动耗时是唯一诚实的插件收益指标
$ time zsh -i -c exit # shell 侧
$ nvim --startuptime /tmp/st.txt +q # 编辑器侧，看 top 慢项
数量本身不是问题，数量与使用频次的比值才是：装 20 个、常用 3 个，那 17 个在纯付加载成本。
7. 快捷键与肌肉记忆的沉没成本
肌肉记忆是最难迁移的资产：换工具要推翻重学，而学习期正落在产出压力最大的时候。于是"更好但不想重学"是理性判断，不是惰性。
| 情形 | 迁移成本 | 判断 |
|---|---|---|
| 核心编辑动作（移动、选择、重构） | 高，数周 | 只在收益是量级差时迁移 |
| 外围操作（开关面板、切窗口） | 中，数天 | 可迁移，但不必为小收益迁 |
| 一次性脚本 | 低 | 不必迁移，重写更快 |
判据：核心动作的迁移只在"把某类任务从分钟级降到秒级"时值得，否则把旧配置带过去比换工具划算。
8. "尝鲜区"的制度化
| 制度要素 | 具体做法 | 不做会怎样 |
|---|---|---|
| 沙箱 | 独立配置目录或容器，不污染主配置 | 试用失败留下残留 |
| 试用期 | 写死截止日期，写进清单 | "再用一阵看看"变成永久 |
| 转正条件 | 明确写出"满足什么就替换旧工具" | 无法判断，只能凭感觉 |
| 到期动作 | 转正或卸载，二选一，不许延期 | 尝鲜区膨胀成第二个堆叠区 |
# 尝鲜登记（三行以内，到期必须处理）
名称：新终端模拟器
试用截止：2026-12-01
转正条件：启动耗时低于现用方案且配置可迁移
到期结论：（空着，到期当天填）
没有截止日期的试用等于一次没有结束条件的采购。
9. 卸载的判断与迁移成本
| 信号 | 含义 | 动作 |
|---|---|---|
| 三个月未进入主路径 | 不在真实工作流里 | 卸载，保留配置在 dotfiles 历史里 |
| 只在"以后可能用"的清单里 | 需求是想象的 | 卸载，需要时重装 |
| 已被另一个工具覆盖 | 职能重叠且旧的不占优 | 卸载旧的，先迁移数据 |
| 卸载会破坏别的东西 | 存在隐性依赖 | 先解耦，再卸 |
| 维护成本高于收益 | 每次升级都要修 | 换掉，而不是留着凑数 |
卸载的真实阻力是迁移成本而不是情感：先算"迁移要多久"再决定——迁移两小时、每周省十分钟，三个月回本；迁移两天、每周省五分钟，一年不回本。
10. 个人偏好与团队统一
| 维度 | 个人收敛范围 | 不在个人范围 |
|---|---|---|
| 编辑器 | 可自选，但需保证格式与钩子一致 | 团队规定的格式化与提交钩子 |
| shell 与别名 | 完全自选 | CI 脚本依赖的运行时 |
| 构建与依赖管理 | 不宜自选 | 版本锁定与产物一致性 |
| 提交信息与分支规范 | 不宜自选 | 评审与追溯依赖它 |
分界线是产物是否离开你的机器：只影响本地的选择归个人，影响产物与他人复现的归团队。动后者会把个人偏好变成别人的排障成本。
11. 度量方式
| 指标 | 采集方式 | 观察什么 |
|---|---|---|
| 一周使用日志 | 命令历史 + 应用启动记录 | 实际用到的工具集合 |
| 卡点数 | 每次"这个怎么弄"记一条 | 学习未回本的工具 |
| 启动耗时 | 计时命令，固定环境重复测 | 插件与配置的真实负担 |
| 配置重建时间 | 新机器从零到可用的耗时 | 可迁移性的直接读数 |
| 切换次数 | 一天内在几个工具间跳 | 职能重叠的规模 |
# 卡点日志：一行一条，只记"卡住"这件事，不写解决过程
$ printf '%s\t%s\n' "$(date +%F)" "想批量改名，忘了 rename 的参数" >> ~/toolchain-friction.log
"卡点数"最能反映学习是否回本：集中在某几个工具上说明还在门外；均匀分布说明工具太多。
12. 复盘频率
| 周期 | 动作 | 时间成本 |
|---|---|---|
| 每周 | 扫一眼尝鲜区，确认截止日 | 两分钟 |
| 每月 | 看使用日志，标记三个月未用的 | 十分钟 |
| 每季 | 重跑启动耗时，清一次插件 | 半小时 |
| 每年 | 从零重建一次配置，验证可迁移性 | 半天 |
每年重建最容易被跳过，也最有价值：它同时验证清单是否完整、脚本是否还能跑、以及那几个"必需"是否真的必需。
13. 排错
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 装了新工具，旧的习惯没变 | 新旧并存，没有淘汰规则 | 强制二选一，删掉旧的入口 |
| 启动越来越慢 | 插件与配置累积 | 跑启动耗时，按 top 慢项砍 |
| 换机器后效率腰斩 | 配置未版本化，靠记忆重建 | 补工具清单与 bootstrap |
| 总觉得"工具不对" | 卡点分散在多工具，非单工具问题 | 收敛职能，先减数量 |
| 尝鲜区变成常驻 | 无截止日期 | 补日期，到期二选一 |
14. 边界
| 场景 | 为什么不该收敛 | 该做什么 |
|---|---|---|
| 职业早期（前两三年） | 没见过足够多的解法，判断没有依据 | 广泛试，用尝鲜区制度兜住 |
| 专精领域 | 领域工具多且不可替代，各有专属场景 | 只收敛通用层，专业层按场景保留 |
| 团队强制统一 | 不在个人决策范围 | 遵守，个人偏好在边界内表达 |
| 工具本身是工作对象 | 需要广度而非深度 | 不适用收敛判据 |
| 高频但极短的任务 | 切换成本高于收益 | 保留专用小工具，不进主路径 |
一句话判据：收敛"每个都能用一点"的工具，保留"某一个能用得很深"的工具。数量不是目标，学习预算的集中度才是。
15. 自测
- 三种成本叠加后为什么是复合损失？
n × 20%这个算法错在哪？ - "与旧工具并存"为什么是长期状态而不是过渡状态？成本按什么算？
- 三层分级里，"加速层"为什么用"进一个、淘汰一个"而不是数量上限？
- 同一职能保留两个工具的例外，需要同时满足哪两个条件？
- 卸载的真实阻力是什么？用什么算式判断迁移是否值得？
- 为什么每年要从零重建一次配置？它同时验证了什么？