企业官网建设流程全解析

1. 项目概述：从桌面到数字，一个桌面角色扮演游戏爱好者的“造物”之旅

如果你和我一样，是个深度沉迷于龙与地下城（D&D）这类桌面角色扮演游戏（TRPG）的玩家，那你一定对“迷你模型”这个词不陌生。无论是地城里狰狞的兽人，还是酒馆中神秘的旅人，那些精心涂装、栩栩如生的微缩模型，是我们将想象世界具象化的核心道具。然而，随着战役的推进，一个现实问题总会浮现：模型越买越多，收纳、查找、携带成了噩梦；想为某个特定场景找个合适的怪物，得在几十个收纳盒里翻箱倒柜；朋友临时想跑个团，手头却没有对应的模型库。D&D Mini Platform这个项目，就是为解决这些“甜蜜的烦恼”而生的。它本质上是一个数字化的微缩模型管理与应用平台，目标是将我们物理世界中的模型收藏、游戏规则与虚拟的桌面战场无缝连接起来。

简单来说，我想做的不是一个简单的电子版模型图鉴，而是一个贯穿“收藏-管理-应用”全流程的工具。它应该能让我用手机拍一下我的模型底座，就自动识别并录入到我的数字库存中；能让我根据《怪物手册》的页码或挑战等级（CR）快速筛选出今晚遭遇战需要的所有怪物模型；更重要的是，它能与虚拟桌面软件（如 Roll20, Foundry VTT）联动，或者自己就具备基础的虚拟桌面功能，让我在线上跑团时，能直接调用我数字库存里的模型，摆放在地图上，省去重复上传、调整的繁琐。这个平台的核心用户，就是广大的TRPG玩家、游戏主持人（DM）以及模型涂装爱好者，它要解决的是从实体到数字、从静态收藏到动态游戏的核心痛点。

2. 核心需求与设计思路拆解

2.1 需求深挖：玩家与DM的双重痛点

要构建一个有用的平台，首先得彻底理解我们的需求。从玩家和DM的日常中，我梳理出了几个最核心的痛点：

1. 物理库存管理混乱：成百上千个模型，按种族、按阵营、按大小分类？听起来美好，但新买的模型不断加入，分类体系很快崩溃。更常见的情况是，所有模型混放在几个大箱子里，找一个特定的食人魔巫师堪比大海捞针。
2. 游戏准备效率低下：DM在准备一场遭遇时，需要根据剧本挑选怪物。他需要查阅《怪物手册》，记下怪物名称，然后去庞大的物理库存中寻找对应模型。如果找不到，要么用其他模型替代（影响沉浸感），要么临时购买（成本高且来不及）。这个过程耗时耗力，打断了游戏设计的连贯性。
3. 线上/线下场景割裂：如今线上线下混合跑团成为常态。线下聚会可以用实体模型，但线上会议（如使用Foundry VTT）则需要数字令牌（Token）。玩家通常需要为同一套模型维护实体和数字两套资产，重复劳动。理想状态是，我的实体模型库能直接生成或关联对应的数字资产。
4. 模型信息孤立：一个模型除了外观，还承载着游戏数据（如AC、HP、攻击模式）。目前这些数据存在于规则书中，模型本身只是一个视觉代表。能否在查看模型时，快速关联并显示其核心游戏数据？
5. 社区与共享需求：玩家们乐于展示自己的涂装作品，也渴望获取他人分享的模型清单（如“经典地城守护者套装”）。一个可以分享“模型清单”和涂装方案的社区功能，能极大丰富平台价值。

基于这些痛点，D&D Mini Platform的设计目标清晰起来：打造一个以“模型资产”为核心，集“数字化库存管理”、“智能游戏准备”、“跨平台资产同步”、“游戏数据集成”和“社区共享”于一体的综合服务平台。

2.2 技术方案选型：轻量、跨平台与生态集成

明确了做什么，接下来就是怎么做。技术选型直接决定了开发效率和最终用户体验。

