用 Opus 5.5 重写整个 Adobe 七件套？ArtCraft 暴露的 AI 编程新剧本

2026 年 10 月初，一个叫 ArtCraft 的项目被推上 GitHub 周增长榜的前列，社区里最出圈的传言是「开发者用 Claude Opus 5.5 重写了整个 Adobe 七件套」：一个人、一周、七个分别对标 Photoshop、Illustrator、Premiere、Lightroom 等产品的仓库，两天之内一口气开出来，界面与快捷键还刻意贴近 Adobe 用户的使用习惯。头条、CSDN、韩媒 digi알데 투데이 都在转发这件事。

这类标题天然自带流量，但它也天然容易失真。谣言与热度之外，真正值得追问的是：AI 编程在真实的大型项目里到底扮演什么角色？用模型生成的代码，凭什么能撑起一个"对标 Adobe"的工程，而不是一堆跑不起来的 Demo？

打开 ArtCraft 的仓库，答案比想象中清晰。这个项目不是「AI 一夜生成的玩具」，而是一个 3,200 多个 Rust 文件、约 25.7 万行 Rust 代码加 1,600 多个 TypeScript/TSX 文件的严肃工程。它的存在方式，恰好暴露了 AI 编程正在发生的变化——不是取代程序员，而是重新定义程序员的日常。

Opus 5.5 在七件套开发中的真实角色

先给结论：无论传言里那个模型叫 Opus 5.5 还是别的什么，它在 ArtCraft 里的角色都更接近"执行承包商"，而不是"架构师"。

仓库的主干是 ArtCraft 本身——一个面向艺术家、设计师和电影人的 AI 创作 IDE，官方定位是 "The IDE for artists"。根目录的 Cargo.toml 是一个 32 个成员组成的工作区：桌面应用本体之外，还有 10 个独立的 Provider 客户端 crate——artcraft、fal、gmicloud、grok_api、grok_consumer、kinovi_web、midjourney、openai_sora、worldlabs_api、worldlabs_consumer——对应 README 里罗列的 Grok、Midjourney、Sora、World Labs 等外部模型供应商，外加 cookie 存储、浏览器指纹模拟、Cloudflare 防护、JWT 解析、SQLite 任务持久化等一系列支撑库。

这套结构呈现出非常明确的工程意图：每个供应商被隔离成一个独立 crate，各自维护自己的请求模型、错误类型与测试夹具。这不是 AI 自由发挥能自然长出来的形状，而是需要从一开始就拍板的分层决策。同样的意图也体现在桌面端的 services 层——services 模块 只有五个子模块：grok、midjourney、sora、storyteller、worldlabs，每一个都是一整条与外部系统打交道的业务线。

如果 AI 真的"重写"了这些代码，那它也是在人类预先画好的模块边界里工作。模型贡献的是规模与速度——单个 Prompt 能吐出上千行结构正确的 Rust，这在两年前不可想象；但模块怎么切、依赖怎么排、接口怎么定，仍然是人拍板。新闻里"一个人一周七个仓库"的戏剧性，掩盖了另一面：这个人一周里写的可能主要是规范，而不是代码。

关于"对标 Adobe 七件套"本身，也要泼一点冷水。社区情报里，韩媒的报道用的是更准确的表述：团队开源的是编辑套件 Crafting Apps，"界面与快捷键贴近 Adobe 习惯"。而当前这个仓库的 README 显示的雄心是另一回事——把 62 个主流 AI 模型（FLUX、GPT Image、Seedream、Veo、Sora 2、Kling、Seedance、Suno、混元 3D、Marble 等）收进一个统一的模型目录，让创作者在 2D 画布、3D 舞台上编排 AI 生成。与其说它在复制 Photoshop，不如说它在做 Photoshop 时代没有的东西：把"生成"变成"可编排"。

AI 生成代码的可维护性：从 AGENTS.md 看工程约束

AI 生成代码最大的质疑从来不是"能不能跑"，而是"能不能维护"。ArtCraft 给出的答案非常具体：给 AI Agent 写一本宪法，然后让它按宪法施工。

仓库里一共有 9 个 AGENTS.md 和 7 个 CLAUDE.md，从根目录一路铺到最细的模块：根 AGENTS.md、crates 级、artcraft_api_defs、artcraft_client、router 的 generate_video 子模块、desktop 的 storyteller commands、schema 的 enums 与 tokens、前端 pagescene 3D 编辑器……每一层都在约束 AI Agent 的行为。

看几个具体的条款，就知道这不是走过场：

命令粒度的强制拆分。 Tauri 命令规范 明文规定：每个 #[tauri::command] 必须放在以命令命名的独立 .rs 文件里，禁止把多个命令塞进一个 *_commands.rs 大文件。于是桌面端出现了一长串单文件命令——storyteller_create_login_challenge_command.rs、storyteller_get_credits_command.rs、storyteller_password_login_command.rs——每个文件就是一条 IPC 边界，改了名字或参数就算破坏契约。这直接消灭了 AI 最爱犯的"把所有逻辑堆进一个文件"的毛病。

