旅行「像」框开发日志——从一张前瞻截图到 2000 幅作品

前言：从 7 月 25 日观看前瞻直播时萌生的一个念头，到 8 月 16 日网站保存超过 2000 幅作品，旅行「像」框一路走来，顺利地完成了它的使命。这篇文章记录它怎样从一个临时念头，变成真正有人使用的工具。

全文约 1.3 万字，如果不想逐日阅读详细的开发过程，可以从“8 月 8 日——如约而至”开始，若只想了解开发之外的故事与最终复盘，可直接跳转至“小插曲”和“尾声”。

项目地址：MiraCeo/tourgrid-studio

项目部署网站：旅行「像」框 | 24×24 像素画编辑器

7月25日——灵感来源

在《明日方舟》夏日活动前瞻直播中，官方展示了一个名为“巡展像素”的游戏内置玩法，隶属于“奇象巡展”这个持续近一个月的大型活动。玩家可以自行填涂一幅 24×24 的像素画用于展示和分享，同时也可以在游戏大厅收藏其他玩家的画作。

前瞻直播录播截图

前瞻直播时我正在回家的动车上。由于信号不好，直到第二天重新观看直播录播时，我才完整了解这一玩法。看完后，我对官方展示出的功能并不完全满意，其中最明显的缺憾，就是没有提供我最想要的功能——图片像素化。

7月26日——初来乍到

回家后的第一个下午，我便着手开发这个项目。第一天完成的内容并不算多，而且当时采用的实现形式后来大多被重构或替换。不过，这些尝试仍然为后续开发确定了基本方向，许多后来加入的功能，也早早地在这个晚上打下了蓝图。

—◊—

我的思路是由内而外，首先实现最核心的部分——图片像素化。

这大概是很多接触像素画的人都会首先想到的功能，也是我最初希望与官方内置玩法形成差异的一点。不过，从项目最终呈现的效果来看，仅凭这一项功能显然还远远不够。如今拼豆流行，早就已经有不少图片转像素画、转拼豆图纸的工具和网站，单纯实现图片像素化并不是一件多么困难的事。真正的问题在于，如何在24×24的极低分辨率下保留原图特征，以及转换完成后，如何在游戏中找到对应色号。

项目总要一步一步做起，脚踏实地，方得始终。

拼豆图案生成器网站截屏

那天晚上的前半夜主要完成了两件事：

第一，我根据前瞻直播中能够确认的 24 种颜色（录播截图中最下方的四种颜色由于被遮挡，所以没有纳入其中），考虑到游戏内操作的便利性，将色板扩充至 64 色，即一行四个，十六行。虽然转换成像素画的时候还原度会有一定的下降，但是考虑到玩家在游戏内的实际操作，这个数量也还算合理。其余颜色则借助 GPT，在尽量保持原有色调风格的前提下进行补充。但后来的结果证明，这套颜色扩展思路的出发点并不合理：真正需要做的，是尽可能覆盖完整色系，而不是简单延续原有色调。尽管如此，64色这一基础设定仍然保留了下来。该框架后来被沿用到7月29日形成的第二版临时候选色板中；又因为64色和官方最终采用的40色都需要为每个像素使用6位索引，数据库中的编码结构也得以继续沿用。

第二，我使用了 Pyxelate、scikit-image 和 SciPy 等库，在同一个 Python 脚本中实现了两套图片转低分辨率像素画的方案：一套直接匹配固定色板，另一套先自动聚类，再映射到固定色板，并且初步拟定了后续网站的图片处理方法——由服务器运行 Python 脚本处理图片，而不是在用户浏览器中完成转换。

—◊—

不过，在后续测试中，这套服务器端转换方案逐渐暴露出几个问题：首先，算法需要反复迭代收敛，时间成本高，在我的本地环境中，处理一张普通图片往往需要半分钟；其次，算法生成的结果并不一定比直接进行加权颜色匹配更接近原图；最后，它的内存占用也偏高，不适合部署在我当时使用的 2 GB 内存服务器上，单次处理就可能吃满服务器内存，更不用说同时处理多个转换请求。

左图为加权颜色匹配，中图为Python脚本转换结果，右图为原图

