目录 为什么给 Claude Code 装一个“画图能力”很重要 SKILL让 Claude Code 从“通用模型”变成“可扩展工程助手”️ Claude Code 的画图能力应该怎么装️ 老项目改造真正高频的其实只有四类图◇ 架构图回答“系统由什么组成”◇ 模块依赖图回答“谁依赖谁”◇ 时序图回答“一次请求到底怎么走”◇ ER 图回答“数据之间是什么关系” 真正决定图质量的不是工具而是 Prompt 三个 Prompt 技巧让 AI 少“脑补”◇ 技巧一告诉 AI“必须读取真实文件”◇ 技巧二追真实代码而不是追接口名字◇ 技巧三数据库关系必须读取 DDL 或 Entity 我的一个判断AI 画图本质上不是“制图”而是“知识压缩”⚡ 工具怎么选不要迷信“一把梭”◇ Mermaid默认选择◇ PlantUML复杂 UML 场景◇ draw.io最终交付场景 图好不好看真正决定于三个细节◇ 颜色分组◇ 留白◇ 固定方向 最重要的一条AI 画的图一定有错 把架构图当成“项目资产”而不是一次性图片 最终形成一套 AI 辅助的项目理解闭环 一份可以直接复用的“AI 画图检查清单” 写在最后AI 写代码已经不稀奇了。真正让 AI 进入老项目改造深水区的是让它能够“看懂、画出、验证并沉淀”系统结构。当 Claude Code 装上画图 Skill 后它不再只是一个会生成 Mermaid 源码的编码助手而开始具备一种更完整的工程能力从真实代码中提取结构再把复杂系统转换成可视化知识资产。本文要点 SKILL扩展 → ️ 画图能力 → ️ 四类核心图 → Prompt方法 → AI结果校验 → 知识资产沉淀 为什么给 Claude Code 装一个“画图能力”很重要很多开发者第一次让 Claude Code 画架构图得到的往往是一段 Mermaid 代码。代码本身没有问题。问题是谁来渲染谁来修改谁来反复迭代如果每次都要复制到 Mermaid Live Editor再截图、调整、重新复制回来这其实还是“AI 给你写代码人负责收尾”。而在老项目改造中架构图不是装饰品。它承担的是一个非常重要的任务把人脑里的系统理解变成团队可以反复查看、修改和验证的工程资产。尤其是面对一个运行了几年、模块众多、历史包袱严重的老项目时代码本身往往不是最大的理解成本。真正困难的是哪些模块是核心一次请求到底经过哪些层哪些模块互相依赖数据表之间是什么关系哪些外部系统不能随便动改一个 Service究竟会影响谁这时候一张正确的图往往比几百行代码更容易建立全局认知。 SKILL让 Claude Code 从“通用模型”变成“可扩展工程助手”理解画图能力之前先理解一个非常重要的概念SKILL。Claude Code 可以通过 SKILL 扩展自己的工作能力。简单理解SKILL 就像给 AI 安装一个“专业能力包”。一个典型的 SKILL 通常包含一个SKILL.md里面描述这个能力是什么、什么时候应该使用、需要调用什么工具以及相关的参考资料和脚本。Claude Code 会从用户级和项目级的 Skill 目录中加载这些能力~/.claude/skills /项目根目录/.claude/skills/这带来一个非常重要的工程思维AI Agent 不应该被理解成一个固定能力的聊天机器人而应该被理解成一个可以持续扩展的工作平台。今天安装画图 SkillAI 多了一种表达系统的方法。以后安装数据库分析 Skill、测试 Skill、代码审查 Skill它就多了一种工程能力。这和传统软件生态中的 package、plugin、extension本质上非常接近。️ Claude Code 的画图能力应该怎么装原文推荐的方案是claude-mermaid。第一步安装负责实际渲染的 Node 程序建议先确认 Node 版本node -vNode 需要 20 或更高版本。第二步在 Claude Code 中安装对应 Plugin/plugin marketplace add veelenga/claude-mermaid/plugin install claude-mermaidclaude-mermaid安装完成后建议完全退出 Claude Code再重新启动让 MCP Server 和相关配置真正生效。然后可以直接测试画一个最简单的用户登录流程图保存到当前目录。如果配置成功Claude Code 就不再只是输出 Mermaid 源码而可以直接参与图形生成、渲染和迭代。️ 老项目改造真正高频的其实只有四类图很多人一说“架构图”就想把所有东西都画进去。结果最后得到一张巨大的“蜘蛛网”。实际上老项目改造阶段最值得优先建立的是四类图。◇ 架构图回答“系统由什么组成”架构图关注的是系统骨架。例如前端↓API / Controller↓Service↓Repository↓Database再把中间件、外部服务等外围系统放进去。它解决的问题是这个系统整体长什么样适合用于项目全景、系统介绍、改造影响分析。◇ 模块依赖图回答“谁依赖谁”模块依赖图关注的是代码结构。例如A → B → C↓D它能帮助你发现哪些模块属于底层能力哪些模块属于业务层是否存在循环依赖修改某个模块会影响哪些上层模块这类图对老项目尤其重要。因为很多“改一个地方”的需求最后变成“大面积连锁反应”根本原因就是开发者没有看到真实依赖关系。◇ 时序图回答“一次请求到底怎么走”时序图特别适合分析接口。例如User↓Frontend↓Controller↓Service↓Repository↓Database它回答的不是“系统有什么”而是某一件事情发生以后系统到底经历了什么。所以它非常适合API 生命周期分析Bug 排查调用链梳理重构前后对比异步流程分析◇ ER 图回答“数据之间是什么关系”ER 图关注数据库。它应该明确表字段主键外键一对一一对多多对多对于老系统来说数据库往往是最难修改、也是最容易产生连锁影响的部分。所以在涉及数据模型改造之前先把 ER 图画出来通常比直接改 SQL 更稳。 真正决定图质量的不是工具而是 Prompt很多人装好工具之后第一反应是“Claude你帮我画一张架构图。”然后发现图非常乱。这不是 Mermaid 的问题。也不完全是 Claude 的问题。问题在于需求没有被结构化。一个好的画图 Prompt至少应该告诉 AI 四件事情画什么、依据什么、画到什么粒度、最终保存在哪里。例如架构图帮我画一张这个项目的架构图。前端、后端、数据库、外部服务分层画出来。每个模块写名字加一句话职责。别画实现细节服务级就够了。保存成 ./docs/architecture.svgdark 主题。这里面其实隐藏了一个非常重要的方法论不要让 AI 自由发挥而要给 AI 建立“观察边界”。 三个 Prompt 技巧让 AI 少“脑补”◇ 技巧一告诉 AI“必须读取真实文件”模块依赖图看一下我的 pom.xml画一张项目内部模块之间的依赖图。外部库不画。有循环依赖用红色标出来。保存成 ./docs/module-deps.svg。这里最关键的不是“画依赖图”。而是看一下我的 pom.xml。这句话把 AI 从“根据经验推测”变成了“基于项目事实生成”。◇ 技巧二追真实代码而不是追接口名字时序图​​​​帮我画 POST /api/prompts/create 这个接口的调用链时序图。先去 grep 真实代码从 Controller 一路追到 DB。标清楚每一步是哪个类哪个方法。保存成 ./docs/sequence-create-prompt.svg。这里有一句非常值得记住先去 grep 真实代码。因为一个接口叫/create不代表它一定经过你想象中的 Controller → Service → DAO。真正可靠的调用链必须来自源码。◇ 技巧三数据库关系必须读取 DDL 或 Entity例如看项目里的建表 SQL。画一张 ER 图。主键、外键、表之间的关系标清楚。保存成 ./docs/schema.svg。如果项目使用 JPA也可以要求 AI 读取 Entity。核心原则只有一句不要根据表名猜字段不要根据字段猜关系。 我的一个判断AI 画图本质上不是“制图”而是“知识压缩”这是这篇内容背后更值得关注的地方。一份大型 Java 项目可能有几十万行代码。但我们不可能把几十万行代码全部装进自己的工作记忆。于是我们需要不断做一件事压缩信息。代码 → 模块 → 依赖图代码 → 请求链 → 时序图数据库 → 表关系 → ER 图系统 → 服务关系 → 架构图所以架构图其实是一种“结构化摘要”。它不是把代码画出来。而是把代码中的结构关系提取出来再用人类更容易理解的视觉语言表达。这也是为什么“图”在 AI 编程时代反而越来越重要。AI 可以处理大量代码但人类仍然需要一个快速建立全局认知的入口。⚡ 工具怎么选不要迷信“一把梭”原文给出的工具策略非常实用。◇ Mermaid默认选择大多数项目的日常图都可以用 Mermaid。优势是文本化AI 容易生成修改成本低Git 可以直接管理适合项目文档GitHub、Notion、VS Code 等生态支持较好所以我更推荐把 Mermaid 当成工程师的 Markdown 图形语言。它最大的价值不是“画得多漂亮”而是可版本化、可迭代、可自动生成。◇ PlantUML复杂 UML 场景当遇到复杂类图、时序图或者 UML 表达需求时可以考虑 PlantUML。它的表达能力比较强但语法也更重。所以没有必要为了“专业”而强行使用 PlantUML。工具应该服务于问题而不是反过来让问题适应工具。◇ draw.io最终交付场景如果要把图放进PPT正式技术方案汇报材料架构评审文档draw.io 往往更合适。因此一个非常实用的工作流是Mermaid 快速生成 → AI 反复迭代 → 人工 Review → draw.io 精修 → 正式交付这比一开始就追求“完美架构图”效率高得多。 图好不好看真正决定于三个细节◇ 颜色分组同类模块使用同一色系。核心模块、外围基础设施、外部系统形成视觉区分。Mermaid 中可以通过classDef等方式统一样式。◇ 留白不要试图把所有信息塞进图里。一个节点通常一行标题 一句话职责就足够了。图应该是索引而不是百科全书。细节应该进入文档。◇ 固定方向架构图可以选择graph TD也可以选择graph LR但一个项目最好保持统一。如果今天架构图从上往下明天模块图突然从右往左阅读成本就会明显增加。 最重要的一条AI 画的图一定有错这是整个方法里我认为最值得强调的一句话AI 画的图一定有错。它可能把废弃模块当成核心模块漏掉隐藏的异步通道把数据库关系画反把重载方法误认为多个接口把历史代码和当前真实调用关系混在一起把代码中“看起来合理”的结构当成真实业务规则为什么因为AI 看到的是代码不是整个系统。老项目真正复杂的地方很多都藏在代码之外历史约定运维习惯特殊客户需求人工操作流程外部系统限制已经废弃但暂时不能删除的模块“只有老员工知道”的业务规则这些信息不会完整写在代码里。因此正确的工作模式不是AI 画图 → 结束而应该是AI 读取代码 → 生成初稿 → 人类 Review → 修正 → 存档 → 持续更新这其实和 AI 写代码的原则完全一样。AI 负责加速人负责判断。 把架构图当成“项目资产”而不是一次性图片很多团队最大的问题不是没有架构图。而是架构图画完以后就没人维护。半年后代码已经改了几十次架构图还停留在半年前。所以我更推荐一种做法把图直接放进项目的docs/目录并和代码一起进行版本管理。例如docs/├── architecture.svg├── module-deps.svg├── sequence-create-prompt.svg└── schema.svg甚至可以进一步把关键架构说明写进ARCHITECTURE.md这样新同事接手项目时不需要先读几万行代码。可以先看架构 → 看模块 → 看调用链 → 看数据模型 → 再进入代码。这其实是在建立一个非常重要的“认知入口”。 最终形成一套 AI 辅助的项目理解闭环如果把这套方法进一步抽象我认为可以形成一个非常实用的工程闭环真实代码↓AI 分析↓结构提取↓Mermaid 可视化↓人工 Review↓修正↓项目文档↓后续开发 / 重构↓再次更新这比单纯“让 AI 帮我画图”高一个层次。因为最终目标并不是得到一张漂亮图片。真正的目标是建立一套可以被 AI 读取、被人理解、被 Git 管理、能够持续演进的系统知识库。当架构图、模块依赖、接口时序、数据库关系都沉淀下来之后AI 下一次进入这个项目时也有更多上下文可以利用。于是图 → 文档 → AI 上下文 → 更准确的代码修改 → 新的图和文档形成一个不断增强的循环。 一份可以直接复用的“AI 画图检查清单”以后让 Claude Code 画图可以直接按照下面这套顺序检查是否基于真实源码生成而不是根据名称猜测是否明确了图的目标是否限制了展示粒度是否排除了无关的外围细节是否统一了方向和视觉规范是否保存到了项目docs/是否经过人工 Review是否和当前代码版本一致是否能够帮助下一位开发者快速理解系统如果这 9 个问题都能回答“是”这张图才真正具备工程价值。 写在最后给 Claude Code 安装画图 Skill表面上看只是增加了一个“小功能”。但从工程实践角度看它真正改变的是AI 理解项目和表达项目的方式。以前我们让 AI 写代码。现在我们可以进一步让 AI读代码 → 理结构 → 画关系 → 生成文档 → 接受 Review → 沉淀知识。而对于老项目改造来说这恰恰是非常关键的一步。因为真正困难的从来不是“写出一段新代码”。而是在不完全理解旧系统的情况下知道自己到底改了什么以及这个改变会影响什么。所以别把架构图当成 PPT 素材。把它当成代码之外的第二套“系统地图”。AI 帮你画第一版你负责判断它对不对判断完成之后把它留在项目里。