用Python和SQLite为手工艺创作者打造一套本地配方数据管理系统

1. 为什么传统工艺创作者需要一套自己的数据系统

1.1 我在三次釉料失败后才意识到的记录问题

先交代一下背景。我平时做陶艺，工作室里堆着高岭土、长石、石英、氧化铁，还有一摞翻烂的笔记本。最初两年，我的创作几乎完全是靠感觉：今天这个比例调出来好看，就赶紧烧一批；下个月想复现，发现当初写的是"氧化铁少许""升温别太快"——这种记录方式基本等于没有。

真正让我下决心动手做点东西的，是连续三次翻车。第一次是釉料缩釉，整窑杯子全部报废；第二次也是缩釉，第三次终于不缩了，但我根本说不清改了哪个变量。我把笔记本摊开对比，发现该记的参数全没记：室温多少、湿度多少、釉料研磨细度、浸釉厚度、烧成曲线的升温速率……这些变量任何一个漂移，结果就完全两个样。

那时我意识到，传统手艺和数字工具之间存在一个巨大的空白地带。手工创作不是不能记录，而是现有的记录方式太"非结构化"。写在本子上的字，检索不了；拍在手机里的照片，归不了类；就算我想用表格管理，也会被一堆复杂的模板吓退。于是我开始琢磨：一个既能尊重手工创作习惯，又能把关键数据锁死的轻量工具，长什么样？

1.2 市面上的笔记、表格、项目管理工具——都不顺手

我试过几类现成工具，每一个都差一口气。

普通笔记软件（备忘录、Notion这类）的问题是太自由。自由到我在写记录的时候根本不知道该填什么字段，结果又滑回了"氧化铁少许"的写法。表格软件（Excel、Numbers）倒是结构化，但维护成本高得吓人。你得自己设计行列、写公式、管版本，稍微复杂一点的筛选对比就要折腾半天。项目管理工具更不用提，它们的逻辑是"任务-人员-截止时间"，和烧窑、施釉这种流程完全不搭。

我需要的其实是另一个东西：它得围绕"一次创作过程"来组织数据。从称量材料、混合搅拌、成型、施釉，到入窑烧制、开窑记录，一整条链路的数据都应该被关联在一起，并且能随时回溯对比。更关键的是，录入要快，不能让我为了记个配方而花十分钟填表格——人在满手泥浆的时候，只想掏出手机快速丢几个数字进去。

这个需求市面上没有现成答案。那就自己写一个。项目我叫它artcraft，当作"工艺 + 工艺"的意思：用软件工艺的严谨，去服务手作工艺的创造。

提示：如果你也有类似的"想复现却复现不出来"的烦恼，先别急着买新工具。下面这套思路完全可以照着复刻，不需要太多编程基础。

2. 把一次烧制变成一张"工艺卡"：artcraft 的数据模型

2.1 从材料清单到环境参数

动手写第一行代码前，我先干了件最笨也最有用的事：把我过去三年翻车和成功的记录全部摊在桌上，找出哪些字段是"选填"，哪些字段是"必填"，哪些字段当初没记所以现在特别后悔。

最后我抽象出一个叫"工艺卡"（Recipe Card）的核心概念。它从四个维度描述一次完整的创作：

• 材料清单：每样材料的名称、品牌/产地、用量、单位。用量按照百分比和实际克重两种口径记录，因为配方既可能需要缩小，也可能需要按比例放大。
• 工艺步骤：从混料到烧制的每一步，标出步骤类型、开始时间、结束时间、关键参数（比如搅拌转速、陈腐天数、施釉厚度）。
• 环境条件：室温、相对湿度、天气，这些看着不起眼，但对陶艺来说影响非常大。同一桶釉料，南方回南天和北方冬天刷出来完全是两个颜色。
• 烧成参数：目标温度、升温段数、每段升温速率、保温时长、气氛（氧化/还原）。

这些字段不是凭空拍的。我翻了国内外很多釉料数据库和制陶笔记，并做了个简化：只保留"每次创作一定会遇到，而且不记录就会丢信息"的字段。宁可表格宽一点，也不要因为怕麻烦而漏掉关键变量。

2.2 版本与结果：工艺卡如何滚动迭代

但只有一张静态的工艺卡还不够。现实是，配方永远在进化和迭代。今天这个版本烧出来偏绿，我下周微调一下氧化铁的比例，下下周再调整一下升温速率。如果每个版本都单独存一张卡，数据就会越积越散，看不出演变关系。

