从工具列表到工具平台：ZGLab Tools 规模化扩展中的架构演进

背景

一个浏览器工具项目最容易开始于几个独立页面：一个输入框、一个按钮、一段处理逻辑。但工具数量增长后，真正的问题不再是实现某个算法，而是如何管理不断增加的能力。

ZGLab Tools 从最初的 JSON、时间戳、文本处理、二维码等少量工具，扩展到几十个工具后，核心变化不是增加页面数量，而是建立了一套平台化约束。

工具数量增长带来的问题

当工具数量增加时，常见问题包括：

• 工具列表散落在多个页面；
• 路由和工具元信息重复维护；
• 新工具需要修改首页、导航和页面代码；
• 相似工具复制大量组件代码；
• 工具状态无法统一管理。

因此需要把“工具是什么”和“工具如何运行”分开。

配置驱动目录

工具注册表成为系统事实来源：

ToolDefinition
    ↓
首页目录
    ↓
搜索
    ↓
分类
    ↓
相关工具推荐
    ↓
静态路由生成

配置只描述稳定事实：

• 名称；
• 路径；
• 分类；
• 状态；
• 关键词；
• 隐私模式。

而具体算法、交互状态和页面内容仍保持独立。

标准化工具生命周期

新增工具不应该意味着新增大量基础设施。

稳定流程应该是：

1. 创建逻辑目录；
2. 编写纯函数和测试；
3. 添加交互组件；
4. 注册工具元数据；
5. 自动进入构建流程。

这种模式使新增工具的成本接近线性，而不是随着项目规模增长不断增加。

平台化的核心不是自动化，而是边界

真正可扩展的平台需要明确：

• 配置层负责“有哪些工具”；
• 页面层负责“如何展示”；
• 组件层负责“如何交互”；
• 逻辑层负责“如何计算”；
• 测试层负责“是否正确”。

自动生成页面只是结果，清晰职责才是原因。

经验总结

小工具项目向平台演进时，最重要的变化不是增加功能，而是提前设计变化发生的位置。

一个好的工具平台应该允许：

• 新增工具而不修改首页；
• 修改分类而不重写页面；
• 替换算法而不影响交互；
• 扩展功能而不破坏已有工具。