Transcript
00:00:00让AI编程助手绘制代码仓库架构，结果经常会凭空冒出根本不存在的Kafka、Redis或API网关。
00:00:07这些架构图看起来往往挺像那么回事，但其实漏掉了大量细节。
00:00:10这就是Archify，它不会让AI直接去绘制任何图形。
00:00:14它输出的是强类型的图表数据，由Archify进行验证，然后再渲染成图表。
00:00:19这或许是可视化我们系统架构的最佳方法之一。
00:00:23我们马上来验证一下。
00:00:30说实话，我们的AI模型其实根本不应该由它来直接画图。
00:00:33Archify的工作原理是将系统描述为结构化的、强类型的JSON格式。
00:00:37经过验证后，才会由本地编译器将其转换为最终的HTML。
00:00:42如果图表数据无效，就会直接报错。
00:00:45这就是Archify，它在短短几个月内就获得了44,000颗星，因为它能直接集成到Cloud Code、Cursor和Codex中。
00:00:53所以我想亲自测试一下。
00:00:54我准备安装Archify，将其指向一个代码库，并让它回答一个关于架构的问题。
00:01:00然后我们看看这样的结果到底能不能直接用在Pull Request里。
00:01:03当然，有些使用场景我是绝对不会用它的，我们稍后就会详细讨论。
00:01:08如果你喜欢能加快工作流的编程工具，请务必订阅。
00:01:11我们一直在持续推出新视频。
00:01:13好了，安装非常简单，就用这里的一行命令。
00:01:17而且这并不是需要我去额外配置的独立应用。
00:01:19它实际上是一个AI代理技能（Agent skill）。
00:01:22安装完成后，我可以从Cloud Code或刚才提到的其他任何工具中直接调用这个技能，
00:01:28完全不需要更换编辑器或改变现有的工作流。
00:01:32现在我可以给它派发一个真正的任务了。
00:01:34我不会要求它去画这个代码库的完整架构。
00:01:37听起来好像挺好。
00:01:39但归根结底，那样做只会给我们返回一堆毫无价值的垃圾信息。
00:01:42所以我打算问一个切实具体的问题。
00:01:45使用Archify，生成架构图，节点控制在8到12个以内。
00:01:49当这个服务发生缓存未命中（cache miss）时会发生什么？
00:01:52只包含该代码库中实际存在的组件方框。
00:01:54如果你无法提供证据证明某个组件存在，就直接省略它。
00:01:58交付一个自包含的HTML文件。
00:02:00这就是所谓的精简方案，只问一个问题。
00:02:02大约8到12个节点。
00:02:04因为如果我们让AI去绘制整个代码库，我们到底简化了问题，还是
00:02:08反而让它变得更难理解了呢？
00:02:10现在我只是把代码库目录变成了一个流程图。
00:02:14AI会以JSON格式编写架构。
00:02:16然后由Archify对其进行验证。
00:02:18我也可以像现在这样直接运行验证过程。
00:02:23这其实是我发现的这个工具非常酷的一个功能。
00:02:27节点还可以包含绑定到特定提交（commit）和代码行范围的代码库佐证（evidence）。
00:02:32如果缺乏这种佐证，即使节点在回答中听起来再头头是道，
00:02:37也不会获得SRC徽章。
00:02:39好了。
00:02:39这到底有什么帮助呢？
00:02:41这看起来确实像是一张架构图。
00:02:43没错，但你其实不必把它当成普通图表来用。
00:02:46我可以在其中搜索具体的某个服务。
00:02:50点击它就能立刻看到它的上游和下游依赖。
00:02:55然后我可以顺着这条路径，追踪缓存未命中时请求在系统中的流转过程。
00:02:59因此，我不必盯着10个箭头在脑海里苦苦回溯，而是可以直接逐步遍历它们。
00:03:05了。
00:03:06除了这些，我还可以将它导出。
00:03:08我可以复制PNG格式，或者生成一个 1200x36 的分享卡片。
00:03:13这里真正的区别在于它不是Mermaid图表，对吧？
00:03:17Mermaid工具通常是我只能去读的东西。
00:03:20而这个是我可以向它提问并对其进行交互的系统。
00:03:23而且这种机制不会被用来掩盖糟糕的结构，即使把图表导出为静态图片，
00:03:28其包含的含义依然能够完整保留。
00:03:31这里还有第二个使用场景，可能实际上更有用，对吧？
00:03:35我们在想什么呢？
00:03:36嗯，我在考虑代码评审。
00:03:38假设这是改动之前的系统。
00:03:41然后我添加了一个现有的重试工作进程（retry worker）。
00:03:44我可以让AI代理更新架构，而不会凭空捏造出不存在的东西。
00:03:49Archify随后可以对比两个经过验证的快照，展示新增、删除、移动和重新路由的变更。
00:03:54所以，与其去对比两张生成的图表，我可以直接看到究竟改动了什么。
00:03:59而且编辑器的界面依然只是聊天窗口。
00:04:02但如果我想让这个架构在下一个AI会话中延续下去，我只需提交这个JSON文件。
00:04:07目前来看，理解Archify最简单的方式是这样的。
00:04:11对于系统地图的HTML虚拟机来说，编程助手是前端。
00:04:15JSON是中间表示层。
00:04:19HTML是编译后的结果。
00:04:21而中间的那层承担了大量核心工作。
00:04:24JSON遵循严格的模式（schema）。
00:04:26未知字段会导致验证失败。
00:04:28并且它支持五种图表模式。
00:04:30架构图、工作流图、时序图、数据流图和生命周期图。
00:04:34但其中最有趣的决定之一，是模型并不控制布局。
00:04:38也就是布局。
00:04:39模型负责描述系统。
00:04:41它并不能决定每个方框具体应该放在哪里。
00:04:44他们其实尝试过带有自动度数布局的主题化Mermaid。
00:04:48结果发现并没有比普通的Mermaid好多少。
00:04:51而且验证机制采用的是故障安全关闭（fails closed）原则。
00:04:54格式糟糕的JSON绝不会变成漂亮的图表。
00:04:58你会得到诊断信息、规则代码以及支持的修复建议。
00:05:02说了这么多，这或许正是我不会使用Archify的地方。
00:05:06如果你需要在自述文件（readme）中直接嵌入图表，那可能不太合适。
00:05:10可能需要花点时间。
00:05:11GitHub会渲染它。
00:05:12而Archify的HTML则不会。
00:05:15Archify在这里解决的是一种截然不同的问题。
00:05:18流程中已经包含了一个AI代理。
00:05:20这个代理正在生成一个架构制品。
00:05:23也许它会被提交到Pull Request中。
00:05:25也许它会进入设计评审环节。
00:05:27这正是经过核对的输出开始发挥作用的时候。
00:05:30总的来说，这里有很多我非常喜欢的地方。
00:05:32它就存在于我们每天已经在使用的工具之中。
00:05:35我可以把输出结果导出来。
00:05:38代码库佐证为我提供了具体、可供实际核对的依据。
00:05:41而且由于架构是结构化的，我可以持续进行编辑，而不会让图表随时间发生莫名其妙的变动。
00:05:46它的视觉效果也足够好，我可能觉得没必要在 Figma 或其他类似工具中重新画一遍。
00:05:53但话又说回来，与此同时，Archify并不真正了解你的架构。
00:05:58一个图表完全可以完全合法有效，但描述的却依然是错误的系统。
00:06:02你仍然必须亲自去阅读它。
00:06:03正如我们所知，一个糟糕的模型通常只会生成能跑通但依然很难看的JSON。
00:06:08如果你的图表最终要放在自述文件中，在这里使用Mermaid可能依然是更好的选择。
00:06:13使用Archify，你大概率需要提交JSON和HTML文件，或者导出为图片。
00:06:18这里有一个绝对应该避免的错误。
00:06:21千万不要把它指向一个庞大的代码库然后说：把所有东西都画出来。
00:06:25我想你大概能猜到结果会怎样，因为你很可能只会得到一堆垃圾信息。
00:06:29但这并不是Archify的失败。
00:06:32这只是提问的方式不对。
00:06:34如果你已经在使用编程助手，并且经常需要创建供自己或他人以后查看的图表，那么这个工具很有意义。
00:06:42在PR评审、设计文档这些场景下，我大概率会使用它。
00:06:47我安装它绝不是因为想要寻找诸如Mermaid之类现有工具的更美观版本。
00:06:52而且我绝对不会指望它能为我逆向工程任何东西。
00:06:55尝试的门槛真的很低。
00:06:58一条npx命令，机器上装了Node就行。
00:07:00这里不需要什么模型权重。
00:07:02我的M4 Pro在这里基本上毫无用武之地。
00:07:05不过我还是会遵守一条准则。
00:07:07每个文件只提一个问题。
00:07:08如果你无法清晰地说出这张图表究竟在回答什么问题，那就不要生成图表。
00:07:14我是来自BetterStack的Josh。
00:07:15如果你喜欢这类编程技巧与诀窍，请务必订阅本频道。
00:07:19我们下期视频再见。
00:07:20我们下期视频再见。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video