AI 做技术方案设计实测：输入 PRD 输出架构图，靠谱吗？

AI技术方案设计能力评估与协作模式通过对3个典型技术场景的测试，AI在技术方案设计上展现出以下特点：基础能力：能快速生成60分方案，覆盖主流技术选型、基础架构和常见风险点局限性：在极端场景（如热点Key问题）、底层机制（如大文件合并）和运营需求（如租户计量）上存在明显盲区模型差异：Claude架构完整性较好，GPT解释更详细，DeepSeek中文表达更自然建议采用三层协作模式： AI生成

随风丶飘

75人浏览 · 2026-05-28 15:30:00

随风丶飘 · 2026-05-28 15:30:00 发布

一、引言：技术方案设计的效率瓶颈

一个中等复杂度的技术方案，资深架构师通常需要 2-4 小时完成，普通开发可能需要一整天。方案内容通常包括：

需求分析与边界界定
技术选型与对比
系统架构图（C4 模型）
接口设计与数据模型
风险点与应急预案
排期与里程碑

在敏捷开发节奏下，这个耗时往往被压缩，导致方案考虑不周、上线后频繁返工。

如果 AI 能在 5 分钟内生成一份"像模像样"的技术方案初稿，开发者只需在此基础上修正和深化，理论上可以大幅提效。但问题是：AI 生成的方案真的靠谱吗？技术选型会不会瞎推荐？架构图是不是纸上谈兵？风险点会不会遗漏？

我们设计了 3 个真实业务场景，对 AI 的方案设计能力进行极限测试。

二、评估框架设计

2.1 四个评估维度

维度	权重	评估标准
技术选型合理性	25%	选型是否符合业务规模、团队技术栈、维护成本
架构完整性	25%	是否覆盖数据层、服务层、缓存、消息队列、监控等全链路
风险识别度	25%	是否识别性能、安全、一致性、扩展性风险
可落地性	25%	方案是否可直接转化为开发任务，有无明显断层

2.2 评分规则

8-10 分：接近资深架构师水平，可直接使用
5-7 分：可用，但需要人工大幅调整
0-4 分：不可用，存在明显错误

三、实测 Case 1：电商秒杀系统

3.1 需求输入（模拟 PRD）

"设计一个秒杀系统，支持 10 万用户同时抢购 1000 件商品。要求：

防止超卖

响应时间 < 200ms

支持库存预热

需要限流和防刷"

3.2 AI 生成方案摘要

技术选型：

缓存：Redis Cluster（库存扣减）
队列：RocketMQ（异步下单）
数据库：MySQL（订单持久化）
限流：Sentinel
防刷：验证码 + IP 限流

架构要点：

预热阶段：将库存加载到 Redis
抢购阶段：Lua 脚本原子扣减库存
异步阶段：MQ 削峰，消费者落库
补偿阶段：定时任务对账

3.3 人工评分

维度	评分	点评
技术选型	8/10	Redis + Lua 是标准方案，但未考虑本地缓存（Caffeine）做二级防护
架构完整性	7/10	缺少 CDN 静态资源加速、缺少秒杀链接动态化（防止提前暴露）
风险识别	6/10	提到了超卖和削峰，但遗漏了热点 Key 问题（单个 SKU 的 Redis Key 可能成为热点）
可落地性	8/10	方案可直接拆分为开发任务，粒度合理
总分	29/40

3.4 关键缺陷分析

遗漏热点 Key：这是秒杀系统的经典难题。当所有请求都命中同一个 Redis Key 时，即使 Lua 脚本原子执行，单节点的网络带宽和 CPU 也会成为瓶颈。标准解法包括：

库存分段（将一个 SKU 的库存拆分为 N 个 Redis Key）
本地缓存 + Redis 二级缓存
请求合并（Singleflight 模式）

AI 的方案完全未提及这一点，说明它依赖的是"常见套路"，而非对极端场景的深度理解。

四、实测 Case 2：分布式文件存储系统

4.1 需求输入

"设计一个企业内部网盘系统，支持：

文件上传下载（最大 10GB）

断点续传

秒传功能（基于 Hash）

多副本备份

部门级权限隔离"

4.2 AI 生成方案摘要

技术选型：

存储：MinIO（对象存储）
分片：前端分片上传，后端合并
元数据：MySQL（文件目录结构）
缓存：Redis（秒传 Hash 映射）
权限：Spring Security + ACL

架构要点：

上传流程：分片 → 暂存 → 合并 → 存入 MinIO
秒传流程：计算 MD5 → 查询 Redis → 命中则硬链接
下载流程：预签名 URL → 直传 MinIO

4.3 人工评分

维度	评分	点评
技术选型	7/10	MinIO 适合中小企业，但未考虑企业已有云存储（如阿里云 OSS）的接入成本
架构完整性	6/10	缺少垃圾回收机制（孤儿分片清理）、缺少病毒扫描环节
风险识别	5/10	提到了断点续传，但未识别大文件合并时的内存风险（10GB 文件合并可能 OOM）
可落地性	7/10	分片合并的细节（并发控制、失败重试）描述模糊
总分	25/40

