临近年底，Raycast 推出了 2025 Wrapped 年度报告。在我高频使用的扩展列表中，Images Compression（Zipic 的 Raycast 扩展）毫无悬念地占据了榜首。
对于博主而言，如何在保证画质清晰的前提下尽可能压缩体积，是一项每日必修课。而 Zipic 正是过去两年中帮助我实现“优雅与高效”平衡的最大功臣。它不仅是一个压缩工具，更代表了一种极致的原生开发体验。
为了挖掘这背后的故事，我特意邀请了 Zipic 的作者 十里 复盘了产品从 0 到 1 的全过程。由于内容过于详实，我将原文拆分为三个篇章：产品设计（本文）、分发与售卖 以及 技术细节复盘。
做独立产品这件事，说起来容易，真动手了才知道水有多深。Zipic 从一个职场工作的小需求，到现在成为我一直在做的主力产品，中间踩过的坑、学到的东西，远比我预想的多。
嗨，大家好，我是十里👋！今天这篇文章想聊聊开发 Zipic 过程中一些真实的技术挑战和决策思考，不是教程，更像是创造记录。希望对同样在 macOS 平台折腾的创客们有点帮助。
从痛点到产品
在前公司做产品经理期间，日常工作离不开文档和 PPT，每份方案都要配大量截图和流程图。文件体积慢慢成了困扰——一份 PPT 动辄几十上百 MB，传文件要等，存几个版本就占掉好几百 MB，打开还卡顿。印象最深的是外包公司交付过一个 600+ MB 的 PPT，在我那台 256GB 的 MBP 上格外扎眼。
从“不爽”到“动手”
根源其实是图片。每张截图几 MB，塞进文档里体积自然爆炸。与其抱怨文档大，不如先把图片压一压。
找了几个工具，选定了图压，设计不错、效果也好。但用久了有些不满足：应用体积大（Electron 通病）、交互方式单一、支持格式有限。脑子里冒出念头：“要不自己做一个？”
琢磨了一阵后定位清晰了：与其事后压缩文档，不如从源头把图片处理好。Zipic 要做的就是图片压缩这个基础需求——更原生、更轻量、更灵活。
Zipic 的核心原则
- 小而美：专注图片压缩，把这一件事做好
- 原生体验：用 SwiftUI 开发，完全遵循 macOS 的设计规范
- 高效灵活：支持更多快捷的交互方式
- 格式丰富：支持更多常用的图像/文档格式
- 隐私安全：所有处理都在本地完成，不上传任何数据
虽然最后确定做图片压缩工具，但文档压缩功能一直在我的 Roadmap 里。计划 2.0 大版本会支持文档和视频压缩，让它变成一个从源头到最终优化的完整方案。
不过那是后话了。接下来聊聊做 Zipic 过程中遇到的一些问题和经验。
产品迭代中的决策思考
代码写得再漂亮，用户用起来不顺手也是白搭。Zipic 从第一版到现在经历了无数次迭代，每一次改动背后都有用户反馈在驱动。
UI/交互优化的迭代过程
第一版 Zipic 的界面我自己觉得挺好的——简洁、干净、macOS 风格。但上线后很快收到反馈：“图片压缩前后的对比在哪里看？”“怎么知道压缩效果好不好？”
我当时的设计是只显示压缩后的文件大小和压缩率，觉得数字已经足够说明问题了。但用户不这么想，他们想亲眼看到画质有没有损失 😅
用户反馈的收集渠道：应用内反馈入口、Twitter/X 关键词监控。负面反馈往往最有价值。
对比视图：给用户“确定感”
用户反馈“想看压缩效果”，表面是功能需求，深层是心理需求——他们需要确认“压缩没有毁掉我的图片”。
压缩率 85%、节省 2MB 这些数字是理性信息，但用户的担忧是感性的：“画质真的没变差吗？”数字无法回答这个问题，只有亲眼看到才能安心。
所以我加入了对比视图：左右滑动查看压缩前后差异，支持缩放到像素级对比。技术上不复杂，就是两张图片叠加用一个可拖动的分割线控制显示区域。
产品决策上有个权衡：对比视图需要同时加载原图和压缩图，会影响处理速度。最终选择默认关闭但易于开启——不影响追求效率的用户，但需要确认的用户随时可以查看。这种“渐进式披露”的思路在很多场景都适用：核心流程保持简洁，高级功能按需展开。
多种压缩入口：融入用户已有的工作流
最初 Zipic 只支持拖拽到主窗口、选择文件、拖拽到 Dock 图标这些基础操作。用起来没问题，但总觉得“还不够”。
后来想明白了：问题不在功能本身，而在于用户必须中断当前工作来使用工具。写博客时想压缩截图，得先打开 Zipic，再把图片拖进去——这个“切换成本”虽然只有几秒，但足以打断心流。
解决思路是：不要让用户适应工具，而是让工具融入用户已有的工作流。于是陆续加入了：
- 文件夹监控：设置好监控目录后新图片自动压缩，用户甚至不需要主动操作
- 剪贴板压缩：复制图片后直接粘贴即可压缩，截图工作流完全不用中断
- Notch 拖放：把文件拖到刘海屏的 Notch 区域直接触发压缩，不需要先打开窗口
- 效率工具联动：提供 Raycast 扩展和 URL Scheme 支持，键盘党在 Finder 选中文件后敲个回车就能压缩，完全不需要触碰鼠标
这些入口让 Zipic 从“需要专门打开的工具”变成了“随时可调用的助手”。设计工具类产品时，值得思考：用户在什么场景下需要这个功能？能不能在那个场景里直接触发，而不是让用户绕一圈？
预设功能：减少重复决策
早期版本每次压缩都要手动选质量和格式。功能上没问题，但用久了会发现：90% 的情况我都选同样的配置，为什么每次都要重新选一遍？
这是个认知负担的问题。每次选择都消耗一点注意力，虽然单次微不足道，但累积起来会让工具变得“累”。
预设功能的本质是把重复的决策固化下来。用户只需要思考一次“我通常需要什么配置”，之后就是一键完成。这个思路延伸一下：任何高频且模式固定的操作，都值得考虑提供“记住我的选择”的能力。
欢迎窗口：展示而非告知
1.8.0 版本加入了欢迎窗口（Onboarding），解决的是功能发现问题。
Zipic 的功能越来越丰富，但数据显示很多用户只用基础的拖拽压缩，Notch 拖放、文件夹监控这些主打功能反而没人知道。功能做了但用户不知道，等于没做。
用户很少会认真看文字说明。原因很简单：阅读是有成本的，用户打开一个工具是想完成任务，不是来学习的。
我的思路是：展示而非告知。与其用文字解释“你可以把文件拖到 Notch 区域”，不如直接用动画演示这个操作。用户一眼就能 get 到“原来还能这么用”，不需要理解任何文字。
技术上选择 Lottie 作为动画格式——文件体积小、支持矢量缩放、可精确控制播放。每个功能点做了一个循环动画，展示具体的操作手势和反馈效果。欢迎窗口分四步：欢迎页 → 依赖安装（自动完成）→ 功能轮播 → 完成页。用户可以点击指示器跳转，不用非得按顺序看完——尊重用户的时间。
有个细节：动画做了亮色/暗色两套主题适配，根据系统外观自动切换。工作量翻倍，但视觉一致性很重要，用户不应该在暗色模式下看到一个刺眼的亮色动画。
上线后有用户说“原来 Zipic 还能文件夹监控自动压缩，太方便了”——这正是我想要的效果。功能的价值只有在被使用时才能体现。
功能优先级的权衡
免费版 vs Pro 版的边界
这个问题纠结了很久，定价策略直接影响用户转化和产品口碑。最终的划分逻辑是：免费版覆盖核心需求，Pro 版提供效率提升。
- 免费版：基础压缩、常见格式（JPEG、PNG、WebP、HEIC）、有限格式转换、每天 25 张限制
- Pro 版：无限批量、更多格式（AVIF、TIFF、PDF、GIF）、完整格式转换、文件夹监控、剪贴板压缩、Notch 拖放、无限预设等
这样划分的考虑是：偶尔压缩几张图的用户免费版完全够用，不会觉得被限制；而重度用户（设计师、博主、开发者）会很自然地为效率付费。
功能丰富度 vs 产品复杂度
每增加一个功能界面就复杂一分，我的原则是：宁可少做，不要做成四不像。
举个例子，有用户建议加入“图片裁剪”功能。需求合理吗？合理。但加进来后 Zipic 就从“压缩工具”变成“图片编辑工具”了，定位会模糊。最终没有采纳，而是推荐用户用系统自带的预览 app 裁剪后再压缩。
类似被我拒绝的需求还有：上传图床、图片拼接……这些都是好功能，但不属于 Zipic 的边界。
性能要让用户感受到
性能优化不仅仅是代码层面的“跑分”，更是用户在使用产品时的真实体感。
内存管理的隐形体验
图片压缩是内存密集型操作。一张 8000×6000 的照片解码到内存要占用近 200MB，如果处理不当，用户最直观的感受就是：电脑风扇狂转，甚至应用直接崩溃。
为了避免这种情况，Zipic 采用了流式处理 + 及时释放的策略——不是先把所有图片加载到内存，而是处理完一张立即释放。缩略图预览则采用了下采样技术，只加载所需分辨率。这些后端的技术决策，反映在前端就是“轻快、不卡”。
拒绝“假死”：及时的进度反馈
批量处理时用户最怕的是应用“假死”——界面卡住，不知道程序在干什么只能干等。这也是性能体验的一部分：心理等待时间。
我的做法是提供整体进度条（已完成/总数）和预估剩余时间（根据已处理文件的平均耗时动态计算），让用户对整个过程有清晰的预期，缓解等待的焦虑。
关于 ImageIO 下采样和双队列并发的具体技术实现，我会在本系列的 技术细节复盘 中详细展开。
做独立产品的心得体会
回顾 Zipic 从想法到产品的整个过程，感慨挺多的。这一路走来有兴奋、有焦虑、有成就感，也有不少“早知道就……”的时刻。
技术选型的思考
做 Zipic 之前我也纠结过：要不要用 Electron 或者 Tauri 这类跨平台方案？一套代码多平台运行听起来很诱人。
但最终还是选择了 Swift + SwiftUI 原生开发。原因很简单：我要做的是“macOS 上最好用的图片压缩工具”，而不是“能在多个平台勉强运行的工具”。
原生开发的优势很明显：应用体积小（Zipic 只有 12MB 左右），启动速度快，内存占用低，和系统的融合度高。SwiftUI 的声明式语法写起来也很舒服，配合 Xcode 的预览功能 UI 开发效率挺高的。
当然 SwiftUI 也有它的坑——在复杂场景下性能不如 AppKit，有些系统 API 还是得用 AppKit 桥接。Zipic 的主窗口最终就是用 AppKit 重构的，才解决了一些边界情况的问题。
我的建议是：如果你的目标用户主要在一个平台，原生开发值得考虑。跨平台方案适合快速验证想法，但要做到极致体验，原生还是有不可替代的优势。
产品与技术的平衡
作为开发者很容易陷入“技术炫技”的陷阱——看到一个新框架很酷就想用上，看到一种新架构很优雅就想重构。但用户不关心你用了什么技术，他们只关心：这个工具能不能帮我解决问题？用起来顺不顺手？
用户反馈驱动开发，而不是技术兴趣驱动开发。每个功能上线前问自己：这个真的是用户需要的吗？还是只是我觉得“应该有”？
独立开发的挑战
独立开发最大的挑战不是技术，而是一个人要扮演太多角色：产品经理、UI 设计师、前端开发、后端开发、运营、客服……时间管理变得特别重要，我的做法是按周规划，每周只聚焦 2-3 个核心任务，那些“可以做但不紧急”的事学会放到下一周甚至下个月。
营销是技术人最容易忽略的短板，这是一门大学问。很多开发者（包括曾经的我）觉得“产品好自然有人用”，但可能会变成 好酒也怕巷子深。市面上同类产品太多了，大多数用户根本没机会发现你，好的产品也可能看到的人很少。
我的体会是：在不擅长营销的时候，可以立马做的就是尽可能增加曝光。今年黑五我从 11 月中旬就开始准备，在 GitHub 上各种黑五优惠合集仓库提交 PR，最终成功提交了 11 个站点。效果很明显：Zipic 和 Orchard 这次黑五两款产品加起来的销售额是去年 Zipic 黑五活动期间的两倍多。
Reddit 也值得重视。去年黑五的订单大部分来自我在 r/macapps 发的一个帖子，一个帖子带来的转化很多，也可认真评论帖子自荐产品；Reddit 也是发掘用户需求的好地方。
说到底，有收入才能可持续。技术再好、产品再精致，卖不出去就是自嗨。独立开发不是纯粹的技术活，学会营销、学会推广，是必修课（小学生艰难修行中🫠）。
还有一点：要学会接受“不完美”。初期版本可能有瑕疵，但先发布、收集反馈、快速迭代，比憋一个“完美版本”更有效。
对未来的展望
Zipic 的 Roadmap 里还有很多想做的事：视频压缩、文档压缩（终于要把最初的想法捡回来了）……一步一步来吧。
对于同样想做独立产品的朋友，可以试着 先从解决自己的问题开始。日常遇到的痛点很可能也是别人的痛点。从小需求切入，做一个“小而美”的工具，比一上来就想做一个“大而全”的平台更容易有正向反馈。Zipic 是我辞职做独立开发后的第一款产品，它让我验证了这条路是可行的。
最后，感谢每一位使用 Zipic 的用户。你们的反馈、建议、甚至吐槽，都是我继续前进的动力。
“优雅而高效地解决用户问题，才是产品的价值所在。“
Zipic
如果你对 Zipic 感兴趣，可以访问 官网 下载试用，pdocs.zipic.app 有详细的帮助说明。有任何问题或建议，欢迎随时联系我！