那个用Claude Opus 5.5“重写Adobe全家桶”的开发者，自己在HN上把项目戳破了：76%的功能广度，45%的真实可用度

一位开发者用Claude Opus 5.5，花了不到两周，用Rust重写了七款Adobe软件。Reddit上的标题写着“100%开源、clean-room实现”，承诺一个月内功能对等。

然后他把项目发到了Hacker News。开头第一句是：“我还没准备好把它发到HN。它离可用还差得很远。”

功能广度76%，真实工作可用度45%。 距离完全对齐，按他自己仓库里那份路线图算，还需要2300到4100个Opus 5.5 agent wall-clock小时——一个agent顺序干活的小时数。

76%是怎么来的：628个菜单都有，但“有”和“能用”是两件事

PhotoCraft的76%不是一个笼统的估计。路线图里拆得很细：628个菜单中的628个，68个工具中的56个，35个面板中的30个，31种格式中的17种。

菜单齐了，工具齐了大半，面板基本都在。从这个口径看，AI确实把“把界面搭出来”这件事的成本打到了接近于零。

但一个早期实测的细节很能说明问题。有用户反馈，吸管工具在按住Alt键切换行为时并不工作；文本选择和快捷键也有多处对不上。这些不是“功能没做”，是“做了，但没做到位”。

功能广度统计的是“这个东西存不存在”，可用度衡量的是“这个东西在真实工作里能不能依赖”。 两者之间的落差，就是那2300到4100个小时要去填的东西。

45%的可用度，在用户手里是什么样子

路线图给了三个分层数字：主流从业者拿到43%，只用核心功能的用户拿到61%，整体45%。

换句话说，一个每天用Photoshop干活的人，拿到这个工具，大概有一半以上的常规操作会卡住或者需要绕路。一个只做简单裁剪、调色、导出的人，体验会好一些，但也不会到“替代”的程度。

PSD的读写是更硬的边界。路线图自己写了：“我们写出的PSD还没有被Photoshop可靠地接受”，对应issue #1281和#2469。有用户实测报告，在PhotoCraft里保存的项目变成了JPG，没有分层PSD的选项。另一个实测跑了437个第三方PSD文件，加载错误是集中出现的一类问题。

对Adobe替代品来说，PSD兼容不是“加分项”，是“入场券”。 你打不开客户发来的分层文件，或者你存回去的文件对方打不开，这个工具就进不了真实工作流。579个开放issue的积压，主要就堆在这类“能用但不可靠”的地方。

性能维度更直白：25个性能预算里只达标3个，22个超预算，150层文档会触发GPU崩溃。AI和生成功能只有10%的准备度，排版40%，插件生态15%。

这不是他一个人的问题：53%的AI代码“看着正确但不可靠”

PhotoCraft的45%之所以值得聊，是因为它和行业数据对得上。

Sonar 2026年的开发者调查里，88%的开发者报告AI生成代码带来了负面效果，53%的人明确说AI代码“看起来正确但不可靠”，96%的开发者不完全信任AI生成代码的功能正确性。这53%描述的正是PhotoCraft用户遇到的东西：菜单在、按钮在、逻辑跑得通，但Alt键不生效、PSD存回去会坏、150层就崩。

Veracode的同年的报告从安全角度给了另一个数字：AI生成代码在安全测试中的失败率大约44%到45%，而且这个通过率在过去一年几乎没有改善。两个45%放在一起看，指向同一件事：AI把“从0到1”的成本压得很低，但“防御性工作”——错误处理、边界条件、兼容性、安全性、性能——这些不产生可见功能、却决定能不能交付的部分，它系统性地跳过了。

Sonar那篇关于“理解债”的分析说得很准：代码生成的速度已经远远超过了组织验证它的能力。PhotoCraft的2300到4100个小时，本质上就是验证和补全的时间。

那14天里到底发生了什么：539k行Rust，277次Claude署名提交

把项目规模摊开看，AI的生产力是真实的。

PhotoCraft在14天内积累了539,000行Rust代码、1,306个文件，提交历史里有277次以Claude署名的提交。一周内GitHub星标冲到6,691。一个4人团队用AI辅助做出了七款应用的骨架，全部MIT/Apache开源。

这不是“AI写不出代码”的问题。 它写出了海量的、结构上像模像样的代码。路线图里提到，PhotoCraft把PSD读写、图像合成、滤镜运算和界面拆成了不同的Rust模块，是一套真正的软件结构。

问题出在“结构对了”之后。一个功能从“模块存在、函数能调用”到“在用户的真实文件上稳定工作”，中间隔着的是边界条件、格式兼容、性能调优、异常恢复。这些东西不体现在代码行数里，只体现在那22个没达标的性能预算、579个开放issue和“PSD不被Photoshop接受”里。

14天能搭出骨架，但骨架不等于房子。 2300到4100个小时，是在给骨架布线、通水、做防水、通过验收。

对想用Claude Code做产品的人，这份路线图是一份诚实的检查清单

如果你正在用Claude Code或类似的Agent做自己的项目，PhotoCraft的ROADMAP比它的代码更有参考价值。它把“从Demo到生产要补什么”拆成了可对照的条目：

PSD兼容性对应的是“你的输出格式能不能被目标生态接受”。22/25性能预算未达标对应的是“功能跑通了，但速度/内存/稳定性不在可交付范围内”。579个开放issue对应的是“用户已经在真实场景里碰到了你没想到的情况”。AI功能10%准备度对应的是“宣传里最亮眼的那部分，往往是完成度最低的部分”。

更值得记住的是一个对比：同一个项目，在Reddit上的说法是“一个月100%对等”，在Hacker News上的说法是“远未准备好”，仓库里的ROADMAP写的是45%和2300小时。最诚实的数字，通常不在发布文案里，在仓库的路线图文件和issue列表里。

2300到4100个agent小时，如果按一个agent顺序干活、每天8小时算，是9到17个月。这不是“AI做不到”，是“AI把做到的成本从‘写代码’转移到了‘验证和补全’”。代码行数变便宜了，能交付的软件没有。

那个开发者自己在HN上把项目戳破，比任何批评者都狠。但他的ROADMAP也证明了一件事：他知道45%和100%之间差的是什么。知道差什么，比假装不差，离交付更近一步。