架构设计这件事，很多团队不是不会做，而是做得“不可见”：方案讨论完就散会，选型凭经验，评审走过场，等代码写出来才发现边界没划清。架构设计技能不是某一个开源工具，也不只是画几张架构图，它是一套能把设计过程结构化、可执行、可验收的能力框架。有了这套技能，架构设计不再依赖某个人“资历深”，而是每个团队都能复制、都能评审、都能在项目里持续改进。
这篇内容会围绕架构设计技能的核心能力、落地流程、评审验收、与AI工具结合、常见坑和最佳实践展开。如果你正在做系统设计、准备技术选型、组建新团队，或者准备把架构设计能力交给AI助手，这篇可以直接收藏。
1. 架构设计技能核心能力速览
架构设计技能并不是某一个软件包，而是一组方法和产出物的集合。把它当作技能来看，优点是可以重复使用、可以培训、可以写到团队规范里。
| 能力项 | 说明 |
|---|---|
| 技能类型 | 系统设计方法论 + 工程实践框架 |
| 核心目标 | 把模糊的业务需求转化为可落地的技术方案 |
| 主要产出物 | 架构设计文档、架构决策记录、领域模型、接口定义、评审报告 |
| 常用方法 | 领域建模、质量属性分析、技术选型、架构评审、演进规划 |
| 是否依赖GPU/CPU | 不依赖，过程主要由工程师和评审环境完成 |
| 是否支持AI辅助 | 支持，可把技能流程封装为提示词或Agent技能包 |
| 是否支持批量任务 | 支持，同一套流程可复用到多个子系统的设计评审 |
| 适合场景 | 新系统设计、模块重构、技术选型、系统间集成、AI辅助代码生成前的结构设计 |
| 不适合场景 | 没有业务输入时强行设计、为评审而评审、过度设计 |
从能力表可以看到，架构设计技能的核心是“过程中有方法、结果可验证”。它不像写代码那样有明确的编译期错误，但它可以通过评审问题和验收清单来发现设计缺陷，这一点在后面的章节会具体说明。
2. 适用场景与使用边界
架构设计技能适合三类人：第一类是开发工程师，希望在动手编码前想清楚模块边界和依赖关系；第二类是技术负责人或架构师，需要把团队的设计能力标准化，让评审不是走过场；第三类是使用AI辅助开发的团队，需要把架构设计流程变成可复用的提示词，让AI在生成代码前先产出结构设计。
用这套技能能解决的核心问题包括：需求方和技术团队对系统范围理解不一致；技术选型缺少决策依据；模块边界模糊导致后续维护成本高；系统上线后出现性能、可用性、安全问题却找不到设计源头；AI生成的代码没有结构约束，局部看起来合理，整体却是散装的。
这套技能也有明确的边界。不要在没有业务输入的情况下套模板，比如只知道一个系统名称就开始画架构图，这种设计最后一定是空架子。不要为了追求“完整”而把架构设计做成一堆没人看的文档，设计一定要对应可执行的决策。不要用架构设计替代详细设计，架构层解决的是边界、选型和关键约束，不是把每个类的字段都定义完。也不要过度设计，业务早期阶段没必要引入微服务、事件驱动、多级缓存等重型方案，能用单体解决的不要先拆。
涉及企业内部的架构方案、核心代码结构、客户数据模型时，要把这些内容当作敏感信息管理。设计文档建议在内网、受限知识库或私有仓库中存放，不要随意复制到公开平台。给AI辅助工具提交需求时，先做脱敏处理，去掉真实的客户名、密钥、服务地址和业务敏感字段。
3. 环境准备与前置条件
架构设计技能虽然不依赖特定硬件，但它需要一套相对完整的“输入环境”。如果输入材料不齐，设计过程就会变成反复猜测。
3.1 输入材料准备
开始设计前，至少确认以下材料是否齐全：
- 业务需求文档或用户访谈记录，确认要解决的问题是什么。
- 关键约束清单，包括预算、时间、团队规模、技术栈限制。
- 现有系统状况，如果是重构，需要了解旧系统结构、数据量、接口情况。
- 非功能要求，例如并发量、响应时间、可用性目标、数据保留周期。
- 组织边界，例如哪些团队维护哪些模块，未来是否会拆分。
这些材料不要求全部是正式文档，哪怕是会议纪要、问题列表也行。关键是要有确定的输入，而不是在真空中做设计。
3.2 工具链选择
架构设计的工具链不复杂，推荐一套轻量组合：
- 文本记录：使用Markdown或任意笔记工具，用于需求澄清和决策记录。
- 架构图绘制：使用PlantUML、draw.io、Excalidraw等工具，绘图优先表达关系而不是追求美观。
- 设计文档仓库：推荐使用Git管理，让架构文档和代码一起走版本变更，评审也能看差异。
- 评审环境：使用在线文档评论功能或代码仓库的MR评审功能，给每条设计决策留下讨论记录。
这里给一个PlantUML示例，用于画系统上下文图，明确系统与外部角色之间的边界。
@startuml left to right direction actor "用户" as User actor "运营人员" as Operator rectangle "核心系统" { usecase "提交订单" as UC1 usecase "审核内容" as UC2 } User --> UC1 Operator --> UC2 @enduml这是一个非常简单的上下文图，作用是让团队在第一时间确认：谁在使用系统，系统对外提供哪些能力，哪些事情系统内部做，哪些事情依赖外部系统。这张图画清楚，后面模块划分会顺利很多。
3.3 判断标准提前定义
在动笔设计之前，先定义“什么样的设计算成功”。推荐给架构设计设置3到5个明确的目标，例如：
- 支持当前业务规模，并预留未来半年到一年的演进空间。
- 模块边界清晰，每个模块有明确负责人。
- 关键路径上的性能能满足业务预期。
- 设计决策都有记录，出现问题可以回溯。
- 团队评审通过，而不是一个人拍板。
这组判断标准要写进设计文档开头，作为验收纲要。没有验收标准的设计，讨论起来永远是各说各话。
4. 架构设计落地流程
架构设计技能的落地过程可以拆成六个阶段：需求澄清与约束盘点、领域建模与系统边界、技术选型与决策记录、架构视图输出、质量属性权衡、演进规划。每个阶段都有输入、操作、产出和验收方式。
4.1 需求澄清与约束盘点
设计的第一步不是画图，而是把问题本身搞清楚。很多架构方案失败，不是因为技术方案差，而是因为设计者没有识别出真正需要解决的业务问题。
这个阶段做三件事：
- 与需求方逐条确认关键业务场景，包括主流程、异常流程、用户角色。
- 列出所有非功能约束，例如预算、交付时间、可用性要求、合规要求。
- 区分“当前必须做”和“将来可能做”，避免把未来假设当成当前需求。
操作方式建议采用访谈加问题清单的模式，例如：“这个系统最核心的指标是什么？”“如果某个依赖服务不可用，业务可以接受吗？”“数据量按什么增长速度估算？”
阶段产出是一份《需求与约束清单》，包含关键场景、非功能指标、风险假设。验收方式是团队能回答“这个系统为什么要做，做到什么程度算成功”。
4.2 领域建模与系统边界
领域建模是把业务语言翻译成技术语言的过程。推荐先画一张系统上下文图，标注出系统、外部系统和角色，再拆分为限界上下文。
具体步骤：
- 识别核心业务对象，例如订单、用户、内容、设备。
- 确认每个对象属于哪个上下文，避免一个“用户”概念在不同模块里含义不一致。
- 划出模块边界，明确模块间是同步调用、异步消息，还是共享数据源。
- 标注出口和入口，确定每个模块对外暴露哪些接口。
这里最容易犯的错是把数据库表设计直接当作领域模型。领域模型关注业务规则和对象关系，数据库设计是另一个层面的问题。建模阶段先不要纠结字段，先把实体关系和边界定义清楚。
阶段产出是一份领域模型说明，可以包含一页核心实体关系图和各模块职责描述。验收方式是每个模块都能用一两句话说清“自己负责什么、不负责什么”。
4.3 技术选型与决策记录
技术选型是架构设计里最容易引发争论的环节。避免争论的方法是建立选型标准，而不是一上来比“哪个技术更好”。
推荐按以下维度打分：
- 团队熟悉度。
- 社区活跃度和维护情况。
- 与现有技术栈的集成成本。
- 在目标规模和负载下的表现。
- 许可证和商用限制。
- 招聘成本。
每一项根据项目情况设置权重，打分结果出来了再讨论。选型结果必须写成架构决策记录，格式可以简化成：背景、决策、理由、替代方案、后果。这里给出一个Markdown模板。
# ADR-001: 消息中间件选型 ## 背景 订单模块与库存模块需要异步解耦，当前系统没有消息中间件。 ## 决策 采用 RabbitMQ，理由为团队已有运维经验，支持延迟队列，满足当前业务规模。 ## 替代方案 - Kafka：吞吐量大，但运维成本高，当前业务规模用不上。 - 数据库表轮询：实现简单，但会造成数据库压力，且延迟不可控。 ## 后果 - 正：架构简单，团队上手快。 - 负：未来如果业务量高速增长，可能要考虑迁移到吞吐能力更强的方案。写好架构决策记录之后，后续即使选错了也能看到当时的判断依据，复盘效率会高很多。
4.4 架构视图输出
架构设计不是一张图，而是多视角的视图集合。至少要保证四类视图：
- 系统上下文视图：系统与外部角色、外部系统的关系。
- 容器视图:应用层、服务层、数据存储的部署结构。
- 组件视图：单个服务内部如何拆分为组件，组件间依赖关系。
- 部署视图：生产环境、测试环境的网络拓扑和服务实例形态。
很多团队只画一张“模块图”，没有部署视图，结果设计评审通过后，运维不知道要开几台机器、开放哪些端口。建议把四类视图固定为设计文档标准章节，缺失任何一个视图都视为评审不通过。
绘图时注意：用明确的连线表示调用关系，标清方向；不要让图包含过多嵌套细节；每次修改都保留版本记录。
阶段产出是架构设计文档，包含上述四类视图和对应说明。验收方式是让一个不熟悉项目背景的开发人员读文档，能画出系统的部署结构和模块依赖。
4.5 质量属性权衡
架构设计里没有“绝对好”，只有“在特定约束下最合适”。质量属性分析就是为了把这种权衡放到台面上。
重点分析四类质量属性：
- 性能：响应时间、吞吐量、延迟。
- 可用性：SLA目标、故障恢复时间、降级方案。
- 安全性：认证方式、数据加密、权限模型。
- 可维护性：模块耦合度、测试成本、文档对齐成本。
针对每个属性，明确“可以接受的下限”和“期望达到的目标”。例如性能目标可以是“核心接口P99延迟小于300毫秒”，可用性目标可以是“月度可用性99.9%”。没有量化目标，质量属性就是空谈。
当两个质量属性冲突时，比如安全校验过多拖慢性能，要明确优先级。优先级也应该记录在架构决策记录中，避免后续开发时反复横跳。
4.6 演进规划与反脆弱设计
架构设计要承认一件事：需求会变，技术会更新，团队会调整。所以演进规划不是可选项，而是必选项。
演进规划包括：
- 预留扩展点，例如插件机制、接口抽象、异步消息边界。
- 明确哪些模块未来可能拆分，提前治理依赖方向。
- 设计拆除成本，让任何一块设计都可以在必要时被替换。
- 定义技术债清单，记录当前为了上线而做出的妥协。
反脆弱设计不是把系统做得无限复杂，而是在关键路径上给不确定性留空间：依赖外部接口时设置超时和熔断，数据量不确定时先做强约束校验和分页查询，团队规模变化时保持模块所有权清晰。这些设计动作会让系统在后续演进中更稳。
5. 架构设计技能验收与效果验证
架构设计有没有做好，不能只看文档页数。建议用一张评审检查清单来验收。
5.1 设计验收问题集
评审架构设计时，重点问下面这些问题：
- 系统目标和范围是否写清楚，所有参与人能复述一致。
- 模块边界是否明确，每个模块是否存在多个负责人，或者有没有人负责的“孤儿模块”。
- 关键依赖是否标注，外部服务不可用时的降级方案是什么。
- 技术选型是否有决策记录，替代方案是否列出。
- 数据存储方案是否说明数据量预估和增长策略。
- 性能、可用性、安全目标是否量化。
- 部署运维方案是否明确，是否包含了环境配置和发布策略。
- 未来演进方向是否说明，哪些扩展点是有意预留的。
评审时把这些问题的结论填进检查单，未通过的问题必须给出整改时间和责任人。
5.2 评审会议怎么组织
架构评审会议不需要追求人多。建议参与人员控制在5到8人，包含：需求方代表、开发负责人、主要模块开发、运维或部署负责人、一位不在项目内的第三方评审人。
评审流程按顺序走：先由设计人花15分钟讲背景和范围，再花20分钟讲关键决策和权衡，然后进入提问环节。提问环节规定只能提“设计是否能满足约束、边界是否清晰”这类问题，不予许在评审会上临场讨论具体实现细节。会后输出评审结论：通过、有条件通过、不通过。
有条件通过时，需要明确修改点，修改完成后由评审人复核。这样能保证评审不是走过场。
下面是一份可复制的评审检查清单YAML示例。
architecture_review: scope: - "系统目标和范围是否清晰" - "关键业务场景是否覆盖主流程和异常流程" modules: - "模块职责是否单一" - "模块间依赖方向是否清晰" - "是否存在孤儿模块或重复模块" decisions: - "技术选型是否有决策记录" - "每个决策是否有替代方案" - "决策后果是否包含正向和负向影响" quality: - "性能目标是否量化" - "可用性目标是否量化" - "安全边界是否明确" operation: - "部署视图是否存在" - "异常降级方案是否设计" - "监控指标是否定义" evolution: - "扩展点是否明确" - "技术债是否记录" - "未来可能拆分的模块是否标注"将这份YAML放入评审文档目录，每次评审都对照执行。执行几次后可以裁剪出适合当前团队的版本，不用事事都套完整模板。
5.3 最小可行架构验证
设计通过评审后，建议先用最小可行架构验证关键风险，而不是直接铺开所有模块。小步走的好处是：如果设计中的关键假设错了，早发现早调整。
验证方法包括：
- 编写一个最小集成测试，把核心接口串起来跑通。
- 对高并发场景做小规模压测，验证选型是否满足预估。
- 用一个“探针页面”验证前端到后端的完整链路。
- 在评审后一周内留下一次架构复盘时间，反馈实际开发中遇到的问题。
这里的“验证”不是单元测试层面的验证，而是验证架构层面的决策。比如选了消息队列，就验证消息是否可以正确生产和消费；选了某一数据库，就验证连接数在目标并发下的表现。
6. 把架构设计技能封装成可复用AI技能包
基于AI辅助开发越来越普遍的背景，架构设计技能也可以沉淀成一套可复用的提示词技能包。这样做的好处是，每次让AI生成代码前，先让AI输出一个结构约束，然后基于这个约束再生成代码，可避免“AI生成局部代码很难维护”的典型问题。
架构设计技能包的核心是定义一套角色和约束：
- 角色：系统架构师。
- 输入：业务需求、关键约束、非功能指标。
- 输出：架构设计说明、模块划分、接口定义、技术选型建议。
- 过程约束：先输出设计，再输出代码；不跳过边界分析；不编造第三方服务细节。
下面是一份可以直接套用的AI提示词模板。
你是一名系统架构师。我将提供业务需求和约束，请先完成架构设计，再等我的指令编写代码。 要求： 1. 先输出系统上下文说明，确认系统边界和外部依赖。 2. 再输出模块划分，每个模块需要给出职责和核心接口。 3. 技术选型要说明理由和替代方案，不要直接给出结论。 4. 明确非功能指标，包括性能预估、可用性目标、安全约束。 5. 如果需求信息不足，先列出需要补充的问题，不要自行假设。 本轮输入： - 业务需求：<在这里粘贴需求> - 技术栈约束：<例如：Java为主，已有MySQL> - 部署约束：<例如：单机起步，未来可能容器化>使用这份提示词时，需要特别强调“需求信息不足时先提问”。因为AI容易补全缺失信息，让AI自行假设会导致架构设计与真实业务脱节。
使用AI辅助架构设计有明确的边界：AI可以帮助生成候选方案、梳理列表、起草文档，但不能替代架构评审，也不能自动决策关键选型。凡是涉及预算、团队能力、数据合规的决策，都要由人工完成。AI生成的架构还需要检查是否引用了不存在的依赖、是否夸大了某项技术的能力、是否忽略了部署运维成本。
7. 时间成本与设计投入观察
架构设计技能本身不消耗GPU和显存，不需要观察内存占用。但投入的时间成本和设计质量是值得关注的。一个典型的中小型系统，预期的时间分配可以参考下面这个表格。
| 设计阶段 | 建议投入占比 | 主要任务 |
|---|---|---|
| 需求澄清与约束盘点 | 15% | 访谈、问题清单、范围确认 |
| 领域建模与系统边界 | 25% | 实体识别、模块划分、接口定义 |
| 技术选型与决策记录 | 20% | 选型评估、方案对比、ADR编写 |
| 架构视图输出 | 20% | 上下文图、容器视图、部署视图 |
| 质量属性权衡 | 10% | 性能、可用性、安全性分析 |
| 评审与修订 | 10% | 评审会、问题整改、二次复核 |
这个比例说明，真正的架构设计大头在“建模”和“选型”，画图只占一部分。如果团队发现画图时间占比过高，而建模讨论很少，说明流程出了问题。
架构设计阶段需要重点观察的指标包括：
- 设计周期：从需求确认到评审通过用了多久，超时说明输入材料不齐或范围失控。
- 评审轮次：一次通过和有条件通过的比例。全部一次通过说明可能评审标准太松，频繁不通过说明前期设计输入不足。
- 需求变更次数：设计完成后需求还在大幅改动，说明需求澄清做得不够。
- 技术债记录数量：完全没有任何技术债记录不一定是好事，可能只是团队没敢说实话。
避免架构设计阶段无限拉长，可以采用“时间盒”策略：为每个阶段设置明确截止时间，到点先输出当前版本的结论，保留未决问题清单，下一轮迭代再补充。设计文档也遵循“先完成再完善”原则，不要一开始追求完美。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 设计文档写完没人执行 | 设计过程未纳入团队工作流 | 检查评审是否闭环、有无责任人 | 将设计文档与开发任务关联，每条决策落实到TBD |
| 模块边界反复调整 | 需求本身不清晰或未做领域建模 | 复盘需求澄清过程，检查上下文图 | 先补领域建模，再谈模块拆分 |
| 技术选型争论不休 | 缺少统一的选型标准 | 检查是否有评分维度和ADR | 建立评分表，按权重对比，避免口头争论 |
| 评审会流于形式 | 评审人员不熟悉设计背景或时间不足 | 检查评审材料是否有提前阅读环节 | 提前48小时发材料，评审会只讨论关键问题 |
| AI输出的架构方案不可用 | 提示词缺少约束，AI自行补全假设 | 检查提醒词是否要求先提问 | 增加“信息不足先提问”的步骤，并补充项目约束 |
| 需求频繁变更影响设计 | 范围管理缺失 | 检查需求澄清阶段是否覆盖主流程和异常流程 | 明确MVP范围，将非核心需求放入演进规划 |
| 架构设计时间过长 | 过度追求完美或输入材料不足 | 检查各阶段时间占比 | 设置时间盒，先输出版本再迭代 |
| 部署视图缺失 | 设计流程未包含运维视角 | 检查文档章节是否覆盖四类视图 | 把部署视图设为文档标准章节 |
| 系统上线后出现设计层问题 | 质量属性未被量化 | 检查是否有可量化的性能、可用性目标 | 补充分布式环境下的性能与可用性指标验证 |
| 技术栈选型上线后才发现不合适 | 选型时只关注功能没有验证 | 检查是否做了最小可行验证 | 在正式开发前先建最小验证工程 |
排查原则很简单：先看输入材料齐不齐，再看过程是否走了正规流程，最后才看具体技术选型。绝大多数架构设计问题都输在流程的前半段。
9. 最佳实践与使用建议
架构设计技能要真正生效，建议把它沉淀成团队自己的规范，而不是停留在个人能力。以下几条实践可以直接落地。
把设计文档纳入代码评审流程。架构设计文档和建议系统代码放在同一个仓库，或者建立明确的文档目录。技术选型、模块边界、接口定义的变化都要走评审和版本记录，不能只在聊天记录里讨论。
先写ADR再写代码。遇到“要不要引入Redis”“用不用消息队列”这类问题，先写出一个简单的架构决策记录，说明背景、决策、替代方案、后果。写完再动手写代码，这样每次决策都是明确、可追溯的。
给团队准备一个最小评审清单。不需要完整的架构评审模板，先把最关键的10个问题定下来。每次新模块设计，至少过一遍这10个问题。把清单放在项目README里，或者做成评审模板，降低使用成本。
对AI辅助产出做强制复核。如果使用AI生成架构设计或代码结构，必须增加复核问题：“这里是否有虚构依赖？”“这个选型在当前规模下是否合理？”“是否考虑了部署成本和维护成本？”由具有项目经验的工程师做最终确认。
不要跳过最小可行验证。架构设计通过评审后，先做一个最小规模的验证工程，跑通关键链路。验证不通过就回到设计阶段调整，不要带着风险硬开发。
涉及用户数据、商业逻辑、密钥和内部基础设施的架构内容，在文档和AI工具中使用前必须脱敏。公开写作、技术分享、开源示例一律使用抽象的示例名称。涉及人脸、声音、版权素材的生成或处理类系统，在设计阶段就要加入授权确认和合规边界，避免后续使用风险。
设计过程要留下复盘机制。建议每个迭代结束时用30分钟做一个轻量复盘：这次设计的哪条决策验证成功，哪条假设被推翻，哪些模块边界下次可以调整。复盘的结论写进技术债记录或ADR补充说明里。
10. 总结与下一步
架构设计技能最值得尝试的点，是它把架构设计从“个人经验驱动”变成“流程与清单驱动”。不需要等到大项目再实践，从下一个模块设计开始，就可以使用这套思路：先澄清需求，再画边界，然后写决策记录，最后用评审清单验收。
建议最先验证的三个动作是：第一，动手写一份包含背景、决策、替代方案、后果的ADR；第二，给团队建立一个最小架构评审清单；第三，如果使用AI辅助开发，把6.2节的提示词模板保存下来，下一次做设计时用起来。
最容易踩的坑有两个：一个是把画图当成设计，流程走完了却没有决策记录，等于没有设计；另一个是让AI自由发挥，没有给AI约束和提问机制，生成的结果看起来完整，实际无法落地。
下一步可以沿着三个方向扩展这套技能：一是针对具体行业做裁剪，比如Web应用开发、数据平台建设、微服务治理，分别沉淀一套评审模板；二是建立团队内部的架构案例库，把历史和当前系统设计的重要决策留存下来，新员工可以快速对齐；三是把架构设计技能与工程效能工具集成，在CI流水线中加入设计文档完整性检查，让“结构先于代码”成为团队默认工作方式。架构设计从来不是一次性的产出，而是每一个项目里持续使用的可复用能力。
建议收藏备用，下一次做系统设计时，直接按这份流程走一遍。
