一百多个工具页面，靠一套模板管住

写在前面 辣椒AI 里有一百多款文件处理和 AI 创作工具。这篇讲一个很实际的产品工程问题：功能各不相同的上百个页面，怎么保证体验一致、且还能持续快速上新。

一、不做标准会怎样

工具类产品最容易陷入的状态是：每个工具都是一个独立的小页面，各自设计、各自实现。

三个月后你会得到：

• 上传区域有五种样式，有的支持拖拽有的不支持
• 参数区有的在左边、有的在上面、有的藏在折叠面板里
• 有的工具能预览结果，有的直接下载，用户无法预期
• 报错提示的位置和措辞每个页面都不一样
• 新增一个工具要从零写一遍页面

用户的感受是"这个产品很杂"，团队的感受是"加个工具好慢"。

一致性的本质是降低认知负荷

当用户进入一个工具页面时，他们需要"学会"这个页面怎么用——上传区在哪、参数怎么调、结果在哪看、出错了提示在哪。如果每个工具都不一样，用户每用一个新工具就要重新学习一次。上百个工具意味着上百次学习成本。

一致性的目的是让这个学习成本趋近于零——用户通过第一个工具学会了页面结构，进入第二个工具时只需要关注"这个工具特有的参数是什么"，其他所有交互行为（怎么上传、怎么看结果、报错提示在哪）都是已知的。

二、三段式结构

我们的做法是定一条强制规则：所有工具页面必须是"上传 → 参数 → 预览/结果"的三段式结构。

┌─────────────────────────────────────────┐
│  ① 上传区域                              │
│     拖拽 / 点击 / 队列展示               │
├──────────────────┬──────────────────────┤
│  ② 参数调整       │  ③ 效果预览 / 结果    │
│  （左 5）         │  （右 7，滚动时吸顶）  │
└──────────────────┴──────────────────────┘

左五右七的栅格比例是实测出来的：参数区通常内容不多，预览区需要更大的空间。预览区在页面滚动时保持吸顶，这样用户调参数的同时能一直看到效果。

这条规则是强制的，不是建议。 新工具不按这个结构做，就不合入。

为什么左五右七

我们试过三个比例：3:9、4:8、5:7。

• 3:9：参数区太窄，控件标签经常被截断，体验不好
• 4:8：大部分参数能完整展示，但名称较长的参数（如"输出格式"的中文标签加上下拉框）仍然偏紧
• 5:7：参数舒适，预览区仍然足够大

5:7 是平衡点。如果你的参数区控件很少（只有三四个）且标签都很短，4:8 也行。比例不是绝对的，但一旦定了就全站统一——不要在工具 A 用 5:7、工具 B 用 4:8。

三、统一的上传队列

上传是所有工具的公共入口，我们把它做成一个统一组件，行为完全一致：

• 追加模式——再次选择文件是追加到队列，不是替换。这符合用户预期，而"替换"这个行为曾经导致过大量误操作。
• 单工具最多十个文件——这个上限是为了避免用户一次丢进几百个文件把队列打爆。数字可以调，但必须有上限。
• 单个文件可移除——队列里每一项都能单独删掉。
• 格式与大小校验在前端先做一遍——不要让用户等到上传完才被告知格式不支持。

统一之后，用户学会一次就会用所有工具。

上传组件的性能考虑

对于大文件（>100MB），在前端做格式校验只能校验文件扩展名和 MIME type，真正的格式完整性校验需要服务端来做。我们把服务端校验的结果通过 WebSocket 实时推给前端，失败的文件在队列里会变红并显示原因——用户不需要等整个队列处理完才知道哪个文件有问题。

对于需要上传到 OSS 的场景，统一组件内部做了分片上传和断点续传，大文件上传失败不需要从零开始。

四、约束换来的东西

这套标准显然牺牲了灵活性。有些工具的最佳形态可能并不是三段式。我们仍然坚持，因为换来的东西更值：

用户侧：可预期。 用过一个工具就会用其他所有工具，学习成本趋近于零。

开发侧：新增工具的成本大幅下降。 页面骨架、上传逻辑、参数控件、结果展示、错误处理都是现成的，开发者只需要写这个工具特有的那部分。

维护侧：改一处，全站生效。 上传组件优化一次，一百多个工具同时受益。这在没有统一组件的情况下是不可能的。

设计侧：不需要为每个工具出稿。 设计资源可以集中投入到通用组件的打磨上。

具体数字

做标准之前，新增一个工具的平均开发周期是 3-5 天（包括前后端）。做标准之后，一个只需要调系统能力的工具可以在半天内完成——后端写一个转换方法，前端套模板只需填几个配置项（标题、描述、支持的格式列表、参数定义）。

从一个 3 天的任务变成一个 4 小时的任务，这是标准化的核心收益。

五、什么时候可以破例

标准需要留口子，否则会僵化。我们允许破例的情况：

• 交互形态本质不同的工具。 比如需要在画布上直接操作的工具，硬套三段式反而别扭。
• 结果不是文件的工具。 比如生成结构化内容并支持继续编辑的工具。

破例的条件是：要说明为什么这个工具不适用标准结构，并且破例部分要单独封装，不能污染通用组件。

破例的审批流程

1. 开发者在设计文档里写明为什么三段式不适用
2. 给出替代方案，说明如何保持和其他工具的体验一致性（至少上传行为和错误提示要一致）
3. 团队 review 通过后开始开发
4. 破例的组件放在独立的目录下，标注"非标准模板"

这个流程不是为了阻拦创新，而是为了确保每一次破例都是有意识的选择，而不是偷懒。

六、这套方法适用的场景

如果你的产品符合以下特征，值得做类似的约束：

• 功能项数量多（几十个以上），且还在持续增加
• 各功能的交互模式本质相似（输入 → 处理 → 输出）
• 团队规模有限，无法为每个功能单独投入设计和开发

反过来，如果你只有五六个核心功能，每一个都值得精雕细琢——那就不要用模板把它们压平。标准化的价值来自规模，规模不够时它只是束缚。