所以我在工艺卡里增加了版本号、继承关系和结果评估三个概念。每次调整，不是新建一张卡，而是基于最新版本复制出一条新版本记录，并标注修改了哪些字段、为什么改。版本之间可以对比，可以回滚。等烧制结果出来后，再补上成品照片、质量评分（从 1 到 5 打分）和一句话问题描述。

这样一来，工艺卡就不再是"一张静态表单"，而是变成了一个研究日志。我不仅知道这个釉料配方现在长什么样，还能看清它三个月前长什么样，中间经历了哪些试探，哪次试探成功了、哪次翻车了。

2.3 代码落地：用一张 SQLite 表承载工艺卡

数据结构想清楚后，代码实现反而很快。我用的是 Python 内置的sqlite3模块，没有引入 ORM，因为这项目小，直接写 SQL 反而更直观。

工艺卡的基础表结构大概长这样：

CREATE TABLE recipe_card ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, -- 工艺卡名称 recipe_type TEXT NOT NULL, -- 类型：釉料/泥料/化妆土 version INTEGER NOT NULL DEFAULT 1, parent_version_id INTEGER, -- 继承自哪个版本 material_json TEXT NOT NULL, -- 材料清单，JSON数组 steps_json TEXT NOT NULL, -- 工艺步骤，JSON数组 environment_json TEXT, -- 环境条件，JSON对象 firing_json TEXT, -- 烧成参数，JSON对象 result_score INTEGER, -- 最终评分 1-5 result_note TEXT, -- 问题描述/心得 photo_path TEXT, -- 成品照片路径 created_at TEXT DEFAULT (datetime('now', 'localtime')) );

大量使用 JSON 字段，是因为手工创作的可变性太大了——每个类型的配方，材料数量、步骤数都不一样，用固定列根本存不完。JSON 提供了灵活性，SQLite 又保证了查询和索引的能力。想快速按名称或类型筛选时，写一条WHERE recipe_type = '釉料'就行；想展开看材料明细时，代码里解析 JSON 就好。

为了让录入足够快，我还专门写了一个简单的命令行函数，核心目标是"30 秒内记录一次称量"。实测下来，手机端通过 SSH 连到工作室的小主机，手脏的时候用语音输入几个数值，效率勉强能接受。

3. 面向"手工艺创作者"的功能设计与选型逻辑

3.1 为什么是 Python + SQLite 而不是其他组合

很多朋友问我，为什么不用最新的 Web 框架或者桌面应用框架？我列一下当时的关键考量：

• 使用环境恶劣：工作室里全是灰、泥、水蒸气，我不会把一台性能很好的主力电脑搬进去。实际运行在一个旧的迷你主机上，性能非常有限。
• 开发速度优先：我想在两三天内有第一版能用的东西，而不是先折腾一个月环境配置。
• 数据一定要在本地：网上那些云端笔记，网络一断就完蛋，而且我总觉得材料配方这种数据不该随便传到别人的服务器上。
• 后续要能分析：将来要做烧制曲线对比、釉色结果分类，Python 的生态最方便。

SQLite 是我最放心的选择。单文件存储、备份就是拷贝文件、查询能力足够强，而且完全离线可用。对比一下其他方案：MySQL 太重，PostgreSQL 更不用说，对于单用户场景完全是浪费。文件型存储（CSV/JSON 文件夹）倒是轻，但改字段、做关联查询时会很痛苦。

这是我的选型清单对比，供参考：

3.2 温度曲线的录入与可视化

在手工创作里，最需要"记录"但也最容易被"记录错"的，就是烧窑时的升温曲线。陶艺里常说的"还原气氛""釉面效果"，很大程度上取决于温度曲线形状。

记录方式有两条路：一是买带数据记录仪的窑炉，自动导出 CSV；二是像我这样用低成本方案——窑炉控温面板自带曲线数据，我每隔 5-10 分钟手动抄一次温度，再录入系统。手动录入的精度肯定不如机器自动记录，但胜在零成本、无侵入。

存下来的数据是时间-温度点组成的一个数组：

