Archify 全流程实测：剑的 AI 实验室第一项完整收成

Archify 全流程实验报告

实验目标是把 Archify 按普通用户路线完整走过剑的 AI 实验室。项目从 GitHub Trending 进入项目库，核对官方 README、中文说明、MIT 许可证、版本和作者来源后安装官方 Skill。doctor 的 16 项检查全部通过，demo 成功生成。随后依据网站真实源码写出 12 个组件、11 条关系和 3 个引导视图。第一轮发现穿节点、7px 微线段、标签覆盖和间距问题；第二轮仍有端点方向和标签问题；第三轮发现桌面文字只有 5.8125px；第四轮将画布宽度调整为 1380 后，9 项检查全部通过，0 错误、0 警告。最终 HTML 为 713,036 字节，SHA-256 为 1e86f6da87bc7804bc9323d5ae48ab661b26e022f1e0b55d436bdb91d441dd10。自动四尺寸视觉检查因环境没有 Chrome 而跳过，1363×936 人工浅色与深色检查通过。

我把 GitHub Trending 第一，种进了自己的 AI 实验室

GitHub Trending 把 Archify 推到了很多人面前。榜单截图里，它排在当天仓库榜第一，页面显示当天新增约 1,035 个 Star。作者很高兴，X 上也有不少人转发。对一个开源项目来说，这已经是很亮眼的一天。 剑的 AI 实验室收录项目以后，还要继续往下走。榜单只能告诉我们，很多人在这一天注意到了它。它能不能安装，能不能处理真实项目，生成结果有没有硬伤，普通用户最后能带走什么，这些问题都要靠实验回答。 我们把 Archify 放进实验田，完整走了一遍项目库、核验、安装、实测和收成区。这也是网站第一次把一项 GitHub 发现做成全过程示范。 ## 它承诺做什么 Archify 是一个多平台 Agent Skill。用户给它一段自然语言描述，也可以让它读取代码库。它会生成架构图、工作流图、时序图、数据流图或生命周期图，最后交付一个自包含 HTML。 这个 HTML 不需要在线图表平台。打开文件就能看，里面有节点搜索、路径追踪、聚焦、引导故事、浅色与深色主题，还能继续导出图片和视频。 它最值得测的地方是验证机制。很多 AI 绘图工具把图生成出来，任务就结束了。Archify 会先把系统写成结构化 JSON，再检查线路、标签、间距、字体和布局。检查不合格，它返回具体诊断，拒绝交付。 这项能力听起来很适合剑的 AI 实验室。我们正需要一张网站架构图，也需要一个能从发现走到产出的示范项目。于是实验目标定得很清楚，用 Archify 读取网站真实结构，做出一张可以打开、核对和分享的系统架构图。 ## 第一次工作从发现与入库开始 第一条记录保留了发现来源。项目来自 GitHub Trending，仓库是 tt-a1i/archify。项目卡记录了作者、仓库地址、版本、许可证和发现时间，也把当天的 X 传播线索留下。 这一环看着简单，网站过去却经常在这里断掉。项目库里有一个链接，有一句中文简介，随后就没有下文。用户看完项目卡，无法知道有没有人装过，也找不到真实结果。 Archify 入库时，我们把项目状态明确分成已发现、已核验、已实测和已产出。项目热度属于发现证据，安装结果属于实测证据，两者不再混成一个模糊的“已验证”。 ## 第二次工作核对官方资料 我们对照官方 README、MIT 许可证、版本说明和 Skill 文档，确认它支持五类技术图，也确认它的主要交付格式和运行条件。 这一步还核对了它的边界。Archify 需要 Node.js 和能够调用 Skill 的 Agent。它输出本地 HTML，没有在线托管编辑器。视觉检查依赖 Chrome 或 Chromium，运行环境缺少浏览器时会明确跳过。 项目介绍也在这里改写成中文。卡片上不能只写“AI 架构图工具”。普通用户需要先看到它解决什么问题，怎样安装，最后会得到什么。项目卡因此写明，它能把一句系统描述或整个代码库交给 Agent，几秒生成可核验、可交互、还能导出的专业架构图。 ## 第三次工作安装与自检 我们安装了官方 Skill，在 Node.js v24.19.0 环境运行 doctor。16 项检查全部通过，退出码是 0。随后运行 demo，示例 HTML 成功生成。 这一步证明项目至少能在当前环境启动。很多仓库的失败发生得更早。依赖装不上，命令已经过期，文档漏掉必要步骤，用户折腾半天还没看到第一个结果。Archify 没有卡在这里。 实验田现在会保存运行环境、完整命令、退出码、检查数量、错误数和警告数。以后再看这条记录，不用凭一句“安装成功”猜当时究竟做了什么。 ## 第四次工作把真实网站交给它 我们没有停在官方 demo。真正的任务是分析 jianailab.com。 网站当时已经有项目库、竞技场、实验田、收成区、聚义厅和公开实验页面。背后还有社区 API、D1 数据库、R2 媒体存储、Supabase Auth、Cloudflare Turnstile、ChatGPT Sites，以及 GitHub 和 Radar 仓库。 根据真实源码和部署结构，我们写出 12 个核心组件、11 条关系和 3 个引导视图。三段引导分别覆盖访客主路径、身份与媒体、项目发现与发布。图里的每一条关系都要能在网站结构里找到来路。 这一步留下了第一张流程图。它记录 Archify 怎样从 Trending 发现进入项目库，随后经过核验、安装和实测，最后到达收成区。 ## 第一轮验证失败 首版图没有被放行。 showcase 验证一共 9 项，第一轮只通过 5 项，出现 4 个错误。线路穿过节点，局部有 7px 微线段，标签覆盖，某处标签与线路间距为 0。 这些问题肉眼未必一下就能看全。尤其是图比较大时，生成结果乍看已经像一张完成品。Archify 把问题落到了具体线路和具体位置，修复对象很明确。 我们保留了这次失败，没有把它删掉。真实实验里，失败记录比一句“效果很好”更有用。后来的人可以看到首版为什么没交付，也能判断工具的验证机制有没有实际作用。 ## 第二轮和第三轮继续失败 修完第一批问题，第二轮仍然没有通过。部分端点方向不符合规则，标签依旧贴近线路。 继续调整以后，第三轮已经通过 8 项，只剩一项可读性检查。桌面投影后的最小文字只有 5.8125px，低于 6px 底线。 这个数字让实验变得很具体。图在作者自己的屏幕上能看，不代表分享出去以后仍然清楚。Archify 会按投影尺寸检查文字大小，5.8125px 也会被拦住。 前三轮失败分别处理结构冲突、线路路由和文字可读性。每次修改以后重新验证，没有用“差不多”代替通过。 ## 第四轮达到 9/9 我们把画布宽度调整到 1380，重新计算布局和文字投影。第四轮验证通过。 最终结果是 9/9 showcase，0 错误，0 警告。deliver 命令成功执行，退出码是 0。生成的自包含 HTML 大小为 713,036 字节。 交付回执还保存了 SHA-256。 1e86f6da87bc7804bc9323d5ae48ab661b26e022f1e0b55d436bdb91d441dd10 这个哈希可以核对文件有没有变化。实验田同时保存 HTML、架构 JSON 和验证回执。用户以后打开项目，不再只看到一段总结，可以直接下载原始成果复查。 ## 自动视觉检查跳过，人工检查补上 最后一步运行 visual-check。当前自动环境没有 Chrome 或 Chromium，命令返回退出码 2，状态是 skipped。 我们没有把跳过写成通过。随后在网站预览浏览器里进行人工检查，视口为 1363×936。浅色主题和深色主题都打开看过，没有发现页面溢出。交互架构图的工具栏、三个引导章节、12 个组件和 11 条关系都能读取。 实验记录同时保留自动检查状态和人工检查状态。自动 skipped，人工 passed。这样写比一个笼统的绿色对勾更准确。 ## 这次实验反过来查出了网站六个缺口 Archify 的图做完以后，我们把一名普通用户从项目库走到收成区的过程重新检查了一遍。工具本身通过了，网站流程却暴露出六处断点。 第一处是项目状态太含糊。现在项目卡会分别显示已发现、已核验、已实测和已产出。 第二处发生在竞技场。同一个仓库如果已经有发现动态，成功实验容易被旧记录压住。现在发现和实验会并行保留，用户可以从讨论进入真实成果。 第三处是成果文件无处安放。实验田以前主要接图片、音频和视频，HTML、JSON、PDF、Markdown 和 ZIP 没有正式入口。现在每次工作都能上传成果文件，收成区也有独立文件列表。 第四处是测试证据太松。过去只能写一段文字说明成功。现在每次工作可以保存环境、命令、退出码、通过数量、错误数、警告数、文件大小和 SHA-256，自动检查与人工检查分开记录。 第五处在收成区。日志、图片和视频虽然存在，用户还要自己重新拼成报告。现在收成区会自动汇总全部工作，统计图片、视频和成果文件，再接住实验报告、长文章和视频制作包。 第六处是成果与实验失去联系。文章写完以后，读者找不到它来自哪项实验。视频制作包也可能单独躺在别处。现在报告、长文章、视频、制作包和交互成果都绑定到原实验，回头可以查到八次工作和全部回执。 这六处修改让网站第一次连通了完整流程。项目从 GitHub 进入项目库，用户把它种进实验田，每次操作留下证据，收成区再把材料整理成可以发布的成果。 ## GitHub Trending 第一到底值多少 Trending 第一很有价值。它能带来第一批注意力，也能帮助我们从大量仓库里找到值得看的项目。 它完成不了核验和实测。榜单不会替用户安装项目，也不会说明某个仓库在他的电脑上能不能运行。Star 数量更不会自动变成一篇文章、一条视频或一个可以打开的文件。 剑的 AI 实验室要补的正是后半段。我们保留热度，继续检查官方资料和运行条件，再用真实任务测一遍。成功要有结果，失败也要留下原因。最后能下载、能打开、能复查，项目才真正进入收成区。 Archify 这次交出了完整结果。官方 Skill 安装成功，doctor 通过 16 项检查，真实网站架构图经过四轮验证，最终达到 9/9。HTML、JSON、回执、流程图和过程视频都已经保存。 它也给网站留下一个很实用的标准。以后收录 GitHub 项目，项目卡负责让人看懂，实验田负责证明它能不能干活，收成区负责把真实过程变成文章和视频。三处连起来，一条链接才会变成可以使用和传播的成果。 ## 下一步拿它做视频 这项实验已经准备好下一条视频。 视频可以从 GitHub Trending 第一开场，随后提出一个直接问题，这个项目到底能不能干活。安装和 16/16 自检很快带过，中段保留前三轮失败。线路穿节点、7px 微线段、标签贴线和 5.8125px 文字都是能看见的内容。 第四轮展示 9/9、713,036 字节 HTML 和 SHA-256，再打开交互架构图。最后回到剑的 AI 实验室，展示项目库、八次工作、结构化证据、成果文件和收成区。 整个过程已经有文字、两张流程图、三张网站操作截图和 16 秒过程视频。长文章和视频制作包也绑定在同一项实验下面。 这是实验室的第一条完整示范。发现有来源，核验有依据，实测有失败，产出有文件。下一次再遇到一个热门 GitHub 项目，我们就按这条路继续走。

Archify 下一期视频制作包

视频标题《我把 GitHub Trending 第一，种进了自己的 AI 实验室》。开场先展示 Trending 榜首，再问它到底能不能干活。第二段展示项目核验和 doctor 16/16。第三段重点保留前三轮失败诊断，让观众看到线路穿节点、7px 短线、标签压线和文字过小。第四段展示第四轮 9/9、713,036 字节 HTML 和 SHA-256。第五段打开交互架构图。最后回到网站，展示项目库、八次工作记录、结构化测试证据、成果文件和收成区的报告、长文章、视频制作包。结尾落到一句话，GitHub 项目只有经过真实实验，才会从一个链接变成可以使用和传播的成果。

Archify 实验过程视频记录

剑的 AI 实验室交互架构图