量子原创春节收假回来第二周，我还在收拾手头一个半烂尾的图表项目，又看到两段让自己有点坐不住的聊天记录：一个做公众号的朋友在群里问，有没有办法把设计稿导出的图压到 2MB 以内，平台后台上传总是提示“图片过大”；另一个卖手作的朋友说，想一次发九张图，但希望每张都是同一套图的局部素材，已经连续换了好几个网页工具，不是要注册就是要下载App。也是在那几天，我决定把心里念叨了很久的“轻量图片处理”这件事真正落地，于是就有了逐影图像工坊。这是一款微信小程序，核心目标很朴素：把 7 个高频图片工具——压缩、裁剪、九宫格切图、长图拼接、格式转换、加水印、简单标注——装进微信里，真正用完即走。文章不打算晒数据、讲大道理，只把从立项到上线的两周过程里，那些取舍、踩坑、实现细节完整过一遍。
1. 立项逻辑：被真实需求撞过以后，再决定做什么
1.1 三类用户画像，指向了同一个结论
我最初并没有马上敲定功能清单，而是先把“要解决谁的问题”想清楚。从身边观察加上群里反馈，主要用户大概是这三类：
- 第一类是不熟悉图片处理软件的内容运营者。他们日常需要做封面、压缩图片、截图标注，但既没时间学 Photoshop，也不想为了一个动作装一个美图秀秀全家桶。
- 第二类是朋友圈重度用户和小微卖家。九宫格切图、长图拼接这类需求对他们来说几乎是日频的，尤其是微商和手作卖家，经常需要把同一张产品图切成细节九宫格。
- 第三类是只想要“一次性结果”的普通用户。手机里照片太多、太大，想压一压再传给别人；又或者想把 PNG 转成 JPG 方便上传。
这三类人的共同点都很明显：第一，任务足够小，不值得为了它去装一个重应用；第二，动作足够高频，可以形成搜索和使用惯性；第三，结果必须在手机端立刻拿到，而不是“传到电脑上处理再传回来”。
1.2 大而全和小而散之间，存在一个“缝隙市场”
打开微信搜“图片处理”，你能看到两条非常明显的路线。一边是头部大厂的功能集合型应用，功能确实全，但启动慢、广告多、动辄要求开会员；另一边是大量只有一个功能的单点小程序，比如“只做九宫格切图”，用完就走，可一旦用户同时需要压缩和加水印，就得来回切换好几个小程序，很难连续处理完一组图。
逐影图像工坊想填的，正是这个“不大不小”的缝隙：功能数量不贪多，只保留我自己高频用到的七个，但处理流程必须连贯。用户可以在同一套画布逻辑里连续完成“压缩、裁剪、加个水印、再导出”，不用每换一个功能就重新选一次图。
1.3 两周时间盒：功能范围是怎么圈定的
两周对于业余项目来说非常短。我当时给自己定的排期是这样的：
- 第 1～5 天：搭建工程骨架，把选图、画布初始化、导出保存这套公共链路先跑通；
- 第 6～10 天：写 7 个工具功能，能跑慢一点没关系，重点是覆盖主流程；
- 第 11～14 天：真机联调、兼容性修复、隐私配置、提交审核。
所以范围控制原则只有一个：凡是不属于“选图-处理-保存相册”这条闭环的功能，一律砍掉。比如账号体系、云端存储、历史记录同步这种听起来很美的东西，一开始就不做。工具类小程序的核心不是留存，而是完成单次任务时的爽快感，这个定位直接决定了后续技术选型和页面结构。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术路线复盘：原生微信小程序加 Canvas 2D，是风险最低的组合
2.1 为什么不直接选 uni-app 或 Taro 这类跨端框架
很多朋友会问：都 2025 年了，为什么还要从零开始用原生小程序写？其实我平时也做跨端项目，uni-app 那套生态确实很熟。但恰恰因为熟，这次才不敢把两周时间押在框架抽象层上。
图片处理的核心是 Canvas。不同端上的 Canvas 实现细节差异非常大，比如同一段绘图代码，在微信开发者工具里表现正常，到 iOS 上的 WebView 内核里可能出现边缘像素偏差；到了 Android 真机上，内存回收策略又不同。跨端框架要同时适配各家小程序，必然在这一层做兼容封装，一旦出现端差异，我就要先判断到底是业务代码问题还是框架桥接层问题，排查链路会多出一截。
这次是纯微信小程序场景，没必要为“未来可能多端分发”的想象买单。原生小程序在 Canvas 2D 接口上的跟进速度是最快的，踩坑资料也最多。两周的时间预算经不起试错，选原生实际上是选了风险最低的路线，不是最炫的路线。
2.2 页面结构：三个页面的背后是一套编辑器逻辑
逐影图像工坊没有做复杂的多级菜单，只安排了三个主要页面。
首页是工具列表和最近使用的入口。用户点进某个工具后，会先走到选图页，选完图再进入统一的编辑页。编辑页其实就是一张 Canvas 画布，外加底部操作按钮和导出按钮。选择这种结构的原因是：大部分工具对用户来说都具备“选一张图，做一步处理，导出结果”的天然心智，如果每一个工具都设计一套独立页面，我根本做不完，用户学习成本也高。
工程目录大致长这样：
code复制miniprogram/
├── pages/
│ ├── index/ // 首页，工具列表
│ ├── choice/ // 选图页，负责调用 wx.chooseMedia
│ └── editor/ // 编辑器，承载 Canvas 和全部工具逻辑
├── utils/
│ ├── pipeline.js // 选图后加载图片、初始化画布的公共流程
│ ├── exporter.js // 导出和保存到相册的统一封装
│ └── tools/ // 各工具的独立处理函数
所有工具的差异都被收敛在 tools 目录里的处理函数中，编辑器只负责把处理函数挂到按钮上。好处显而易见：新增一个工具时不需要动页面结构，只需要引入一个新的处理函数并配置入口信息。
2.3 关于旧版 Canvas 接口为什么不能碰
微信小程序早期用 wx.createCanvasContext 那套接口写绘图，当时的写法是命令式的，要为每张画布维护一个 context 对象。如果你只是画几个固定形状，它确实够用；但图片工具要对一张任意尺寸的大图反复做区域裁剪、缩放、旋转，旧接口在大量异步操作和像素级控制上会变得很难受。
新版 Canvas 2D 接口在基础库 2.9.0 之后逐步普及，获取节点的方式更像 Web 前端：
js复制const query = wx.createSelectorQuery()
query
.select('#canvas')
.fields({ node: true, size: true })
.exec((res) => {
const canvas = res[0].node
const ctx = canvas.getContext('2d')
const dpr = wx.getWindowInfo().pixelRatio
canvas.width = res[0].width * dpr
canvas.height = res[0].height * dpr
ctx.scale(dpr, dpr)
})
这段代码里有一个特别容易踩的坑：如果只用 wx.getSystemInfoSync() 获取像素比，在部分新版本基础库上会提示 API 即将废弃，而 wx.getWindowInfo() 在老版本上又不存在，所以版本兼容要提前做判断。我当时的做法是封装一个 getPixelRatio() 函数，先判断是否存在新接口，再做降级。
3. 先在公共流水线上花掉一周，是两周里最值的一笔投入
3.1 选图逻辑：很多权限问题都集中在第一步
选图是全流程的入口，这个环节如果体验不好，后面处理做得再顺都白搭。这里我直接使用了 wx.chooseMedia 替代老旧的 wx.chooseImage，因为 chooseMedia 返回的临时文件结构更清晰，而且支持直接选择视频，如果以后做视频封面提取功能，扩展起来也不费劲。
但选图环节藏着一个合规细节。当用户第一次选择图片时，小程序会触发相册读取权限；如果后续要保存处理结果，还必须拿到相册写入权限。按微信小程序现状，wx.saveImageToPhotosAlbum 对应的 scope 是 scope.writePhotosAlbum，这个权限需要在调用前用 wx.authorize 主动申请，并且在 app.json 的 permission 字段里写清楚用途：
json复制{
"permission": {
"scope.writePhotosAlbum": {
"desc": "用于将处理后的图片保存到你的相册"
}
}
}
还要提醒一点：如果用户第一次拒绝授权，再次调用 wx.authorize 是不会再次弹窗的。正确做法是先判断授权状态，如果已拒绝，就通过 wx.showModal 引导用户去设置页打开开关：
js复制const res = await wx.getSetting()
if (!res.authSetting['scope.writePhotosAlbum']) {
const modal = await wx.showModal({
title: '需要相册权限',
content: '请允许保存图片到相册，否则无法导出处理结果',
})
if (modal.confirm) {
wx.openSetting()
}
}
3.2 统一导出封装：把导出的“不确定性”收敛到一个函数里
7 个工具的后半程几乎都是同一件事：把当前画布内容导出成一个临时图片文件，再保存到相册。所以我花了比较多时间把导出动作封装成了统一的 exportCanvas。
js复制function exportCanvas(canvas, options = {}) {
return new Promise((resolve, reject) => {
wx.canvasToTempFilePath({
canvas,
fileType: options.fileType || 'png',
quality: options.quality || 1,
destWidth: options.destWidth || canvas.width,
destHeight: options.destHeight || canvas.height,
success(res) {
resolve(res.tempFilePath)
},
fail(err) {
reject(err)
},
})
})
}
这里有个细节值得展开：destWidth 和 destHeight 单位是像素，但如果不对它们做控制，图片尺寸会直接等于画布的物理像素尺寸。在 Canvas 2D 中，canvas.width 已经乘过了 dpr，所以如果不额外设置 destWidth，导出结果在高分屏上会偏大很多。对于同一张 1200px 宽的图片，在 3 倍屏设备上，canvas.width 可能已经到了 3600，直接导出的临时文件体积会成倍增加。对纯图片压缩工具来说，这是致命的逻辑浪费。
所以我的导出封装里默认把 destWidth 控制在目标尺寸，比如压缩场景的目标宽度是 2000；只有九宫格切图这种需要高分辨率素材的场景，才放开到原始尺寸。
3.3 临时文件清理：不做这一步，用户存储很快爆掉
每次 canvasToTempFilePath 都会在微信临时目录生成一张图片，临时文件会占用小程序的内存和磁盘空间。虽然系统有清理机制，但在连续处理多张图片的场景里非常不可控。我观察到的问题是：用户连续处理 10 张照片，每次都导出一个新临时文件，整个过程下来可能多出几十 MB 临时垃圾。
解决办法是维护一个“会话文件池”，页面上所有临时文件路径都放进去。每次导出新文件后，就把旧文件通过 FileSystemManager.unlink 删掉；页面卸载时再统一清理一遍。
js复制const fs = wx.getFileSystemManager()
async function clearTempFiles(filePaths) {
for (const path of filePaths) {
try {
await new Promise((resolve) => {
fs.unlink({ filePath: path, complete: resolve })
})
} catch (e) {
// 临时文件可能已被系统回收，删除失败不影响主流程
}
}
}
这条公共流水线非常值得先写，因为七个工具全部依赖它。磨刀不误砍柴工，说的就是这种底层工作。
4. 逐个实现 7 个工具：能跑通和真正好用之间，隔着一堆边界问题
4.1 图片压缩：质量参数不能解决所有问题，尺寸也要配合
图片压缩是工具列表里的入口应用。用户需求分两种：一种是只要体积小，另一种是既要体积小又不能太糊。
小程序里要压缩图片，很多人的第一反应是 wx.compressImage，这个接口确实能快速把体积压下来，但限制也比较多：它无法自定义目标尺寸，也不能控制输出的宽高比。如果你只是想把一张大图从 5MB 压到 800KB，官方接口没问题；可如果图片是 8000px 宽的设计稿截图，单纯调低 quality 后体积可能还是超标的。
所以逐影图像工坊的压缩工具走的是“先缩放、再导出”的路线。用户设定最大边目标值，比如 1920px，代码先计算出等比缩放后的宽高，把图片绘制到对应尺寸的画布上，最后用 fileType: 'jpg' 配合 quality: 0.8 导出。
压缩比的经验值可以这样看：同样一张图，quality 设为 0.9 和 0.8 时，肉眼通常看不太出差异，但体积可能差 30%；从 0.8 再降到 0.6，体积下降空间就不那么明显了，画质劣化却开始显现。所以我的默认值是 0.8，把偏差留给用户手动调整。
这里还要分享一个很多人不知道的盲区：quality 参数只对 JPG 生效，对 PNG 是无效的。如果用户想把 PNG 压小，必须先把图像绘制到画布上，导出时选择 JPG，同时注意背景色问题。PNG 转 JPG 时如果原图带透明区域，默认导出会出现黑色背景，这个坑在格式转换那一节还会详细说。
4.2 九宫格切图：对不整除尺寸的处理决定了成片质量
九宫格切图的逻辑听起来很简单：把一张图平均切成 3×3，输出 9 张正方形图片。但实际实现中真正的麻烦点是“原图不一定是正方形”。
我在设计时用了两种策略：一种是“居中裁切成正方形后再九等分”，另一种是“直接按照原图比例切成 3×3 的九张矩形图”。前者更适合朋友圈，因为朋友圈缩略图是正方形的，居中裁切会让视觉焦点最集中；后者更适合保留完整画面，比如淘宝详情页多图上传。
代码核心思路是：先把原图加载到一个隐藏的 Image 对象中，然后计算每格的尺寸，循环 9 次，每次从原图的特定区域 drawImage 到画布中央，再调用导出。
js复制function cropToCell(img, canvas, ctx, col, row, gridSize, cellSize) {
const sx = Math.floor(col * cellSize)
const sy = Math.floor(row * cellSize)
ctx.clearRect(0, 0, canvas.width, canvas.height)
ctx.drawImage(
img,
sx,
sy,
cellSize,
cellSize,
0,
0,
canvas.width,
canvas.height
)
}
注意这里 sx、sy 必须向下取整，否则在部分安卓机型上会出现 1 像素的偏移，最终九张图拼回去时会有细缝。另一个建议是：如果原图尺寸不是 3 的整数倍，就按“居中裁切”的方式先裁掉多余像素，而不是把小数像素分配到每一格里，后者更容易出现边缘锯齿。
4.3 图片裁剪：预设比例加可拖拽选区是最短路径
图片裁剪功能如果完全做自由选区，会让触摸事件处理变得非常复杂，涉及多点触控、缩放、旋转等一堆手势，这不是两周内能打磨好的。所以初版我只做了“预设比例 + 可拖动选区 + 画布缩放预览”。
实现上，先把原图等比缩放到适合屏幕显示的大小，然后根据用户选择的比例（1:1、3:4、4:3、9:16）生成一个选区框。选区框的移动逻辑基于触摸事件：
touchstart记录手指起始位置与选区原点的差；touchmove更新选区位置，并做边界限制，不让选区超出画布；- 最终通过选区相对原图的坐标，反推出原图中的裁切区域。
导出时不再把整张画布存下来，而是只导出选区对应区域。我使用的方法是：把隐藏画布的大小设置成目标输出尺寸，然后直接 drawImage 从原图对应区域绘制。这样裁剪出来的图分辨率不受屏幕显示尺寸影响，放大 2 倍、4 倍也不会糊。
实际使用中还有一个操作上的注意点：选区框移动时，如果只更新选区坐标而不重绘画布，界面会有肉眼可见的闪烁。正确做法是先把整张原图绘制到底层画布，再把选区作为覆盖层单独绘制，选区移动时只刷新覆盖层，这样可以做到很顺滑。
4.4 加水印：文字水印和图片水印的时序完全不一样
水印工具我做了两种模式：文字水印和图片水印。
文字水印相对简单，设置好 ctx.font、ctx.fillStyle，然后调用 ctx.fillText 即可。但这里有一个跨端差异容易坑人：Android 上中文字体默认渲染高度比 iOS 高一些，同一个字号在两种机型上占据的视觉面积不同。如果完全依赖预览时看到的文字位置保存，可能出现“预览图上文字居中，导出后文字偏上或偏下”的情况。我在编辑器里给文字水印增加了一个动态边距，用 ctx.measureText 测量文字实际宽度，再根据行高做偏移修正。
图片水印的麻烦点则是异步加载。要把水印 Logo 绘制到画布上，必须先通过 canvas.createImage() 创建图片对象，并等待 onload 完成，而不能直接把一个本地临时路径丢给 drawImage。如果水印图片还没加载完就开始绘制主图，导出结果里可能会缺少水印层。我写了一个 loadImage 方法，把所有图片的加载过程 Promise 化。
js复制function loadImage(canvas, src) {
return new Promise((resolve, reject) => {
const img = canvas.createImage()
img.onload = () => resolve(img)
img.onerror = reject
img.src = src
})
}
然后统一通过 Promise.all 等主图和水印图都加载完成再开始绘制，这个细节能避免 80% 的“结果图没有水印”问题。
4.5 长图拼接：核心不是拼，而是控制总像素量
长图拼接最常见的场景是多张聊天截图、网页截图拼成一张长图。初始版本的实现很直接：把多张图片按顺序纵向排列，画布总高度等于所有图片高度之和，宽度取最宽一张的宽度。逐张 drawImage 到最后，再一次性导出。
但真实用户的使用场景很快暴露了问题：有人一次性选了 15 张聊天记录截图，每张截图宽度 1080px、高度约 2400px，总高度接近 36000px。画布本身也许能创建出来，但到 canvasToTempFilePath 导出时，部分中低端安卓机会直接内存溢出，表现是微信白屏或小程序闪退。
所以我加了“目标总像素”限制：如果原图拼接后的总高度过大，就按比例缩小每张图的绘制尺寸，把最终导出图片的高度控制在 12000px 以内。这算是一个不算完美的降级方案，但能保证功能在任何机型上都能出结果。
另外一个隐性需求是排序。用户选择图片的顺序未必等于截图时间顺序，如果只按选中顺序拼接，导出后经常是上下颠倒的。我在选图页提供了“长按拖动排序”的能力，用户可以在处理前手动调整顺序。这个看似简单的交互，反而被很多用户提到了满意点里。
4.6 格式转换：透明 PNG 转 JPG 的黑底问题
格式转换工具支持 PNG 转 JPG、JPG 转 PNG 两种最常见场景。
JPG 转 PNG 不会有太多问题，直接绘制再导出 PNG 即可。麻烦的是 PNG 转 JPG。JPG 格式本身不支持透明通道，如果一张 PNG 图片带有透明区域，直接将它绘制到画布上再导出为 JPG，透明区域在部分平台上会被填充成黑色，而不是常见的白色。这个“黑底”问题非常惊吓用户。
解决办法是在绘制原图之前，先在画布上填充一层白色背景：
js复制ctx.fillStyle = '#ffffff'
ctx.fillRect(0, 0, canvas.width, canvas.height)
ctx.drawImage(img, 0, 0, canvas.width, canvas.height)
进一步的需求，比如 PNG 转 JPG 时是否能自动检测透明区域并用纯白或自定义颜色填充，我也做了选项。在工具列表里用户可以先选背景色，再执行转换，这样就避免了一张透明 Logo 转成 JPEG 后出现一大块黑底的尴尬。
4.7 简单标注：最受欢迎的功能，实现反而最简单
开发前我以为标注工具使用率不会太高，结果上线后恰恰是标注功能把很多人留住了。用户给图片加红框、画箭头、写字，很多场景是发给朋友时标注重点位置，比单独发原图再打一段文字解释高效得多。
实现上，编辑器维护一个“标注元素数组”，每次手指绘制时生成一个新元素，然后在 Canvas 上重绘所有元素。线条粗细、颜色、透明度都进入元素属性，这样撤销功能只需要从数组里弹出最后一个元素，不用记录每一步的像素快照，内存占用非常小。
箭头绘制原本以为很难，但实际上就是一条线加两个箭头辅助线。这里的小技巧是，如果直接用 ctx.moveTo/lineTo 画箭头，在移动端会因为线段帽的样式渲染产生毛刺，把 ctx.lineCap 和 ctx.lineJoin 设置为 'round' 可以明显改善视觉效果。
5. 真机联调、隐私配置与审核：真正折磨人的都在最后两天
5.1 开发者工具上的“虚假繁荣”与真机黑屏差异
最典型的问题集中在 Canvas 2D 上。在开发者工具里，绘制一张图片再导出，一切正常；到 iPhone 真机上，偶尔会出现导出黑屏或只导出了空白画布。为什么？原因是图片异步加载完成后，绘制时机和画布节点初始化时机产生竞态。如果 Canvas 组件还没完成节点渲染，就尝试获取 canvas 节点，后续绘制动作全部会静默失败。
针对这个问题，我做了两件事：一是所有获取 Canvas 节点的动作都封装在 Promise 里，确保节点存在后才开始加载图片；二是在绘制完成后等待至少一帧再导出，给渲染管线留出时间。
真机调试还有一个经常被忽略的差异：内存。开发者工具使用的是电脑内存，基本不会出现内存溢出；而低端安卓机对 Canvas 内存的分配很小，几张大图同时存在时就可能被杀后台。所以我在所有处理流程开始前，都会先释放上一次导出产生的临时文件，避免内存累积。
5.2 隐私协议与授权提示的处理要前置
微信小程序这几年对用户隐私的管控越来越严格。wx.chooseMedia 和 wx.saveImageToPhotosAlbum 都属于隐私接口，如果小程序后台没有提交《用户隐私保护指引》，在开发版和体验版调用这些接口时会直接失败或在 Console 报错。
具体操作有两种方式：第一种是登录微信公众平台，在“设置-服务内容声明-用户隐私保护指引”中声明收集相册信息；第二种是代码中通过 wx.getPrivacySetting 与 wx.onNeedPrivacyAuthorization 做动态隐私弹窗。我采用的是前者加后者的组合。
这里我踩过一个坑：只配置后台隐私保护指引而没有处理前端隐私授权回调，在低版本基础库上不会出问题，但在新版本基础库上调用隐私接口时会被拦截。最终我在编辑器页面进入时先检查隐私授权状态，如果用户未同意，就先展示功能说明页，确认后再进入选图。
5.3 审核注意事项：工具类小程序更容易过，但千万别带“诱导分享”影子
工具类小程序因为功能纯粹，审核通过率通常比较高。但要注意的是，涉及九宫格切图、长图拼接这类天然带有社交分享属性的功能，页面文案中如果出现“分享到朋友圈更好看”“分享给好友一起拼”这类引导，很容易被判定为诱导分享。
所以在整个小程序里，我刻意没有放任何分享引导文案，只提供“导出图片成功后，用户可以自行选择保存或转发”。不主动暗示，也不搞分享解锁功能，审核非常顺利。
提交审核时还发现一个小细节：工具类小程序功能入口简单，审核人员测试路径会很短，但如果首页是空状态或者某个按钮点击后没有反馈，被拒风险就很高。我首版只保留了 7 个已经全部可用的工具入口，没有放“即将上线”的置灰按钮，避免审核员点到未完成功能。
5.4 网络异常兜底：图片处理不能因为弱网变成“白屏”
图片工具类小程序还有一个看似无关但必须处理的场景：网络不可用。如果图片都来自本机相册，理论上不需要网，但小程序的框架层、组件资源加载和部分字体渲染仍然依赖网络。一旦弱网，用户进入小程序后页面可能长时间白屏，体验会非常差。
我在全局添加了网络状态监听，通过 wx.getNetworkType 和 wx.onNetworkStatusChange 判断网络状态，弱网或断网时在页面顶部显示“当前网络不可用”的通栏提示，但不阻塞相册选图和本地处理。这个设计既保证了功能可用，也避免用户误以为小程序坏了。
6. 几点个人体会与下一步想做的事
如果让我重来一次，有两件事会在一开始就做得更彻底。
第一件是公共流水线的健壮性测试要更早介入。我做压缩功能时用的是一张 2MB 左右的小图，一切正常；但等到用户真正处理一张来自 iPhone 的 48MB 原图时，加载耗时、内存占用、绘制性能都完全不同。后来我建立了一个测试图片池，专门放各种尺寸和格式的图，每次改完公共逻辑都会跑一遍，这节省了大量调试时间。
第二件是临时文件的清理不能只在本地处理阶段做。如果用户导出了图片但一直没有离开页面，临时文件的堆积仍然存在。我的兜底方案是在每次进入编辑页时清理上个会话残留的文件，并在 onHide 生命周期里也执行一次清理。虽然可能删掉用户刚导出但还没保存的图，但因为最终保存相册的流程很快，实际影响很小。
后续迭代方向上，我最想做的是“批量处理”能力。比如用户选择一批图片后，一次性完成压缩，再全部保存到相册。现在的流程是一张一张处理，对于自媒体运营者来说效率还是太低。批量场景不只考验画布调度，更考验文件并发和内存管理，但这类优化一旦完成，使用体验会上一个台阶。
最后分享一个可能对大家有帮助的小经验：工具类小程序不要被“日活”或“留存”绑架，努力把单个任务完成率做高就够了。逐影图像工坊第一版能顺利上线，最核心的原因就在一开始克制住了功能膨胀的冲动；先让七把工具都有自己的用处，再谈其它，产品才立得住。