换 Photoshop 前，先用 4 个问题验收 PhotoCraft 的 PSD 工作流

今天被一个开源项目刷到的人，可能都会有点心动。PhotoCraft 是一个用 Rust 写的图像编辑器，项目把自己定位成面向 Photoshop 工作流的 clean-room 重写。截至写稿时，它在 GitHub 已有约 4.9 万 Star。

这个数字很容易把人带到一个结论，订阅终于可以停了。

可真要迁工具，最贵的从来不是把软件装起来的十分钟，而是那些躺在硬盘里的 PSD。里面有中文字体、智能对象、调整图层、蒙版、混合模式，可能还有一堆两年前的交付文件。你要的不是一个看起来像 Photoshop 的界面，而是它打开、改完、保存、交付之后，下一位同事还能不能接住。

所以这篇不讨论「它能不能替代 Photoshop」这种太大的问题。项目自己也标成 early alpha，答案不该被一篇热帖抢答。更有用的事，是趁它还热，把验收顺序留好。

下面四个问题，适合任何准备把历史 PSD 交给新工具的人。PhotoCraft 只是一个具体样本。

别先看工具栏，先拿出最难的四个文件

PhotoCraft 的 README 很会让人兴奋。它列出了图层、蒙版、调整图层、文字、矢量、画笔和分层 PSD，还写了 500 多条可调用命令。项目展示的界面也不是只摆一个空画布，曲线、直方图、文字图层和导出面板都在。

图来自 PhotoCraft 官方 README，展示的是项目演示文件，不是本文实测。

但迁移时最不该做的，恰好就是找一张普通 JPG 点几下滤镜，然后宣布它可以用。

先从你的文件库里拣四类副本出来。一个多层海报，专门看文字、图层样式和混合模式。一个修图稿，专门看调整图层、蒙版和色彩。一个带智能对象或外链素材的交付件，专门看引用关系。再加一个真正要交厂或交客户的文件，专门看尺寸、颜色配置和导出。

这四个文件不用漂亮，越让人头疼越好。把它们复制到单独目录，别拿唯一原件做试验。工具是否能替你省订阅，先由它们决定，不由 Star 数决定。

项目公开的 PSD 说明 给了一个很好的提醒。它说自己在 psd-tools 测试集的 309 个文件里，有 307 个能在重新保存后保持渲染结果。这是值得认真看的工程信号，不过它仍然是项目选定的语料，不是你的品牌文件库。

画面没变，不等于文件真的回来了

PhotoCraft 也很坦白地写了一个限制，重新保存的文件不会和源文件逐字节相同。它会重写图像资源、图层记录和合成图。这个表述反而比「完全兼容」靠谱，因为它把验收的重点从「能打开」拉回了「你需要保留什么」。

第二个问题就落在这里，重新打开之后，文件里的语义还在不在。

不是只看画布上有没有一张差不多的图。请在副本里做一次轻微但能暴露问题的编辑，比如改一处文字、隐藏再显示一个图层、移动一个蒙版、调整一条曲线，然后保存。接着用原来的工具重新打开，或者至少把两边导出的成品放到同一尺寸下比较。

你要记录的不是「感觉没问题」，而是这几类结果。

文字是否仍可编辑，中文字体是否替换
图层、蒙版和混合模式是否仍按原意工作
调整图层与智能对象是否保留为可继续编辑的状态
导出后，颜色与透明边缘有没有变化

这一步有点像代码迁移后的回归测试。截图相同只说明一帧看起来过关，不说明明天还能继续改。对设计源文件来说，能继续改往往比这一刻的像素相似更重要。

项目的公开说明还提到它覆盖 PSD、PSB，以及 8、16、32 位的 RGB、灰度、CMYK 和 Lab 文档。范围很大，但不等于每一种组合都已经在你的生产链路里被验证。尤其是特殊字体、印刷色彩和第三方插件留下的数据，最好单独标成高风险样本。

验收表里还应该多留两列，测试时的版本号，以及失败以后能否退回。前者防止某次更新修好了一个样本、又改坏另一个样本，后者防止团队在没有可逆路径时把半成品当主力。没有这两列，三天后再看记录，大概率只剩一句「当时好像可以」。

