# 22. AI-native 架构师

如何把 AI 当成架构师的工作工具来用:探索、设计批判、文档、测试、幻觉风险,以及 quality gate。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-22-ai-native

---

## 1. 核心观点

AI 作为推理的放大器很有用,作为"未经校验的自信"的来源则很危险。

### AI 擅长拓宽选项空间

> 助手能在一分钟里拿回十份路线图。但选哪条路,仍然归司机说了算。

架构师可以用 AI 来生成备选方案、风险 checklist、ADR 草稿、trade-off 对比、测试场景、安全威胁,以及 review 问题。这能加速准备工作。

但 AI 不了解完整的系统 context,会幻觉出根本不存在的 API,会低估运维成本,还会在其实需要数据的地方装出一副自信的样子。所以它的输出必须经过校验:代码库、文档、metric、约束,以及团队的知识。

### prompt 必须带上约束

> 让一位建筑师去"设计一栋房子"毫无意义。你得给出地块、预算、气候、家庭、工期和约束。

要做架构工作,AI 需要 context:领域、当前架构、team topology、负载、合规、预算约束、产品目标、已有决策,以及成功标准。

没有约束,模型往往会默认退回到泛泛的 best practice:microservices、Kafka、Kubernetes、event sourcing。那东西可以既漂亮又有害。

## 2. 例子与反例

AI-native 的工作方式应当强化工程纪律,而不是绕开它。

### 例子:把 AI 当成 ADR 的 reviewer

> 副驾驶不会代替机长来开飞机——他帮忙核对仪表,抓住机长漏掉的东西。

团队正在写一份关于转向异步处理的 ADR。AI 收到 context、这份 ADR、约束,以及已知事故的清单。任务是:找出缺失的风险、不清晰的假设、迁移的缺口,以及测试场景。架构师审阅它的输出,把真正成立的条目加进文档。

这样,AI 帮你照见盲点,却不替团队做决定。

### 反例:不经校验就接受 AI 的设计

> 一张漂亮的桥梁图没用,如果没人检查过土质、荷载和材料。

AI 给一个简单的 CRUD 系统提议 event sourcing 和 CQRS。团队接受了,因为那段解释听起来很专业。一个月后,replay、schema evolution、调试和团队上手的复杂度全冒了出来——而业务价值一点没动。

当架构师没把住质量这道杠,AI 会加速 over-engineering。

#### 自检

- 我给 AI 的是哪些约束?
- 哪些事实需要拿代码或文档来核对?
- AI 可能在哪里给出了一个泛泛的方案?
- 哪些 quality gate 在保护我们不被未经校验的输出坑到?

下一模块:[Anti-patterns](./software-architect-23-antipatterns)。