从功能列表到SVG架构图：一份给开发者的DeepSeek提示词编写指南
在软件开发的生命周期中，系统架构图是沟通技术方案的核心载体。传统的手工绘制方式不仅耗时费力，更难以应对频繁的需求变更。DeepSeek的出现为这一痛点提供了智能化的解决方案——但要让AI真正理解你的架构意图，关键在于提示词的设计艺术。
我曾在一个微服务改造项目中，尝试用DeepSeek生成初始架构图。第一次输出的结果虽然美观，却把消息队列画在了数据库层，暴露出AI对技术栈层级的理解偏差。经过五轮提示词迭代，最终获得的SVG不仅准确反映了服务边界，还自动标注了各组件通信协议。这个案例让我深刻意识到：好的提示词如同精准的施工图纸，能引导AI建造出符合预期的技术蓝图。
1. 提示词设计的四大核心维度
1.1 角色设定：建立专业对话语境
无效的提示词往往始于模糊的角色定位。试试对比这两种开场：
- 普通版："画个架构图"
- 进阶版："你是一位拥有10年经验的系统架构师，正在为电商平台设计秒杀系统架构。需要将以下功能模块..."
后者通过角色+场景+目标的三角定位，立即将AI的响应质量提升到专业层级。我在实践中总结出三个关键要素：
- 专业身份：明确AI的虚拟角色（云架构师/DevOps专家等）
- 业务背景：说明系统类型（IoT平台/金融核心系统等）
- 技术约束：声明必须遵循的标准（如TOGAF/微服务设计模式）
提示：角色设定越具体，AI越能模拟真实专家的思维模式。例如"要求遵循AWS Well-Architected Framework的可靠性支柱"会比泛泛而谈更有效。
1.2 信息结构化：从杂乱列表到清晰输入
面对客户提供的混乱功能清单，我常用分层标记法重构输入信息：
[核心功能] - 用户服务: 注册/登录/权限管理 - 订单服务: 创建/支付/退货 [支撑组件] - Redis缓存: 会话存储 - MySQL集群: 主从架构 - API网关: 限流熔断配合明确的层级指示词：
"请将上述组件组织为三层架构：表现层（用户交互）、业务逻辑层（服务）、数据层（持久化）。使用不同颜色区分："
这种结构化输入能显著降低AI的认知负荷。最近为物流系统设计架构时，通过添加流量标注（如"日均10万订单"），DeepSeek自动推荐了适合的负载均衡方案。
1.3 视觉规范：控制SVG输出细节
专业架构图需要统一的视觉语言，这要求提示词包含明确的样式指令：
- 配色方案："使用Material Design配色，主服务用Indigo 500，数据库用Teal 300"
- 连接线规范："同步调用用实线箭头，异步消息用虚线"
- 图标标准："数据库使用AWS RDS官方图标，Kafka用Apache项目logo"
我曾整理过一份样式对照表，大幅提升输出一致性：
| 元素类型 | 样式要求 | 示例 |
|---|---|---|
| 微服务 | 圆角矩形+浅蓝填充 | ![][service] |
| 数据库 | 圆柱体+渐变绿 | ![][database] |
| 消息流 | 虚线+橙色箭头 | ![][message] |
1.4 约束条件：规避常见设计陷阱
通过预判AI可能犯的错误，可以在提示词中加入防御性条款：
"特别注意：
- 不要将认证服务与业务逻辑服务放在同一层级
- 确保所有外部依赖项明确标注为第三方
- 避免出现单向依赖循环"
最近帮助团队重构单体架构时，我们添加了"必须显示服务间契约接口"的约束，使生成的SVG直接包含gRPC协议定义，节省了大量沟通成本。
2. 从简单到复杂的提示词模板
2.1 基础模板：功能列表转架构图
适用于初创项目或MVP阶段的快速可视化：
角色：你是我团队的解决方案架构师 任务：将以下电商系统功能转换为层级架构图 输入： - 用户管理（注册/登录） - 商品服务（CRUD/搜索） - 订单流程（创建/支付） - MySQL数据库 - Redis缓存 要求： 1. 按经典三层架构组织 2. 使用不同形状区分服务类型 3. 输出PlantUML格式的SVG 4. 标注关键数据流向这个模板的特点是快速启动，适合在需求讨论阶段快速产出可视化素材。上周用这个版本为创业团队生成初始架构，仅用2分钟就锁定了技术选型方向。
2.2 进阶模板：云原生架构设计
针对分布式系统的增强版提示词：
你作为AWS认证架构师，需要设计跨境支付平台的云原生架构。技术选型要求： - 容器化部署在EKS - 使用Service Mesh进行服务通信 - 数据层考虑多区域复制 组件清单： [核心服务] - 汇率计算服务（高CPU需求） - 风控引擎（需要GPU加速） - 交易流水服务（高IOPS） [基础设施] - Aurora Global Database - ElastiCache for Redis - Amazon MQ (ActiveMQ) 特别说明： 1. 使用AWS架构图标工具包 2. 显示可用区分布情况 3. 标注SLA承诺等级（99.9%/99.99%） 4. 突出显示安全边界（PCI DSS合规区域）这类提示词的关键在于技术栈特异性。上个月设计IoT平台时，明确要求"显示边缘节点到云端的MQTT连接拓扑"，使AI准确生成了包含协议细节的架构图。
2.3 专家模板：领域驱动设计可视化
对于复杂业务系统的领域建模：
角色：领域驱动设计专家 任务：为保险理赔系统创建符合DDD原则的架构图 输入材料： [限界上下文] - 保单管理（聚合根：Policy） - 理赔处理（实体：Claim） - 欺诈检测（领域服务） [实现细节] - 前端：React微前端 - 后端：Spring Cloud - 事件总线：Kafka 绘图要求： 1. 使用颜色区分核心域/支撑域/通用域 2. 用包图形式展示模块依赖 3. 标注关键领域事件（如ClaimSubmitted） 4. 在右下角添加图例说明符号含义 5. 使用C4模型中的容器级别视角这个模板的精髓在于领域概念显性化。去年在金融项目中使用类似结构，生成的架构图直接反映出"保费计算"与"再保险"的上下文映射关系，被团队用作DDD工作坊的教具。
3. 迭代优化：当结果不如预期时
3.1 诊断常见问题模式
根据数十次优化经验，AI输出问题通常呈现几种模式：
- 层级混乱：将基础设施画在应用层
- 关系缺失：未显示服务间调用关系
- 过度简化：合并了应独立展示的模块
- 技术误解：混淆了Redis与关系型数据库的符号
最近一次优化中，发现DeepSeek持续将API网关误绘为普通服务节点。通过添加对比说明解决问题：
"注意区分：
- API网关（流量入口，菱形图标）
- 业务服务（功能实现，矩形图标）"
3.2 精准反馈技术
低效的反馈如"不够好看"，高效的反馈应包含：
- 具体问题定位："认证服务不应直接连接数据库"
- 修改建议："请添加API管理层作为中介"
- 参考范例："类似AWS架构中心的'安全前端模式'"
我常用的反馈公式：
[当前问题] + [期望状态] + [参考依据]
例如："目前所有服务显示为平级结构（问题），需要按领域分组显示（期望），类似《微服务模式》图3-5的布局（依据）"
3.3 版本对比工具
建立提示词-结果对照表有助于快速调优：
| 迭代版本 | 关键修改点 | 改进效果 |
|---|---|---|
| v1 | 基础三层架构 | 组件层级混乱 |
| v2 | 添加云服务图标约束 | 可视化提升但缺少网络拓扑 |
| v3 | 明确要求显示AZ分布 | 生成符合云设计原则的完整架构 |
这个表格来自真实的项目记录，通过5次迭代最终获得客户认可的架构图。关键转折点在v3加入可用区细节要求后，AI自动生成了跨区域灾备方案。
4. 扩展应用：超越基础架构图
4.1 时序图生成技巧
架构图展示静态结构，而时序图揭示动态交互。有效的提示词需要：
- 明确触发事件："从用户点击支付按钮开始"
- 界定参与方："包含前端、订单服务、支付网关"
- 设定时间约束："在100ms内完成风控检查"
样例片段：
生成RESTful API调用时序图，要求： - 显示OAuth2令牌获取流程 - 标注HTTP方法（GET/POST）和状态码 - 用红色高亮显示失败路径 - 包含重试机制（最多3次）4.2 部署拓扑图特别考虑
基础设施图需要强调物理和逻辑双重维度：
- 区域划分："展示VPC对等连接情况"
- 网络层级："明确区分公网/私网边界"
- 容量规划："用不同大小图标表示节点规格"
上周生成K8s集群图时，通过提示"显示节点亲和性规则"，得到了包含zone分布标注的专业拓扑图，直接用于运维手册。
4.3 架构决策记录(ADR)可视化
将枯燥的决策文本转化为直观图表：
将以下ADR转换为决策流程图： "选择MongoDB而非PostgreSQL因为： 1. 需要处理多变的产品数据模式 2. 读写比例达到8:1 3. 开发团队熟悉NoSQL" 要求： - 使用决策树形式 - 在否决分支标注淘汰原因 - 添加技术雷达评分（成熟度/采纳度）这种可视化极大提升了架构评审效率。有个团队甚至将生成的决策图制作成海报，帮助新成员理解技术选型背景。
