artcraft：手工艺创作全流程管理工具

1. 为什么做artcraft手工艺创作的三大痛点先说结论artcraft 不是又一个笔记工具也不是那种只能记流水账的待办清单它是我为手工艺创作场景专门搭建的一套全流程管理方案。如果你和我一样玩木工、做皮具、缝合织物或者搞模型涂装、黏土雕塑甚至只是偶尔捣鼓点手工蜡烛和植物染布那你大概率被下面这三个问题折磨过。第一个痛点是灵感碎片散落各处。我翻相册的时候经常发现有几十张当时觉得有用的参考图截图时间跨越好几个月有的来自社交平台有的是自己拍的实物细节还有几张是从视频教程里截的步骤图。真正要开工的时候想找某一张金属配件组合参考得翻半天还经常翻不到因为当时根本没分类也没归档。artcraft 专门处理了这个环节把灵感采集的入口做得非常轻轻到我在地下室干活的时候一只手沾着胶水另一只手拿手机点两下就能完成记录。第二个痛点是材料库存全凭脑子记。玩手工的人都有这种经历——你想做一批植鞣革手机壳结果做到一半发现手头的 1.5mm 厚度皮革只够裁三片而快递要两天才能到。更麻烦的是五金配件铜扣、铆钉、磁吸扣、气眼价格不高但品类极杂囤多了占地方囤少了又总是缺货。artcraft 里我做了很轻量的按项目绑定材料模型每开一个新项目先把可能用到的材料挂上去开工之后一边消耗一边记录库存剩余量会自动扣减。这样就算哪天心血来潮想再做一批同款打开项目看一眼就知道还差哪些件不用再翻箱倒柜。第三个痛点是进度追不上变化。我见过很多手工艺人的做法是同时做三四个项目木工做到一半因为等胶水干插空去缝皮具皮具缝到一半又去调色。项目一多就很容易出现某件半成品在角落里放了一个月收尾时完全忘了当初设计的收线方式是什么更别说某些步骤当时是否预处理过。这类信息如果只靠记忆几乎必然出错。artcraft 的核心想法就是让每个创作项目自带进度快照——不需要写长篇日志只要每次收工时花一分钟记录当前状态下次拿起半成品就能无缝衔接。这个项目最适合两类人一是刚刚从兴趣尝试跨到定期创作的手工爱好者他们正处于作品变多、材料变杂、流程变长的阶段最需要一套轻量管理方法二是已经有一定产出量、但受不了传统项目管理软件那种重流程的独立创作者artcraft 的定位是像发朋友圈一样记录创作过程而不是在表格里堆砌任务依赖关系。2. 产品架构与技术选型思路2.1 功能模块的取舍逻辑一开始我参考了市面上好几类工具包括通用型的项目看板、笔记软件、图片管理应用甚至还有某些电商后台的库存管理模块。但它们的问题都很明显看板类工具太重做一张手工卡片要建五六个列表、拖来拖去记录成本比实际干活还高笔记类工具虽然灵活却完全没有材料库存递减这种创作场景特有的数据关系图片管理工具只解决了收藏和分类没法把一张参考图和一个具体项目的进度关联起来。所以 artcraft 的设计原则定为三条灵感入口要快、项目状态要一目了然、材料数据要准确可追溯。整个系统只保留了五个核心导航入口灵感箱、项目看板、材料仓库、作品集、复盘日志。任何一次打开的停留时间都被刻意压缩比如记录灵感默认不需要输入标题拍照或者选图就完成一条记录创建项目也只要填一个名字和选一个类型模板其余字段都可以后续再补。这套取舍逻辑想清楚之后我决定不做成重型的多人协作系统而是先专注单人和轻量团队场景。手工艺创作的管理本质上是一个人面对一堆实物的自我协调工具的价值是减少决策负担而不是增加流程节点。2.2 技术栈选择与背后理由技术选型上我选择了足够成熟、资料多、踩坑成本低的组合没有追新。后端是 Node.js 加 Express配合 SQLite 作为默认数据库前端是 Vue 3 加 Vite样式部分用 Tailwind CSS 快速搭界面移动端适配优先因为很多使用场景是在工作台旁边掏出手机顺手记录。文件存储先用本地磁盘目录图片统一走压缩与缩略图双轨制。为什么不用 NoSQL因为创作记录和材料库存的数据关系其实非常规整。一个项目关联多条灵感记录、多个材料消耗记录、多个进度节点这些用关系模型表达最自然查询和统计也最省事。我后来确实遇到了需要联表统计某个项目的材料成本这种需求SQLite 一条带 JOIN 和 GROUP BY 的查询就解决了。Node.js 的选择也不复杂前端后端口径一致热重载调试效率高再加上 Express 中间件生态成熟单人开发非常合适。前端没有做成 SPA 的大型应用而是按页面维度拆了几个独立视图用 Vue Router 做页面切换。首版甚至没有引入 Pinia 做全局状态管理只用了组件内状态和简单的provide/inject因为实际业务场景大多是列表跳到详情、详情跳回列表跨页面共享的全局状态非常少。等到材料仓库看板需要实时反映最新库存时我再补上了轻量的事件总线。这套思路比较朴素但对一个小体量项目来说节省的时间非常可观。2.3 数据模型的关键设计模型设计是整个项目里最值得展开的部分因为它直接决定了后续所有功能的开发成本。核心有四张表项目表projects、灵感记录表inspirations、材料库存表materials、项目材料消耗记录表project_material_logs。项目表里我特意加了一个 status 枚举有筹备中/制作中/搁置/已完成/已封档五种状态。之所以加搁置和已封档是因为手工艺项目的生命周期和软件开发完全不同——回坑率极高。一个木工项目可能因为季节原因木蜡油干得太慢被搁置两个月但它不等于废弃后续打开时还需要恢复全部上下文。封档则是彻底做完的状态此时可以单独生成作品集页面但项目里的历史记录不会消失。材料库存表的关键字段是总量和单位以及安全阈值。安全阈值是我在实际使用中慢慢体会到重要性的设计比如黄铜螺丝我设定当存量低于30颗时项目列表和材料明细里会出现一条低库存提醒这样就不用每次开工前人工点数。项目材料消耗记录表则关联项目、材料和数量每一条消耗记录都会实时回写材料库存表的剩余量。为了保证准确性我在应用层做了事务处理避免高并发下库存被扣成负数具体怎么排查这个问题后面常见问题章节会细说。3. 实操落地从零搭建核心功能3.1 项目的生命周期管理创建项目时所有字段都有默认值但我会强烈建议填三样东西项目类型、目标尺寸或规格、参考预算。项目类型用的是内置枚举比如木工、皮具、织物、陶瓷、涂装、综合材料。这样做的好处是后续统计作品集时可以按类型生成产出分布图而不需要手动打标签。项目创建完成后会进入筹备中状态。此时主要操作是往项目里添加材料和灵感。材料关联是纯选择操作从已有库存里选选完可填计划用量方便后续对比实际消耗和预估偏差。灵感关联则有两种方式一种是直接添加已有灵感记录另一种是调起相机拍照新拍的图会自动存入灵感库并绑定到当前项目——这是开发中使用频率最高的操作。进入制作中状态时项目详情页会展示一个竖向时间轴每次记录进度实际上是在时间轴上追加一条动态内容可以是一段文字、一组图片也可以批量标记若干材料消耗。时间轴的设计参考了社交应用的信息流展示逻辑每条动态只显示最近三条文字预览需要查看细节时点开。这么做是为了让记录本身的视觉负担足够小。已完成状态需要满足两个条件手动切换状态以及至少有一条带图片的进度动态。第二个条件是我故意加的软约束目的是确保作品集页面不会出现没有配图的空项目。如果做完了却连一张照片都没拍系统会提示这个项目该补一张收尾图这个设计后来被好几个使用者说是最戳心的功能。3.2 材料库存的双层追踪材料这块我踩过很深的一个坑最早版本里只有材料名称数量两个字段结果用了一周就出问题——同一款疯马皮油分成250ml罐装和500ml补充装两个条目它们的实际使用频率并不相同而在计算总成本时又需要把它们归并到同一种材料。痛定思痛后我把材料拆成两层一层是材料品类比如植鞣革、黄铜条、亚克力板另一层是具体SKU比如植鞣革 - 1.5mm - 原色、黄铜条 - 2mm x 100mm - 10根装。消耗记录挂在SKU级别上每个SKU可单独设置安全阈值。品类层则只做统计聚合比如查看植鞣革品类时下面所有SKU的剩余量的单位需要统一换算才能加总这阶段暂时支持按最常用单位显示。这层设计确实增加了一些开发量但换来的是统计报表的可靠性——你可以轻松知道这个月到底用了多少 CCD 和多少克银黏土而不只是看到一个扁平列表。材料消耗录入还有一个捷径在时间轴里发动态时可以直接用材料名 x数量的文本语法比如完成榫卯打磨 榉木 300g 砂纸240目 2张。后端的解析逻辑会把匹配到的材料名和数量自动登记为消耗记录。这个看起来不起眼的语法实际上是整个系统里做得最值的一个功能因为它把记录和顺手记一笔从操作层面合并了。3.3 灵感记录的低摩擦设计灵感采集的常见失败场景是记录的时候分类分得太细消耗了大量精力结果一段时间后觉得分类体系不合理整个灵感库变成一团乱麻。artcraft 的做法是反其道而行无论什么来源的灵感第一层只做临时收藏与已归档到项目两种状态。灵感记录本身不强制填标签、不强制选分类、不强制写描述。也就是说在刷网页或者逛社交平台时看到一个不错的装饰配件搭配只需截图或者保存图片然后导入 artcraft它就自动进入临时收藏。之后当你在创作某个项目时想参考它可以从临时收藏列表里直接拖进当前项目到了这一步它才会要求选择用途角色比如是参考造型、参考配色还是参考结构。通过把分类延迟到真正使用那一刻来做系统的前期使用阻力降到了最低。批量操作上也下了功夫支持多选后一键归档到项目也支持从项目里移回临时收藏。为了让图片加载足够快上传后的原始图会存在原图目录同时生成宽度分别 400px 和 900px 的两份缩略图列表和详情页都用缩略图原图延迟到点击查看大图时才加载。这样即便一个项目里挂了上百张灵感图浏览体验依然流畅。3.4 作品的进度快照机制进度快照是本项目区别于普通笔记工具的核心创新点。它解决的场景是真实的创作过程中很多关键信息是以非文字形式存在的比如木工做狼椅时坐面的倾斜角度微调了多少、陶瓷烧制前后的收缩率差别、涂装时某个颜色盖在哪层的光油下面。这些信息光靠一两句文字描述很难留全最好的方式是拍一张照再录一句话。所以我在每次进度记录里都设计了图片语音转文字的复合结构。图片作为证据、语音转出的文字作为索引。语音转文字我用的是系统级语音识别接口识别完成后会生成一段可编辑的文本同时保留原始音频文件作为附件。使用者只需要做三件事拍照、按住说话、松手。剩下的分类、归档、关联全部自动完成。实际用下来这个机制最厉害的地方在于拾起重启的效率明显提高。以前我从搁置项目里回坑至少要在桌前坐半小时回想思路现在打开项目看最近三五条进度快照三分钟就能把状态接上。对于六七个项目并行的人来说这个时间代价可以说是质变。4. 部署上线与日常运维4.1 单机Docker化部署说实话最开始我用的是本地直跑后来发现工作台旁边那台老笔记本电脑经常关机导致有时候人在客厅想翻一下材料库存还得摸去地下室开机器。于是我把它包进了 Docker 镜像部署到一台常年开机的家庭服务器上。Dockerfile 写得非常简单Node.js 运行时加一层镜像、代码加一层、静态资源加一层前两层变化频率不高镜像层缓存利用率很高每次构建都很轻量。编排方式上我用了 docker-compose只起了一个应用容器没有刻意拆分数据库独立容器SQLite 文件直接挂载到宿主机目录。相比 MySQL 容器方案少一个容器就是少一个故障点而且 SQLite 备份实在方便副本文件即所得。nginx 放在宿主机上做反代处理 TLS 和 HTTP/2前端静态资源也由 nginx 直接服务应用容器只收 API 请求。因为 artcraft 是单人为主的使用场景我没有做复杂的用户注册体系和权限控制只是暴露了三个基础账号管理员、编辑、只读。编辑账号只能新增和编辑自己的内容只读账号方便在手机上看库存和进度。这样即使临时让朋友帮忙看一眼某个项目进度也只需要分享只读链接没有安全焦虑。4.2 备份策略的实操方案手工艺人的数据资产不是代码仓库而是那几千张灵感图片和上百条创作过程记录。图片一旦丢了基本不可能再找回所以我吸取了一次惨痛教训。那次我把家目录下某个文件夹误杀恢复的时候发现里面包含了三个月前一个皮具项目的所有过程照片当场傻眼。从那以后我配置了两层备份第一层是每晚增量备份到同一个局域网里的 NAS用 rsync 同步数据库文件和原图目录第二层是每周全量压缩后同步到对象存储的私有桶并只保留最近四周版本。备份恢复这事儿我建议任何人玩这个工具都至少做一次演练而不是等到哪天真的要从头恢复时才临时看文档。我在本地搭过一个临时目录把备份的 SQLite 文件和解压的图片拉下来改一下配置里的路径启动后逐个项目检查缩略图是否都能显示。整个过程花了大概一小时之后对备份方案的信心就完全不一样了。对于网络同步问题artcraft 暂不支持多人实时协同刻意避开了 Live Sync 的复杂度。如果你需要用手机和家里电脑同时访问推荐做法是家庭服务器做端口转发然后在手机上用浏览器直接访问内网IP。如果条件允许也可以套一层内网穿透服务但这不是我当前部署的重点。4.3 性能优化的几个实测节点数据量上来之后最明显的性能瓶颈出现在项目时间轴页因为每页要拉取该项目的全部进度动态每张图都要压缩、去重、排序。我做了三步优化第一步是图片懒加载先把首屏每条动态的缩略图占位等滚动到可视区附近再真正请求图片第二步是分页改为按时间游标的分页方式每次只取20条滚动到底部再加载更早的第三步是在后端给项目详情最近动态做成一次 API 接口返回避免前端连续发多次请求拼接数据。优化前一个包含300多条进度动态的项目页加载时间在满是图片的情况下大约4到5秒优化后首屏基本能压到1秒以内滚动加载也几乎没有明显卡顿。如果后续项目数量再上一个量级我可能会把 SQLite 换成 PostgreSQL但就当前单人使用的规模来说SQLite 完全够用。5. 常见问题与排查技巧实录5.1 项目启动够不够轻经常有人问我想用 artcraft 管理创作但是又担心一开始要填的数据太多。我的建议恰恰相反只填必填三件套其他都留空。项目名、类型、状态这三个字段就能把一个项目立起来剩下的比如预算、目标规格、关联库存等你真正开始动手时再补。工具的价值应当在创作过程中被感受到而不是在开工前成为负担。反例我也见过有朋友一装上就开始按软件工程项目的方式做精细规划建一堆任务清单、里程碑节点结果项目本身只有两个周末就能做完。过度规划不但没带来掌控感反而消磨了创作的冲劲。artcraft 的设计哲学是记录服务于过程不需要为了填满字段而填满。5.2 库存统计经常对不上怎么办这个问题在系统上线前两周几乎每天困扰我。排查下来的原因有两类一类是消耗录入时数量写错了比如一次用了5张砂纸结果时间轴输入法里敲成了砂纸 5张但实际售卖的包装是10张/包存量计算始终按照实际消耗数量扣减没有考虑单位换算另一类是同一材料的多个SKU容易串比如蜂蜡存在固体块和液体罐装消耗记录时选了错误的SKU。改进方案有三个第一在材料SKU上增加换算公式字段比如1罐500g录入消耗时如果检测到单位不同会弹出换算提示第二在消耗录入文本框旁边加一个最近使用材料快捷列表直接点选历史材料大大降低串SKU的概率第三在库存明细页增加手动盘点按钮每个月底实际点一次货把差异量记成一条盘盈/盘亏动态这样即便偶尔有统计疏漏也不至于失真到影响下一次备料决策。5.3 灵感记录字段太松散归档时找不到东西这个问题的本质是收藏时零成本与使用时高精准之间的天然矛盾。如果你在收藏阶段完全不分类使用时在大堆未归档照片里翻找同样痛苦。我的解法是用一个很轻的自动标签引擎图片导入时会做一次 OCR 文字识别把识别到的关键词比如皮革、金属、木纹、绿色自动附加到灵感记录上不需要人工干预。如果识别不出关键词就保持无标签反正它还可以等到归档到项目时再补充用途角色。此外我给灵感记录增加了颜色占比功能导入时可以抽取图片的主色调生成一个小色卡。这样即使你对图片内容一无所知也可以通过我想找一张偏棕色的配色参考来快速筛选。这个功能虽然开发成本不高但实际搜索体验提升非常明显。5.4 多设备同步时出现冲突怎么办由于 artcraft 目前没有做实时协同多设备同时编辑场景其实没那么常见。但我在路上用手机随手记了一条材料消耗回家后又用电脑提交了一次旧的数据备份导致重复扣减的情况确实遇到过一次。排查之后发现是手机端在离线状态下通过浏览器缓存延迟提交而电脑端覆盖了同一条时间线快照。为了避免这类问题我在数据表里增加了一个 revision 版本号每次写入都会带上版本号如果提交时版本落后后端会拒绝写入并返回“数据已更新请刷新页面”。这个机制虽然简单但解决了我担心的数据完整性大问题。同时在移动端优先考虑写入后立即本地重查确保刚录入的消耗能被及时感知。5.5 图片等素材体积膨胀太厉害艺术创作过程图片往往高分辨率单张可能10MB以上。要是一直往服务器里狂传原图不仅磁盘空间吃紧网络上传的时间也会让人不想用。推荐的做法是上传后立刻生成三种规格缩略图400px、预览图1000px、原图保留但压缩到80%质量。预览图用于时间轴和详情页原图仅当需要导出作品集高清文件时才流转压缩流程。我在工作流里增加了一个后台任务队列图片先传到临时目录由队列异步处理后生成三种规格然后才在界面上显示“图片处理完成”标识。这个异步流程的好处是即便一次传20张图使用者也不会感到卡顿处理完成只是一个时间问题。6. 一些后续可以继续扩展的方向到这一步artcraft 的核心闭环已经走通了灵感入库、项目创建、材料关联、消耗记录、进度捕捉、作品集沉淀。但它还能继续生长的方向也很多。我个人比较看好的几个扩展点是第一生成月度或季度的创作统计报告比如本月完成3件作品消耗了多少材料材料成本是多少相比上月是增是减第二增加图纸/模板库把常用尺寸的裁切版型存成PDF/矢量图和项目绑定后可以一键打印第三对接一下社交平台的发布接口作品集完成后可以直接排版后导出九宫格图发到自己的主页省去手工拼图的环节。不过我的原则是“够用就好”。手工艺创作管理的本质是让创作的链条更顺畅而不是让工具本身成为新的负担。根据我这两三个月的实际使用体验artcraft 已经完全改变了我的工作台习惯——以前那些散落在相册、备忘录、购物车和脑子里的零散信息终于被收拢到了一个真正自然的流程里。如果你也在玩手工、做设计或者做任何周期较长的实体创作我真心建议你把项目材料进度快照这套框架试着套用到自己的流程里哪怕不用我的工具先按照这个思路整理一遍也能感受到一种从未有过的从容感。最后再分享一个小技巧我每周五晚上会花五分钟快速浏览这一周录入的所有灵感碎片只做一件事——把其中已经过时或者看腻的图片删除。这个看似无用的习惯反而让灵感库一直保持高信噪比下次创作时打开灵感箱的体验跟打开一个精心整理过的私人画廊一样舒服。删有时候比存更值钱。