• 前端框架：React + TypeScript。选择React是因为其组件化开发模式非常适合构建这种交互复杂、模块清晰的管理平台。TypeScript的强类型检查能在开发阶段就规避大量潜在错误，对于管理模型数据、游戏规则数据这种结构复杂的应用至关重要。UI库方面，我选择了Ant Design，它提供了丰富、专业且风格统一的企业级组件，能快速搭建出美观且功能强大的后台管理界面。
• 后端框架：Node.js + Express。JavaScript全栈开发可以降低上下文切换成本。Express轻量灵活，足以应对平台初期的所有API需求。对于需要更高实时性的功能（如未来可能加入的在线虚拟桌面），可以方便地引入Socket.io。
• 数据库：PostgreSQL。关系型数据库在管理高度结构化、关联性强的数据方面具有天然优势。模型信息、用户信息、游戏规则数据（怪物属性、法术）之间都存在复杂的关联关系（如一个用户拥有多个模型，一个模型对应一个怪物类型）。PostgreSQL的JSONB类型也能很好地存储一些非结构化的扩展数据，比如模型的定制涂装配方、用户笔记等。
• 核心服务与第三方集成：
  • 图像识别服务：这是实现“一拍即录”梦想的关键。我评估了多个云端AI服务，最终选择了Google Cloud Vision API。它的“物体检测”功能能识别出照片中的微缩模型（尽管是特定品类），更关键的是其“OCR”功能可以高精度读取模型底座上厂商印制的产品编号（如“WZK98765”）。通过产品编号反向查询本地或第三方数据库（如Miniature Market的API），就能自动补全模型名称、系列、种族等元数据，极大简化录入流程。
  • 虚拟桌面软件集成：这是平台的“出口”。短期目标是通过生成标准格式（如PNG透明背景图、WebP）的数字令牌，并打包为符合Foundry VTT模块规范的模块，让用户一键导入。长期可以探索与Roll20的API对接，甚至开发简单的内置虚拟桌面视图。
  • 规则数据源：直接搬运受版权保护的规则书内容是不可行的。我们的策略是：1) 仅存储怪物/角色的名称和官方来源索引（如“《怪物手册》第245页”）；2) 提供手动输入自定义数据的字段；3) 探索与开源游戏规则数据库（如5e SRD内容）的合规联动，为开源内容提供自动填充。

注意：在处理任何游戏规则数据时，版权是红线。平台必须明确区分官方版权内容和用户自定义内容，所有功能设计都应以“工具”和“索引”为核心，而非内容提供者。

3. 核心功能模块详解与实操要点

3.1 模型数字化入库：从拍照到信息完善的流水线

这是用户接触平台的第一站，体验必须流畅。我设计了一个多路径入库流程：

1. 自动识别录入（推荐路径）：

   • 操作：用户在App或网页端点击“添加模型”，拍摄一张包含模型底座（最好有产品编号）的清晰照片。
   • 背后原理：照片上传至后端服务器，后端调用Google Cloud Vision API。API返回两个关键结果：objectAnnotations（可能识别为“玩具”、“人偶”）和textAnnotations（提取出的所有文字）。我们编写一个解析器，从文字中匹配类似“WZK”、“GF9”、“ICO”等厂商代码加数字的格式，将其作为产品编号。
   • 数据匹配：平台维护一个产品编号与基础元数据的映射数据库（初期可手动从各大零售商网站爬取公开信息构建）。通过编号查询，自动填充“名称”、“生产厂商”、“产品线”、“种族/类型”等字段。
   • 用户确认与补充：系统展示自动填充的信息，并引导用户补充关键字段：涂装状态（未涂装、已涂装、大师级）、存储位置（如“A箱第三层”）、标签（自定义，如“兽人”、“BOSS”、“最爱”）。最后，为模型拍摄一组多角度展示图（用于生成数字令牌）。

2. 手动录入与批量导入：

   • 对于没有编号的老模型或自制模型，提供全手动表单。
   • 支持CSV批量导入。用户可以按照模板，在电脑上整理好一批模型信息，一次性导入。模板包含：名称、厂商、类型、涂装状态、存储位置等。

实操心得：图像识别不是100%准确，尤其是对于涂装复杂、背景杂乱的模型。我们的策略是“辅助而非替代”。即使编号识别失败，我们也可以将识别出的文字（可能是模型名称的一部分）作为搜索建议，提供给用户。同时，建立用户纠错机制，当某个编号被多次纠正后，可以反向更新我们的本地映射库。

3.2 智能库存管理与检索系统

库存管理不是简单的列表，而是强大的搜索引擎和过滤器集合。

• 多维筛选器：这是核心。筛选维度包括：

  • 游戏属性：种族（兽人、精灵、龙）、阵营（守序善良、混乱邪恶）、挑战等级（CR）、怪物类型（异怪、野兽、构装体）。
  • 物理属性：模型比例（28mm、32mm）、底座形状（圆形、方形）、状态（已涂装/未涂装）。
  • 库存属性：存储位置、标签、来源（某次购买）。
  • 动态清单：用户可以将筛选结果保存为“清单”，例如“失落矿井的怪物包”、“我的所有巨龙收藏”。清单可以一键分享给其他用户。

• 可视化存储：结合“存储位置”字段，可以生成一个虚拟的“储物柜”视图，用格子或抽屉的形式展示不同箱子、柜子里的模型概览，点击即可查看详情。

• 快速检索：支持关键词搜索，搜索范围覆盖名称、标签、自定义笔记。例如，搜索“拿斧头的”，可以找出所有相关模型。