基于这些原因，这套方案随后被搁置，我也暂时停止了对图片转换算法的继续开发，转而推进前后端功能的实现。7 月 28 日，项目正式放弃服务器端图片转换方案，删除相关子系统、接口、任务处理代码和测试，图片转换则改为在浏览器本地完成。

7月26日深夜至27日凌晨——志同道合？

其实在晚上10点，就已经有朋友向我发来了一个类似项目的视频：【明日方舟】通宵搓出来图片转巡展像素和拼豆的工具。它发布得比我预想中早得多，距离前瞻直播结束甚至不过十个小时。虽然整个网页界面还很朴素，但麻雀虽小，五脏俱全，最基础的功能已经实现了。而这也促使我开始认真思考，自己的项目究竟该如何做出差异化，或者更进一步说，怎么样让我自己这个用户也能够满意。

视频中展示的原始前端

前半夜的忙碌多少有些事倍功半；到了后半夜，我反而慢了下来，项目的方向也逐渐明确：以视频作者分享的 HTML 文件为前端基础，在此之上不断重构和打磨，最终做成一个功能更加完整的网站，而我也会同时从开发者和用户两个角度出发，不断完善这个网站。

7月26日深夜至27日凌晨，项目正式启航。我将项目命名为 tourgrid-studio，建立并整理了 Git 仓库，同时借助 ChatGPT 完成了转换核心、FastAPI 后端以及 Docker 部署环境的初步搭建。

—◊—

当时，在该视频的评论区，我也看到有人直接把视频作者分享的 HTML 文件部署到了自己的网站上，却几乎没有进行修改，甚至保留了文件中的乱码注释和一处失效的图片引用。我希望 Tourgrid Studio 不只是原文件的在线镜像，而是能够在此基础上继续发展，形成一套真正完整、易用的编辑与分享工具。

7月27日——摸索前行

凌晨完成后端与部署环境的初步搭建后，Tourgrid Studio 已经不再只是一个孤立的 HTML 文件——它有了转换核心、API、测试和 Docker 部署环境，勉强具备了一个完整项目的轮廓。不过，此时的网站距离真正“好用”还很远。因此，27日白天的工作主要围绕前端布局重构、功能删减和交互优化展开。

我首先从右侧和上侧工作区入手，重新整理色板、绘图工具和图片导入相关功能，右侧功能区上方的快捷工具甚至一度删到只剩下撤销和重做；随后又调整了中央画布的尺寸、缩放和工作区的整体布局，使整个网页的工作区比此前更加舒展，也为后续功能扩展留下了空间。

优化后的布局展示

我又根据实际绘画需求，对左侧工作区进行了功能删减和外观优化，使其不再局限于前瞻中展示的纵向缩放条。导入图片后，用户可以开启或关闭参考图，并调整其透明度；裁切后的参考图会显示在中央画布上，方便用户临摹。

画布参考图功能展示

在完成三个主要工作区的调整后，我发现原文件左上角的返回键和提示键都没有实际功能，于是我将其分别替换为作者介绍和公告入口。

作者界面展示

相比于不断向页面中增加新按钮，这一阶段更重要的工作，是判断哪些功能真正有用、哪些内容只会增加操作负担，进而优化整体布局，为后续功能扩展打下基础。

—◊—

不过，这一天重要的变化并不只是界面。

下午，我重新审视了图片导入流程。考虑到服务器性能、处理时间和用户隐私，我准备将网页主要使用的图片转换流程迁移到浏览器本地，暂时停用服务器端处理。图片在用户设备中完成裁切、缩放和色板匹配，不再需要发送至服务器；服务器端转换接口虽然暂时仍被保留，但已经逐渐退出网站的主要工作流程。

与此同时，编辑器被进一步限制为固定的 24×24 工作流，导入后的参考图也开始在浏览器中持久化保存：此前，撤销和重做只能恢复画布上的像素，无法同步还原对应的参考图；后续的修改则把画布内容、参考图和编辑状态统一纳入历史记录，使一次撤销能够真正回到上一个完整状态。

修改后的导入界面

