storytold/craft-anything：8,302 stars 的纯 Rust 逆向引擎，看懂一个软件然后让 AI 重写一个

发表于 2026-11-04 分类于开源项目

storytold/craft-anything 是 ArtCraft 团队 2026 年 10 月 31 日开源的纯 Rust 逆向工程引擎，8,302 stars、1,394 forks、双许可 MIT OR Apache-2.0。它把「看懂一个网站或游戏，再让 AI 写一个自己的」做成流水线：Study 量清原物、Build 交给编码 Agent 造新项目、Check 在三种屏幕宽度逐页比对、Ready 交付。引擎自带 320 个工具，覆盖原生代码、.NET、Java、Android、Electron、网站、固件、数据库和游戏文件，自带反汇编器与反编译器。每个工具同时是 CLI 子命令和 MCP tool。默认 Clean room 模式由引擎层白名单强制不读原物代码与页面源码，只用访客可见的截图、文本、量出的布局与配色；Deep 模式才解锁全部工具并可接入 Ghidra。

上周我想抄一个网页。

不是什么正当需求，就是看到一个设计挺漂亮的落地页，想知道它那个留白和字体层级到底怎么排的。我打开 DevTools 划了半天，量出来一堆 margin 和 font-size，然后发现我花了四十分钟在看一个本该用十分钟看完的东西。

那天晚上我刷 GitHub，撞见一个叫 Craft Anything 的东西，简介只有一句话：

Craft Anything: understand how any software works, and craft your own.

我当时的反应是” 又一个套壳 AI 工具吧”。然后我点进去看了一眼它的架构，直接坐直了。

因为它不是” 让 AI 帮你写代码”，它是先把一个东西拆开、量清楚、记成证据，再让 AI 拿着这份证据去写。中间那个” 拆开、量清楚、记成证据” 的环节，是它自己用纯 Rust 写的 320 个工具干出来的，不是调用 Ghidra、不是调用 IDA、更不是让 LLM 靠截图猜。

行，今天就聊聊这个。

一、它到底想解决什么

先说清楚问题。这问题有两层。

第一层：AI 看不见” 结构”

现在让 AI 重做一个网站，你把网址丢给它，它会怎么做？截图 → 看 → 猜 → 写。

猜什么？猜这个导航栏是 flex 还是 grid，猜间距是 16 还是 24，猜这个圆角是 8px 还是 10px，猜这个阴影是哪一层 box-shadow。猜出来的东西看着像，但量一下全不对。这就是为什么 AI 生成的页面总是” 有点野”—— 不是审美问题，是它根本没有数字。

Craft Anything 的解法是：先让一个真正的检查工具去把数字量出来，量成结构化的事实，然后把这些事实当作输入喂给编码 Agent。

量出来的东西包括（这是 docs/STATUS.md 里对 web_site_capture 的描述）：

每个宽度下的截图（desktop /tablet/phone 三档）
渲染后的 HTML
设计令牌：颜色（十六进制）、间距、内容宽度
CSS 断点
每个宽度下的布局：页面宽度、标题字号、每一段的 padding、gap、内容列宽、每行几个 item
页面健康度：脚本错误、控制台错误、失败的请求
可访问性大纲、布局大纲
资源：字体文件、请求列表
链接和表单的大纲

这份清单里的东西，不是截图能告诉你的，也不是 LLM 能” 合理推测” 出来的。

第二层：逆向工程一直是个” 手动苦力活”

再往下一层。这类活儿 ——“搞明白这个程序怎么做的”—— 本身是逆向工程的经典场景。

现有工具（Ghidra、radare2、IDA）做得都很好，但它们是给专家用的交互式工具：你手动 load、导航、看汇编、追调用、重命名、写注释。每个动作都是一次点击和一次思考。一个程序几千个函数，你不可能全手动过一遍。

Craft Anything 想做的是把这些能力打包成可调用的工具，让 Agent 能像调用 API 一样用它们：

1
2
3

craft-anything-cli commands                                   # every tool, by toolset
craft-anything-cli mcp                                        # serve them to any MCP client
craft-anything-cli rebuild https://example.com "Recreate this website"

注意这三个命令的层次：列工具、以 MCP 方式暴露、跑一次完整重建。同一套东西，三种入口。

所以它其实是两件事的合体：一个好用的逆向引擎（给人用），和一个把引擎接到 Agent 上的调度层（给 Agent 用）。

二、它是什么

一句话定义：一个纯 Rust 的逆向工程引擎 + 桌面应用，用来研究任意软件并让编码 Agent 基于研究结果重建一个自己的版本。

关键数字（截至 2026-11-04 我去查的时候）：

项	值
Stars	8,302
Forks	1,394
Open Issues	158
主语言	Rust（约 895 万字节）
许可	MIT OR Apache-2.0（双许可，任选）
建仓时间	2026-10-31 14:50 UTC
最新 release	v0.3.0（2026-11-02）
引擎工具数	300（加上 AI 和 setup 层共 320）
Toolset 数	17
状态	early alpha

代码规模的分布也值得说一句。/languages 接口给出的字节数：

