Douku

背景

我为女朋友开发了 Douku，用来管理拼豆库存和图纸。最初的想法很具体：选好一张图纸后，能够方便地找到色号、了解材料是否够用，并记录制作后的消耗。

项目由我独立维护。早期的精力主要花在手机、平板和电脑的界面适配上，随后根据试用反馈，重点转向图纸管理、材料增减和数据恢复等实际操作。

设计

每个制作项目围绕一张图纸组织，使用用户熟悉的色号和材料清单。考虑到用户通常批量补货，也未必愿意逐颗盘点库存，功能集中在色号查找、库存增减和用料记录上。

账户恢复的设计也经历过调整。早期注册流程强制下载账户凭据，重新检查使用体验后，下载改为可选，并增加了保存提醒。用户可以直接进入应用，也可以随时在设置中查看和复制账户码。

图纸导入分为定位图例、解析色号与数量、用户核对三个步骤，确认后的清单再进入库存操作。

实施

应用由 JavaScript PWA 客户端、使用 SQLite 的 Express API，以及 Python FastAPI 识别服务组成。图像经过候选区域定位和 OCR 后，解析器识别色号，规范 x142 等数量写法，并依据位置关系匹配记录。

客户端通过 IndexedDB 保存库存、历史、图纸和待同步变更，并通过带版本校验的接口和持久化发送队列同步数据。界面区分待上传、冲突和需要恢复等状态。识别服务使用线程池执行重型计算，限制并发并串行访问共享引擎，就绪检查覆盖数据库和模型。

遇到的问题

• 功能和用词偏离使用习惯。 试用暴露了几个细节问题：图纸名称与另一项图纸标识重复，专业缩写增加理解成本，色号输入示例也与实际不符。
• 图例识别受到版面干扰。 一张竖版图纸在测试中无法识别。我保存并检查每一步的图像结果，沿裁剪、识别和解析流程定位问题，发现标尺判断可以利用数字连续递增的特征。
• 同步提示缺少可操作的信息。 最初的交互按单设备使用设计。实际使用中出现过“1条数据未同步”的提示，点开却找不到对应内容，用户无法判断该处理哪条记录。

解决方案

调整后的项目页面遵循一张图纸的制作流程，色号搜索方式和示例保持一致，不符合日常需要的功能得到精简。注册时保存账户凭据的操作交由用户选择，设置中保留查看和复制入口。

标尺识别改为检查连续整数序列，同时结合版面结构、颜色变化、边缘密度和文字密度定位图例。保存中间图像便于检查裁剪、识别和解析各环节；最后保留材料清单核对步骤，让用户在修改库存前纠正识别错误。

同步协议通过版本校验拒绝旧状态写入，并保存变更标识和处理回执。在回执保留范围内，相同请求重试时返回已有结果，发送队列保留尚未明确的请求。待上传记录集中在可展开的页面，提供“立即尝试同步”入口；支持的冲突可以选择本地或云端版本，其他情况保留数据供恢复。

成果

Douku 将图纸识别、清单核对、制作规划和库存更新连成了一套可使用的流程，离线编辑、同步冲突处理与恢复入口也在迭代中逐步完善。

这些改进来自试用反馈和实际图纸样本：项目页面贴合一张图纸的制作流程，识别结果可以核对和修改，同步提示也提供了查看记录与重试的入口。