傍晚，我参考前瞻画面右上角的保存按钮，加入了独立于自动存档的手动保存点。其左侧的恢复按钮用于回到最近一次手动保存点，并与右侧用于逐步撤销编辑操作的按钮作出区分；恢复保存点这一操作本身仍然可以撤销。随后，我又精简了24×24像素图和图纸的导出流程。至此，从图片导入、逐像素编辑，到保存和导出，最基本的本地创作流程已经逐渐连贯起来。

手动保存点撤销展示

当天晚上，我开始根据和朋友讨论的结果，实现作品的永久保存与分享，这也是 Tourgrid Studio 第一次真正需要由后端保存用户生成的数据。

最开始，我和shallow借用了Base64字符表的思路，让64个不同字符分别对应色板中的64种颜色，这样，一幅24×24的作品可以表示为一个由576个字符组成的字符串。假设每个字符占用一个字节，相比于每个像素使用三个字节的 RGB 数据，空间占用可以从1728字节减少到576字节。不过，这段字符串仍然太长，并不适合直接交给用户分享。

讨论过程中，rx向我推荐了一些能够长期保存图片的网站，但我最终没有采用图床方案。24×24图片本身并不大，真正需要保存的不只是静态图片，而是一份可以重新读取、继续编辑，并携带色板版本、标题和作者信息的作品数据。使用图床不仅无法直接解决这些问题，还会增加第三方依赖，进而增加网络开销。

—◊—

最终，我选择了色板索引这个方案。每一种颜色对应一个色板索引，64种颜色只需要6位二进制即可区分，因此576个像素共需要3456位，也就是432字节，比未经压缩的RGB数据减少了75%。作品数据会与作者名称、作品标题和保存时间等信息一同写入 PostgreSQL，再由服务器生成一段12位 Base58 分享码。其他人凭借分享码即可读取作品。

对于编码版本、色板版本和像素内容完全相同的作品，服务器不会重复保存。而最初提交的标题和作者信息也不会被后来者覆盖，以避免同一幅作品被反复提交后篡改署名。

保存与分享页面展示

在完成这一项核心工作之后，我继续调整了右侧工具区。

此前，右侧快捷工具只剩下撤销和重做。根据前瞻截图，我又加入了辅助线开关和吸管取色；针对画布放大后不便移动的问题，还加入了画布移动模式。至此，五个快捷工具就这样定下来了。

与此同时，我还修改了顶部作品信息和界面图标，并开始补充响应式布局与复刻进度功能。

复刻模式功能展示

回头来看，7 月 27 日在一开始并没有十分明确的计划，很多功能都是在使用过程中不断发现问题，然后再进行针对性的修改。项目的方向也在这一天发生了变化：它不再围绕一个复杂的服务器图片转换算法展开，而是逐渐转向本地转换、像素编辑、状态保存和在线作品分享。

至此，Tourgrid Studio 已经不再只是一个单纯的像素画编辑器，而是逐渐具备了独立网站应有的基本结构。

7月28日——前呼后应

27日的开发一直持续到28日凌晨。零点过后，我继续完善复刻进度与作品状态管理，又对界面和导出流程做了最后一轮整理。零点十八分，我提交了名为“完成初版功能与界面美化”的修改，宣告Tourgrid Studio的第一个完整版本基本成形。

完成初版之后的第一件事，是删除已经退出网页主要流程的服务器端图片转换系统，“上岸第一剑，先斩意中人”，也算与26日最初设想的服务器转换方案正式道了别。

—◊—

上午，我着手处理移动端适配。

此前的界面主要按照桌面浏览器设计，在手机上会出现面板拥挤、按钮尺寸不合适和部分操作区域难以触及的问题。我重新调整了页面在不同宽度下的布局和显示方式，让编辑器至少能够在移动设备上正常打开和操作。

移动端初步适配截图

下午，作品分享功能带来了另一个此前没有认真考虑的问题：既然任何人都可以向服务器提交作品，那么服务器迟早会面临违规内容、恶意提交和作品删除等管理需求。于是，我开始更新后端，并加入了管理员界面。

管理员可以根据状态查看作品，将作品隐藏、恢复或彻底清除，也可以封禁存在滥用行为的客户端，后台会记录每次处理的目标、原因和时间。作品被隐藏或清除后，普通用户在读取该作品时也会得到对应的状态和原因，而不是只看到一个含义不明的失败提示。