3.3 游戏准备与遭遇战规划器

这是为DM量身定做的核心工具。

1. 从剧本到模型清单：DM在准备遭遇时，输入或选择怪物名称（支持从SRD数据库中选择）。平台展示该怪物的官方艺术图、关键数据（基于SRD）以及一个关键按钮：“匹配我的模型”。
2. 模型匹配：点击后，平台会在用户的库存中，根据怪物名称、种族、类型进行智能匹配。例如，为“兽人酋长”匹配用户库存中涂装最好的兽人模型，并标记为“首选”。如果没有完全匹配，则推荐相似的模型（如其他兽人模型），并允许DM指定替代品。
3. 生成遭遇战卡片：DM确认本次遭遇的所有怪物及其对应的实际模型后，平台可以生成一张“遭遇战摘要”。这张摘要可以打印出来，包含每个怪物的简化数据块（HP、AC、攻击）、对应的实际模型图片/存储位置，以及一个二维码。
4. 二维码的妙用：在游戏现场，DM或玩家用手机扫描某个怪物对应的二维码，可以快速在手机上查看该怪物的完整数据（如果DM选择共享），避免了频繁翻书，也防止了玩家偷看其他怪物信息。

3.4 数字资产导出与虚拟桌面集成

这是连接物理与数字世界的桥梁。

• 数字令牌生成：平台利用用户上传的多角度模型照片，自动裁剪、去除背景（使用如rembg这样的AI库），生成带有透明背景的PNG图像。可以生成不同角度的令牌（正面、侧面），并自动套上符合虚拟桌面软件标准的圆形或方形边框。
• 一键导出至Foundry VTT：
  • Foundry VTT支持用户开发模块。我们可以编写一个简单的模块，该模块在安装后，在游戏世界的设置中提供一个“导入平台模型包”的按钮。
  • 用户在网页端选择一批模型，点击“导出为Foundry模块”。后端会将这批模型的令牌图片、一个预设的演员数据（包含名称、基础属性）打包成一个.zip文件。
  • 用户下载后，在Foundry的“模块管理”中从本地安装此压缩包。安装后，在演员目录中就会出现这些预设好的演员，令牌图片也已关联好。DM只需将其拖拽到地图上即可。
• 通用资产包：除了Foundry专用格式，也提供纯图片包的下载，方便用户用于Roll20、Owlbear Rodeo等其他平台。

4. 技术实现关键点与踩坑记录

4.1 后端数据模型设计：灵活性与扩展性

数据库设计是系统的基石。核心的几张表如下：

• users：用户表。
• miniatures：模型主表。字段包括：id,user_id,product_code（产品编号）,name,manufacturer,base_type,scale,status（涂装状态）,storage_location,images（图片URL数组）。
• miniature_tags：模型与标签的多对多关联表。
• game_entities：游戏实体表（如怪物、角色）。这里只存储索引信息，如name,source（“MM.245”），srd_content（仅限SRD开放内容）。不存储受版权保护的详细数据。
• miniature_game_entity_links：模型与游戏实体的关联表。一个模型（比如一个兽人战士）可以关联到“兽人”这个通用实体，也可以被用户手动关联到“兽人酋长”这个具体怪物。这实现了灵活性。
• collections和collection_items：用于实现用户自定义的模型清单。

踩坑记录：最初我将模型的所有属性（包括种族、阵营）都作为miniatures表的固定字段。但很快发现，不同用户对同一模型的分类方式不同（有人按种族分，有人按阵营分），且游戏实体的属性远比我预想的复杂。后来改为“核心属性固定字段+标签系统+游戏实体关联”的模式，灵活度大大提升。标签系统允许用户自由打标，而关联游戏实体则提供了官方视角的分类。

4.2 图像处理与令牌生成自动化

这是体验上的甜点功能，但技术细节不少。

• 背景去除：我们使用了开源的rembg库，基于AI模型进行背景移除。但它对光线均匀、背景简单的照片效果最好。我们需要在用户上传指南中强调拍摄建议：将模型放在纯色（最好是白色或绿色）背景前，光线充足。
• 自动化脚本：编写一个Node.js脚本，使用sharp库进行图片处理。流程是：1) 使用rembg去除背景；2) 使用sharp将图片缩放至标准尺寸（如256x256像素用于Foundry）；3) 根据底座类型，叠加一个圆形或方形的彩色边框层；4) 将不同角度的图片保存。
• 批量处理队列：当用户导出几十个模型时，同步处理会导致请求超时。我们引入了Bull库，基于Redis创建处理队列。用户发起导出请求后，后端创建一个作业推入队列，立即返回一个“任务已开始”的响应。前端可以通过WebSocket或轮询查询任务进度。处理完成后，提供下载链接。

