企业官网建设流程全解析

在日常使用 Claude Code 处理代码库分析、方案设计和技术评审时，最容易被低估的能力之一，是它对“图表”的理解与输出。很多开发者习惯让 Claude Code 直接改代码、跑测试，却忽略了它还可以把一段复杂的调用链、一个数据库模型、一份项目排期整理成结构清晰的图表，让沟通和文档效率提升一个档次。本文将围绕 Claude Code 中常用的编辑类图表类型展开，梳理每一类图表的适用场景、提示词组织方式、输出形态和最佳实践，适合正在将 Claude Code 用于项目分析和文档沉淀的开发者。

1. 为什么要在 Claude Code 中使用图表

Claude Code 是 Anthropic 推出的终端 AI 编程助手，它能够读取项目目录、理解代码结构、执行命令并直接修改文件。除了常见的“帮我实现某个功能”“修复这个 Bug”之外，Claude Code 在梳理逻辑关系和数据流向方面同样有很强的表现，而图表正是这类产出的最佳载体。

所谓“编辑类图表”，指的是在编写文档、整理方案、做技术评审和重构规划时使用的图示表达。它不必像专业设计工具画出的架构图那样精美，重点在于信息准确、层级清晰、方便评审和复用。典型的场景包括：

• 接手一个新项目时，让 Claude Code 分析模块依赖，输出一张系统分层图。
• 设计订单支付接口前，先让 Claude Code 画出用户、前端、后端、数据库之间的时序图。
• 重构核心业务代码时，用状态图梳理一个订单从创建到完成的所有状态变化。
• 编写数据库设计文档时，用实体关系图表达表与表之间的关联。
• 制定迭代计划时，用甘特图或表格化排期描述任务顺序和里程碑。

使用图表的直接好处是降低沟通成本。一段纯文字描述可能让人产生多种理解，而一张结构清晰的图示能把参与的角色、流转的顺序、分支的条件一次性讲清楚。对于代码评审、新人 onboarding 和方案汇报，图表往往比大段文字更高效。

2. 环境准备与前置条件

在深入图表类型之前，先把 Claude Code 的基础环境准备好。Claude Code 目前以命令行工具为主，安装和使用都比较直接，但对 Node.js 环境和账号权限有一定要求。

2.1 安装 Node.js 与 Claude Code

Claude Code 基于 Node.js 开发，官方推荐使用 Node.js 18 或更高版本。你可以先用下面的命令检查本机版本：

node -v npm -v

如果尚未安装 Node.js，需要先到 Node.js 官网下载对应的 LTS 版本并完成安装。确认 Node.js 环境正常后，通过 npm 全局安装 Claude Code：

npm install -g @anthropic-ai/claude-code

安装完成后，验证命令行是否可用：

claude --version

如果能输出版本号，说明安装成功。如果提示claude: command not found，通常是因为 npm 的全局 bin 目录没有加入系统 PATH，只需将 npm 全局目录配置到 PATH 中即可。

2.2 登录与账号认证

安装完成并不代表可以直接使用，Claude Code 需要完成身份认证。首次运行claude命令时，工具会引导你进行登录，通常有两种方式：

• 使用 Claude 订阅账号授权。
• 使用 Anthropic API Key，通过环境变量ANTHROPIC_API_KEY注入。

如果你所在的组织统一管理 Claude 订阅权限，可能出现“your organization has disabled claude subscription access for claude code”的提示，此时需要联系组织管理员开通权限，而不是自己尝试绕过限制。Claude Code 的可用地区以官方支持清单为准，如果命令行提示当前地区不可用，请按官方支持范围确认使用环境。

2.3 在 VS Code 中集成

除了终端原生体验，Claude Code 也提供 VS Code 扩展。你可以在扩展市场中搜索“Claude Code for VS Code”并安装。安装后，可以直接在编辑器侧边栏打开 Claude Code 面板，让 AI 读取当前工作区文件，并在同一个界面中查看改动和生成结果。

2.4 准备一个测试项目