Rust:       8,955,526
Shell:         52,599
PowerShell:    24,473
Java:          15,682
Python:        7,697
Swift:         4,333
HTML:          1,089
Handlebars:      934

Rust 占绝对主导，其他语言基本是构建脚本和少量辅助。Rust 仓库的头部目录是这么分的：

crates/
  ai/          # 与模型对话、rebuild 调度
  analysis/    # 分析层
  disasm/      # 反汇编
  engine/      # 引擎核心，工具分发
  engines/     # 各具体引擎（native / managed / java / ...）
  evidence/    # 证据账本
  formats/     # 文件格式解析
  js/          # JavaScript 分析
  mcp/         # MCP server
  platform/    # 平台抽象
  setup/       # 安装与设置
  testkit/
  ui-egui/     # egui 桌面界面
apps/
  craft-anything/       # 桌面应用
  craft-anything-cli/   # CLI
  craft-anything-web/   # WebAssembly 版

evidence 单独成一个 crate，这在下面会讲为什么重要。

它还有个特点：这是个商业产品团队做的开源项目。母体叫 ArtCraft，官网 getartcraft.com，README 里挂了一长串同门产品 ——PhotoCraft、VectorCraft、FilmCraft、LightCraft、PdfCraft、EffectCraft、DesignCraft、FigCraft、WordCraft、SoundCraft、DeckCraft、CadCraft、GridCraft、TextureCraft……Craft Anything 是这堆里的一个，但它的 logo 是” 蓝底上刻着一只乌鸦”。

所以它不是一个孤立的玩具，是一个产品矩阵里的一格。这既有好处（工程规范、发布流程、文档密度都很高），也有代价（有些设计明显是为了产品化而不是为了社区）。

顺带说一句：这仓库的 README 有简体中文版（README.zh.md，23,030 字节），还有日文、韩文。而且界面本身支持简体中文、繁体中文、德语。文档密度相当高 ——docs/ 下有 STATUS.md、ROADMAP.md、tools.md、tool-status.md、pitfalls.md、extending.md、claude-code.md、codex.md、copilot.md、opencode.md、localization.md、file-formats.md 等等。

一个刚建仓四天的项目能写出这种文档，说明团队是认真在做事，不是刷 star 的。

三、核心机制：四步流水线

整个东西的骨架就是四步。README 里叫 Study → Build → Check → Ready（中间还有一步 Refine，我下面单独讲）。

1. Study：研究原物

这一步是整个项目的地基。它要回答的问题是：“这个东西到底是怎么做的？”

不同类型的目标，研究方式不一样：

网站：用 web_site_open 开一个私有浏览器保持会话，然后 web_site_capture 记录三种宽度下的截图、渲染 HTML、设计令牌、CSS 断点、布局、页面健康度、可访问性大纲、资源、链接表单大纲。而且 ——Study 阶段最多还会额外捕获这个站点另外 4 个页面，菜单会在电脑和手机两种形态下被打开。

原生程序：用内置引擎读代码和文件，native_function_pseudocode 出伪 C，native_functions_list 列函数，native_xrefs_list 找交叉引用。

游戏：core_target_triage 直接告诉你它是什么做的 —— 引擎和版本、代码怎么分发、Unity 程序集名暴露了哪些库、它自己的代码、场景和体积。引擎检测覆盖 12 种：Unreal、Unity、Godot、Source、GameMaker、RPG Maker、Ren’Py、MonoGame、LÖVE、CryEngine、Cocos、Cube。

数据库：db_sqlite_show 能读 SQLite，包括 WITHOUT ROWID 表（从 index b-tree 读，含 interior records 和 overflow）。

2. Build：让编码 Agent 造一个新的

这一步是” 让 AI 写”。但注意它不是 “让 AI 随便写”。

关键点在技术栈的选择逻辑，docs/STATUS.md 写得很清楚：

The request decides how to build: a language, framework, engine or platform it names wins over the kind’s default stack (Rust + egui for apps, Unity for games, the original’s for websites)

也就是你在需求里说的技术栈优先。你说” 用 Rust 重写这个贪吃蛇”，它就用 Rust；你说” 用 Next.js + Tailwind + shadcn/ui”，它就用这个。需求里没提，才走默认：网站用原站的栈，App 默认 Rust + egui，游戏默认 Unity。

而且 ——“stack or library named in the request（Next.js、shadcn/ui、Tailwind CSS…，见 stacks.toml）就是 builder 要用的；没指定的话，网站的栈由 builder 自己选（但会被告知要匹配原站是用什么做的），并且用了什么栈会从 app/package.json 里记录下来。”

这个设计我觉得是整篇里最聪明的地方之一，后面第六节展开。

3. Check：跟原物比对

这一步是它跟” 套壳 AI 工具” 的分水岭。

网站的比对方式（docs/STATUS.md 的原文细节）：

把 build 在 loopback 上跑起来
在 1440、768、390 三个宽度下逐页比对
相似度定义：likeness = 布局和感知细节（SSIM）的均值，再对所有页面取平均
而且它很讲究：把原站自己会变动的部分排除掉 —— 办法是给原站拍三次照，找出哪些区域每次都不一样，把这些区域从评分里剔掉

