AI 辅助架构设计：从需求到方案草稿
架构设计的核心难点从来不是”画一张图”，而是在相互冲突的约束之间做出取舍：性能、成本、可维护性、团队熟悉度、上线时间，往往不可能同时拉满。AI 不会替你承担这些取舍的责任，但它在两个阶段非常有用——快速产出可讨论的初稿，以及充当不知疲倦的审查者查漏补缺。一个合理的工作流是：让 AI 几小时内给出 2–3 个候选骨架，你据此组织讨论、做决策，再把决策沉淀成文档，而不是从空白页开始。
能帮什么：四个具体产出
- 需求结构化：把”做一个能用的后台”这类模糊表述，改写成带优先级的功能清单、明确的范围边界与非目标（non-goals）。这一步本身就能暴露需求里的矛盾。
- 方案初稿：给出候选架构（如单体 vs 微服务、同步 vs 事件驱动）、模块划分、关键数据流，以及对每种技术选型的优劣对比。
- 风险扫描：从安全、可扩展性、单点故障、成本、运维复杂度等维度，列出人类容易忽略的检查项。
- 文档产出：生成架构决策记录（ADR）、API 草案、部署拓扑描述，以及写给不同读者（开发、运维、老板）的版本。
协作流程：上下文、多方案、收敛
要让 AI 的输出可用，输入质量比模型本身更关键。
1. 喂足上下文。 至少提供：现有系统现状、预期规模（QPS/数据量/用户数）、团队技术栈与熟练度、硬约束（合规、预算、必须用的内部组件）。上下文越薄，AI 越容易给出”教科书正确但本地不可用”的泛泛建议。
2. 强制多方案。 明确要求”给出 2–3 个候选并对比，不要只给一个”。单一方案会诱导你直接进入细节，而失去对整体方向的比较。可以要求它用表格列出各方案在扩展性、成本、复杂度上的差异。
3. 逐项追问取舍。 对每个选项，追问”这个选择的代价是什么""在什么规模下会失效""如果流量涨 10 倍哪里先崩”。这类问题能把隐含假设逼到台面上。
4. 人工收敛为 ADR。 架构决策影响长期演进，最终必须有人拍板。把结论写成 ADR（记录背景、考虑过的方案、最终选择及理由），比散落在聊天记录里可靠得多，也便于日后回溯”当初为什么这么定”。
提示与实例
一个有效的输入模板：
目标：为内部 200 人团队搭建一个文档检索系统。
约束：数据不能出内网；峰值 500 并发；团队只有 2 名后端。
请输出：2 个候选架构（含模块划分），并对比成本与运维复杂度。
其中必须说明：单点故障在哪、数据合规如何满足。
另一个高价值的用法是对抗式审查：让 AI 扮演资深架构师，专门挑战它自己刚给出的方案——“假设我是 CTO，指出这份方案三个月后会出问题的三个地方”。这种角色反转往往比正向陈述更能暴露薄弱环节。
必须人工把关的三条红线
- 技术选型的时效性：AI 训练数据有截止时间，它推荐的某个库可能已停止维护，或出了更优替代。凡是涉及具体版本、具体产品，必须人工核实。
- 长期演进责任：架构决策是”沉没成本型”的，选错后迁移代价极高。拍板权必须留在人手里，AI 只提供选项与论据。
- 合规与安全红线：涉及数据出境、权限模型、审计要求时，AI 的建议只能作为 checklist 的起点，不能当作合规结论。这类问题应回归到对应法规与内部安全规范。
小结
AI 在架构设计里扮演的是”初稿加速器 + 结构性审查者”，不是决策者。把上下文给足、强制它产出多方案并公开取舍、再亲手把结论落成 ADR，能显著压缩从需求到可执行方案的时间，同时把单人思考的盲区交给机器去穷举。架构的最终责任，始终在坐在键盘前的人。
参考与延伸阅读
- 架构决策记录（ADR）实践指南（如 adr.github.io）。已核验。https://adr.github.io/
- 本站「AI 代码审查」「AI 重构」与「MCP 协议」相关教程
- 《Fundamentals of Software Architecture》（Richards & Ford）关于架构属性与权衡的框架（常见工程参考，具体章节请以原书为准）