为了让后续的图表示例更直观，建议准备一个简单的 Web 项目作为实验对象。项目不需要很复杂，只要包含前后端分层和数据库脚本即可：

demo-project/ ├── frontend/ │ └── src/ │ ├── pages/OrderPage.vue │ └── api/order.js ├── backend/ │ ├── controller/OrderController.java │ ├── service/OrderService.java │ └── repository/OrderRepository.java └── sql/ └── schema.sql

从下一节开始，我会结合这类典型项目，逐一介绍 Claude Code 中常用的图表类型。

3. Claude Code 常用编辑类图表类型全景

在 Claude Code 的对话中，可以按需要求它生成不同类型的图表。先把常见类型放在一张总览表中，方便快速定位：

下面逐类展开，每类都会给出适用的提示词思路和输出示例。需要说明的是，Claude Code 在终端中可能返回不同形式的图表，例如纯文本 ASCII 图、Markdown 表格，或在支持的环境中渲染为图形化输出。本文的示例以文本形式呈现，重点演示图表背后的逻辑结构。

4. 八类图表详解

4.1 流程图

流程图是最常用的图表类型，适合表达“一个任务经历了哪些步骤，在什么条件下走哪个分支”。

在 Claude Code 中，你可以针对具体方法或业务场景发起请求。比如：

请分析 OrderController.createOrder 方法，绘制一张创建订单的流程图，包含参数校验、库存检查、扣减库存、创建订单、发送消息这几个步骤，并标注失败分支。

Claude Code 会优先读取相关代码，提取关键逻辑，然后用可读性强的文本图输出。一个典型的流程图结果如下：

[开始] | v [接收创建订单请求] | v [参数校验是否通过] -- 否 --> [返回参数错误] | 是 v [检查商品库存] | v [库存是否充足] -- 否 --> [返回库存不足] | 是 v [扣减库存] | v [创建订单记录] | v [发送订单创建消息] | v [返回创建成功]

使用流程图时有几个建议：

• 分支数量控制在 5 到 7 个以内，太多会让图变得难以阅读。
• 每个判断节点问句要明确，例如“是否成功”“是否通过”，不要使用模糊表达。
• 如果流程涉及异常处理，主动要求 Claude Code 单独画出“异常分支”的流程，再合并到一起看。

4.2 时序图

时序图擅长表达跨系统、跨模块的调用关系，尤其是接口交互顺序。它强调的是“谁在什么时间向谁发起了什么请求”。

一个常见提示词示例：

画出用户下单到支付成功的完整时序图，参与者包括：用户、前端、后端、支付服务、数据库。

Claude Code 输出的文本时序图大致如下：

用户 前端 后端 支付服务 数据库 | | | | | | 点击下单 | | | | |--------->| | | | | | 创建订单 | | | | |-------->| | | | | | 保存订单 | | | | |---------------------->| | | | | | 返回订单ID | | 拉起支付 | | | | |<--------| | | | | | | | | 确认支付 | | | | |--------->| | | | | | 支付请求 | | | | |------------------->| | | | | | 支付结果回调| | | |<----------------------| | | 查询订单 | | | | |-------->| | | | | 更新状态 | | | | | |---------------------->| | | | | | 返回更新结果 | 显示成功 | | | | |<---------| | | |

时序图适合在开发接口前做设计评审，或者在排查线上问题时梳理调用链。推荐的提示词套路是明确列出“参与者”和“关键动作点”，并告诉 Claude Code 要画出返回路径。这样生成的时序图会比默认输出完整很多。

4.3 类图

类图用于展示类、接口和它们之间的关系，包括继承、实现、聚合、关联等。Claude Code 分析 Java、Python 等面向对象项目时，可以用类图快速反映模块结构。

示例提示词：

阅读 backend 目录下的核心类，输出一张订单模块的类图，标注 User、Order、OrderItem、OrderService 之间的关联关系。

一个简化示例：