后台管理员界面截图

后台工作基本稳定后，我又回到编辑器本身，继续处理此前留下的交互问题：重新整理了快捷键说明，避免不同功能占用同一组按键；修复了切换工具后画布光标没有同步变化的问题；又为像素格加入悬停高亮，让用户在密集的24×24网格中更容易判断当前指向的位置。

—◊—

当天最后得到完善的是复刻进度。此前的设计更接近按颜色记录完成状态：一种颜色要么全部完成，要么完全没有完成。但实际复刻时，玩家可能只会先完成某种颜色的一部分，或者在复刻同一种颜色时有疏漏，因此这种记录方式并不够准确。

新的方案开始逐格保存完成状态。用户可以点击某一个像素格进行标记，也可以按住并拖动，连续标记经过的格子。为了让拖动操作保持连贯，我又接连修复了笔触在格子之间和画布边缘中断的问题。这样一来，复刻进度不再只是一个粗略的颜色清单，而是真正能够对应到24×24画布上的每一个位置。

借助取色器实现的左半面复刻

回头来看，这一天增加的新功能固然不少，但更主要的工作，是回应此前每一个选择带来的后续问题：本地转换确定后，旧的服务器转换系统需要删除；作品分享完成后，后台管理和内容保护必须跟上；复刻进度加入后，也需要从“能够记录”进一步走向“能够准确、顺手地记录”。

前有所用，后有所管；前有所呼，后有所应。

7月29日——精雕细琢

随着网站部署到服务器并对外开放，我开始着重处理移动端工作区的适配问题。

桌面端可以同时容纳左侧参考区、中央画布和右侧工具区，手机横屏却没有足够的空间照搬这套布局。

我首先想到的是加入全屏功能，并将按钮放在左上方公告按钮的右侧。开启全屏后，手机端的显示效果已经十分接近电脑端，基本功能也可以正常使用；但实测发现，并非所有手机浏览器都支持这一功能，因此还需要另辟蹊径。

手机端全屏展示

为了尽可能保留画布面积，我重新设计了移动端工作区：中央画布保持可见，左右面板则根据需要展开；顶部工具栏可以折叠，也可以通过上下滑动快速收起或恢复。工具栏折叠后留下的按钮还可以横向拖动，避免它遮挡正在查看或绘制的位置。

三栏式页面左侧工作区展示

三栏式页面右侧工作区展示

这些改动很快又引出了新的问题。参考图、双栏控件、触摸事件和工具栏状态会相互影响；原本适合鼠标的图片裁切窗口，在手机上也显得过于拥挤。于是，从早上到中午前，我连续修复了移动端参考图、左右面板、触摸绘制、工具栏布局、裁切窗口和缩放操作。

图片导入缺少移动端适配

高度的限制导致提示文本被遮挡

完成这一轮移动端收尾后，我重新回到项目最早的出发点——图片像素化。

此前的导入流程虽然已经可以在浏览器本地把图片转换为24×24像素画，但用户只能调整裁切区域，然后直接接受转换结果。如果图片本身偏暗、颜色过淡，或者缩小后细节混在一起，就只能先退出网站，使用其他软件处理原图，再重新导入。

为此，我在裁切界面中加入了实时预览。用户可以随时在处理后的原图和最终像素化结果之间切换，并在确认导入前观察每一项调整带来的变化。

原图片导入界面

随后，我参考前文所述视频作者后来更新的HTML版本，进一步扩展了导入参数，开始支持亮度、对比度、饱和度和目标颜色数量调节，也加入了Floyd–Steinberg、Atkinson以及Bayer等多种抖动方式和对应的强度控制。

这些参数并不会保证结果一定更好。颜色数量更多，可能保留更多细节，也可能让画面显得杂乱；抖动可以模拟中间色，却可能在24×24的画布上产生过多噪点；提高对比度有时能突出轮廓，也可能让暗部和亮部丢失层次。它们的意义并不是替用户找到唯一正确的答案，而是让用户拥有更多的选择，并且能够根据不同图片自行取舍。