4.4 关键缺陷分析

大文件合并内存风险：AI 建议"后端合并分片"，但对于 10GB 文件，如果采用内存合并，很容易导致 OOM。正确的做法是：

使用流式追加写入（FileOutputStream 或 MultipartFile.transferTo）
或者使用 MinIO 的 Compose Object API（服务端合并，零内存拷贝）

AI 对底层 I/O 机制的理解显然不够深入，给出了"看起来对"但实际上有性能隐患的方案。

五、实测 Case 3：多租户 SaaS 数据隔离

5.1 需求输入

"设计一个 SaaS 化 CRM 系统，支持多租户：

中小租户共享资源，降低运营成本

大客户支持独立部署

租户数据严格隔离

支持租户级自定义字段"

5.2 AI 生成方案摘要

技术选型：

隔离方案：共享数据库 + 独立 Schema（中小租户）；独立数据库（大客户）
路由：MyBatis 插件实现动态数据源切换
自定义字段：JSON 扩展列（MySQL 8 JSON 类型）

架构要点：

租户标识：通过 JWT 中的 tenantId 传递
数据路由：拦截 SQL，自动添加 tenant_id 条件
大客户：独立 RDS 实例，通过配置中心切换数据源

5.3 人工评分

维度	评分	点评
技术选型	9/10	混合隔离方案是业界最佳实践，MyBatis 插件也是标准做法
架构完整性	8/10	覆盖了隔离、路由、扩展字段，但缺少租户级限流和计费计量
风险识别	7/10	提到了数据隔离，但未深入讨论跨租户查询的复杂性（BI 报表如何聚合？）
可落地性	8/10	方案可直接落地，MyBatis 插件有成熟开源实现
总分	32/40

5.4 亮点与不足

这是 AI 表现最好的一个场景。原因是多租户 SaaS 是极为成熟的模式，AI 的训练数据中有大量相关案例，因此生成的方案非常"套路化"且正确。

但不足也很明显：AI 没有考虑运营层面的需求，如：

租户级资源配额（CPU/内存/存储限制）
租户数据备份策略（共享实例如何单独备份？）
跨租户数据分析（平台运营视角的聚合查询）

六、架构图生成专项测试

6.1 C4 模型图生成

要求 AI 为 Case 1（秒杀系统）生成 C4 容器图（Container Diagram），使用 Mermaid 语法。

AI 生成结果：

6.2 人工评估

语法正确性：10/10（Mermaid C4 语法完全正确）
逻辑正确性：7/10（缺少 CDN、负载均衡、监控告警）
细节完整性：6/10（未标注端口、协议版本、数据流向的时序）

结论：AI 生成的架构图"能用"，但距离生产级文档还有差距。它适合作为初稿或会议讨论素材，不适合直接放入技术评审文档。

七、三模型横向对比

为了验证不同模型的差异，我们用同样的 Prompt 在 GPT-5.4 和 DeepSeek V4 上重复测试：

场景	Claude 4.7	GPT-5.4	DeepSeek V4
秒杀系统	29/40	27/40	24/40
文件存储	25/40	26/40	23/40
多租户 SaaS	32/40	31/40	30/40

观察：

Claude 在架构完整性上略胜一筹（C4 图生成更规范）
GPT-5.4 在技术选型的解释上更详细（会给出对比表格）
DeepSeek V4 整体稍弱，但在中文表达上更自然

八、人机协作模式建议

基于实测，我们提出"AI 方案设计的三层模型"：

需求输入
    ↓
【第一层】AI 生成初稿（5 分钟）
  → 输出：技术选型建议、架构框架、风险清单（初版）
  → 目标：提供"60 分方案"，消灭空白页焦虑
    ↓
【第二层】人工架构评审（30-60 分钟）
  → 聚焦：修正技术选型、补充边界场景、识别 AI 遗漏的风险
  → 目标：将方案提升到"80 分"
    ↓
【第三层】AI 辅助完善（10 分钟）
  → 将人工修正后的方案再次输入 AI，要求：
    - 生成详细的接口设计
    - 生成 C4 模型图
    - 生成开发任务拆分（WBS）
    ↓
最终方案定稿

九、结论

9.1 AI 在方案设计中的能力边界

能力	表现	建议
套路化方案（秒杀、SaaS、电商）	⭐⭐⭐⭐⭐ 优秀	可直接作为初稿
技术选型对比	⭐⭐⭐⭐ 良好	需人工验证与团队技术栈匹配度
架构图生成	⭐⭐⭐ 一般	适合初稿，需人工补充细节
深度风险识别（热点 Key、OOM、跨租户查询）	⭐⭐ 较弱	必须人工补充
创新架构设计	⭐ 差	无法替代架构师的创造性思考