近日，一位开发者利用Claude Opus 5.5，在短短不到两周的时间内，使用Rust语言重新编写了七款Adobe软件的核心功能。在Reddit上，他以“100%开源、clean-room实现”为标题，宣称一个月内实现功能对等，引发了广泛关注。
然而，当这位开发者将项目发布到Hacker News时，态度却截然不同。他坦言：“我还没准备好把它发到HN。它离可用还差得很远。” 这种坦诚的态度，反而赢得了更多技术社区成员的尊重。
据开发者透露，目前项目的功能广度达到了76%，但真实工作可用度仅为45%。 根据他仓库中的路线图，要实现完全对齐，还需要投入2300到4100个Opus 5.5 agent wall-clock小时，即一个智能体连续工作的小时数。
76%的功能广度是如何得出的？628个菜单齐全，但“有”不等于“能用”
PhotoCraft的功能广度并非泛泛而谈。路线图详细列出了各项指标：628个菜单全部实现，68个工具中完成了56个，35个面板中实现了30个，31种格式中支持了17种。
从表面上看，AI确实大幅降低了搭建界面的成本。然而，实际使用中却暴露出诸多问题。例如，有用户反馈吸管工具在按住Alt键切换行为时失效；文本选择和快捷键也存在多处不匹配的情况。这些问题并非功能缺失，而是实现不够完善。
功能广度衡量的是“是否存在”，而可用度则关注“能否在实际工作中依赖”。 这两者之间的差距，正是需要投入大量时间进行优化的部分。
45%的可用度，在实际使用中意味着什么？
根据路线图，不同用户群体的可用度存在差异：主流从业者可用度为43%，仅使用核心功能的用户可达61%，整体平均为45%。
这意味着，对于每天依赖Photoshop进行专业工作的用户来说，超过一半的常规操作可能会遇到障碍或需要绕行。而对于仅进行简单裁剪、调色和导出的用户，体验会相对较好，但仍不足以完全替代Adobe软件。
PSD文件的读写能力是衡量Adobe替代品的重要标准。路线图明确指出：“我们写出的PSD文件尚未被Photoshop可靠接受”，并列举了相关问题编号。用户实测发现，在PhotoCraft中保存的项目默认变为JPG格式，缺乏分层PSD选项。另一项测试中，437个第三方PSD文件加载时频繁出错。
对于Adobe替代品而言，PSD兼容性不是加分项，而是入场券。 如果无法打开客户发送的分层文件，或保存的文件无法被对方打开，该工具就无法融入实际工作流程。目前，项目积压的579个开放问题中，大部分集中在“能用但不可靠”的功能上。
性能方面的问题更为直观：在25个性能指标中，仅3个达标，22个超标。例如，处理150层文档时会导致GPU崩溃。此外，AI和生成功能的准备度仅为10%，排版功能为40%，插件生态为15%。
并非个例：53%的AI代码“看似正确但不可靠”
PhotoCraft的45%可用度并非孤立现象，而是与行业数据高度吻合。
根据徽声在线2026年的开发者调查，88%的开发者认为AI生成代码带来了负面影响，53%明确表示AI代码“看似正确但不可靠”，96%的开发者不完全信任AI生成代码的功能正确性。这与PhotoCraft用户遇到的问题如出一辙：菜单和按钮存在，逻辑能够运行，但Alt键失效、PSD文件损坏、高负载时崩溃。
Veracode同年的安全报告提供了另一个视角：AI生成代码在安全测试中的失败率约为44%至45%，且这一通过率在过去一年几乎没有改善。两个45%的数据共同指向一个问题：AI降低了“从0到1”的开发成本，但忽略了“防御性工作”——错误处理、边界条件、兼容性、安全性和性能优化。这些工作不直接产生可见功能，却是决定产品能否交付的关键。
徽声在线的分析指出，代码生成速度已远超组织验证能力。PhotoCraft所需的2300至4100小时，本质上就是用于验证和补全这些“隐形工作”的时间。
14天内发生了什么？53.9万行Rust代码，277次Claude署名提交
从项目规模来看，AI的生产力是实实在在的。
PhotoCraft在14天内积累了53.9万行Rust代码和1306个文件，提交历史中有277次以Claude署名的提交。一周内，该项目在GitHub上获得了6691个星标。一个4人团队借助AI辅助，完成了七款应用的核心框架开发，并全部采用MIT/Apache开源协议。
问题不在于AI能否编写代码，而在于代码的质量。 AI生成了大量结构上看似合理的代码。路线图显示，PhotoCraft将PSD读写、图像合成、滤镜运算和界面拆分为独立的Rust模块，形成了完整的软件架构。
然而，“结构正确”并不等同于“功能可用”。一个功能从“模块存在、函数可调用”到“在用户真实文件上稳定运行”，中间需要处理边界条件、格式兼容、性能调优和异常恢复等问题。这些问题不体现在代码行数中，却反映在22个未达标的性能指标、579个开放问题和“PSD不被Photoshop接受”的现象中。
14天可以搭建框架，但框架不等于成品。 2300至4100小时的工作，相当于为框架布线、通水、做防水和通过验收。
对Claude Code开发者的启示：路线图比代码更有价值
对于正在使用Claude Code或类似工具开发产品的团队来说，PhotoCraft的路线图比其代码更具参考意义。它详细列出了“从Demo到生产需要补全的内容”：
PSD兼容性对应“输出格式能否被目标生态接受”；22/25性能指标未达标对应“功能虽能运行，但速度、内存或稳定性不达标”；579个开放问题对应“用户在真实场景中遇到了未预料的问题”；AI功能10%准备度对应“宣传中最亮眼的功能往往完成度最低”。
值得注意的是，同一项目在Reddit上宣称“一个月100%对等”，在Hacker News上承认“远未准备好”，而仓库中的路线图则明确标注了45%的可用度和2300小时的工作量。最真实的数据往往不在宣传文案中，而在仓库的路线图文件和问题列表中。
2300至4100个agent小时，按每天8小时计算，相当于9至17个月。这并非AI能力不足，而是AI将开发成本从“编写代码”转移到了“验证和补全”。代码行数变便宜了，但能交付的软件并未因此增多。
这位开发者在Hacker News上的坦诚，比任何批评都更有力量。他的路线图证明，他清楚45%与100%之间的差距所在。承认不足，比假装完美，更接近交付的目标。