更新后的图片导入界面

—◊—

网站当时缺少类似“油漆桶”的批量改色能力。考虑到24×24画布主要使用固定色板，我没有照搬连续区域填充，而是开始扩展原有的用色统计功能，让用户能够按照颜色统一替换像素。

最初的统计面板只能显示画布使用了哪些颜色，以及每种颜色分别出现了多少次。新的流程允许用户在统计结果中选中一种或多种颜色，再将所有对应像素统一替换为另一种色板颜色。之后，这一功能又从“统计”正式更名为“替换”，让名称更直接地反映它的用途。

为了减少在64种颜色中反复寻找的麻烦，我又加入了相关颜色推荐。用户选择需要处理的颜色后，系统会列出一组较为接近的候选色；选定目标颜色时，画布不会立即被永久修改，而是先显示替换预览。只有确认后，替换才会真正应用；如果结果不合适，也可以直接取消。

7月30日——查漏补缺

白天，我主要在剪辑项目展示视频——【明日方舟】《巡展像素》先行预览 | 在线编辑分享网站旅行「像」框。在我眼里，四分钟不到的视频节奏把握得很好，风格也很清新。

至于视频最终只有几百次播放，其实也在情理之中，就是八个字——前不着村后不着店。前不着村指的是在官方前瞻直播之后，已经有人第一时间做出来成品抢走了一波热度，而我发布的那么晚，关注度自然就低了；后不着店指的是要到8月8日才正式开放玩法，现在也不会有很多人对这个功能有所需求。就这样也挺好的，毕竟，上周我发布的一个视频已经有三十万播放了，这个视频更多是做给我自己看的，也算圆了我的一个开发梦。

8月8日凌晨截图

晚上只做了一项修改：删除了原始HTML文件中从项目伊始便遗留的乱码注释。之后便是静待“巡展像素”正式上线。

8月8日——如约而至

《明日方舟》中的“巡展像素”玩法终于在这一天正式上线。

—◊—

在取得正式色板之前，我先继续完善了图片导入流程。图片导入被区分为照片与像素画两种采样方式：照片更注重区域平均后的整体观感，像素画则尽量保留格子内部具有代表性的颜色。同时，我重新整理了裁切界面的预览逻辑，使用户可以在处理后的原图、24×24 真彩采样和最终色板结果之间进行对比，并为像素画导入加入了对齐网格。

这一阶段还补充了一些不太显眼，却会直接影响实际使用体验的细节。例如，调整浏览器窗口大小、旋转手机或收起地址栏时，裁切区域不再突然偏移；导入较大的 PNG、JPEG 或 WebP 图片时，浏览器会先读取图片尺寸，并在解码阶段将过大的图片缩小到安全范围，以减轻移动设备的内存压力。色板匹配也加入了较为保守的色相保护，避免高饱和颜色在误差接近时被错误地映射到另一种色调。

—◊—

下午四点，游戏服务器进入停机维护，客户端也开始下载并解压更新资源，活动则在晚上六点开服后正式开放。在此期间，我通过解包官方资源提前取得了完整的40色色板，并开始筹备新一期项目展示视频。

官方资源解包记录

结果与此前的预测并不相同：官方最终采用的不是 64 色，而是 40 色，其中白色同时承担绘制颜色、空白背景和橡皮的作用。

虽然颜色数量从 64 种减少到了 40 种，但由于 5 位二进制最多只能表示 32 种颜色，作品中的每个像素仍然需要使用 6 位索引。因此，原先每幅作品 432 字节的压缩结构得以保留，不需要重新设计分享协议。

至此，项目的默认色板正式由此前推测的 natural-64-v2 更换为 official-40-v1。色板的改变也意味着此前保存的作品需要进行迁移。即使数据库中暂时只有十几幅作品，我仍然选择编写迁移程序，将旧 64 色作品逐格映射到距离最近的官方颜色，同时保留原有的分享码、标题、作者、浏览量和审核记录。

8月9日——井然有序

正式色板完成替换后，第二天的工作主要转向管理后台。

