Software Architect · 模块 22
AI 不会取代架构思维。它加速探索、批判和文档——前提是架构师懂得如何设定框架、并校验它的输出。
AI-assisted design · critique · verification · quality gates
AI 作为推理的放大器很有用,作为"未经校验的自信"的来源则很危险。
AI 擅长拓宽选项空间
助手能在一分钟里拿回十份路线图。但选哪条路,仍然归司机说了算。
架构师可以用 AI 来生成备选方案、风险 checklist、ADR 草稿、trade-off 对比、测试场景、安全威胁,以及 review 问题。这能加速准备工作。
但 AI 不了解完整的系统 context,会幻觉出根本不存在的 API,会低估运维成本,还会在其实需要数据的地方装出一副自信的样子。所以它的输出必须经过校验:代码库、文档、metric、约束,以及团队的知识。
prompt 必须带上约束
让一位建筑师去"设计一栋房子"毫无意义。你得给出地块、预算、气候、家庭、工期和约束。
要做架构工作,AI 需要 context:领域、当前架构、team topology、负载、合规、预算约束、产品目标、已有决策,以及成功标准。
没有约束,模型往往会默认退回到泛泛的 best practice:microservices、Kafka、Kubernetes、event sourcing。那东西可以既漂亮又有害。
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 在保护我们不被未经校验的输出坑到?