碰到不一致也别急着判死刑。先把它归类。若只是预览缩放或某个滤镜的显示差异，可以继续观察。若是文字不能再编辑、图层关系消失、颜色配置变了，或者原工具无法重新打开，那就不是普通小 bug，而是这类文件暂时不该迁移的证据。把文件类型和失败方式留下来，比在群里贴一句「有问题」有用得多。

图来自 PhotoCraft 官方 README。导出面板好看不等于你的交付规范已经被覆盖。

有交付的一天，色彩和版本才会来算账

第三个问题不是「它支持多少格式」，而是「你的下一次交付靠什么证明没出错」。

很多迁移测试只做到打开和保存，到了导出才发现事情没那么简单。社媒图、网页图、印刷 PDF 和需要留透明通道的资产，各自都可能踩到不同的坑。项目 README 明确写了部分格式和色彩模型的支持范围，也列出了 HEIC 只读、AVIF 写入等边界。这样的边界越早看见越好，别等到交付前一小时才翻。

给每类交付准备一个很小的对照。比如网页图看边缘和透明度，印刷物看颜色配置和尺寸，带图层的存档文件则看能否再次打开。把原工具的导出结果和新工具的结果放在一起，必要时请真正接收文件的人看一眼。

这里不需要装成实验室。你只要能回答两个朴素问题，文件能不能继续被编辑，交出去会不会让人返工。两个答案都还不稳，就先把新工具放在探索、辅助和非关键任务里，不要让它一上来接管全部存档。

还有一个很容易被漏掉的地方，版本并不是生产保障。早期项目更新快，今天能通过的样本不必然代表下个版本仍会通过。把通过的样本和导出规则留在仓库或共享目录里，下一次升级后只要再跑一轮，就能知道是工具变好了，还是工作流悄悄漂了。创作文件也值得有这一点点回归意识。

自动化很诱人，目录权限要比提示词先写好

PhotoCraft 最有意思的一点，是它不只做桌面界面。项目把菜单、工具和对话框放进统一的命令体系，同一套命令可以被界面、命令行、JSON 控制通道和 MCP server 调用。README 还给出了批量处理和无界面导出的示例。

图来自 PhotoCraft 官方 README。它说明命令化工作流有基础，不替代真实项目的权限验收。

这对批量调色、统一导出和重复性的图层操作很有吸引力。可一旦让自动化接触设计文件，第四个问题就该放在工具能力前面，它到底能读哪一层目录，又能写回哪里。

比较稳妥的起步方式，是把输入、临时输出和最终交付拆开。自动化只读副本目录，只写一个新目录，最终文件仍由人确认后再进入交付区。这样即使某个动作列表选错了文件，也不会把一整批原稿悄悄改掉。

README 里的命令示例可以先在测试目录里跑一遍。项目展示了 photocraft-cli batch 和 MCP server 的入口，但这不等于应该把整个素材盘直接交出去。命令化让重复劳动变快，也让错误重复得更快。这个账，做过批量重命名的人大概都懂。

更实际的分工是，把可重复、可观察、可撤销的动作交给命令，比如生成预览、导出不同尺寸、给测试副本套统一调整。把品牌判断、终稿修图、授权素材和正式交付留给人。不是因为自动化不够酷，而是这些步骤一旦错了，损失的不是一次命令执行时间，是一整段创作链路的可追溯性。

现在适不适合用，答案可以分层

如果你的目标是看看一个开源工具能把分层 PSD 做到什么程度，PhotoCraft 已经很值得下载一份副本来研究。公开的回归数据、测试数量和命令化架构，都说明它不只是一个截图里的壳子。

如果你的目标是明天替换整个团队的设计主力，先别急着把结论交给热度。让它通过你自己的四类文件，再谈迁移。你甚至可以把上面的记录做成团队固定模板，以后评估别的编辑器、格式转换器和自动化脚本也继续用。

创作工具的迁移，最后比的不是谁的界面最像，而是谁能把旧文件和下一次修改一起带过去。

你手里最难迁的设计文件，卡住你的通常是字体、图层，还是颜色？