此前，后台通过不断加载下一批数据来浏览作品。作品数量较少时，这种方式尚且够用，但当保存、分享、隐藏和清除等状态逐渐增多后，想要重新找到某一幅作品便不再方便。于是，我将后台的作品列表改为页码分页，并在页面上方和下方都加入了翻页、跳转和总页数提示。管理员也可以按照发布时间或浏览量排序作品，并在刷新当前页面后继续停留在原来的浏览位置。

我还加入了一套仅保存在管理员浏览器中的作品收藏功能。它不会修改服务器中的作品，也不会向数据库写入额外状态，只用于临时整理值得关注的作品。收藏列表保持添加顺序，并且可以像其他作品列表一样分页查看。

管理界面展示

8月10日——美美与共

在后台具备基本的作品整理能力后，我开始思考另一个问题：用户上传的作品除了依靠分享码单独传播之外，能否在网站中获得一个集中展示的入口？

凌晨，我加入了推荐作品功能。管理员可以通过分享码维护一组推荐作品，普通用户则可以在主界面的“发现”窗口中浏览这些作品。推荐作品的预览不会增加浏览量，只有在用户真正选择读取作品时，才会沿用原有的画布替换确认流程。

最初，推荐区域只能配置并展示六幅作品；当天晚上，我又将它扩展为不限数量的推荐作品池。浏览器会在本地打乱作品顺序，每次最多展示六幅，并可以通过“换一批”继续浏览。被隐藏或清除的作品不会出现在公开列表中，因此后台的审核状态仍然能够正常生效。

推荐卡片随后加入了匿名点赞。这里的“点赞”没有建立一套独立的永久计数，而是作为作品热度的一部分累加到现有浏览量中；点赞和读取分别使用独立的去重记录，同一用户在三十分钟内重复执行相同操作不会继续增加数值。这样的实现比较轻量，也避免了为了一个辅助功能再增加一整套用户账户和点赞数据库。

“分享”界面展示

与此同时，我也再次对图片导入算法进行了调整。除照片区域平均和像素画代表色之外，又加入了边缘自适应的 Mitchell 采样方式：平坦区域仍以平均颜色为主，边缘和细节较明显的位置则适当保留更多变化。三种方式分别面向照片、像素画以及介于两者之间的复杂图像，用户可以根据素材特点进行选择。

采样方式展示

移动端界面也迎来了另一轮较大的改动——完整的移动端竖屏适配。此前网站主要针对横屏进行设计，移动端也沿用了桌面端的三栏布局，没有为竖屏模式提供完整支持，但仍有不少浏览器不支持锁定横屏，导致用户无法正常使用网站。因此，我决定正式加入竖屏模式，进一步解决移动端适配问题。

新的竖屏布局将画布放在最优先的位置，并通过底部的“参考”“工具”“色板”三个入口互斥打开对应面板。面板展开时，画布会尽量自动避开被遮挡的区域；色板面板的高度也可以拖动调整，并在当前会话中保留。如果浏览器支持，网站仍会尝试进入全屏并锁定横屏；如果设备或浏览器不允许，用户也不必因此中断操作，而是可以继续使用完整的竖屏编辑界面。这样一来，无论设备是否支持全屏和横屏锁定，移动端用户都能获得相对完整的编辑体验。

移动端竖屏界面展示

8月11日——余音未了

功能更新基本完成后，最后一个问题出现在容器冒烟测试中。测试仍按照旧色板检查部署结果，因此在默认色板更换为官方40色后连续触发了CI失败通知。我随后更新了测试中的色板预期，使其与实际运行配置保持一致，此后测试重新通过。

小插曲——AI 降低了门槛，却没有补上规则

我和前文提到的HTML作者也有过一定的交流，只是交流的结果，不尽如人意。

首先是在 27 日凌晨，我看到他在视频评论区表示，自己已经整理出了 38 个官方色，于是便询问这些颜色是如何得到的。其实就和前面说的一样，是官方同步开启的网页活动中的四幅作品和前瞻展示的画板结合得到的，不过，他得到的 38 色与我整理出的 32 色并不一致，可能是因为我这边的归并条件更加严格。方法不同，无可厚非。

评论区截图

真正令我介意的，是原始 HTML 的许可问题。