这个” 拍三次排除动态区域” 的做法，我一开始以为是吹的，看到它写进文档后我专门去找了对应的实现位置。这个思路是对的 —— 很多做视觉回归的团队都会栽在” 页面上的轮播图让 CI 天天飘红” 上。

比对结果不是一句” 像不像 87%” 就完事，它会列出具体差在哪：

缺失的文本
页面结构的差异
缺失的颜色
缺失的字体
缺失的文字尺寸
缺失的间距
每个宽度下是否横向滚动
标题字号差异
哪些区块的 padding、每行 item 数、内容列宽不同
build 新增的错误、失败的请求
build 新增的可访问性缺口
打开的菜单和弹窗的表现

这才是有用的输出。不是” 相似度 0.87”，而是” 你的 .container 在 768px 下应该收成单列但现在是两列”。

游戏的比对更狠：每个游戏有自己的自测（--self-test），要显示玩家在移动、在操作、HUD 画出来了，才算过关。

Deep 模式的表格：原代码里每一个数字都要对上。

控制台程序：退出码和输出要和原物一致。

4. Ready：交付

能打开、能玩、能预览。然后你可以在下面的输入框里说” 把头部改成蓝色”，它会继续 refinement。

关于 refinement 的上限，docs/STATUS.md 给了确切数字：

Up to 6 refinement rounds, or until a website reaches 90% likeness.

最多 6 轮 refinement，或者到网站达到 90% 相似度为止。

90% 这个数字我得说两句。SSIM 在 0.9 是个挺高的门槛，但对于” 逐像素对齐的重建” 来说，能到 90% 已经相当能用了。反过来说，把 90% 当作终止条件而不是目标，也说明作者知道无限打磨是不现实的。

四、Clean room 与 Deep：两种模式，这是它的灵魂

这个设计我认为是整个项目最值得学的地方。

Clean room（默认）

nothing inside the original is read, not its code, files or page source. Craft Anything works from what you can see: pictures you add, the website as a visitor sees it (screenshots, visible text, measured layout, colours, fonts and spacing, menus opened) and, when you allow it, a picture of the app’s window. Tools that would look inside are refused and say how to turn on Deep mode.

翻译成人话：默认情况下，一个字节的原物内部都不读。不读代码，不读文件，不读页面源码。只用” 访客能看见的东西”—— 你提供的图片、网站访客看到的（截图、可见文本、量出来的布局、颜色、字体、间距、打开的菜单）、以及你允许时给的一张应用窗口截图。

而且这个约束是在引擎层实现的，不是提示词里的君子协定。docs/STATUS.md 说得很明确：

Clean room (the default) runs only the tools in engine/src/clean_room.rs: ones that touch no target or watch from outside… Every other tool, a plugin’s included, is refused in the app, CLI, MCP and agents, with a way to turn on Deep mode.

也就是说：Clean room 是一个代码级的白名单机制。在 App、CLI、MCP、Agent 四个入口，任何不在白名单里的工具 —— 包括第三方插件带的 —— 都会被拒绝，并提示你” 要开 Deep 模式”。

这是个很硬的保证。有插件也绕不过去。

Deep

every tool is used, for your private use. A program’s code and files are read with the built-in engines (and Ghidra when it’s installed), a website’s JavaScript is read and its start page watched, and the builder may use all of them.

Deep 模式：所有工具都开放，读代码、读文件、读 JavaScript、watch 启动页十秒，还可以接入 Ghidra。

README 里对 Deep 模式下的 builder 还有一条很细的规则：

The builder must decompile before the build is checked; addresses the built-in analysis can’t place go to Ghidra, which makes a function on demand (for this run only) where its analysis has none, e.g. code reached only through tables of pointers.

翻译：内建分析定位不到的函数（典型是只通过指针表可达的代码），临时交给 Ghidra 反编译。这个 fallback 做得挺细的。

切换方式

# 标题栏或 Settings 里切
settings_set deep_mode true

# 或者单次 CLI 运行
craft-anything-cli rebuild https://example.com "Recreate this website" --deep
craft-anything-cli rebuild https://example.com "Recreate this website" --clean-room

单次运行的 --deep / --clean-room 不会被保存。

为什么这个设计值钱

我拿它跟另一个思路对比一下就明白差别了。

思路 A（多数 AI 工具）：给 Agent 一句” 你参考这个网站做个差不多的”，靠提示词约束它不要抄。

思路 B（Craft Anything）：给 Agent 一个物理上碰不到原物内部的工具集。

区别在哪？A 靠模型的自律，B 靠系统的边界。

模型有上下文窗口限制、指令遵循度问题，也可能被注入的网页内容带着跑。B 不用赌这些 —— 工具层直接把读取原物内部的能力摘掉了。

而且它把合法性也一并想清楚了。README 有一节叫 Responsible use：