// 示例：使用Bull创建令牌生成队列 const Queue = require('bull'); const tokenGenerationQueue = new Queue('token-generation'); tokenGenerationQueue.process(async (job) => { const { miniatureIds, userId } = job.data; // 1. 获取模型图片 // 2. 循环调用rembg和sharp处理每个模型 // 3. 打包成zip // 4. 将zip文件上传到云存储（如AWS S3） // 5. 返回文件URL return { downloadUrl: s3Url }; }); // 在API中触发任务 app.post('/api/export-tokens', async (req, res) => { const job = await tokenGenerationQueue.add({ miniatureIds: req.body.ids, userId: req.user.id }); res.json({ jobId: job.id, status: 'queued' }); });

4.3 前端状态管理与性能优化

随着库存模型数量增长（轻松上千），前端列表的渲染和筛选性能成为挑战。

• 状态管理：使用Redux Toolkit管理全局状态，如用户信息、库存列表、当前筛选条件。特别是筛选条件，我们设计为一个独立的slice，任何筛选器的变化都会触发一次针对当前库存列表的本地计算（或向后端请求新的筛选结果）。
• 虚拟滚动：对于模型列表，我们采用了react-window库实现虚拟滚动。无论用户有100个还是10000个模型，只会渲染可视区域内的几十个DOM元素，极大提升了滚动流畅度。
• 图片懒加载：列表中的模型缩略图使用懒加载，只有当滚动到视口附近时才加载真实图片，初始时使用一个极小的Base64占位图。

5. 部署、维护与未来迭代思考

5.1 初期部署架构

考虑到个人项目的成本和维护复杂度，我选择了以下架构：

• 前端：部署在Vercel或Netlify。它们对React应用支持极好，自动化部署、全球CDN、免费额度对起步阶段非常友好。
• 后端API：部署在Heroku或Railway。同样是考虑到易用性和免费套餐。将环境变量（如数据库连接串、API密钥）妥善配置。
• 数据库：使用Supabase或Heroku Postgres。Supabase提供了完整的PostgreSQL数据库外加实时订阅、存储等BaaS功能，生态更现代。
• 文件存储：模型图片和生成的令牌包需要存储。我选择了Cloudinary或AWS S3。Cloudinary的API对图片优化（压缩、格式转换）非常强大，而S3更通用、成本更清晰。

5.2 实际运营中的挑战与应对

1. 数据来源与版权：这是最大的挑战。我们坚决不爬取和存储受版权保护的详细规则数据。所有非SRD内容，都只作为“索引”存在（名称和出处）。鼓励用户手动输入自定义数据。同时，积极与一些微缩模型厂商接触，探讨通过官方API获取产品数据的可能性，这能极大提升自动录入的准确率。
2. 用户习惯培养：让用户从零开始录入几百个模型是一个极高的门槛。我们通过“批量CSV导入”和“从流行社区导出文件转换”等工具来降低初始成本。并设计“成长性奖励”，比如每录入50个模型，解锁一个高级筛选器或视觉主题。
3. 社区冷启动：分享清单和涂装方案是核心社交功能。初期需要“创造”内容。我的做法是自己精心制作几个高质量的“经典战役模型包”清单和涂装教程作为种子内容，并积极在Reddit的r/DND、r/minipainting等社区分享，引导用户回平台查看。

5.3 未来可能的迭代方向

这个平台有丰富的扩展可能性：

1. AR预览功能：利用手机AR，让用户可以在真实的桌面上“预览”数字令牌的摆放效果，辅助线下战局布置。
2. 涂装流程管理：为涂装爱好者增加项目管理功能，可以记录每个模型的涂装进度（底漆、底色、 washes、高光）、使用的颜料品牌和色号，甚至关联教学视频。
3. 模型交易与置换市场：在用户间搭建一个以模型为基础的二手交易或置换平台，以“库存”为基础，交易变得更方便。
4. 与3D打印整合：为自制模型玩家提供支持，可以关联3D打印文件（如STL文件）来源，管理打印进度等。

构建D&D Mini Platform的过程，就像是在进行一场长期的战役。它从一个简单的个人需求出发，逐渐演变成一个试图解决社群共同问题的项目。技术实现上有挑战，但更大的挑战在于对用户需求的理解和对复杂生态（版权、厂商、不同虚拟桌面软件）的适配。目前，一个可用的MVP（最小可行产品）已经能覆盖从拍照录入、智能管理到遭遇规划的核心流程。对我来说，最大的成就感莫过于在准备下一次跑团时，不再需要花半小时翻找模型，而是轻松地在平台上点选几下，就生成了完整的遭遇战清单和对应的数字令牌包。这节省下来的时间，或许又能多设计一个有趣的剧情钩子了。