项目最初使用了他所分享的 HTML 文件作为前端基础。那并不是一个带有提交记录和许可证的代码仓库，而是视频评论区中的夸克网盘链接；下载得到的也只有一个 HTML 文件，没有许可证文件，更没有关于复制、修改和再发布的明确说明。

随着项目的修改范围不断扩大，我开始认真处理原始代码的许可与署名问题。7 月 28 日，我通过私信说明了项目的使用情况，提供了仓库和部署地址，并明确询问能否继续复制、修改和公开相关代码。我也表示，如果获得许可，会在 README、版权范围说明和第三方声明中注明原作者及来源；如果不授权，我会替换所有直接来源于原文件的部分。完整对话如下图。

B站私信截图

AI 的确给了所有有想法的人一条更加便捷的开发途径，包括他，也包括我。

我尊重他制作并分享原始工具的劳动，也正因如此，才会主动说明项目的使用情况、询问授权，并承诺保留来源说明。但对方没有直接回答许可问题，只表示自己即将发布升级版，并建议我部署新版。

我无法认同这样一种做法：将代码公开分享出来，却既不附带许可证，也不正面回答后续开发者对使用边界的询问。公开可下载不等于开源；在 AI 让代码变得越来越容易生成和传播之后，这种区别反而更加重要。

到 7 月 28 日时，Tourgrid Studio 的主要功能已经基本成形。此后至 30 日的开发，主要集中在图片导入预处理、移动端适配和后台扩展，项目早已不是将原始 HTML 简单部署到服务器上。他所说的“要部署的话部署新的吧”，既没有回应我所说明的项目现状，也回避了我真正询问的问题：是否允许复制、修改和公开发布原始代码。最终，我没有直接部署他的新版，只参考了其中新增的导入前预处理功能，继续在自己的版本上进行开发。

他当然可以拒绝授权，也可以对衍生项目持保留态度。不同创作者对于代码复用和二次开发有不同看法，这本身无可指摘。真正令我失望的是，他既没有明确拒绝，也没有说明许可范围，只是用一个与问题并不相干的答复结束了交流。

我算是一个比较开放的创作者。如果有人部署或 Fork 我的项目，我会为自己的作品能够继续产生价值而感到荣幸；但我也明白，并非所有创作者都愿意采用这种方式。我不要求别人认同我的开放态度，只是认为：既然选择公开分享代码，至少应当清楚说明别人能否使用、能够如何使用。对一个具体而审慎的授权询问作出明确回答，也是对彼此劳动最基本的尊重。

—◊—

后来还发生过另一件不算严重，却进一步影响了我观感的事。

8 月 8 日，一位创作者发布了与“巡展像素”相关的视频，并在评论区置顶推荐了旅行「像」框。他不仅附上了网站链接，还特意说明，不会制作拼豆图的观众可以使用这个网站。

看到这期视频的播放量后，我还在评论区开玩笑说，它甚至比我自己介绍旅行「像」框的视频更加热门。

视频作者在评论区置顶推荐旅行「像」框

然而两天后，原始 HTML 的作者也来到这个评论区，附上使用其工具制作的作品，并直接留言：

原始 HTML 作者随后在同一评论区宣传自己的工具

评论区当然不属于任何一个项目，他也有介绍自己工具的自由。但这并不是一个正在中立比较不同工具的讨论区：视频作者已经明确置顶推荐了旅行「像」框。在这样的前提下，作为同类项目的作者，以“直接用我的不就得了”的语气否定原有推荐并宣传自己的工具，在我看来已经不只是单纯分享，而是明显欠缺分寸。

这并不违反平台规则，也谈不上什么严重过错。但“可以这样做”与“这样做是否尊重视频作者和其他创作者”是两回事。至少换作是我，我不会进入一个已经明确推荐其他同类项目的视频评论区，用这样的方式要求观众改用自己的工具。

单独来看，这或许只是一句不太得体的自荐；但它发生在那次没有得到明确答复的授权沟通之后。前者让我看到他面对代码许可问题时的态度，后者则让我看到他处理同行关系时的分寸。两件事放在一起，最终改变了我对这位创作者的看法。

尾声——虽败犹荣