安全边界被写死。 同份规范还规定：认证相关的 HTTP 请求必须在 Rust 层通过 artcraft_client 的端点绑定完成，前端只能调用 Tauri 命令，绝不能直连后端数据库。这意味着即便前端被攻破，签名会话 Cookie 也永远不会跨过 IPC 边界——CSDN 上一篇文章专门拆解过这个设计。安全不是靠"这次代码恰好写对了"，而是靠规范让"写错"成为不可能。

对已知雷区的显式标记。 pagescene 工程规范 开头就用警告框标注了一个 footgun：3D 编辑器的挂载依赖三个 DOM 节点，任何一个被条件卸载都会导致整个编辑器重建、未保存场景被清空，因此禁止用条件渲染卸载这些画布，只能用 CSS 隐藏。它还规定视图层必须走"Three.js 引擎 → 类型化事件总线 → Zustand store → React"的单向数据流，并注明"do not violate it"。这类文档是把一次线上事故的教训，固化成 AI 和人类都绕不开的规则。

编译器层面的强制。 根 AGENTS.md 规定 SQLite 访问优先使用 sqlx::query! / sqlx::query_as! 编译期检查宏，而不是运行时 sqlx::query()；禁止在生产代码里用 println!，一律走 log crate。前者让 SQL 错误在编译期暴露，后者让日志系统可观测。这些不是风格偏好，是把"代码质量"变成"编译器能帮你检查的东西"。

迁移的版本红线。 任务表迁移脚本 的文件头注释写着：任何改动（哪怕只是改注释）都必须升版本号，否则 Windows 启动时会段错误——"This is horrible!"。旁边是一段完整的迁移历史（tasks_v1 到 tasks_v7，每版加了什么字段都记录在案）。AI 能生成这样的文件，但它不会自己记住"改注释也要升版本"这种用崩溃换来的教训——那是人写进规范里的。

这套"规范驱动生成"的模式，解释了一个关键事实：为什么 AI 生成的海量代码没有变成烂摊子。因为 AGENTS.md 不是给人类看的 README，而是给 Agent 的 prompt。它是把工程经验显式化、可执行化的产物：人类把踩过的坑、定过的边界、守过的规矩写下来，AI 每次开工前先读一遍，然后产出的代码与人类代码共享同一套质量基线。

对『AI 取代程序员』叙事的再思考

ArtCraft 最值得玩味的，是它的 ROADMAP.md 里那句写在最底部的 Loftier Goal："Build an Open OpenAI / Google / Anthropic. Open models, open platforms, open hardware."——做一个开放的 OpenAI。这跟"AI 取代程序员"是两种完全不同的叙事：前者假设程序员依然存在，而且会继续定义这个行业的天花板。

从仓库里还能看到程序员工作的另一个证据：持续的测量与权衡。性能实验文档 记录了 2026 年 9 月 26 日的一次前端优化：15 个页面改用 React.lazy 懒加载后，启动到首帧从 566.4ms 降到 350.6ms（-38.1%），启动期 JavaScript 从 9.05MB 减到 6.47MB。但文档没有停留在"变快了"的结论上，而是详细交代了为什么 Drawing 页面保持 eager 加载（实验证明延后它的适配器反而更慢）、为什么 Tab 切换改成保留 Zustand 现场而不是序列化导出（省掉 8 次 FileReader 读盘）。这些是典型的工程师判断：测量、取舍、记录权衡。AI 能写出 React.lazy，但"该懒加载谁、该保留谁"的决策，来自对真实用户体验的理解。

类似的人类痕迹遍布仓库：桌面端版本号被单独定义在 version.rs（当前 0.41.0），开发环境文档 花了大量篇幅描述三端热重载工作流里端口冲突、进程退出码、SQLx 离线构建这些只有长期维护者才关心的问题。而整个工程本身的体量——32 个 crate、25.7 万行 Rust、46 个前端组件库——就是最直白的反驳：如果 AI 让程序员的边际成本趋近于零，那维护成本就是新的瓶颈，而维护恰恰是人类目前还无法外包的部分。

把这三节串起来看，ArtCraft 暴露的"AI 编程新剧本"其实是这样的：

• AI 负责规模，人负责形状。 模型把一周写七个仓库从噱头变成可能，但仓库的分层、crate 边界、安全红线，全是在生成之前定好的。
• 规范即产品。 AGENTS.md 从配角变成主角——它是写给 Agent 的接口文档，是让"AI 生成代码"与"人类工程标准"对齐的唯一机制。谁写得一手好规范，谁就掌握了 AI 时代的架构权。
• 取代的是重复，不是判断。 性能测量、迁移版本管理、雷区记录——这些文档化的判断会越来越值钱。程序员的位置没有消失，只是从"写实现"上移到了"写约束、做评审、扛维护"。

所以那个流传最广的标题——"用 Opus 5.5 重写整个 Adobe 七件套"——答案既是对也不对。模型确实可能贡献了绝大多数代码行，但把 3,200 个文件组织成一个可维护工程的那些决定，依然是人的作品。AI 编程真正的新剧本，不是"AI 取代程序员"，而是"程序员变成给 AI 写剧本的人"。ArtCraft 只是把这个剧本开源了。