Q02 · 扩展复杂度 · WORKFLOW 001
模型和插件越来越多，项目连续性要付出什么代价？
新增能力本身不是问题。问题是模型、技能、MCP 和插件是否改变结果，还是只增加配置、权限、切换和失效成本。
当前决定
当前选择
把扩展分成主路径、限时试验和移除三类；没有可观察收益的能力，不继续占用主工作流。
展开选择理由
工具越灵活，越需要人为维护它们的角色边界。否则每次换项目、换客户端或升级版本，都要重新确认安装、权限、兼容和正确用法。
Q02 / 决策地图TRIGGER → STATES → ONE ACTION
我的当前做法
为什么这样选
主工作流要少，试验区可以有边界地多。
展开经历与判断依据
我曾经把模型切换、插件数量和技能覆盖面看成灵活性。它们确实能扩大能力，但同期使用痕迹不能证明每项扩展都提高了项目完成率。
现在我更关心扩展是否在真实项目中改变结果，以及几天后恢复现场时是否还知道它为什么存在。主路径只保留高频、可解释、失败方式清楚的能力。
当前可以确认展开记录
多工具和扩展的实际使用痕迹存在；公开页面不展示本机安装清单、版本、权限或内部工具链。
仍然不能确认展开记录
每项扩展带来的净时间收益、冲突频率和长期维护成本尚未系统记录。
下次想装扩展时
下一步怎么做
给它一个七天试用期，而不是永久席位。
不需要立刻清空。先看哪些能力连存在理由都说不清。
- 01
列出当前主工具实际启用的模型、技能、MCP 与插件。
- 02
为每项写出最近一次真实使用，以及它改变了什么结果。
- 03
没有近期使用或结果证据的，移入七天待证区。
- 04
七天内仍没有真实任务需要它，就记录重新安装方式后移除。