或许7月30日的那个视频已经昭告了我的失败，8月8日与8月10日的视频只不过是我最后的努力。

我也逐渐明白，战术上的失误，足以让整个战略部署功亏一篑：

我在战略上是相当正确的。据我当时所见，Tourgrid Studio 是除前文所述 HTML 工具之外，第二个针对该活动进行预热的项目。可惜第一波流量已经被抢走，我能做的只有继续优化网站。正如前文所述，我也确实一直在持续更新和完善项目。

8月8日，我尽可能提前完成资源解包和视频制作。晚上七点十三分，也就是游戏开服一个多小时后，我便发布了网站介绍视频，后来几条走红的视频，大多到晚上十点以后才出现。

然而，视频到了第二天仍然没有明显起色。截至截图所示的8月16日，播放量甚至还没有破万。明明占据了这样的时间优势，为何最终还是败得一塌糊涂？

—◊—

这么久过去了，我走出来了，也想明白了，原因无非就三个。

其一，我的问题，下图展示的已经是第三版的标题和封面了，8日因为我比较急所以基本沿用了前一个视频的封面和标题，然后封面点击率不出意外地寄了，甚至比上一个视频都差；

其二，视频的问题，虽然我很喜欢这样的风格，但是视频节奏的确有一些慢了，后来出现的一些视频甚至没有详细介绍功能，而是用更短的篇幅直接展示转换效果，一方面，核心功能本来就比较直观；另一方面，更短的内容也更符合短视频平台的观看习惯，不过，与接下来的第三点相比，我认为视频节奏完全算不上主要问题；

其三，也是我认为最关键的一点：平台推流。前两点本身也会影响平台推荐，因此三者并非完全独立；但从最终获得的曝光来看，我仍然认为推流不足是最直接的原因——我眼看着前述的 HTML 工具以及后来出现的另一个网站明日方舟-奇象巡演像素画取色工具，其相关视频播放量不断增长，而我的视频却始终没有获得进一步推荐。三人行，必有我师，我的前端框架借助于前者，后续的图片处理算法又借鉴了后者，只可惜，舞台上没有我的身影。

8月16日晚截图

还有一个我曾经十分在意、后来却逐渐认为无关紧要的因素——像素画的还原效果。在我还期待10日的视频能够带来转机时，看到了这样一个网站奇象巡展拼图工具，它提供的转换和调整方式是我当时见过最丰富的，我原本想参考它的实现，再改进一次网站的图片转换算法。

但是已经无关紧要了。没有曝光，即使做得真的最好也很容易被埋没，更何况还存在着从众效应。即使体验下来没有特别满意，也是能用就足够了，毕竟最终目的只是把转换结果复刻到游戏中，又何必再去寻找其他网站。

回头看，我取得了发布时间上的优势，却没有把优势转换成传播结果。封面点击率、视频节奏、已有工具形成的先发认知，以及平台推荐的不确定性，可能共同造成了结果。与其把原因归结为某一个环节，更准确的说法是：我低估了产品能力与内容传播之间的距离。

—◊—

你问我甘心吗？当然不甘心，即使在所有制作这类项目的人中，我已经算是做得不错的了，但……

无论如何，我总要给自己一个体面的收尾。而所谓的收尾，原本也是最后一轮冲刺——那期“千人千面”视频。尽管结果没有预想中那么体面，但事已至此，也没有什么可再多说的。几天前的一个凌晨，我也想过是否要花钱为自己助力一把，最后还是作罢。如此这般，也好。

从8月8日活动开放到8月10日视频发布，网站中的作品数量恰好从0增长到1000幅；截至8月16日，又刚好达到了2000幅。如今热度已经过去，是时候说声再见了。

—◊—

工具做出来是为了让人用的

有如此多的人切切实实地在这个网站上留下了自己的痕迹，我也应当感到欣慰。与其他同类工具不同，我没有在网站标题中直接使用“巡展像素”或“奇象巡展”，而是留下了一个真正属于自己的名字——“旅行「像」框”。与此同时，项目也在GitHub上收获了五颗星。

从传播结果来看，它没有获得我期待中的关注；但从开发和实际使用来看，它显然不能算作失败。我也算是不枉此行了。