tt-a1i/archify

解决什么问题

讲清楚一个系统，通常要在会腐烂的 wiki 页和不能点的 PPT 之间二选一。diagrams-as-code 往前推了一步，但源文件仍然得有人写。Archify 的判断是：你的编程代理已经读过仓库或理解了方案，写图这一步可以直接交给它。你描述要画什么，代理生成可视化结果，后续用自然语言继续改。

有什么不同

和 Mermaid、PlantUML 相比，那两个给的是确定性的文本格式加固定渲染引擎，而 Archify 产出的是一个自包含的交互式 HTML 文件，节点可点、源码片段能钉到某个 commit、版式也比那些引擎自由得多。和 Excalidraw、Figma 手绘相比，它是生成而非摆放，画大系统更快，像素级控制则差很多。真正有意思的是第二种模式：一页式 "explainer"，结论先行、分面板作答、带编号引用，图只是论证的一部分，而不是全部答案。

它真正的依赖不是渲染器而是代理本身。这是它的取舍：输出质量跟着模型和 skill 的指令走，你信任的是生成出来的结构，而不是自己写的 schema。

适合谁

需要向同事、新人文档或设计评审解释架构的开发者和技术负责人，尤其是已经在用 Claude Code、Codex、Cursor、OpenCode 的人。不适合两类团队：一类要求图以可 diff 的文本形式进版本库并由 CI 重新生成，一类要精确可复现的布局控制。如果所在组织禁止把仓库内容发给模型厂商，那就不用考虑了。

上手成本

安装就是一条命令 npx skills add tt-a1i/archify -g，然后开始提示。真实成本在别处：得有代理订阅或 API 额度，装 skill 需要 Node 工具链，以及把代码交给模型的信任成本。产物是 HTML，分享意味着托管一个文件或传文件，没法像 Markdown 那样贴一段进文档。MIT 协议。README 里营销、赞助商和推广链接偏多，对 skill 如何约束生成结果讲得很薄，建议直接看在线 gallery 判断效果。

点评

对一个这么年轻的项目来说，star 数字很扎眼：2026 年 4 月创建，到 10 月下旬已 88.7k star，但只在趋势榜上出现过一天（+445）。这种巨额累计 star 加上几乎没有持续上榜的组合，更像借助 skill 生态分发的爆发，而不是逐月自然增长。目前只有一个追踪数据点，势头好坏都还谈不上。概念确实有用，交互式 HTML 产物相对静态图是实打实的进步，但要判断是否采用，应该拿自己的代码库跑一遍，看生成的图站不站得住。