1. 从“artcraft”这个名字说起：它到底想解决什么问题
第一次看到“artcraft”这个词，我脑子里蹦出来的第一反应是“艺术（art）”和“手艺/工艺（craft）”的拼接。这不是一个随便起的名字，它精准地指向了一类需求：把艺术创作和手工制作这两件事，用数字化的方式串起来。过去几年里，我接触过不少独立开发者和小团队做的创意工具项目，很多都卡在同一个坎上——要么偏艺术表达，工具太“虚”，落不了地；要么偏工程实现，功能太“硬”，创作者不爱用。而“artcraft”这个命名本身，暗示了它试图站在中间地带，做一座桥。
那这座桥具体通向哪里？结合我自己的项目经验和对这类工具的观察，我判断它大概率是一个面向创意工作者、手工艺爱好者或者数字艺术初学者的轻量级创作辅助平台或工具集。它可能包含素材管理、创作流程引导、作品展示，甚至是一些半自动化的生成能力。为什么这么判断？因为“art”代表的是审美、表达、灵感这些偏主观的东西，“craft”代表的是技法、步骤、材料这些偏客观的东西。一个项目敢把这两个词绑在一起，说明它的核心价值主张不是“我功能多强”，而是“我能帮你把想法变成看得见摸得着的东西”。
这里我要插一句自己的体会。我做过一个类似定位的小工具，当时犯的最大错误就是贪多，既想做素材库，又想做编辑器，还想做社区。结果每个模块都浅尝辄止，用户用两次就跑了。后来复盘发现，真正留住人的不是功能数量，而是一条完整的、低摩擦的创作路径。所以看“artcraft”这个标题，我首先关心的不是它有多少功能，而是它有没有想清楚：用户从“我有一个模糊的想法”到“我完成了一件作品”，中间到底需要几步？每一步的阻力在哪里？这才是决定这类项目生死的关键。
另外，从关键词和摘要描述为空这一点来看，这个项目可能还处于早期阶段，或者它的定位本身就比较开放，不想被几个词框死。这其实是个双刃剑。好处是灵活，坏处是容易失焦。我在实际操盘项目时，如果遇到这种情况，通常会先做一件事：用一句话把“谁在什么场景下用它做什么”写清楚。比如“一个让零基础的手工爱好者在30分钟内完成第一件数字拼贴作品的小工具”。这句话写不出来，后面的功能设计全是空中楼阁。
所以这一章我想先把这个项目的核心命题拆开：它面对的是哪群人？这群人现在是怎么解决创作需求的？现有的方案哪里让人不爽？“artcraft”如果只是把现有工具换个皮，那它没有存在的必要。它必须找到那个“现有工具做不好、用户又确实需要”的缝隙。根据我的经验，这个缝隙往往不在“功能”层面，而在“流程”和“情绪”层面。比如，很多专业软件打开就是一片空白画布，对新手来说压力巨大；而一些傻瓜式工具又太模板化，做出来的东西千篇一律，没有“这是我的作品”的成就感。“artcraft”如果能在这两者之间找到一个平衡点，让创作既有引导又不失个性，那它的立足点就稳了。
2. 拆解“artcraft”可能涉及的核心技术模块与选型逻辑
既然名字里带了“craft”，那它就不可能是一个纯展示类的静态网站。它一定涉及某种形式的交互式创作。我按照自己的经验，把这类项目通常会碰到的技术模块拆成四块：素材与资源管理、创作画布与交互、作品导出与分享、以及用户数据与进度保存。每一块都有不同的技术选型逻辑，我逐个说。
2.1 素材与资源管理：为什么我倾向于“轻数据库+对象存储”而不是全塞进前端
素材管理是很多创意工具最先崩掉的地方。一开始为了图快，开发者容易把图片、字体、纹理这些资源直接打包进前端代码里。项目小的时候没问题，一旦素材超过几十个，打包体积就爆炸，首屏加载慢得让人想关页面。我踩过这个坑，后来学乖了：素材必须走独立的存储和分发通道。
具体来说，我会把素材分成两类。一类是基础素材，比如常用的笔刷、基础形状、标准色板，这些可以放在前端静态资源里，但要做按需加载，不能一次性全拉下来。另一类是用户素材和扩展素材，比如用户自己上传的图片、收藏的纹理、社区分享的模板，这些必须放在对象存储（比如兼容S3协议的服务）里，数据库只存元数据和访问路径。这样做的好处是，前端只负责展示和引用，不负责承载，扩展性完全不一样。
数据库选型上，如果项目还小，我建议直接用SQLite或者轻量级的PostgreSQL。别一上来就上分布式数据库，那是给自己找麻烦。素材的元数据无非就是ID、名称、类型、标签、存储路径、创建时间这几个字段，关系型数据库处理起来绰绰有余。真正需要花心思的是标签体系和搜索。用户能不能快速找到想要的素材，直接决定了创作流程顺不顺。我的做法是给每个素材打上多维标签：风格（写实/卡通/极简）、用途（背景/前景/装饰）、颜色主调。搜索时支持标签组合过滤，比全文检索实用得多。
注意：素材的版权和来源一定要在数据库里留痕。我见过太多项目因为素材来源不清，上线后被投诉下架。每个素材记录里至少要有“来源类型”和“授权方式”两个字段，哪怕现在用不上，以后也一定用得上。
2.2 创作画布与交互：Canvas还是SVG，这是一个需要想清楚的问题
创作画布是“artcraft”这类项目的核心中的核心。选Canvas还是SVG，直接决定了后面能做什么、不能做什么。我自己的经验是：如果作品以位图为主、需要频繁的像素级操作（比如涂抹、模糊、混合模式），选Canvas；如果作品以矢量图形为主、需要每个元素独立可选中可编辑，选SVG。
但现实往往更复杂。很多创意工具需要两者结合。比如，底层用Canvas做位图绘制和滤镜，上层用SVG做矢量图形的叠加和交互。这种混合方案不是不行，但复杂度会翻倍。我的建议是，在项目早期，先想清楚80%的用户会做什么。如果大部分用户只是拖拽素材、调整大小位置、加个文字，那SVG完全够用，而且交互实现起来简单得多，每个元素都是DOM节点，事件绑定、层级管理、动画过渡都很直观。如果用户需要自由绘制、笔刷效果、图层混合，那就必须上Canvas，而且要提前考虑离屏渲染和分块重绘，不然稍微大一点的画布就会卡。
这里有一个我实测下来的性能分界线：画布尺寸超过2000x2000像素，或者同时操作的图层超过20个，Canvas的交互延迟就会变得明显。这时候需要引入脏矩形重绘机制，只重绘发生变化的区域，而不是整个画布。这个优化做不做，用户体验差距巨大。SVG这边，元素数量超过500个之后，DOM操作的开销也会上来，需要考虑虚拟化或者分组渲染。
还有一个容易被忽略的点：撤销/重做。这是创作工具的生命线。Canvas方案下，实现撤销重做通常靠保存操作历史或者画布快照。操作历史省内存但实现复杂，快照简单但吃内存。我的折中方案是：关键操作存历史，非关键操作存快照。比如“添加图层”“删除图层”这种结构性操作存历史，“调整笔刷大小”这种连续操作合并成一次快照。这样既保证了撤销的准确性，又不会让内存爆掉。
2.3 作品导出与分享：别让最后一步毁了整个体验
用户辛辛苦苦做完一件作品，结果导出的时候卡住、格式不对、清晰度不够，那种挫败感足以让他再也不打开这个工具。导出这块，我总结了几条硬经验。
第一，导出格式要覆盖主流需求。PNG是必须的，支持透明通道；JPEG用于照片类作品，体积小；如果涉及矢量元素，SVG导出也要有。如果项目定位偏印刷或手工艺，PDF导出可能也是刚需。别小看格式支持，很多用户就是因为你不能导出他想要的格式而离开的。
第二，导出分辨率要给选项，但要有默认推荐值。我见过一些工具只给一个固定分辨率，用户想导出高清图还得自己算尺寸，体验很差。我的做法是提供“屏幕预览（72dpi）”“标准打印（150dpi）”“高清打印（300dpi）”三档，默认选标准打印。同时显示预估文件大小，让用户心里有数。
第三，导出过程要有进度反馈。大画布导出可能需要几秒钟，如果界面没有任何反应，用户会以为卡死了。一个简单的进度条或者加载动画就能解决这个问题。如果导出时间超过3秒，最好做成异步任务，导出完成后通知用户，而不是让他在那里干等。
分享功能则是另一个维度。如果“artcraft”有社区属性，分享就不只是导出一个文件，而是生成一个可访问的链接或者嵌入代码。这里要注意的是分享内容的权限控制。用户可能只想分享给特定的人看，或者只想展示低分辨率预览图。我的建议是默认生成带水印的低分辨率预览链接，用户可以选择是否开放高清原图下载。这样既保护了创作者的权益，又降低了分享的心理门槛。
2.4 用户数据与进度保存：自动保存是底线，版本历史是加分项
创作类工具最怕的就是丢数据。用户画了半小时，浏览器崩了，进度全没，这种事故发生一次，口碑就完了。所以自动保存必须是底线功能，而且不能只存在内存里，要定期持久化到本地存储或者服务端。
我的实现方案是：本地优先，服务端兜底。用户每次操作后，先把当前状态序列化到IndexedDB或者localStorage里，这个操作是同步的、无感的。然后每隔30秒或者每积累10次操作，再异步同步到服务端。这样即使网络断了，用户刷新页面也能从本地恢复。服务端的数据主要用于跨设备同步和长期存档。
版本历史是加分项，但对专业用户来说很重要。我见过一些工具只保留最近一次自动保存，用户想回退到十分钟前的状态都做不到。实现版本历史不一定非要存全量快照，可以存操作日志，回放操作来重建任意时间点的状态。这样存储成本低，灵活性也高。当然，操作日志的设计需要仔细，要保证每个操作都是幂等的、可重放的。
3. 如果我来从零搭建“artcraft”，会怎么设计开发路线
假设现在让我从零开始做一个“artcraft”这样的项目，我会把开发路线分成四个阶段，每个阶段有明确的交付目标和验证标准。这不是理论推演，是我自己做过类似项目后总结出来的节奏。
3.1 第一阶段：用最小闭环验证核心假设
这个阶段的目标只有一个：证明用户愿意用你的工具完成一件作品。注意，是“完成”，不是“试用”。很多项目死在用户试了一下就走了，因为流程太长、太复杂。
我会把功能砍到不能再砍：一个空白画布，能添加三种基础素材（形状、文字、图片），能调整位置大小颜色，能导出PNG。就这些。没有图层，没有滤镜，没有社区。然后找10个目标用户，看着他们用。观察的重点不是他们会不会用，而是他们在哪一步犹豫、在哪一步问“这个怎么弄”、在哪一步放弃。
这个阶段的技术选型可以很随意，甚至可以用现成的开源画布库快速搭。关键是快。我给自己定的时间是两周，超过两周就说明想太多了。验证的标准也很简单：10个人里至少有6个人能独立完成一件作品并导出，就算通过。如果不到6个，那就回去改流程，而不是加功能。
提示：这个阶段千万别碰用户系统和后端。所有数据存本地，刷新就丢也没关系。你要验证的是创作流程本身，不是数据持久化。
3.2 第二阶段：把“完成一件作品”的路径打磨到丝滑
第一阶段验证通过后，第二阶段的核心任务是降低摩擦。用户能完成作品，但可能花了20分钟，其中10分钟在找功能。这个阶段要做的就是让那10分钟消失。
具体要做几件事。第一，引导式起步。不要给用户一个完全空白的画布，而是提供几个“起步模板”，比如“一张贺卡”“一个头像”“一张拼贴画”。用户选一个模板，画布上已经有基础布局和占位素材，他只需要替换和调整。这比从零开始的心理压力小得多。
第二，上下文工具栏。用户选中什么，工具栏就显示什么相关的操作。选中文字就显示字体、字号、颜色；选中图片就显示裁剪、滤镜、透明度。不要把所有工具都堆在顶部菜单里，那是专业软件的做法，不适合轻量工具。
第三，操作反馈要即时且明确。拖动素材时要有对齐参考线，调整颜色时要实时预览，删除元素时要有撤销提示。这些细节看起来小，但累积起来就是“好用”和“难用”的区别。
这个阶段还需要引入本地持久化，也就是前面说的自动保存。用户关掉页面再打开，作品还在，这是建立信任的关键一步。技术实现上，用IndexedDB存画布状态和素材引用，每次操作后防抖保存。注意IndexedDB的异步特性，保存操作不要阻塞主线程。
3.3 第三阶段：引入用户系统和云端同步，但别做重
到了这个阶段，用户开始有跨设备需求了，或者想把自己的作品分享给别人看。这时候才需要引入用户系统。我的建议是用现成的认证方案，别自己造轮子。OAuth或者邮箱验证码登录都行，关键是快、稳、安全。
云端同步的设计要遵循一个原则：本地是主，云端是备。用户的所有操作先落本地，然后异步同步到云端。冲突处理用“最后写入 wins”策略就够了，创意工具很少出现多人同时编辑同一作品的情况。如果真有协作需求，那是另一个量级的产品，不在早期考虑范围内。
这个阶段还要做作品管理。用户的作品列表、重命名、删除、复制、导出历史版本。这些功能不复杂，但很琐碎，需要耐心打磨。我的经验是，作品列表的加载速度比什么都重要。用户打开工具第一眼看到的就是作品列表，如果这里卡顿，他对整个工具的信任度都会下降。列表数据要分页加载，缩略图要懒加载，排序默认按最近编辑时间倒序。
3.4 第四阶段：社区和模板生态，让用户帮你留住用户
最后一个阶段才是社区。为什么放这么后？因为社区是典型的“先有鸡还是先有蛋”问题。没有足够多的创作者和作品，社区就是一片荒地，反而让新用户觉得冷清。所以必须等前面三个阶段积累了足够的活跃用户和优质作品，再开社区。
社区的核心不是“发帖”，而是模板的流通。用户A做了一件作品，可以一键发布为模板，用户B可以基于这个模板二次创作。这样模板库会自然增长，新用户永远有东西可以玩，老用户也有成就感。技术实现上，模板本质上就是一份画布状态的序列化数据，加上素材引用。发布模板时要做一次校验，确保引用的素材都是可公开访问的，避免出现“模板打开后素材丢失”的尴尬。
这个阶段还要考虑内容审核。用户生成的模板和作品需要过滤明显违规的内容。我的做法是先用自动化手段过一遍（图片鉴黄、文本敏感词），然后对高风险内容进行人工复核。审核策略要透明，让用户知道什么能发什么不能发，避免误伤创作热情。
4. 实操中容易踩的坑：我踩过的和看别人踩过的
这一章不讲理论，只讲实际开发中会遇到的坑。有些是我自己踩的，有些是看同行项目复盘时记下来的。每一个坑都对应着真金白银的时间和精力损失。
4.1 画布性能的隐形杀手：你以为优化了，其实没有
画布性能问题往往不是一下子暴露的，而是随着用户操作逐渐累积的。我遇到过一个典型案例：用户画了50个元素之后，拖动任何一个元素都开始卡顿。排查后发现，每次拖动都会触发整个画布的重绘，而不是只重绘被拖动的元素和它覆盖的区域。这就是典型的脏矩形缺失。
修复方案是引入一个简单的脏矩形系统。每次操作后，记录发生变化的区域坐标，下一帧只重绘这个区域。对于Canvas来说，这意味着要用clearRect清除脏区域，然后重新绘制该区域内的所有元素。听起来简单，但实现时要注意元素的层级关系——脏区域内的元素要按正确的顺序重绘，不能只重绘被操作的那个元素。
另一个隐形杀手是阴影和模糊效果。Canvas的shadowBlur和filter属性在元素数量多的时候性能下降非常明显。我的建议是，如果元素数量超过30个，就禁用实时阴影和模糊，只在导出时应用。或者用预渲染的阴影图片代替实时计算。这个取舍需要根据项目定位来定，但一定要提前测试，别等用户抱怨了才发现。
4.2 素材加载的并发陷阱：为什么你的画布打开总是慢半拍
素材加载是另一个容易翻车的地方。用户打开一个包含20张图片的作品，如果代码里是循环里逐个await加载，那总加载时间就是20张图片加载时间的总和。正确的做法是并发加载，但控制并发数。浏览器对同一域名的并发请求数有限制（通常是6个），超过这个数反而会排队。所以我的做法是用Promise.all配合一个简单的并发池，同时加载4-6个素材，加载完一个就补一个。
还有一个细节：素材的预加载和缓存。用户第一次打开作品时加载了20张图，第二次打开时如果还要重新下载，体验就很差。要用Service Worker或者Cache API做素材缓存，设置合理的过期策略。对于用户自己上传的素材，缓存时间可以长一些；对于公共素材，可以设置版本号，版本不变就一直用缓存。
注意：素材加载失败的处理也很重要。如果某张图片加载不出来，画布上应该显示一个占位符，而不是直接报错或者留白。用户需要知道“这里本来有东西，只是暂时没加载出来”，而不是“我的作品坏了”。
4.3 撤销重做的边界情况：那些让你怀疑人生的bug
撤销重做看起来简单，实际做起来边界情况多到让人崩溃。我列几个我遇到过的：
连续操作合并：用户拖动滑块调整透明度，从100%拖到50%，中间触发了50次
input事件。如果每次事件都存一个历史记录，用户按一次撤销只回到99%，要按50次才能回到100%。正确的做法是合并连续操作，在用户停止操作（比如mouseup或防抖500毫秒）后才存一个历史记录。异步操作的撤销：用户上传了一张图片，上传过程中按了撤销。这时候图片还没上传完，撤销操作应该取消上传，还是等上传完再撤销？我的做法是给每个异步操作一个取消令牌，撤销时先取消未完成的异步操作，再回退状态。
跨画布状态的撤销：如果作品有多个页面或者多个图层组，撤销操作要能跨页面回退。这要求历史记录里不仅存当前页面的状态，还要存页面切换的操作。实现起来复杂，但用户预期就是这样，不做不行。
撤销栈的内存管理：历史记录不能无限增长。我的做法是限制撤销步数为50步，超过后丢弃最旧的记录。同时，对于占用内存大的操作（比如添加高分辨率图片），历史记录里只存引用，不存完整数据。
4.4 移动端适配：别把桌面端经验直接搬过去
如果“artcraft”有移动端需求，那又是另一个故事了。移动端的画布交互和桌面端完全不同。桌面端靠鼠标精确点击，移动端靠手指触摸，精度差很多。所以移动端需要更大的点击热区，至少44x44像素。元素的选择、拖动、缩放都要重新设计交互方式。
性能方面，移动端的Canvas性能比桌面端差一大截。同样的元素数量，桌面端流畅，移动端可能就卡了。我的经验是，移动端的元素数量上限要控制在桌面端的一半以下。同时要避免使用复杂的滤镜和混合模式，这些在移动端GPU上开销很大。
还有一个容易忽略的点：移动端的屏幕尺寸差异。从5寸手机到13寸平板，画布的显示区域变化很大。我的做法是画布尺寸固定，但显示时按比例缩放适应屏幕。用户操作时，坐标要经过缩放换算。这个换算逻辑要封装好，不然到处都是bug。
5. 从“artcraft”延伸出去：这类创意工具还能怎么进化
做“artcraft”这样的项目，如果只盯着眼前的功能，很容易做成一个“够用但不出彩”的工具。我在复盘自己项目的时候，会刻意想一些延伸方向，不一定马上做，但要有意识地为未来留接口。
5.1 从工具到平台：模板生态的冷启动策略
前面提到模板生态是社区的核心，但冷启动是个难题。我的思路是官方先做一批高质量模板，覆盖最常见的创作场景。比如节日贺卡、社交媒体配图、简单的手工图纸。这些模板不需要多复杂，但要精致、有设计感，让用户觉得“我用这个模板做出来的东西拿得出手”。
然后设计一个模板贡献激励机制。用户发布的模板被使用多少次，就获得相应的积分或徽章。积分可以兑换高级素材或者导出高清图的次数。这样既激励了创作，又不会让社区充满低质量内容。关键是审核要跟上，宁缺毋滥。
5.2 引入AI辅助：不是替代创作，而是降低门槛
AI在创意工具里的角色应该是助手，不是替代者。我设想过几个实用的AI辅助场景：
- 智能配色：用户上传一张参考图，工具自动提取配色方案并应用到当前作品。
- 布局建议：用户添加了几个元素后，工具根据元素类型和数量，给出几种布局排列方案。
- 素材推荐：根据用户当前作品的主题和风格，推荐匹配的素材。
- 文字转图形：用户输入一段描述，工具生成几个简单的图形草稿供参考。
这些功能的共同点是给用户选择，而不是替用户决定。AI生成的结果永远是建议，用户可以选择接受、修改或忽略。这样既降低了创作门槛，又保留了用户的控制感。
技术实现上，这些功能不一定需要大模型。配色提取用颜色量化算法就够了，布局建议用简单的规则引擎也能做出不错的效果。关键是响应速度，AI辅助功能如果等好几秒才出结果，用户早就自己动手了。
5.3 跨端同步与离线优先：用户在哪，创作就在哪
创意工作者的一个典型场景是：通勤路上用手机记录灵感，到办公室用电脑继续完善。这就要求作品能跨端同步，而且离线也能用。
离线优先的架构设计有几个要点。第一，所有操作先写本地，本地是唯一的数据源。第二，同步是后台行为，不阻塞用户操作。第三，冲突解决要简单可靠，我推荐“最后写入 wins”加上操作日志合并。第四，同步状态要可见，用户要知道当前是“已同步”“同步中”还是“离线”。
跨端同步的难点不在技术，在数据模型的设计。如果数据模型没有考虑同步需求，后期改造会非常痛苦。我的建议是，从第一天起就用操作日志而不是状态快照作为同步单位。操作日志天然支持增量同步和冲突合并，状态快照则很难处理并发修改。
5.4 商业化的一点思考：别急着收费，先想清楚谁愿意付钱
创意工具的商业化是个敏感话题。我的观察是，个人用户对工具付费的意愿普遍偏低，除非这个工具能直接帮他赚钱。所以如果“artcraft”要商业化，目标用户应该是靠创意吃饭的人，比如自由设计师、手工艺店主、社交媒体运营者。
对这群人来说，付费的理由不是“功能多”，而是“省时间”或者“出效果”。比如，批量导出不同尺寸的图片、一键生成多平台适配的版本、高级素材库的访问权限。这些功能对普通用户可有可无，但对专业用户是刚需。
定价策略上，我倾向于免费基础功能+订阅高级功能的模式。免费版足够完成一件作品，但导出有分辨率限制或者带水印。订阅版解锁高清导出、高级素材、批量处理等功能。价格不要太高，月付控制在两杯咖啡的价位，降低决策门槛。
提示：在积累到一定用户量之前，不要花太多精力在商业化上。过早追求收入会扭曲产品决策，让团队做出短视的功能。先把创作体验做好，让用户离不开，收入是水到渠成的事。
6. 一些零散但重要的经验碎片
写到这里，还有一些不成体系但我觉得值得分享的经验，放在最后。
关于技术选型：不要因为某个框架“火”就选它。创意工具的核心是稳定和性能，不是技术时髦。我见过用最新前端框架做的画布工具，结果因为框架本身的渲染机制和Canvas冲突，性能怎么优化都上不去。选型时先做性能基准测试，别等做了一半才发现选错了。
关于用户反馈：早期用户的反馈要听，但不能全听。用户会告诉你“我想要这个功能”，但不会告诉你“我为什么需要这个功能”。要追问背后的场景和动机。有时候用户说想要“更多笔刷”，实际需求可能是“我画不出想要的效果”，而解决方案可能是更好的笔刷预览或者笔刷推荐，而不是单纯增加数量。
关于代码组织：画布相关的代码一定要和UI代码分离。画布逻辑应该是纯函数式的，输入状态和操作，输出新的状态。这样测试起来方便，也容易在不同端复用。UI层只负责渲染和事件绑定，不包含业务逻辑。这个架构决策在项目早期就要定下来，后期改成本很高。
关于测试：画布功能的自动化测试很难做，但至少要做快照测试。每次代码变更后，用相同的操作序列生成画布快照，和基准快照对比。如果像素差异超过阈值，就说明有回归。这个测试能抓住大部分渲染相关的bug，性价比很高。
关于文档：创意工具的文档不是写给程序员看的，是写给创作者看的。不要写“调用addLayer()方法添加图层”，要写“点击工具栏的加号按钮，就能新建一个图层”。文档里要多用截图和动图，少用文字描述。创作者没有耐心读大段文字。
关于性能监控：上线后一定要有性能监控。记录用户从打开作品到可以操作的时间、每次操作的平均响应时间、导出成功率。这些数据比用户反馈更真实。我自己的项目就是通过监控发现，导出失败率在特定浏览器版本上异常高，及时修复后避免了一次口碑危机。
关于版本迭代：创意工具的迭代节奏要稳。不要频繁改界面布局，用户刚熟悉就变，会很烦躁。新功能尽量以“可选”的形式加入，不要强制改变用户已有的工作流。大版本更新前，给用户足够的预告和迁移时间。
这些经验不一定都对，也不一定适合所有项目，但都是我实际做过、错过、改过之后留下来的。做“artcraft”这样的项目，技术只是一部分，更重要的是对创作流程的理解和对用户情绪的体察。工具是冷的，但创作是热的。能把这两者接起来，项目就成功了一半。
