企业官网建设流程全解析

目录

💡 为什么给 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 不应该被理解成一个固定能力的聊天机器人，而应该被理解成一个可以持续扩展的工作平台。

今天安装画图 Skill，AI 多了一种表达系统的方法。

以后安装数据库分析 Skill、测试 Skill、代码审查 Skill，它就多了一种工程能力。

这和传统软件生态中的 package、plugin、extension，本质上非常接近。

🛠️ Claude Code 的画图能力应该怎么装？

原文推荐的方案是claude-mermaid。

第一步，安装负责实际渲染的 Node 程序：建议先确认 Node 版本：

node -v

Node 需要 20 或更高版本。

第二步，在 Claude Code 中安装对应 Plugin：

/plugin marketplace add veelenga/claude-mermaid/plugin install claude-mermaid@claude-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.svg，dark 主题。

这里面其实隐藏了一个非常重要的方法论：

不要让 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 帮你画第一版，你负责判断它对不对；判断完成之后，把它留在项目里。