+----------------+ +----------------+ | User | | Order | +----------------+ +----------------+ | - id: Long | 1 1 | - id: Long | | - name: String |----------| - userId: Long | | - email: String| | - status: int | +----------------+ | - amount: BigDecimal | +----------------+ | | 1 | +----------------+ | OrderItem | +----------------+ | - id: Long | | - orderId: Long| | - productId: Long | +----------------+ OrderService ..> UserRepository OrderService ..> OrderRepository

类图对重构决策很有帮助。当你犹豫“某个 Service 是否职责过重”“两个类是否应该拆开”时，先让 Claude Code 生成一张类图，再结合关系数量判断耦合程度，会比盲改代码稳妥得多。

4.4 状态图

状态图非常适合表达一个对象从创建到结束的完整生命周期。订单、审批单、任务、设备等都适合用状态图描述。

典型提示词：

梳理订单状态机，状态包括：待支付、已支付、已发货、已完成、已取消、退款中、已退款。绘制状态图并标注触发条件。

示例输出：

[*] ----------> 待支付 待支付 ------> 已支付 : 用户支付成功 待支付 ------> 已取消 : 用户取消 / 超时关闭 已支付 ------> 已发货 : 商家发货 已支付 ------> 退款中 : 用户申请退款 已发货 ------> 已完成 : 用户确认收货 已发货 ------> 退款中 : 用户申请售后 退款中 ------> 已退款 : 退款完成 已退款 ------> [*] 已完成 ------> [*] 已取消 ------> [*]

状态图的价值在于把“非法状态变化”一目了然地暴露出来。你可以在生成状态图后追问一句：“有没有代码中存在但状态图中没有覆盖的状态迁移？”往往能发现一些隐藏分支或历史遗留逻辑。

4.5 实体关系图

实体关系图（ER 图）用于表达数据库表、字段和表之间的关系。做数据库设计或评审时非常实用。

示例提示词：

读取 sql/schema.sql，绘制订单模块的实体关系图，标出主键、外键和一对多关系。

示例输出：

USER ------ id BIGINT PK name VARCHAR email VARCHAR ORDER ------ id BIGINT PK user_id BIGINT FK -> USER.id status INT amount DECIMAL ORDER_ITEM ----------- id BIGINT PK order_id BIGINT FK -> ORDER.id product_id BIGINT FK -> PRODUCT.id quantity INT price DECIMAL PRODUCT ------- id BIGINT PK name VARCHAR stock INT USER 1 --- N ORDER ORDER 1 --- N ORDER_ITEM PRODUCT 1 --- N ORDER_ITEM

ER 图的关键在于字段和关系都必须来源于表结构本身。如果 Claude Code 产出的字段和你的建表脚本不一致，多半是因为它只扫描了部分文件，此时可以明确指定表名或文件路径。

4.6 甘特图

甘特图用于项目排期和进度管理，可以表达任务的开始时间、持续时间和依赖关系。Claude Code 无法像专业项目管理软件那样动态拖拽，但可以基于你的描述生成结构化的排期文本。

示例提示词：

帮我制定一个 3 周迭代计划，包含需求评审、开发、联调、测试、发布五个阶段，开发阶段需要依赖需求评审完成，测试依赖开发完成，请用甘特图形式输出。

示例输出：

迭代计划：3 周 ------------------------------- 阶段 开始 结束 耗时 ------------------------------- 需求评审 第1周周一 第1周周二 2天 开发 第1周周三 第2周周五 10天 联调 第2周周一 第2周周五 5天 测试 第3周周一 第3周周三 3天 发布 第3周周四 第3周周五 2天 ------------------------------- 依赖关系： 开发 -> 需求评审 联调 -> 开发（部分并行） 测试 -> 联调 发布 -> 测试

由于甘特图涉及时间信息，提示时最好给出明确的迭代长度和关键里程碑。如果项目里没有现成时间数据，Claude Code 会基于通用经验估算，最终排期仍需要人工确认。

4.7 思维导图

思维导图适合整理发散信息。比如梳理一个新需求的影响范围、整理微服务拆分方案、归类项目知识，都可以让 Claude Code 输出树状思维导图。

示例提示词：