Use Craft Anything on software you own or are allowed to examine. It never bypasses DRM, logins or anti-cheat. Rebuilds recreate layout, style and behaviour from evidence; the agent is told not to copy logos, photos or text unless you confirm you own them or have permission.

不绕 DRM、不绕登录、不绕反作弊。重建的是布局、风格和行为 —— 这三个是” 怎么做” 的表达，不受版权保护的” 内容” 是另一回事。Logo、图片、文字要你确认拥有才用。

这个边界划得我觉得相当专业。国内很多工具在这块是含糊的。

五、证据账本：让” 我以为” 和” 我查到了” 分开

前面说了 evidence 是个独立 crate。这不是随便分的。

README 里提到结果的形式：

Results are evidence records with their confidence, coverage and limitations; big ones come back as a summary first and are paged with core_evidence_browse.

每个结果都是一条证据记录，带三样东西：confidence（置信度）、coverage（覆盖率）、limitations（局限）。

这三条加在一起解决的是 AI 工具的一个老大难：幻觉。

AI 最容易犯的错不是” 不会写代码”，而是” 我以为这个函数是干 X 的”—— 然后基于这个想象往下写，错的越多偏的越远。

Craft Anything 的做法是：任何关于原物的断言，都必须挂一个可查的证据，而且证据自己会说明” 我能确定多少”” 我覆盖了多大范围”” 我有什么做不到”。

围绕这个还有一整套工具：

core_evidence_show / core_evidence_export / core_evidence_import
core_evidence_browse —— 大结果先给摘要，再分页翻（还支持在已存结果上按字段筛选，不用重跑）
core_unknowns_show / core_unknown_add / core_unknown_edit / core_unknown_verify —— 显式记录” 我查不到的东西”
core_hypothesis_record / core_hypothesis_update —— 假设是单独的一等公民
core_finding_record / core_finding_edit —— 发现
core_investigation_show —— 调查进展
core_person_ask —— 问人
core_action_approve —— 批准动作

其中 core_unknown_add 我觉得是精髓。AI 干活最怕的不是不会，而是不知道的当成知道的。它有一个专门的一等类型用来装” 我不知道”，builder 遇到查不到的东西会记成 unknown，run 结束会把还开着的 unknown 报出来。

配套的还有 core_brief_write（写任务书）、core_plan_update（更新计划）、core_handoff_write（写交接）、core_journal_read（读日志）、core_report_save / core_report_write（报告）。

这套东西合起来，其实是在给 Agent 建了一个可审计的认知状态机：目标、证据、假设、未知、发现、计划、日志。

六、为 Agent 而生：三种接法

方式一：本地编码 Agent（首选）

README 说：

Claude Code is supported first: Craft Anything runs your own, unmodified claude program, which uses your own sign-in; Craft Anything never sees or handles your account.

注意这三个短语：your own（你自己的）、unmodified（不改一个字节）、never sees or handles your account（它永远不碰你的账号）。

它的做法是运行你自己装的 claude，走 headless 模式，用你自己的登录态。Craft Anything 只是拉起这个进程、给它接上自己的 MCP server。你的 API key 和订阅不经过它。

配置上它做得细：

每个 Claude Code 可以有自己独立的 CLAUDE_CONFIG_DIR，所以可以挂多个账号
Opus 5.5、high effort（可配）
预检（preflight）：CLI 缺失或起不来，构建会干脆地停下来报错，而不是跑到一半失败
断线恢复：被时间限制、崩溃或连接中断打断的一轮，会自动恢复最多 3 次
builder 单轮可以跑 24 小时
Claude Code 的会话文件 agent-session.jsonl 每轮后保存一份，换台电脑能接着聊

最后这条我觉得很值得单独说。docs/STATUS.md 里：

