用 Coding Agent 画出可检查的图
Archify 是面向 Coding Agent 的开源画图技能，可配合 Claude Code、Codex、Cursor、OpenCode 和 GitHub Copilot 使用。Agent 理解你的描述或代码仓库证据，编写结构化 JSON；Archify 将其渲染并校验为可交互的 HTML 图。
当你需要讲清系统组成、流程步骤、调用顺序或其他受支持的关系结构时，可以使用它。没有仓库也能从文字开始；需要解释真实代码时，再让 Agent 查阅相关源码。
图表达的是作者提供的事实模型。通过图表校验，不等于证明真实系统确实如此运行。
Agent 和 Archify 分别负责什么？
Agent 阅读你提供的信息，询问关键缺失事实，选择图型，并编写或修改结构化源文件。任务涉及真实仓库时，Agent 还需要检查相关代码。
Archify 根据源文件生成 HTML，并执行对应的渲染与校验。你可以保留结构化源文件，继续让 Agent 修改；读者只需在浏览器中打开生成的 HTML，不必安装 Archify。
因此，不要把它理解为独立的代码发现服务、生产监控系统或在线团队编辑器。一张好看的图，不能替一条没有依据的连线作证。
先配置你实际使用的 Agent
打开快速开始，选择自己的 Agent，再按需要选择项目级或全局安装。使用页面给出的对应命令，不要套用其他 Agent 的安装目录。
安装说明列出了不同使用入口及限制。完整渲染流程需要文件访问和 Node.js 等环境能力，具体要求因集成方式而异。能与模型聊天，不等于当前环境能执行完整工作流。
安装说明也不表示所有 Agent 版本组合都已验证。如果失败，先记录 Agent 及版本、操作系统和完整错误，再判断问题出在配置还是图表本身。
不用代码仓库：读懂一张中文流程图
没有代码仓库，也可以从步骤、额度和规则开始。打开现有的中文休假流程图，对照固定版本的 JSON 源文件。这是已有源文件的阅读示例，不是一次新的 Agent 执行记录。
先看“休假计划”和“规则提醒”两条泳道：全图有 8 个节点、7 条关系；主路径只有 6 个节点，从年初额度经过四次安排，到全年用完。年假按 1 + 4 + 3 + 2 分配，正好 10 天；春节另用 2 天调休，合计 12 天。两条分支连接过期和审批提醒，不是再次扣减休假额度。
检查时把“顺序”“额度”“提醒”分开读：先沿主路径核对剩余额度，再看分支是否只是补充约束，别把提醒算成额外休假。图中的规则都是示例，不是实际日历或公司休假政策建议；“连休 9 天／10 天”标签不是现实保证，必须另行核对日期和适用制度。
想从自己的描述开始，可打开工作流快速开始，只提供已确认的步骤和规则，并标出未知条件。
第一个例子：分别画缓存命中与未命中
时序图适合回答“谁调用谁，先后顺序怎样”。对于这里介绍的稳定版 3.1.0 工作流，应把这两种互斥场景分别画成两张图，不要放在同一次请求的时间线上。在完成配置的 Agent 中，可以这样描述：
用 Archify 分别画两张时序图：缓存命中场景和缓存未命中场景。两者都从 Browser 调用 API、API 查询 Redis 开始。命中时，API 将缓存结果返回 Browser；未命中时，API 查询 PostgreSQL，把结果写入 Redis，再返回 Browser。明确标注每张图对应的场景，不要把互斥路径串成同一次请求的时间顺序。不要添加未说明的鉴权、队列、重试或实测耗时。缺失信息会实质影响顺序时，先问我。
这是演示输入，不是对你应用行为的断言。现有的缓存未命中示例描述的是另一条包含鉴权与追踪细节的未命中路径，不是上述提示词的生成结果。不要把它额外的设定当成自己系统的事实。
检查成品时，重点看：
- Browser、API、Redis 和 PostgreSQL 的职责是否符合描述？
- 是否有两张场景标注明确的独立图，而不是暗示一次请求会同时经历命中与未命中？
- 未命中路径是否按描述完成数据库查询、缓存写入和响应返回？
- Agent 是否擅自添加了行为或耗时？
如果图不准确，先改语义，再调外观。例如，只有在符合实际情况时才补充：“我们的缓存写入是异步的，请修改对应部分；响应的具体时机还没确认，先标为未知。”
从仓库画架构图，怎样避免编造？
说明要看的仓库和具体行为。比起“把整个项目都画出来”，范围明确的问题更容易验证。
阅读这个仓库，用 Archify 解释［某个请求或任务］的运行路径。只画代码支持的组件和关系，区分运行时组件与构建、开发工具。在支持的范围内附上仓库证据，说明检查的版本；未知的部署信息标为未知，不要猜测。不影响主路径理解的实现细节放进补充卡片。
接受成品前，逐项确认：
- 范围：解释的是哪个请求、任务、模块或子系统？
- 版本：检查的是哪个仓库、哪个提交？
- 证据：哪些文件支持关键组件和关系？
- 边界：外部服务、归属和部署边界有依据，还是假设？
- 完整性：是否遗漏影响理解的失败路径或返回路径？
- 未知项：缺失事实是否明确暴露，而不是被画得像定论？
如果成品附有已验证的源码链接，应点开检查。源码链接说明证据来自哪里，不会自动证明生产环境的运行行为；必要时仍需日志、链路追踪、配置及人工确认。
可参考现有的 MCO 运行时架构示例及其结构化源文件。它解释的是所标明的提交版本，不代表仓库之后永远保持相同结构。
修改、检查和分享
每次提出聚焦的修改：补充一个返回、重命名一个组件，或纠正一条关系。没有变化的事实应保持不变。要求 Agent 重新执行适用检查，遇到失败如实报告，不要把未经检查的版本当成最终交付。
打开 HTML，分别检查内容是否准确、文字和连线是否可读。自动校验与人工视觉检查解决的是不同问题，不能彼此替代。
读者需要交互时，分享 HTML；文档或幻灯片需要静态画面时，再导出图片。文档列出了 PNG、JPEG、WebP、SVG 和 WebM 等导出格式，但具体可用性取决于格式、浏览器及本地工具。先查看实际成品的导出菜单，再承诺交付格式。导出图片不会保留 HTML 中的交互控件。
分享仓库生成的图之前，检查标签、卡片、内嵌源文件和链接是否包含不宜外传的信息。单文件便于携带，并不表示适合公开。你使用的 Coding Agent 如何处理数据，也不能仅凭 Archify 的输出格式推断。
常见问题
Archify 是 AI 图片生成器吗？
它通过 Agent 编写 JSON、再渲染的方式生成结构化图表。更适合解释组成、关系、步骤和状态，而不是通用插画生成。
支持哪些图？
当前稳定版文档列出架构图、工作流、时序图、数据流、生命周期、实体关系图、类图、树图、时间线和瀑布图。场景指南提供精选配方，但不同图型不一定拥有完全相同的交互和表示能力。
能画流程图或 UML 吗？
工作流可表达步骤、分支和参与者；类图与时序图适合 UML 相关的部分建模需求。应按问题选择已支持的图型，不要由“有类图和时序图”推断为完整支持全部 UML 标准。
能从 Mermaid 开始吗？
可以让 Agent 理解受支持的 Mermaid 输入，并按含义重新编写 Archify JSON。这不等于承诺完整自动解析或无损往返转换。转换后要检查重要关系和分支是否保留下来。
必须有代码仓库吗？
不需要。足够清楚的文字描述即可作为起点。只有当图需要解释真实代码、并希望检查源码证据时，仓库才成为重要输入。
免费吗？这里说的是哪个 Archify？
这里指 tt-a1i/archify 开源项目，官方网站是 archify.si。项目代码采用 MIT 许可证。你使用的 Agent 或其他服务可能另有费用与条款；名称相似的收费服务不自动构成官方关联。