ArtCraft 和 PhotoCraft 下载前先核对来源

ArtCraft 和 PhotoCraft 下载前先核对来源
灿烂的番茄原本想写一篇“PhotoCraft 能否代替 Photoshop”。找安装包时,问题却先来了:搜索结果里有自称官方的 GitHub 仓库,简介反复堆叠 artcraft adobe、photocraft photoshop、download artcraft 等搜索词,仓库首页又催人下载 Windows 压缩包。如果我还没弄清是谁发布的软件,就劝读者下载安装、再谈功能评测,次序恐怕颠倒了。
我查到的仓库线索
以 2026 年 10 月中旬查询 GitHub API 的结果为例,ArtCraft-Corp/ArtCraft 的仓库创建于 10 月 10 日,简介将下载链接直接指向 GitHub Release 的 ZIP;PhotocraftAdobe/PhotoCraft-Photoshop 同样创建于 10 月 10 日,其主页链接也是 Windows portable ZIP。两者在仓库根目录都列出了 README、LICENSE 和若干分类文件夹,但“有 README、有 MIT 文件、有截图”只能证明页面上出现了这些材料,不能证明压缩包安全,更不能证明它们与某个产品官网存在授权关系。
更值得留意的是前一个仓库的 README 让使用者“如果面板要求,粘贴 studio key”。这并不能单独证明它有恶意,却足够让人停下来检查:所谓 key 从哪里来、会传给谁、程序实际请求了什么权限?我没有下载或运行这两个 ZIP,也没有核实它们与 getartcraft.com 的归属关系。因此本文不提供它们的下载直链,不声称已证实为假官网,也不把项目自称的‘开源’当成已验证事实。
为什么不能拿截图当实测
仓库 README 的产品图可以用来观察发布者宣称的界面,却不能回答 PSD 能否可靠打开、图层与字体是否兼容、导出后会不会丢内容;更不能从几张图得出“免费开源 Photoshop 替代品”的结论。许可证文字与完整可构建源码也要分开看。即使源码确实公开,还需确认 Release 中的二进制能否对应到该源码,以及发布者身份能否与官网相互印证。仅凭一个会把关键词写满简介的新仓库,做“下载指南”并不负责。
我的检查顺序是先从产品官网出发,看官网是否明确链接到该仓库;再从仓库反查官网与维护者身份,查看提交历史、源码目录、构建说明、发布签名或校验和;接着核对 Release 的具体文件与来源,必要时在隔离环境中分析。前后两条链接如果对不上,先不运行文件。尤其不要把来源不明的“studio key”、账户凭证或 API Key 填进刚下载的程序。
第一关是发布者,不是 ZIP 文件名
GitHub 仓库的 owner/repo 可以由注册用户创建,Release 的下载地址长得像 GitHub,也只能证明文件由这个账户发布,并不能证明这个账户是某个桌面软件的原作者。就本文看到的两例,GitHub API 的 created_at 均为 2026 年 10 月 10 日,而 README 中介绍的产品版本、发布时间可能早于仓库创建日;这不是定罪证据,旧项目迁入新仓库也会如此,但应该追问迁移公告在哪里、旧发布页是否链接到新仓库、有无连续提交或发行记录。官网若没有清楚指向该 owner/repo,仓库单方面写“official”也不能完成身份校验。
对 ArtCraft-Corp/ArtCraft 而言,GitHub homepage 字段指向其自身 Release 中的 ArtCraft-v0.41.0.zip;对 PhotocraftAdobe/PhotoCraft-Photoshop 而言,该字段指向 photocraft-0.5.0-windows-x64-portable.zip。这些信息来自各自仓库的公开元数据,证明的是仓库配置了什么,不证明 ZIP 能做什么。域名 getartcraft.com、名字里带 Adobe 的账户、写着 MIT 的许可文件,是三个不同的来源线索,任何两者间的归属关系都应由双向可核的证据建立,不能靠名称相像来推断。
第二关是源码与发布物能否对上
若某页面称软件开源,先查看仓库里是否有能构建主程序的源码、依赖锁定文件、构建指令与可复现的发行说明;根目录有 README.md、LICENSE、Screenshots/ 或零散片段并不足够。接着找发布流程:版本对应的 tag 是什么,构建是否由可审查的 CI 产生,签名证书或校验和由可信渠道发布。单独附在下载页上的 SHA-256,只能帮忙确认下载前后文件一致;攻击者若能同时换掉 ZIP 与网页上的哈希,它不能证明文件安全。可复现构建也不是所有小项目都具备,但缺少这一步时,至少不能把“源码可看见”写成“发布二进制已经得到源码审计”。
真需要获取文件供分析,应在明确授权且有隔离环境的前提下进行,不把它放进日常系统启动项,更不要先输入真实凭证。Windows 上可用系统自带的 Get-FileHash 在隔离环境算哈希,但必须与独立可靠的发布渠道核对才有意义;只看杀毒软件一次扫描的“未检出”也不能推导无害。对普通读者而言,缺乏身份与发布链证明时,不下载、不运行往往比设计一套复杂的沙盒分析更划算。
仓库信息本身可以不下载程序就检查。安装了 GitHub CLI 的读者可执行以下只读命令,对照 created_at、homepage 与仓库所列 Release 文件;查询日期和实际返回值应保存在自己的核验记录里。它们只读取 GitHub 元数据,不会运行该项目代码:
1 | gh api repos/ArtCraft-Corp/ArtCraft --jq '{created_at,homepage,html_url}' |
若要查看 Release 中有什么文件,可在 GitHub 页面打开对应的 Releases 栏并核对发布者、tag、发布时间及附件;若没有 Release、文件改名或仓库被删,应该记录“本次未找到”,不能继续照旧文引导下载。第三方镜像的介绍有时先于真实项目上线,甚至能把项目不存在的功能写进摘要,因此独立来源之间相互引用的关系比多篇内容使用同一套宣传措辞更重要。一个转发官方稿件的新闻站,可以佐证当时有人这样介绍,却不能代替软件发布者的身份确认。
还可以把线索分成三个等级:其一,仓库自述,比如 README 上写“开源”“Windows x64”“支持 PSD”;其二,可观察的 GitHub 元数据,比如创建时间、仓库目录及 Release 附件名称;其三,经过独立验证的事实,比如从官网双向链接确认身份、从源码构建出能与发布物对应的程序,并用自己准备的 PSD 文件测试兼容性。前两级能决定是否值得继续调查,却不足以跨级宣布“安全可靠”。这不是咬文嚼字,下载推荐涉及读者的电脑和账号,证据不能只靠标题里的“official”。
要评测 Photoshop 替代能力,应测哪些事
等来源核对无碍,才轮到产品体验。与 Photoshop 比较,至少需要同一组素材、相同版本、明确系统配置,并逐项看图层混合、蒙版、文本字体替换、PSD 导入导出、色彩配置和大型工程的保存恢复。举例说,“能打开 PSD”与“保存后交还给 Photoshop 还能完整编辑”是两项不同的测试;截图也无从显示撤销记录是否正常、滤镜在离线环境里是否仍可用。想写可靠的结论,应附实际文件、步骤、结果与失败情形,不能把仓库 README 的产品承诺改写成本站测评。
目前这几项验证都没有完成。所以这不是对 ArtCraft 或 PhotoCraft 本身下判决。产品可能有其真正的官方渠道;这里只能就我核查到的两个具体仓库说明证据不足。等拿到可核对的官方源码、发行渠道和可运行版本,再写软件功能比较,才有意义。搜索热度固然诱人,但“排名靠前”从来不等于“下载安全”。
核对对象:ArtCraft-Corp/ArtCraft · PhotocraftAdobe/PhotoCraft-Photoshop。仓库内容随时可能更新,本文记录的是写作时看到的状态。