A project copied from another computer (or moved to another folder) keeps building with Claude Code: the project keeps a copy of the builder’s session (agent-session.jsonl) after every turn and puts it back where Claude Code finds it on a computer without it, so the same conversation carries on (#451); when the session still isn’t there, a new one starts from the brief, what’s in app/ and the kept requests and replies (or the last summary)…

也就是：项目自带 builder 的会话副本。你把项目目录拷到另一台电脑上，它能把会话放回 Claude Code 找得到的位置，对话接着往下走。找不到的话，就从任务书、app/ 里已有的东西和保存的请求 / 回复（或者最后一份摘要）重新起一个。

这解决的是 AI 编码工具一个非常真实的痛点：上下文丢失。你换个终端、换个机器、Claude Code 崩了，之前那一大段调研对话就没了。这个” 会话随项目走” 的做法，比” 每次重新解释一遍需求” 务实太多。

方式二：ACP Agent

支持 Gemini CLI、Qwen Code、opencode、goose、Hermes、Maki，走 ACP 协议。

但 README 说得很诚实：

A Codex adapter exists but hasn’t been verified on a real install yet. GitHub Copilot can use your installed Copilot CLI through ACP: sign in separately with copilot login. Other agents that speak ACP (Gemini CLI, Qwen Code, opencode, goose, Hermes, Maki) can be switched to it per backend; of those, only Maki has been run live.

翻译：Codex 适配器有，但没在真实安装上验证过；ACP 这一堆里，只有 Maki 实测跑过（2026-11-02，Linux，headless CLI，静态页面 38 秒建到 Ready）。

这种” 哪些真的跑过、哪些只是编译过了” 的区分，在 README 和 STATUS 里到处都有。我一会儿在第八节展开。

方式三：纯 API 调用

不跑本地 Agent，直接调 API：

Anthropic, OpenAI, OpenRouter and local OpenAI-compatible servers are available for questions and analysis (Settings → AI).

也就是本地模型（Ollama 之类 OpenAI 兼容的）可以用于提问和分析。但注意措辞：这些是”for questions and analysis”，不是用来 build 的。Build 这一环需要一个能写代码、能调工具的 coding agent。

上下文预算也做了控制：context_tokens 在 [[ai.backends]] 里配置，控制 API 对话何时被裁剪和摘要化。

方式四：直接当 MCP 用

1	craft-anything-cli mcp # serve them to any MCP client

这个对已经在用 Claude Desktop、Cursor、或者自己写的 Agent 的朋友最有用 —— 你不用装桌面应用，就能拿到这 320 个工具。

我在这条路上最关心的一点是 README 里这句：

No AI is needed to inspect.

研究原物这件事本身不需要 AI。 工具是工具，AI 是 AI，两者解耦。这意味着你可以纯用 CLI + 脚本做逆向分析，完全不碰 LLM。

七、快速上手

环境要求

Requires Rust 1.97 or newer (a dependency needs it; rustup update).

Rust 1.97 起。这个版本号比一般项目新不少，说明它用了比较新的 Rust 特性。

Debian / Ubuntu 上桌面应用还需要系统库：

1	sudo apt-get install libxkbcommon-dev libwayland-dev libx11-dev libxrandr-dev libxi-dev libgl1-mesa-dev libgtk-3-dev

从源码构建

git clone https://github.com/storytold/craft-anything && cd craft-anything
cargo run --release -p craft-anything                # the desktop app
cargo install --path apps/craft-anything-cli         # the CLI, as `craft-anything-cli`
craft-anything-cli doctor                            # checks the install, coding agents and engines

doctor 是个很贴心的设计 —— 它检查安装、编码 Agent 和引擎，告诉你缺什么。README 里说构建需要一个登录了的 coding agent，doctor 会告诉你缺了什么。

命令行重建

craft-anything-cli rebuild https://example.com "Recreate this website"
craft-anything-cli rebuild - "A snake game in Rust" --rounds 1
craft-anything-cli rebuild https://example.com "Make the header blue" --continue-in "<project folder>"
craft-anything-cli rebuild - "Add a contact form" --project-folder "<your folder>" --existing edit

几个参数值得说：

- 表示目标是本地描述而不是 URL
--rounds 1 限制 refinement 轮数
--continue-in "<project folder>" 接着上次的项目继续
--project-folder 指定项目起在哪
--existing edit 声明已有文件就是要改的应用本身，builder 直接原地编辑

最后这个 --existing edit 很有意思。它对应的是” 我有个项目已经在那儿了，让它帮我改” 这个诉求 —— 但这里” 改” 依然走的是” 先研究、再比对” 的流程，不是直接让 AI 改代码。

安装 CLI

1
2
3

craft-anything-cli commands                                   # every tool, by toolset
craft-anything-cli mcp                                        # serve them to any MCP client
craft-anything-cli rebuild https://example.com "Recreate this website"

项目目录结构

这个结构我觉得设计得很好，一眼能看出” 证据” 和” 产物” 是分开的：

Documents/Craft Anything/<project>/
  craft.json            # the request, target, status and history
  capture/              # what was recorded from the target
  app/                  # the generated project
  checks/               # each comparison against the original
  investigation.cany/   # evidence
  inbox/                # open questions

六个目录，职责清晰：

capture/ 是从原物采集的原始记录
investigation.cany/ 是整理后的证据
checks/ 是每一次比对的结果
app/ 是产物
craft.json 是状态与历史
inbox/ 是待你回答的问题

.cany 这个后缀也挺好，Craft ANything 的缩写。

平台支持

平台	形式
Windows	x64 /arm64 /x86 的 MSI 安装包和 portable zip，代码签名
macOS	通用二进制 DMG，签名并公证
Linux	AppImage / Flatpak /deb/rpm /tar.gz，x86_64 与 aarch64
FreeBSD	x86_64 tar.gz
Web	WebAssembly zip，浏览器里看文件，文件不离开浏览器
RISC-V	riscv64 tar.gz（仅 tarball）

Linux 覆盖得相当全。

八、真实局限：这份 STATUS 文档值得一读

这个项目的 STATUS.md 有 323 行，全是” 什么能用、怎么验证的” 的表格。我把它的诚实之处摘几条 —— 这是我觉得判断一个项目靠不靠谱的最直接指标。

它明确标出来” 只是编译过，没实测” 的部分

功能	状态
Codex 适配器	有，没在真实安装上验证过
ACP Agent（Gemini CLI、Qwen Code、opencode、goose、Hermes）	可切换，只有 Maki 实测跑过
用 API key 构建	“built, not yet run live”
App 和游戏的行为检查（behaviour checks）	部分实现
部分引擎工具	只对着 stub 测过

它写明” 没做” 的检查

各种条目后面会跟一句” 这次修正没在真实二进制上验证”、” 没有用 javac 输出或 JVM 检查”、” 没跑过真实的前端”、” 没跑过真实 SSH 主机或付费生成”。这种话在开源项目里很少见。

我印象最深的一条：

Clean room and Deep mode: engine, AI, MCP, CLI and app tests; no live Clean room build run yet.

Clean room 模式的完整构建，从来没有真跑过。 全是单元测试和集成测试。

还有：

Live runs with Ghidra 12.1.4 on Windows (a shared analysis, and a decompile in seconds on a large program).

这个是有实测的，Ghidra 12.1.4 on Windows，共享分析，大程序几秒反编译。

它自己承认的边界

“Real binaries were not checked for this correction”（Mach-O Objective-C 指针修正）
“Real app bundles were not checked for this correction”（Apple app graphs）
“This correction was not checked on real ARM binaries or devices”（ARM32 值流）
“No real minified application was run for this correction”（esbuild 模块依赖）
“No browser-made recording or real front end yet“（stand-in backends）
“Not yet run between two real computers“（跨机器恢复 builder 会话）

最后一条我要特别提一下，因为它是我上面夸的那个功能的反面：“项目拷到另一台电脑接着聊” 这个功能，两个真机之间从来没跑过。 验证方式是” 用第二个单独的 CLAUDE_CONFIG_DIR 假冒第二台电脑”。

其它我注意到的限制

Windows 独占了某些能力。 引导安装 Ghidra 及其 Java 在 Linux 和 macOS 上也提供，但” 只在 Windows 上试过”。
游戏重建默认落到 Unity。 Unreal 和 Godot 用同引擎重建，其他引擎一律用 Unity。所以你重建一个 Source 引擎的游戏，产物是个 Unity 项目。
需要本地装 Claude Code 并登录。 这是 build 环节的硬前置。纯 API 模式只能做提问和分析。
资产生成要自己掏 fal.ai 的钱。 assets_image_generate（默认 Nano Banana Pro）、assets_model_generate（图片 → Tripo P1 低模 GLB），每个项目默认预算 5 美元（[assets] budget_usd）。开了开关没 key 会问你要 key。而且 Nano Banana Pro “还没用真 key 跑过”。
Deep 模式的资源消耗。 分析最长锁 8 小时，Java 要占机器一半内存（Settings → Engines 可设，4 到 31 GB），还有四趟慢速 pass 会被跳过。
158 个 open issue，四天建仓的项目，这个数字算是健康的。

一个我认为需要读者自己判断的点

Clean room 模式下，网站访客能看到的东西里包含” 量出来的布局、颜色、字体和间距”。这些是原站的事实数据，被提取、记录、然后用来生成一个高度相似的站。

法律上这和” 看一眼然后照着画” 有多远？我不知道，我不打算假装知道。但有一点是明确的：README 自己写了” 只用于你拥有或被允许检查的软件”，而且默认模式连原站内部的代码都不读 —— 它读的是” 任何人访问这个网站都能看到的东西”。

这个设计我认为是在努力找一个自洽的位置：不复制内容，只重建表达方式。 但如果你要商用，建议自己再过一遍法务。

九、跟同类项目比一比

对比 Ghidra

	Craft Anything	Ghidra
Stars	8,302	97,541
语言	Rust	Java
形态	引擎 + 桌面应用 + CLI + MCP	交互式 SRE 框架
自动化	320 个工具，全是 CLI/MCP 可调	有脚本能力（Java/Python），但 API 不统一
AI 集成	原生，内建 rebuild 流水线	无（需自己接）
依赖	零外部依赖（Deep 模式可选 Ghidra）	JDK

关键差异不在能力，在形态。Ghidra 是” 给你一双手和一个工作台”，Craft Anything 是” 给你一台能自动开干的机器”。

而且它俩不是纯竞品 ——Craft Anything 在 Deep 模式下会主动调 Ghidra。README 提到它在 Windows 上实测过 Ghidra 12.1.4 和 Linux 上的 12.2。

Craft Anything 的自研引擎替代的是” 轻量场景”，Ghidra 替代的是” 专业逆向”。 一个处理” 这个网页是怎么排的”” 这个游戏是什么引擎”” 这个安装包里面装了什么”，一个处理” 这个加壳程序的壳在哪一层”。

对比 radare2 /rizin

	Craft Anything	radare2	rizin
Stars	8,302	25,299	4,119
语言	Rust	C	C
交互	GUI + CLI + MCP	CLI 为主	CLI 为主
上手	图形界面友好	命令行强	命令行强

radare2 的强项是交互式的命令行逆向，命令密度极高，学习曲线也陡。Craft Anything 把同样的能力包装成 GUI + MCP，代价是灵活性不如 r2 那种” 什么都能手动敲”。

有个很实际的差别：Craft Anything 的工具是为 Agent 设计的 —— 每个工具的输出都是结构化的证据记录，带 confidence /coverage/limitations。radare2 的输出是给人看的文本。这决定了它们服务的是两类不同的使用者。

对比 Claude Code / Codex 这类编码 Agent

这是最需要说清楚的一组。

Claude Code（154,430 stars）、Codex（133,009 stars）这类工具是通用编码 Agent—— 你让它写代码，它就写代码。它们不知道” 逆向工程” 这个概念，不会自己去反汇编一个程序，不会量一个页面的 CSS 断点。

Craft Anything 不是一个替代品，是一层底座。它的 320 个工具里，大部分是编码 Agent 自己做不到的事。

有句话能概括这个关系：Craft Anything 提供” 眼睛和手”，编码 Agent 提供” 脑子和意图”。它自己也这么说：

320 tools, each one a CLI command and an MCP tool, so any agent can drive the same engine the app uses.

“any agent” —— 关键是这句话。它不是要把 Claude Code 吞掉，是要当所有 Agent 的公共底座。

对比 MCP 工具生态里的其它逆向类 Server

市面上有零星做二进制分析的 MCP server，但基本是给 Ghidra /radare2 套个 MCP 壳 —— 底层还是那些工具。

Craft Anything 的不同是引擎是自研的。README：

A pure-Rust reverse-engineering engine with 320 tools… Its own decoders, disassembler and decompiler work without any outside program.

这意味着不装 Ghidra 也有反汇编和反编译能力。代价是覆盖面肯定不如 Ghidra 广，但换来的是零依赖、启动快、跨平台一致（Windows /macOS/ Linux / FreeBSD / 甚至浏览器里）。

WebAssembly 那部分我觉得挺有意思：部分引擎跑在浏览器里，craft-anything-web 那个 zip “在浏览器里告诉你这是个什么文件，而且文件永远不离开浏览器 “。这是一个真实的隐私优势 —— 有些文件你根本不想上传到任何服务器。

对比其它”AI 复刻网站” 的服务

这两年冒出来不少” 上传网址 → AI 复刻” 的 SaaS。Craft Anything 和它们的根本区别：

它们在线、闭源、按量收费；它开源、本地、Apache-2.0。
它们给的是” 看起来像” 的页面；它给的是量过的事实 + 逐项差异清单。
它们不能处理 App 和游戏；它能。
它们的核心是 LLM 猜；它的核心是 300 个确定性工具量。

一句话对比总结

Craft Anything 用确定性工具代替模型猜测，用证据账本代替口头断言，用代码级白名单代替提示词约束。

十、适合谁，不适合谁

适合

1. 做前端还原 / 复刻的人

你有一个喜欢的设计，想搞明白它的布局。这个工具给你的不是” 我看了它大概是这样”，而是” 它的容器宽度是 1140px，间距是 24px，断点在 768 和 1024，标题用了 X 字体”。

2. 做逆向工程但不想手动点 Ghidra 的人

你有几百个函数要看，或者一个 Electron 应用想搞清楚它的 JS 逻辑。让 Agent 跑一轮，比自己点两小时快。

3. 想给自家 Agent 加” 眼睛” 的开发者

这是我觉得最实在的用途。你有一个 Agent，需要它能分析二进制、分析 APK、读 SQLite、拆 Unity 包、量网页布局 —— 自己接 20 个不同的工具太痛，它一个 mcp 命令全给你。

4. 游戏开发者 / 技术美术

引擎检测、pak 文件解包（Unreal pak、Unity .assets、Unity bundle 存成 PNG）、贴图格式支持（DXT1、DXT5、BC4–BC7 未压缩）。这些是很实打实的逆向工作。

5. 对”Clean room 怎么真正落地” 感兴趣的人

不管你用不用它，这个 engine/src/clean_room.rs 的白名单机制本身就是个好设计样本。

不适合

1. 想三分钟出结果的人

它要跑 Claude Code、要做完整的研究 — 构建 — 比对 — 精修循环。一个复杂网站可能跑很久，builder 单轮上限 24 小时。别指望” 点一下就出成品”。

2. 不愿意装 Rust 工具链、也不打算用预编译包的人

README 给的路径是从源码 cargo run --release。虽然有 Release 页的各平台预编译包（Windows 安装包还带代码签名，macOS 有签名公证），但要自己编译的话，Rust 1.97+ 和一堆系统库是硬要求。

3. 生产环境的关键路径依赖

这是 early alpha，README 自己写着 “Status: early alpha”。README 徽章里也标着 status-early alpha。项目管理器里 CLI 和桌面应用会记录每次构建的耗时、AI 成本和 token（存在项目的 usage.json 里）—— 但” 注意：一个 AI 编码 Agent 的成本数字是按 API 价格估算的，不是账单”。

4. 需要完整逆向能力的专业逆向工程师

自研引擎覆盖的是广度上的常见场景，专业逆向要的深度（复杂混淆、定制壳、深度符号恢复）还是 Ghidra/IDA 更靠谱。而且 Deep 模式它自己也要借力 Ghidra。

5. 期待它对所有 Agent 后端都开箱即用的人

只有 Claude Code 是被完整支持并实测过的。Codex “没验证过”，ACP 里只有 Maki 跑过。

6. 不接受” 可能不准确的还原” 的人

90% 相似度上限、6 轮 refinement、部分检查是部分实现 —— 它追求的是” 很像”，不是” 像素级一致”。而且它还原的是布局、风格、行为，不是内容。

十一、我的观察和几个小问题

写到这里，我想说几个自己的判断，不算结论，算观察。

它最聪明的地方：把” 测量” 和” 生成” 分开

市面上的 AI 工具基本都在做同一件事：让 LLM 同时扮演观察者和作者。这在简单的场景里没问题，一旦复杂了，观察就开始靠猜。

Craft Anything 的做法是把观察下沉到一个确定性引擎里，LLM 只负责在拿到事实之后做决策和写代码。这让” 幻觉” 从一个系统性问题降级成了一个局部问题。

我甚至觉得这个思路可以推广到别的领域 —— 凡是” 需要先量清楚再动手” 的场景，都适合这么拆。

它的第二聪明处：技术栈由需求决定，而不是由默认值决定

前面提到的那个规则 —— 需求里点名的技术栈永远赢过 kind 的默认栈 —— 听着像个小细节，其实很关键。

因为这解决了 AI 复刻类工具一个老问题：它给你复刻出一个” 技术栈是它自己选的” 东西，你还得再手工重写一遍。而这里，你要 Next.js 它就 Next.js，要 Rust 就 Rust。

而且它还记录” 实际用了什么栈”（从 app/package.json 读），这个信息后面很有用 —— 你至少知道产物是什么。

它的第三聪明处：证据的” 边界” 是一等公民

confidence /coverage/limitations 三件套，加上独立的 unknowns 类型，加上 core_evidence_browse 的分页与筛选 —— 这不是” 我记录一下结果”，这是在给模型造一个可审计的认知工作台。

我印象最深的是那个 core_unknown_add。一般的 Agent 工具没有” 我不知道” 这个概念，因为不知道的东西不会进 prompt，模型就直接编一个。Craft Anything 强迫它把不知道的记下来，而且 run 结束会把还开着的 unknown 报给你。

这大概是我从这个项目里能偷走的最大一个设计。

我担心的地方

一、生态的可持续性。 这是一个商业产品团队的开源项目，star 涨得快，issue 也有 158 个。如果商业化优先级和社区需求冲突，社区能拿到的东西会变少。目前看起来文档和 issue 都在认真做，希望保持。

二、对 Claude Code 的强依赖。 build 环节只有 Claude Code 被完整支持并实测过。虽然 MCP 和 CLI 的开放性很好，但” 核心流程绑在一个特定的 coding agent 上” 这个风险是真实的。Codex 适配器” 没验证过” 这句话，希望早点能划掉。

三、Clean room 从没真跑过。 这是我最在意的一条。整个项目的伦理优势建立在这个模式上，但它的完整构建路径只在测试里跑过。真机上第一次跑会暴露什么，很难说。

四、证据可能被” 填满”。 证据机制是好机制，但它挡不住”Agent 引用了证据但理解错了证据”。它能保证” 你说的这句话有出处”，不能保证” 你对出处的理解是对的”。这不是这个项目能单独解决的问题。

如果你只有二十分钟

我会建议你这么试：

不装桌面应用，直接 cargo install --path apps/craft-anything-cli，然后 craft-anything-cli commands 看看 320 个工具长什么样
挑一个你不熟的网站，craft-anything-cli rebuild https://example.com "Recreate this website" --rounds 1
去翻 checks/ 目录，看它到底量出了什么

第 3 步最值得看。那里面是这个项目真正的价值 —— 不是它帮你复刻了什么，而是它把” 怎么量一个网页” 这件事变成了一份可读的记录。

十二、小结

Craft Anything 是一个四天大的新项目，8,302 stars，纯 Rust，300 个自研引擎工具，MIT OR Apache-2.0 双许可。

它做的事，用一句话讲完是：把” 看懂一个软件” 变成一个可自动化的、可审计的、有明确边界的流程，然后把结果交给编码 Agent 去重建。

我觉得它值得关注的三个点：

Clean room 在引擎层实现，不是提示词层面的君子协定。插件也绕不过去。
证据是一等公民，带置信度、覆盖率和局限，还有独立的” 未知” 类型。
技术栈由需求决定，而不是由工具的默认值决定。

它现在确实是 early alpha：Clean room 完整构建没真跑过，Codex 没验证过，ACP 只有 Maki 跑过。但它的文档诚实度、架构清晰度和设计克制，在我最近看过的 AI 工具项目里排第一档。

那一开始说的那个落地页 —— 我后来还是用 DevTools 量了。

不过下次可能不用了。

本文基于 2026-11-04 时的仓库状态（v0.3.0，8,302 stars）。项目处于 early alpha，功能和数字都可能变化，以仓库 README 和 docs/STATUS.md 为准。