一位开发者利用Claude Opus 5.5，在不到两周的时间里，用Rust语言重写了七款Adobe软件。他在Reddit上发布了这一项目，声称实现了“100%开源、干净房间重建”，并承诺在一个月内达到功能对等。然而，他在Hacker News上发布时，却表示项目尚未完全就绪，距离实用版本还有很大差距。根据他的评估，功能覆盖率为76%，而真实可用度仅为45%。如果按照他自己的路线图来看，还需要2300到4100个Opus 5.5 agent wall-clock小时的努力工作，以便实现全面的一致性。76%的功能覆盖率是经过仔细计算得出的，其中包括628个菜单项，68个工具中的56个，35个面板中的30个，以及31种文件格式中的17种。虽然菜单和大部分工具都到位，但有些功能并不能真正被使用。例如，早期用户反馈提到，在使用吸管工具时，按下Alt键并未能如预期切换功能；而文本选择及快捷键也存在许多不匹配的情况。这些问题表明，不同于“功能已完成”的简单量化，“可用性”则在于用户能否在实际使用中依赖这些功能。功能覆盖率与真实可用度之间的差距，反映出需要填补的2300到4100个小时的工作量。在此情况下，路线图提供了三组不同的使用数据：主流用户获得43%的功能，核心功能用户获得61%的，而整体用户的可用度则为45%。换句话说，一个经常使用Photoshop的用户，拿到这个工具后，他们的常规操作中大约有一半以上会遇到问题。而对于那些进行简单裁剪、调色和导出的人来说，虽然体验会好一些，但仍不足以达到“替代”的水平。PSD文件的读写是个更为严格的边界问题。按照路线图的说明：“我们所生成的PSD文件还无法被Photoshop可靠接受”，对应的漏洞号为#1281和#2469。有用户实测，发现使用PhotoCraft保存的项目变成了JPG格式，而没有分层PSD的选项。还有一位用户对437个第三方PSD文件的测试，显示加载错误成为了普遍问题。对于Adobe的替代软件来说，PSD兼容性不是“华丽附加”，而是“基本要求”。如果不能打开客户发送来的分层文件，或是自己保存的文件无法被对方打开，该工具就无法嵌入真实工作流程中。目前，项目中还存在579个开放问题，主要集中在那些“能用但不可靠”的功能上。在性能方面，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将“从零到一”的开发成本压低至极限，但在“防御性工作”方面——如错误处理、边界条件、兼容性、安全性、性能等——基本被忽视。这些方面虽然不会直接生成可见功能，但却是影响交付的重要因素。Sonar的分析中提到，“生成代码的速度早已超出了组织验证的能力”。PhotoCraft所需的2300到4100个小时，实际上就是进行验证和补充的时间。在这两周的开发过程中，创造出了539,000行的Rust代码，进行了277次Claude署名的提交，项目中积累了1,306个文件，并在一周内在GitHub上获得了6,691个星标。一个由四人团队利用AI辅助策划出的七款应用基础架构，全部遵循开源协议。问题并不在于“AI不能写代码”，相反，它确实生成了大量结构上相似的代码。路线图中提到，PhotoCraft将PSD读写、图像合成、滤镜运算和界面划分为多个Rust模块，形成了一套真正的软件结构。然而，问题出现在“结构正确”之后。一个功能要从“模块存在和函数可调用”，到“在用户实际文件上稳定运行”，中间有许多需要解决的边界条件、格式兼容、性能调优和异常恢复等。这些问题并不直接通过代码行数体现，而是体现在22个未达标的性能指标、579个开放问题和“PSD文件未能被Photoshop接受”的现状中。尽管14天内能够搭建出框架，但这个框架并不等同于实际的房屋。