AI 与架构师配对工作的实战
AI 辅助编程这两年的讨论，大多集中在”初级开发者”和”写代码”这个维度——用 Cursor 补全代码、用 Claude Code 生成单测、用 GitHub Copilot 加速业务逻辑实现。但有一类工作很少被讨论：架构师怎么用 AI。
架构师的日常不是大量敲代码，而是做决策、写方案、评审、说服人。这类工作和”代码补全”的适配度一开始看起来并不高。但实际上，在过去一年多的实践里，AI 在架构工作中的价值远超我最初的预期——前提是你知道怎么配合它工作，以及哪些地方不该依赖它。
一、架构师工作的本质与 AI 的适配性
架构师的核心工作可以大致分为四类：
- 技术调研：评估某个技术栈/方案，收集对比信息
- 方案设计：针对具体问题设计系统结构，权衡取舍
- 方案评审：发现其他人提案的问题，给出改进意见
- 沟通与说服：把技术决策用非技术语言解释给管理层和业务方
这四类工作里，AI 对 1 和 3 的帮助最大，对 2 的帮助是”辅助放大而非主导”，对 4 的帮助在于草稿生成。下面逐一展开。
二、技术调研：AI 作为结构化信息整合器
这是 AI 对架构师帮助最显著的场景。架构决策前通常需要调研 3–5 个候选方案，收集信息的方式往往是：翻官方文档、看 GitHub Issues、读 HN/Reddit 讨论、看几篇博客……这个过程耗时且分散。
实战用法：用 AI 建立初步对比框架
在开始深度调研前，先问 AI：
我需要在以下三个方案中选择一个用于 [具体场景]：
- 方案 A：Kafka
- 方案 B：Pulsar
- 方案 C：NATS JetStream
我的核心约束条件：
- 峰值消息量：10万条/分钟
- 消息保留时间：7天
- 运维团队规模：3人，无 Kafka 运维经验
- 部署环境：Kubernetes，内存受限（单节点 8GB）
请从以下维度建立对比表，并标注你不确定的项目：
吞吐量、延迟、运维复杂度、存储模型、社区活跃度、Kubernetes 支持AI 能很快给出一张初步对比表，即使有些细节不准确，也能给调研提供一个结构化框架，让后续深入查资料时知道重点关注哪些维度。
关键使用原则：
- 让 AI 标注它不确定的项目（加 “请标注你的置信度” 或 “如果你不确定请说明”）
- AI 给出的数字（吞吐量、延迟指标）必须用官方基准测试验证，不能直接采信
- 把 AI 的输出当成”草稿”，自己做核实，不要当成终稿
三、方案评审：AI 作为挑剔的橡皮鸭
架构评审的核心价值是”发现问题”。但现实中，评审者往往受到以下限制：时间有限没有深读方案、对某些技术栈不熟悉、或者碍于人情不好意思直接质疑。
AI 在这里充当一个没有人情负担、不知疲倦的评审员。
实战用法：让 AI 扮演挑剔的评审
以下是我们团队提交的微服务拆分方案草稿（粘贴方案文档）。
请以一个资深架构师的视角对这份方案进行评审，重点关注：
1. 服务边界是否合理？是否存在过度拆分或边界不清晰的问题？
2. 数据一致性方案是否完整？分布式事务如何处理？
3. 服务间依赖关系是否形成了环状依赖？
4. 扩容瓶颈在哪里？哪个服务最可能成为瓶颈？
5. 这个方案里有什么我们可能没想到的风险？
对每个问题，请给出具体的说明，不要只说"需要考虑XX"，请指出方案中具体哪里有问题。这个场景下 AI 的输出质量往往超出预期——它能以惊人的速度从大量文字里提取矛盾点，找出那些”说了等于没说”的模糊描述。
一个实际案例：我们曾有个团队提交了一份 API 网关方案，AI 在 30 秒内发现了：鉴权方案里 JWT 过期时间写了两个不同的值（一个在介绍部分说 1 小时，一个在实现部分说 24 小时）；以及负载均衡策略和 session 亲和性的描述存在逻辑冲突。这些问题在人工评审时因为文档太长可能被遗漏。
四、方案设计：AI 作为第一稿生成器
这是 AI 作用最需要”留个心眼”的场景。AI 能生成看起来非常合理的架构方案，但这个方案是否真的适合你的场景，取决于你提供了多少上下文信息。
实战用法：先给约束，再要方案
背景：
- 这是一个 B2B SaaS 产品，用户是中型制造业企业
- 当前用户量：500家企业，预计3年内增长到5000家
- 核心功能：生产计划排程 + 物料需求计划（MRP）
- 数据特点：每家企业数据完全隔离，数据量差异巨大（小企业10MB，大企业100GB+）
- 团队：后端5人，没有 DBA
- 现有技术栈：Node.js + PostgreSQL，部署在 AWS
当前痛点：
- 大企业的 MRP 计算任务（每次运行需要5–10分钟）会严重影响其他用户的响应速度
- 多租户数据隔离目前用行级策略（tenant_id），性能问题开始出现
请为我设计一个能解决当前痛点同时支持3年增长目标的架构改进方案。
要求：
- 不要做大跃进式重构，优先最小可行改动
- 明确说明哪些改动是第一优先级、哪些可以延后
- 指出方案中的主要风险点这个 prompt 比”帮我设计一个多租户 SaaS 架构”好得多，因为它提供了具体约束（团队规模、现有技术栈、增长目标）和具体痛点。约束越具体，AI 的方案越有参考价值。
使用原则：
- AI 的第一稿是你自己方案的”对照物”，不是你该直接采纳的方案
- 让 AI 列出它的假设（“这个方案假设你们…”），审查这些假设是否成立
- 对 AI 提出的每个技术选型追问：“这个选型的替代方案是什么？为什么选这个而不是替代方案？“
五、沟通材料生成：AI 作为语言翻译器
架构师需要向不同受众解释技术决策：向 CTO 说明为什么要引入消息队列、向产品经理解释为什么这个需求需要3个月而不是3周、向业务方解释微服务拆分带来的好处。
AI 在这里可以做”技术语言→业务语言”的翻译。
实战用法：
我需要向公司 CEO（非技术背景）解释为什么我们需要把系统从单体架构改造成微服务。
主要动机：
1. 不同模块的发布频率差异大，单体架构导致高风险的整体发布
2. 某些核心计算模块需要独立扩容，目前整体扩容浪费成本
3. 不同团队频繁互相阻塞，开发速度下降
请帮我写一段 5 分钟左右的汇报材料（约 400 字），用业务语言而非技术语言，
重点说明业务价值和投资回报，避免用"微服务"、"容器"等技术术语。这类”翻译”任务 AI 完成得相当好，它会自动用”模块化”、“灵活扩展”、“减少风险”等业务语言替换技术术语。
六、AI 在架构工作中的边界
有几件事是 AI 不应该主导的：
1. 涉及公司特定业务逻辑的设计
AI 不了解你们公司的历史债务、团队能力、政治生态。一个技术上完美的方案在你的组织里可能根本推不下去。
2. 新兴技术的准确性判断
AI 的训练数据有截止日期，对 2025 年之后发布的新技术的判断可能存在偏差或幻觉。新技术的决策要靠官方文档和社区一手资料。
3. 最终的技术决策签字
决策的责任必须在人这里。AI 的方案可以作为参考，但不能当成答案。这不仅是责任问题，也是因为AI 无法真正理解你所在组织的约束条件。
4. 数字的盲信
任何 AI 给出的吞吐量、延迟、成本数字，都需要用官方测试数据或自测验证。AI 生成的数字往往”看起来合理”，但细节可能完全错误。
七、工具选型：Claude vs GPT 在架构工作中的差异
在架构师的工作场景下，Claude（尤其是 Claude 3.5 Sonnet 及以上）在长文档处理和方案评审上表现更好，能更好地处理包含大量上下文的评审请求。GPT-4o 在技术调研类任务上反应更快，且对 OpenAI 生态的工具（如 Function Calling、Structured Outputs）细节描述更准确。
实际工作中可以两者结合用：方案评审和长文档分析用 Claude，快速技术问答用 GPT-4o。关于两者在编码任务上的对比，可参考 Claude 4.7 vs GPT-5.1 编程能力对比。
八、让 AI 参与架构工作的前提
最后说一点容易被忽略的问题：AI 辅助架构工作的质量，取决于你提供上下文的质量。
如果你只问”帮我设计一个高可用系统”，你会得到一个放之四海皆准但毫无价值的答案。如果你把具体的系统现状、团队约束、业务目标、遇到的具体问题都给出来，AI 的输出质量会提升一个量级。
架构师的核心能力之一是”把模糊的问题结构化”，这个能力同样适用于和 AI 协作：你越能精确描述问题，AI 就越能给出有价值的输出。
对于 AI 配对开发的更多实战经验，可以参考 AI 配对编程的真实故事 和 AI 编程如何接入后端开发工作流。
九、相关阅读
如果你在架构调研或方案评审中需要调用 Claude、GPT-4o 等模型，YoTradeApi 提供稳定的 API 中转，支持全系主流模型，按量付费，无最低消费。