一位开发者用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天能搭出骨架，但骨架不等于房子。 23