基于当前电商项目的代码结构，整理一份领域模块思维导图，从前端、后端、数据库、消息队列四个维度展开。

示例输出：

电商项目 ├── 前端 │ ├── 商品模块 │ │ └── 商品列表、商品详情 │ ├── 订单模块 │ │ └── 购物车、订单确认、支付 │ └── 用户模块 │ └── 登录、注册、个人信息 ├── 后端 │ ├── 商品服务 │ ├── 订单服务 │ ├── 用户服务 │ └── 支付服务 ├── 数据库 │ ├── MySQL │ │ ├── product 库 │ │ ├── order 库 │ │ └── user 库 │ └── Redis │ ├── 商品缓存 │ └── 会话缓存 └── 消息队列 ├── 订单创建消息 ├── 支付结果消息 └── 库存扣减消息

思维导图的特点是层级感强，适合用列表形式呈现，也便于复制到文档中继续编辑。你还可以要求“展开到具体类或方法级别”，从而得到一张更加细粒度的项目知识图。

4.8 表格与矩阵

表格和矩阵不属于传统图形图表，但在编辑场景中应用频率极高。比如技术选型、权限矩阵、版本功能对比，用表格呈现远比图形清晰。

示例提示词：

用矩阵表格对比 Spring Boot 和 Node.js 在订单模块开发中的差异，维度包括：开发效率、团队上手成本、性能表现、生态成熟度、维护成本。

示例输出：

表格类输出非常适合直接粘贴到 PR 描述或技术方案文档中。当你需要 Claude Code 给出“是否适合某个场景”的判断时，要求它先输出对比矩阵，再基于矩阵给出建议，效果会比让它直接下结论更可靠。

5. 实战：让 Claude Code 输出项目架构图

下面通过一个完整案例，演示如何用 Claude Code 从零生成一份项目架构文档。整个过程分为三步：先理解项目结构，再梳理模块关系，最后输出分层架构图。

5.1 让 Claude Code 读取项目结构

在项目根目录启动 Claude Code，输入：

请查看当前项目的目录结构和关键配置文件，汇总项目的技术栈、模块划分和主要入口。

Claude Code 会列出目录树并读取关键文件。你可以在它的分析基础上补充一句：

用树状图展示 backend 模块下 controller、service、repository、entity 四层之间的依赖关系。

输出示例：

OrderController | v OrderService | v OrderRepository | v OrderEntity

5.2 让 Claude Code 梳理模块关系

继续输入：

结合以上分层关系，绘制一张订单模块的架构图，包含 Web 层、Service 层、Repository 层、基础设施层（MySQL、Redis、MQ）。

Claude Code 可能返回类似下面的分层结构：

[前端] | | HTTP v +-----------------------+ | Web 层 | | OrderController | +-----------------------+ | | 业务调用 v +-----------------------+ | Service 层 | | OrderService | | OrderStateMachine | +-----------------------+ | | 数据访问 / 消息发送 v +-----------------------+ | Repository 层 | | OrderRepository | +-----------------------+ | | JDBC / Redis / MQ v +-----------------------+ | 基础设施层 | | MySQL | Redis | MQ | +-----------------------+

5.3 把图表写入项目文档

拿到满意结果后，可以让 Claude Code 直接把图表写入 README 或 docs 目录：

将上面的架构图整理成 Markdown 格式，写入 docs/architecture.md，在图中加入当前日期和版本号。

Claude Code 会创建或更新文件。此时再打开docs/architecture.md，就能看到一份结构化的架构文档。后续项目发生调整时，可以继续让 Claude Code 基于最新代码重新生成并对比差异。

6. 用 CLAUDE.md 沉淀图表约定

Claude Code 在读取项目时，会重点关注项目根目录下的CLAUDE.md文件。这个文件相当于项目的“AI 使用说明”，你可以把图表相关的约定写进去，让后续每一轮对话都遵守同样的输出规范。

一个示例片段：