firing_curve = [ ("09:00", 25), # 室温 ("09:30", 120), # 每分钟约 3.2℃ ("10:30", 320), ("12:00", 800), ("13:30", 1230), # 保温一小时 ("14:30", 1230), # 自然降温 ("16:00", 600), ]

为了后续对比方便，我写了一个简单的均分采样：把整个烧成过程按时间分成 100 个采样点，再做归一化处理。这样无论这次是 3 小时烧完还是 6 小时烧完，两条曲线都能叠在同一个坐标系里对比，直观看出差异。

可视化我用的是matplotlib，一键生成配方曲线图。即使不打开电脑看图，只要把图存成 PNG 丢进配方记录里，以后翻起来也一目了然。这块的经验是：不要追求实时曲线，实时数据确实酷，但对创作者来说，烧完后的对比分析远比烧的过程重要。

3.3 材料换算：放大/缩小配方不再按计算器

手工创作者经常碰到一个需求：这张釉料配方算出 1000g 的量，但我的坯体只需要刷 300g。以前的做法是拿出计算器，先算百分比，再乘目标重量，还要考虑损耗率。麻烦不说，一个不小心就算错。

我在 artcraft 里写了一个非常简单的换算函数：

def scaling_formula(materials, target_total_g, loss_rate=0.08): """ materials: [{"name": "长石", "percent": 40}, ...] target_total_g: 目标总克重 loss_rate: 损耗率，默认8% """ adjusted_total = target_total_g * (1 + loss_rate) result = [] for mat in materials: grams = mat["percent"] / 100 * adjusted_total result.append({"name": mat["name"], "percent": mat["percent"], "grams": round(grams, 1)}) return result

损耗率是实操中特别重要的变量。釉料混合、过筛、搅拌、蘸取的过程中，多少会黏在容器壁上。如果每次都不算损耗，实际施釉厚度就总比预期薄。我更常用的是把损耗率固定在 5%~8%，不是每个配方都精算，而是凭经验给一个安全系数。

这个功能看起来不起眼，但恰恰是它让 artcraft 从"记录工具"变成了"创作辅助工具"。因为有了换算，我可以放心大胆地在配方百分比上做实验，先算好理论值，再称量，不用每次对着计算器手忙脚乱。

4. 实跑三个月的五个坑：不写 API 文档就发现不了的细节

4.1 计量单位的规范与转换

第一个坑是我自己给自己挖的：录入时贪快，有的写克，有的写毫升，有的干脆写"一勺"。等到真要用数据对比时，完全没法算。

比如氧化铁这种着色剂，用量差 0.1% 都能导致釉色深浅不同；而水这种液体的密度接近 1，毫升和克还能混着用。但问题在于，陶艺材料里还有一堆堆密度不同的东西：石英、长石、滑石、碳酸钡，每一份的体积和重量都不对应。

我的解决方案是：在材料字典里维护每种材料的密度参考值，录入时强制选择单位（克、毫升、百分比），换算时优先按重量计算；液体的体积仅供参考。虽然初期录入慢一点，但换来的是后续所有换算、对比都不会因单位错误而崩掉。

4.2 升温速率与目标温度的表达方式

第二个坑在烧成参数上。最初我把"升温速率"存成一个数字，比如 150℃/小时。但实际操作里，烧窑升温不是匀速的：刚开火时升温快，到 600℃ 以后因为窑体散热，升温会变慢，而且很多釉料配方要求分段控温，比如 600℃ 前快烧，600℃ 后慢烧到 900℃，再保温一段时间后最后冲刺到 1230℃。

要表达这种复杂曲线，单一数字完全不够。改用数组存多段控温指令后，才真正匹配实际烧窑操作：

{ "segments": [ {"target": 600, "rate": 120, "hold": 0}, {"target": 900, "rate": 80, "hold": 30}, {"target": 1230, "rate": 100, "hold": 60} ], "atmosphere": "oxidation" }

这个改动让整个记录的准确性提升了一个层级。以后我想复现"渐变蓝釉"的效果，只要把对应配方的烧成段位调出来，照着执行就行。

4.3 烧成结果的照片、评分放到哪一层

第三个坑是关于成品照片和评分的存放。最初我把照片存为文件路径，结果整理文件时挪了个文件夹，整条路径就断了，照片在记录里变成死链。后来我改成把照片复制进 artcraft 的数据目录，用"工艺卡ID + 版本号 + 序号"作为文件名，路径写进数据库。备份数据时整个目录一起拷走，照片永远不会丢。

评分放哪一层也折腾了一下。最初试着给每个工艺步骤单独打分，后来发现这个设计过于理想。实际上我只能对最终成品打一个综合分，过程评分主观性太强，评了也没参考价值。所以最终只有"最终成品评分"一栏，外加一句描述。

4.4 备份窗口期别卡在断电那一下

第四个坑比较隐蔽。SQLite 单文件数据库最怕写入过程中断电或掉盘，轻则数据库锁死，重则文件损坏。我的迷你主机曾经因为工作室跳闸，直接导致一次手动烧制的记录全丢。虽然数据量不大，但打击不小。

后来我加了三重保险：

1. 每次写入后立即执行commit，不让事务堆积在内存里。
2. 每天定时用sqlite3 .backup命令做热备份，保留最近 14 天的副本。
3. 每次烧窑结束后（数据录入最频繁的阶段），手动触发一次备份到网盘。

SQLite 在单用户场景下极少出问题，但你永远不能赌断电发生在哪一秒。

4.5 字符串太自由，标签要有边界

第五个坑是关于"标签"。最初我允许随便输入标签，结果出现了一堆语义重复的标签：蓝、蓝色、天蓝、浅蓝、蓝釉……相似的概念被写成了十几个不同标签，统计时一团乱。

我改成维护一个标签字典，录入时只能从已有标签里选，或者新建并在新建前强制检查是否和已有标签重复。这一条规则让我后续的筛选统计省了非常多时间。

5. 当工艺卡变成工作流：artcraft 与现有创作习惯的磨合

5.1 记录时机：从称量开始，到开窑结束

工具再好，如果和创作节奏冲突，就会被弃用。我把 record 环节拆成了四个时机，每个时机只记录必要信息，不贪心：

• 称量时：录材料名、百分比、实际克重。
• 混合后：录环境温度、湿度，拍一张釉浆状态照片。
• 烧窑前：录烧成曲线分段、气氛类型，设置提醒。
• 开窑后：录成品照片、评分、一句话心得。

每步都控制在 30 秒内。这个设计让我坚持了三个月，而不是像之前那样用了三天就嫌麻烦。

5.2 把输出还给创作者：一键生成配方卡

我一直觉得，数据系统的价值不仅在于输入，更在于输出。如果每次记录都要我打开数据库看一行行 JSON，很快我就会厌倦。所以我又做了两个输出功能：

• 一键生成配方卡图片：用 Python 的 PIL 库，把材料清单、烧成曲线、照片和评分合成一张长图，可以直接打印贴到工作室墙上，或者发到配方分享群里。这张图比任何数据库界面都直观。
• 一键生成对比报告：选择两个版本，自动列出所有字段差异，包括材料比例差、烧成曲线变化，生成一小段文字总结。这个功能在分析"哪次改动导致效果变化"时特别管用。

5.3 我目前最常用的三个查询

数据积累到一定程度，查询的价值才真正体现出来。我目前最常用的三个查询，供你参考：

1. 所有评分 ≥4 的配方——这是我创作的"镇店之宝"，每次要开始新系列时，先翻一遍找灵感。
2. 同一釉料在不同季节（湿度区间）下的评分对比——用来判断环境因素到底影响多大。结果很有意思：同一配方，湿度大于 70% 时成品率骤降，这是我以前完全没察觉的。
3. 所有"蓝釉"标签配方的材料比例散点图——把几种同色系配方叠加对比，快速理解哪种材料组合更稳定。

这三个查询让我彻底明白了一个道理：所谓"老师傅的直觉"，其实很多是可以被数据翻译出来的。

6. 这个项目还能往哪里走

跑了三个月后，artcraft 已经从一个解决个人焦虑的小工具，变成了我工作室里的基础设施。我现在能精确回答"这个釉料上次是什么配方、哪个温度段烧的、结果几分"，再也不用翻那几本糊着泥浆的笔记本。

接下来我计划做三件事：

第一，把材料库存和配方联动起来。当天称量的所有材料自动扣减库存，低于安全线时提醒补货。这样不会出现配釉配到一半发现缺料的情况。

第二，加入烧制曲线相似度对比。之前用均分采样存了一堆归一化曲线，现在可以算两条曲线的欧氏距离，找出历史记录里最接近的一次烧制。这样新配方没烧之前，就能参考最相似的那条经验曲线。

第三，考虑把 artcraft 开源。我有一种感觉，需要这套东西的不止我一个人。做木工漆艺、皮具染色、植物染、玻璃吹制的朋友，处理记录的困难是相似的。一个人维护数据模型的速度太慢，如果更多人参与，把各自领域的字段精华贡献进来，这个"工艺卡"的数据结构会变得更通用、更有生命力。

最后再分享一个小经验：别上来就做一堆功能。我最初想实现东西很多，多端同步、协同编辑、报表自动生成，全写在计划表里。真正常用的功能一只手数得过来——录入、换算、查询、对比、导出。少即是多这四个字，在工具类项目里是绝对的真理。先记录，再分析，最后优化，一步步来。