移除服务器一年：拒绝盲目加 AI

现在随便哪天打开 DEV 首页，基本都能看到 AI 生成的组件工具、号称能“生成生产级代码”的 AI prompt，或者某个上个月还没有聊天功能、现在却硬塞进了 chatbot 的产品。我写这篇文章并不是为了嘲讽这些东西——其中有些确实很有用。但它们形成了一种奇怪的引力：无论讨论什么产品路线图，最后总会有人问一句：“这里要不要加 AI？”哪怕面对的根本不是一个需要 AI 的问题。

我选择了相反的方向。过去一年里，我一直在构建一个拥有 70 多款工具的图片与 PDF 处理平台。在这个过程中，真正棘手的工程问题并不是“如何加入 AI”，而是“如何移除服务器”。

一个没人炒作的无聊问题

大多数图片和 PDF 工具都会把你的文件上传到服务器，在服务器上完成处理，再把结果发回来。这种方案简单、成熟、大家也很熟悉，但它恰恰是我投入最多工程精力试图消除的部分——并不是因为服务器不好，而是对于相当一大类工具而言，比如调整尺寸、压缩、格式转换和裁剪，文件根本没有理由离开你的设备。现代浏览器完全可以自行完成这些工作。

这里不需要任何 AI 模型。只需要 Canvas API、针对压缩参数的二分查找，以及真正确定性的处理结果——同样的输入始终会得到同样的输出。事实证明，这一点非常重要：当有人为了提交政府表格而压缩证件照时，他们需要相信这个工具不会悄悄对照片做出某种不可预测的处理。

我确实考虑过使用 AI，但最终没有用

公平地说，我确实评估过是否要在几个功能中使用 AI：

护照照片的自动裁剪与智能取景——理论上，AI 模型可以检测人脸位置并给出裁剪建议。但我最终上线的是一种更简单的几何方案：检测面积最大的连续肤色区域，然后将其居中。因为这种方案能够即时完成、支持离线运行，而且最关键的是，它的失败方式是可预测的。AI 自动裁剪出错时，你往往很难看出原因；基于规则的方法出错时，你通常可以准确判断究竟是哪项假设不成立。

智能压缩建议（“这张图片看起来还能进一步压缩，而且不会造成肉眼可见的画质损失”）——在这里接入一个基于 AI 的画质评估模型，确实很有吸引力。但最终，我采用了一种没那么令人兴奋的方案：围绕目标文件大小进行二分查找。因为它足够快，完全可以在客户端运行，不需要调用 API，也不依赖网络连接，更不会产生每次使用都要承担的持续推理成本。

这两个决定都不是因为“AI 不好”，而是因为：“当确定性方案能够以同样好的效果解决这个特定问题，而且速度更快、成本为零时，就没有必要使用概率模型。”

由此引出的一个令人不安的问题

如果当前这波“给产品加上 AI”的决策中，有相当一部分确实源于真实的能力缺口，那当然很好——尽管上线就是了。但我怀疑，其中也有相当一部分更接近 FOMO，而不是因为 AI 真能比现有技术更好地解决某个实际问题。那些确定性、无聊且经过充分验证的方法，不会像“我给自己的待办事项应用加了 AI”那样在 “Show HN” 上迎来流量高峰——哪怕对于那个具体问题而言，无聊的方法客观上才是更好的工程选择。

我并不认为这意味着 AI 整体上被高估了——有些问题类别，例如真正模糊的分类、自然语言理解和生成式任务，本来就是 AI 最适合发挥作用的地方。我认为，真正值得在产品上线之前认真思考的问题是：“我选择 AI，是因为它确实是最合适的工具，还是仅仅因为它更有话题性？”而不是等上线之后才开始反思。

最终成果就是 ResizeHub——70 多款工具，整个处理流程中完全没有 AI，也从来没有任何服务器接触用户文件。事实证明，“无聊而确定”的方案，才是整个过程中更困难、也更有意思的工程问题。

我真的很好奇其他人在这件事上的选择——你是否上线过某项 AI 功能，后来却感到后悔？或者你是否放弃过某项 AI 功能，并庆幸自己做出了这个决定？我并不是想引发一场反 AI 的围攻，只是真的很好奇那些最终走向不同结果的真实案例。

如果你想采取进一步措施，可以考虑屏蔽此人和/或举报滥用行为。