tool-manage

一个开发者的电脑会逐渐积累全局包命令、Shell 脚本、内部 CLI、AI Coding 辅助工具和一次性自动化。命令也许仍然能够运行，但与它有关的上下文会慢慢消失：它解决什么问题、仓库在哪里、由谁维护、怎样使用、现在是否还应该保留，以及当初为什么把它加入工作流。

包管理器解决安装，运行时管理器解决版本切换，Shell alias 负责缩短输入。它们都不是为了把来源不同的本地工具整理成一个可回看的目录，特别是当一部分命令有完整的 package 元数据，另一部分只是没有任何标准说明的私有脚本时。

tool-manage 从这个“记不住”的问题出发。它不接管工具的安装与执行，而是在已经存在的命令之上增加一层登记和记忆。

产品需要通过一个克制的命令入口，完成登记工具、查看当前目录、读取单条记录、刷新元数据、补充本地说明，以及归档旧命令。有效记录也不能只有路径；描述、版本、作者、仓库、包信息和帮助预览，才足以让几个月后的自己重新理解这个工具。

它还必须同时兼容两类来源。标准 CLI 往往能从 PATH 中发现，并进一步读取 package 信息；私有脚本和内部工具可能什么都不暴露，所以同一套登记库也要接受手写 JSON 描述，而不是把这种情况当成不完整的次级方案。

完成标准不是做出功能最多的 CLI，而是让遗忘的上下文重新可查询，同时保持本地存储、较小的安装成本，以及容易记住的命令结构。

Ming 负责产品边界、命令语言、记录模型、终端呈现、代码结构、测试、文档和 npm 发布。核心工作是把一个个人工作流里的真实问题整理成公共产品，同时让它承诺的范围保持准确。

这也包括 CLI 中不容易直接被看到的判断：PATH 发现和包信息读取失败时如何处理，详情页是否隐藏空字段，手工描述怎样与自动检测的元数据共存，以及旧数据库如何在不丢失记录的情况下加入新字段。

文档被视为产品界面的一部分。公开仓库提供中英文说明、面向 AI 工作流的 JSON 规范、本地测试指引和真实终端演示，让开发者在安装之前就能理解主要流程和产品边界。

最重要的判断，是将“记住工具”和“安装工具”明确拆开。边界确定以后，数据模型和命令面只需要服务于上下文、维护和历史，不必逐渐变成另一个包管理器。

tool-manage 已作为 MIT 许可的 npm 包 `@alucpro/tool-manage` 发布，并为 Node.js 18 及以上环境提供 `tm` 命令。公开仓库包含命令实现、SQLite Schema 参考、描述模板、中英文 README、JSON 规范和自动化测试。

当前版本能够登记本机发现的命令、列出活动记录、查看已保存的元数据与帮助信息、编辑或刷新记录、生成 JSON 描述骨架、从本地或远程 JSON 导入，以及归档旧命令。运行数据保存在 `~/.tool-manage`，其中登记库使用 SQLite，旁边保留可以编辑的模板。

这个案例不使用下载量或用户量来替代成果。包可以实际安装，源码、Schema 和测试都可以公开检查，终端录屏也展示了真实命令流程；这些可验证行为就是当前阶段更准确的结果。

小型开发者工具要产生价值，往往需要先准确命名一个被忽略的层。在这里，缺失的既不是执行，也不是安装，而是持久的上下文。明确这一点以后，项目就不必膨胀成任务编排器、版本管理器或包管理器。

本地优先也与问题本身匹配。私有脚本和内部命令的目录可能包含路径、仓库、作者和帮助文字，不应该为了查询这些信息而必须创建远程账号。SQLite 提供了足够的数据结构和迁移能力，同时让资料继续留在开发者自己的机器上。

这个项目还进一步确认了可恢复性是维护体验的一部分。软删除、元数据覆盖层和明确的数据库迁移，使日常清理不会悄悄破坏有价值的历史，也让个人工具目录更值得长期使用。