# 图表规范 - 技术方案讨论时，优先输出 Mermaid 或文本结构图。 - 架构分析统一使用“分层图 + 依赖说明”格式。 - 数据库设计统一使用实体关系说明，字段必须来自 sql 目录。 - 排期类内容使用表格化甘特图，包含具体开始和结束时间。 - 所有图表输出后必须附带关键结论，避免只给图不给解释。

将图表规范写入CLAUDE.md后，Claude Code 在后续对话中会更稳定地按照你的预期输出，而不是每次都要重新强调格式要求。这对团队协作尤其重要，新人开箱即用，AI 产出的文档风格也能保持统一。

7. 常见问题与排查思路

在安装和使用 Claude Code 生成图表的过程中，可能会遇到一些典型问题。下面整理成表格，方便对照排查。

遇到图表输出不符合预期时，优先检查提示词是否足够具体。一个笼统的“画个架构图”往往得不到理想结果，而“画出从 OrderController 到 OrderRepository 的分层依赖图”会好很多。

8. 最佳实践与工程建议

8.1 依据问题选择图表类型

图表不是越多越好，选择的关键在于当前要解决什么问题：

• 要说明处理步骤，用流程图。
• 要说明跨系统交互，用时序图。
• 要说明对象关系，用类图或 ER 图。
• 要说明生命周期，用状态图。
• 要说明时间安排，用甘特图。
• 要说明层级分类，用思维导图或树状图。
• 要说明多维对比，用表格矩阵。

如果拿不准，可以让 Claude Code 自己判断：“我现在的目标是分析订单模块的代码结构，你推荐用哪种图表类型？为什么？”它会给出建议，并直接生成初稿。

8.2 设计高质量提示词

生成图表的提示词可以遵循三分法：

1. 明确阅读对象：指定文件、目录、方法。
2. 明确图表目标：画出什么关系，表达什么流程。
3. 明确输出约束：包含哪些角色、分支、字段，用什么格式。

例如：

读取 backend/src/main/java/com/demo/order 下的代码，绘制 OrderService.createOrder 的时序图，包含 controller、service、repository、entity 四层，重点标注事务提交和异常回滚的路径，输出为文本时序图。

这样的提示词比“分析一下订单模块”清晰得多，产出的结果也更贴近业务实际。

8.3 让图表成为项目文档的一部分

单次生成的图表如果没有沉淀，价值会大打折扣。建议在每次生成图表后，让 Claude Code 把结果同步到 README 或 docs 目录。图表所在位置尽量固定，例如统一放到docs/diagrams/，这样后续更新时能快速定位。

图表也是一种需要维护的“代码”，当业务逻辑变化时，旧的架构图、状态图很容易失真。定期让 Claude Code 基于最新代码重新生成图表，并和已有文档做差异对比，可以避免文档和真实实现逐步脱节。

8.4 保持安全与最小权限意识

在让 Claude Code 分析项目时，避免在提示词中粘贴数据库密码、API Key、私有证书等敏感信息。Claude Code 确实能处理大量代码，但遵循最小权限原则，只开放当前任务需要的目录和文件，能降低信息暴露风险。生产环境的变更，应在测试环境验证后再执行，涉及数据库修改时提前做好备份。

9. 总结

本文围绕 Claude Code 的编辑类图表类型，从流程图、时序图、类图、状态图、ER 图、甘特图、思维导图到表格矩阵，逐类梳理了适用场景、提示词思路和输出示例。通过一个订单模块的实战案例，演示了如何让 Claude Code 从项目结构分析一路生成到架构文档，也补充了 CLAUDE.md 规范、常见问题排查和工程实践建议。

值得记住的核心要点是：Claude Code 是一款能力很强的 AI 编程工具，但图表质量高度依赖提示词的具体程度。阅读范围越明确、角色越清晰、输出约束越具体，得到的图表就越有价值。建议你找一个熟悉的项目，按照本文的提示词模板，分别尝试生成流程图、时序图、类图和 ER 图，再逐步沉淀到自己团队的文档体系中。图表看似只是开发流程中的辅助产出，但在减少沟通误解、加快方案评审、降低新成员上手成本方面，它的作用往往被严重低估。