空白画布是个谎言：你的架构早就写在 Structurizr 文件、Terraform 模块、Mermaid 图和 README 里了。把 AI 代理接上 Archyl 的 MCP 服务器，把这一切变成一个活的 C4 模型——一个框都不用重画。

用 MCP 把代码、Terraform 和图表变成 C4 模型

架构文档最难的部分不是画框。而是当你打开工具的那一刻，你的架构早已存在——散落在五个互不相通的地方。

一份某人维护了八个月的 Structurizr DSL 文件。十几个 README 里的 Mermaid 图。比任何架构图都更真实地描述你基础设施的 Terraform 模块。从上一个工具导出的 PlantUML。还有代码库本身——唯一从不撒谎的来源。

周六我展示了如何用两个 MCP 服务器加一段提示词把 Confluence 空间迁移进 Archyl。今天，同样的招式，更大的战利品：导入架构本身。

两条路径，按来源选用

先说内置路径：如果你的代码仓库已经连上了 Archyl，AI Discovery 会分析代码并提出一份完整的 C4 模型——系统、容器、组件、关系——由你审阅批准。而如果你是从另一个 C4 工具迁过来的，Structurizr DSL、LikeC4 和 IcePanel 的导出文件已经有了一键导入器。这两条路只要有一条合适，就从这里开始。

MCP 路径针对的是其余一切：Discovery 看不到的来源。图表即代码的文件、基础设施定义、某人 wiki 里的那页架构说明，或者一台私有服务器上的仓库。Archyl 的 MCP 服务器开放了 C4 模型的完整写入面——create_system、create_container、create_component、create_relationship、set_element_technologies、create_adr——只要一个代理能_读_你的来源，它就能_写_你的模型。

配置还是周六那一行命令：

claude mcp add --transport http archyl https://api.archyl.com/mcp \
  --header "X-API-Key: your_api_key"

配方 1 —— Structurizr、Mermaid、PlantUML

图表即代码是最容易的赢面，因为语义本来就是显式的。对于标准的 workspace.dsl，上面的一键导入器更快——代理真正派上用场的场景是 Mermaid 和 PlantUML（没有对应的导入器）、导入器解析不了的 DSL 变体，或者你想把内容_有选择地_合并进一个已有模型的项目。在 Claude Code 里打开仓库，然后：

读取这个仓库根目录下的 workspace.dsl。在我的 Archyl 项目
"Aurora Commerce" 里复刻这个模型：

- softwareSystem → create_system（外部系统标记为 external_system）
- container → create_container，挂到正确的系统下，保留
  technology 字段
- 每一条 relationship → create_relationship，带上描述
- DSL 里没有的东西一律不要杜撰；列出所有你无法映射的内容

最后用 list_systems 和 list_containers 把模型读回来，
给我一份摘要，让我确认没有任何遗漏。

结尾那个"读回来"的步骤是值得养成的习惯：代理对照线上模型验证自己的导入结果，而不是想当然地认为成功了。

配方 2 —— Terraform

你的基础设施代码知道那些你的图早已忘掉的事。把代理指向你的 Terraform，让它在正确的高度上工作：

读取这个仓库里的 infra/。在 Archyl 中建模部署层面的架构：
托管服务（RDS、SQS、S3、CloudFront……）变成容器或外部系统，
每个真实服务一个——而不是每个资源一个。依赖关系从 IAM 策略、
安全组和环境变量中推导出来。给你创建的所有内容都打上
"terraform" 标签，方便我之后过滤这批导入的层。

"每个真实服务一个，而不是每个资源一个"这句话干的是真活。天真的导入器会把 400 个 Terraform 资源变成 400 个框。代理则明白，一个数据库实例、它的子网组和参数组，其实是同一个叫 Orders Database 的容器。

配方 3 —— 代码库本身

没有 DSL、没有图、仓库也没连 Archyl？代理已经坐在你的代码里了。让它自底向上提出模型——从部署清单里找服务，从包结构里找组件，从它发现的 HTTP 客户端和队列生产者里找关系。这就是把 AI Discovery 的活儿手工干一遍，也是 Discovery 够不着来源时的正确兜底。

配方 4 —— 困在 wiki 里的图

把周六那篇文章里的两个 MCP 服务器合起来用：代理通过 Atlassian 的 MCP 服务器读取架构页面，抽取其中描述的系统和流程，写进 Archyl。那张_描述_你事件管道的 wiki 页面，变成了一个真实可导航的模型——页面本身也作为关联文档一并带入。

导入只是无聊的部分——重点在这里

导入之后的第二天，才是你做这一切的原因。因为模型是通过 MCP 进来的，它就始终可以通过 MCP 触达：

你的代理边写代码边查询它——"哪些容器在和支付数据库通信？"只需一次工具调用。
新服务由构建它们的同一批代理加入模型，模型跟着现实走，而不是慢慢腐烂。
偏移评分和一致性规则跑在一个真正与你的系统相符的模型上。

最后用一条实在的规矩收尾：代理提议，你来审。 一次导入一个系统，读摘要，剪掉不属于这里的东西——和任何代码评审一样的纪律。你最终得到的模型，好坏取决于你喂给它的来源，而只有你知道那五个来源里哪个说的是真话。

你的架构早已存在。别再重画了——把它导入进来。完整工具清单见 MCP 服务器文档。

用 MCP 把代码、Terraform 和图表变成 C4 模型 - Archyl Blog