技术思考问题26：AI 时代，架构师的角色到底变成什么了？

资深架构师调研：AI 时代，架构师的角色到底变没变？

图越容易生成，判断越需要证据。

[读者] 带队做系统设计的架构师与技术负责人
[痛点] AI 几秒出图，评审通过了却落不了地
[现在读] 生成成本趋近于零，判断成本浮出水面
[读完] 拿到"约束—取舍—验收"三段可落地判定法

[旧方案] 图靠人手画，贵，画之前必须先摸底
    |
    v
[新需求] AI 一次生成三套架构图
    |
    v
[冲突] 生成能力上来了，判断依据没上来
    |
    v
[后果] 返工、验收缺口、恢复演练失败

我是老李，常年在一线做系统架构和交付，最近半年反复撞见同一个画面：评审会上有人投屏三张 AI 生成的架构图，讨论十五分钟，举手通过。

同盟技术雷达 Vol.3 把这个问题摆到了台面上——AI 时代架构师的角色到底变没变（原文：https://mp.weixin.qq.com/s/BJmpt6I-fGtEUvQTbqOf4A ）。需要说明的是：该页面正文在当前环境不可读取，本篇不复述、不代笔它的调研结论，只讨论可被验证的工程过程；本篇涉及的工具能力边界，也需按当前官方文档核验。

芒格讲能力圈，说的不是"我会什么"，而是"哪些事我能可靠判断、哪些事我判断不了"。把它搬到架构评审上，味道立刻就变了：图是 AI 生成的，判断得由人来做，而人能可靠判断的范围是有边界的。

那，图为什么能这么容易被生成？

为什么被生成出来的图，反而更难判断？

如果判断错了，代价最终由谁承担？

01、故事

某客户订单中台重构，团队满编 5 人：两名后端、一名前端、一名测试、一名运维兼职。领导要求两周内给出重构方案。团队用 AI 生成了三套架构图——A 是 Spring Cloud 微服务加 Kafka；B 是 Go 加服务网格加可观测性全家桶；C 是在现有单体上做模块化改造。评审会上 B 图最漂亮，直接通过。

任务是：两周内交出一份可实施方案，并写清楚为什么否决另外两个。

实施到第二周，三个问题同时冒出来。运维说团队没人碰过服务网格，值班只有一个人；合规说日志留存与数据不出境，压根没设计进方案；老系统只暴露 JDBC，没有可对接的 API，B 方案里那条"统一接入层"落不了地。

回头看，图没错，图甚至挺像样。错的是没有人问过一句：这张图值不值得实施。团队把"能生成"当成了"能判断"，把"看起来完整"当成了"可以交付"。

图白得像雪
落地重如铁
不问谁维护
返工自己接

02、问题

旧方案失效得很彻底。过去靠人手画图，画一张要一天，画的过程本身就是筛选——不摸清约束、不问清团队能力，根本画不出来。现在生成成本趋近于零，筛选环节消失了，评审会变成了"选好看的"。

业务影响：评审周期从一周缩到一天，返工周期却从零拉长到三周。方案定得越快，改得越贵。

技术表现有三条：选型与团队运维能力不匹配；合规等不可违反约束在评审之后才暴露；集成与恢复要求没进验收清单，验收时才发现根本测不了。

可验证的完成标准，我把它定成四条：一，每个候选方案必须有业务目标与不可违反约束的记录；二，至少比较两个替代方案，并写明否决理由；三，验收清单必须包含成本、恢复、集成三项；四，用返工量、验收缺口数、恢复演练结果来衡量，而不是用"评审通过率"。

旧时图很贵
贵得先摸底
如今图免费
免费最昂贵

03、原理

能力圈其实只有三句话。第一，它描述的是判断的可靠性，不是技术的熟悉度；第二，它的边界由约束划出来，不是由技术栈划出来；第三，圈外的事不是不能做，而是不能一个人拍板。

反直觉判断：AI 把生成架构图的成本打到接近零，架构师的工作量不会减少，只会从"画"整体转移到"验"。图越多，验的成本越高，而验这件事目前还没有被自动化。

第二个反直觉判断：判断的可靠性主要取决于输入的完整性，而不是模型的强弱。判断约等于 f(约束完整度, 能力证据, 边界知识)，模型只影响生成那一端。输入缺一半，再用强的模型也只是把错误画得更精致。

因此落到工程上有一条硬规矩：承认"这张图我判断不了"，本身就是一个有效判断。

能生成是力
能判断是权
圈外不开口
圈内再定调

04、架构

[输入] 业务目标 + 候选方案(含AI生成图)
    |
    v
[模块] 约束登记器 / 能力圈过滤器 / 取舍记录器 / 验收清单生成器
    |
    v
[数据/状态] 硬约束、能力证据、否决理由、验收项
    |
    v
[处理] 替代方案比较 + 边界判定 + 风险分级
    |
    v
[输出] 可实施方案 + 否决记录 + 验收清单

输入是业务目标加候选方案，方案可以由 AI 参与生成。四个模块各管一件事：约束登记器负责把不可违反的约束落成清单；能力圈过滤器负责回答"谁来维护"；取舍记录器负责留下否决理由；验收清单生成器负责定义什么叫交付。

中间那层状态才是关键：硬约束、能力证据、否决理由、验收项，这四样东西是判断的凭证，缺一样，评审就退化成投票。

边界要说清楚：这套结构管不了业务目标本身是否合理，也管不了方案的具体实现质量，它只解决"这张图值不值得实施"。收益是把判断从"看法"变成"可追溯的记录"；代价是评审会时间变长，且必须提前准备输入。适用条件是中大型系统的选型评审、AI 参与生成的方案、以及合规约束较强的行业。

约束先落纸
能力再排位
取舍留痕迹
输出才可验

05、实战一次

先跑一个最小版本，只做一件事：把候选方案和团队真实能力对齐。

环境与版本：Python 3.8+，仅用标准库，无第三方依赖。未在当前环境实测，以下为预期结果。

依赖：无。

配置 plan_input.json：

{
  "goal": "订单中台重构，支撑大促峰值",
  "hard_constraints": ["数据不出境", "日志留存 180 天"],
  "capabilities": ["Java", "Spring Cloud", "Kafka", "MySQL"],
  "candidates": [
    {"name": "A", "tech": ["Java", "Spring Cloud", "Kafka", "MySQL"]},
    {"name": "B", "tech": ["Go", "Service Mesh", "Kafka"]}
  ]
}

核心实现 v1_judge.py：

import json
import sys


def load(path):
    with open(path, 'r', encoding='utf-8') as f:
        return json.load(f)


def judge(plan):
    gaps = []
    caps = set(plan.get('capabilities', []))
    candidates = plan.get('candidates', [])
    if len(candidates) < 2:
        gaps.append('候选方案少于 2 个，无法形成取舍记录')
    for c in candidates:
        missing = [t for t in c.get('tech', []) if t not in caps]
        if missing:
            gaps.append('候选 %s 的能力缺口: %s' % (c['name'], ','.join(missing)))
    return gaps


def main():
    plan = load(sys.argv[1])
    gaps = judge(plan)
    if gaps:
        print('结论: 不可直接实施')
        for g in gaps:
            print('  - %s' % g)
    else:
        print('结论: 进入验收清单阶段')


if __name__ == '__main__':
    main()

启动：

python v1_judge.py plan_input.json

预期输出（示例输出）：

结论: 不可直接实施
  - 候选 B 的能力缺口: Go,Service Mesh

验证方式：改一次 capabilities，观察输出是否随之变化；再删掉一个候选，确认工具会提示"无法形成取舍记录"。V1 到这里能跑通了，但它只回答了"技术栈对不对得上"，另外三个问题原封不动地留着。

先跑最小版
再谈大架构
缺口看得见
方案才敢签

06、排查

现象一：V1 判定候选 A 可实施，评审会后合规直接提出日志留存问题，方案被退回。

怀疑：硬约束没有进入判定路径。

检查：grep -n 'hard_constraints' v1_judge.py，只在 load 里出现过一次，judge 函数里完全没有引用。

证据：把读到的 plan['hard_constraints'] 打印出来是有值的，但判定逻辑里没有任何一行用它。

根因：约束被当成了描述性上下文，而不是判定输入。它存在于文件里，却不参与结论。

修复：把约束校验加进判定流程，并把缺失项单独输出。

现象二：候选 B 被否决，但一周后另一个小组又把几乎一样的方案端了上来，理由是"当时也没说不行"。

怀疑：否决理由没有落成数据。

检查：查看 V1 输出，只有一句结论，没有任何结构化字段说明哪个候选、因为哪条约束被否。

证据：输出文本里检索不到候选名与约束名的对应关系。

根因：把取舍当成会议结论，而不是可追溯的数据。

修复：输出结构化否决记录，包含候选名、原因、对应约束编号。

错误尝试： 一开始我怀疑是 AI 生成的方案质量太差，于是换更强的模型、重写提示词，让 AI 重新出图。为什么错：根因在判定输入缺失与取舍未记录，不在生成质量。换模型的唯一效果是把图变得更漂亮，而漂亮恰恰是这次事故的诱因。

现象先记录
怀疑别先信
证据摆上桌
根因才认账

07、优化

基于 06 的两条证据，V2 只做四件事：约束进判定、能力证据分级、否决理由结构化、验收清单自动生成。

根因一（约束不参与判定）→ 修改：把约束校验独立成函数，默认约束与声明约束合并比对。原因：合规类约束往往不会被主动写进方案，必须由工具兜底提示。新行为：输出约束缺口列表。验证：删掉配置里的一条约束，输出中应立刻出现该缺口。

根因二（否决理由不可追溯）→ 修改：输出 rejected 结构，包含候选名与理由。原因：同一方案被反复提起，本质是组织记忆缺失。新行为：否决记录可直接粘进评审纪要。验证：按候选名检索输出，能命中对应理由。

能力证据分级用"熟悉/了解/无"三档，低于"熟悉"的组件视为不可维护。这一步不是为了评分，而是为了让"谁维护"这个问题的答案进入方案本身。

核心实现 v2_judge.py：

import json
import sys

LEVELS = {'熟悉': 3, '了解': 2, '无': 1}
DEFAULT_CONSTRAINTS = ['数据不出境', '日志留存 180 天', '关键链路可回滚']


def load(path):
    with open(path, 'r', encoding='utf-8') as f:
        return json.load(f)


def check_constraints(plan):
    declared = set(plan.get('hard_constraints', []))
    return [c for c in DEFAULT_CONSTRAINTS if c not in declared]


def check_capability(candidate, threshold=3):
    gaps = []
    for tech, level in candidate.get('tech_level', {}).items():
        if LEVELS.get(level, 0) < threshold:
            gaps.append('%s 的 %s 为 %s，低于可维护阈值' % (candidate['name'], tech, level))
    return gaps


def evaluate(plan):
    report = {'constraint_gaps': check_constraints(plan), 'candidates': [], 'rejected': []}
    for c in plan.get('candidates', []):
        gaps = check_capability(c)
        if gaps:
            report['candidates'].append({'name': c['name'], 'ok': False, 'reasons': gaps})
            report['rejected'].append({'name': c['name'], 'reason': '; '.join(gaps)})
        else:
            report['candidates'].append({'name': c['name'], 'ok': True, 'reasons': []})
    return report


def acceptance_list(plan):
    return [
        '成本: %s' % plan.get('cost_budget', '未给出'),
        '恢复: RTO/RPO 与回滚演练记录',
        '集成: 与既有系统的接口清单与联调计划',
    ]


def main():
    plan = load(sys.argv[1])
    report = evaluate(plan)
    print('约束缺口:', report['constraint_gaps'] or '无')
    for c in report['candidates']:
        print('候选 %s -> %s' % (c['name'], '可进入验收' if c['ok'] else '否决'))
        for r in c['reasons']:
            print('  理由:', r)
    print('验收清单:')
    for item in acceptance_list(plan):
        print('  -', item)


if __name__ == '__main__':
    main()

启动与预期输出（示例输出）：

python v2_judge.py plan_input.json

约束缺口: ['关键链路可回滚']
候选 A -> 可进入验收
候选 B -> 否决
  理由: B 的 Service Mesh 为 无，低于可维护阈值
验收清单:
  - 成本: 未给出
  - 恢复: RTO/RPO 与回滚演练记录
  - 集成: 与既有系统的接口清单与联调计划

注意：这里只给出方法与该方法的预期行为，没有实测数据，也没有线上数字。真正的验证要靠三样外部证据——返工量、验收缺口数、恢复演练结果。

缺什么补什么
多一条否决
验收写三层
结论才有底

08、演进

[同一输入]
    |
    +--[V1] 只比技术栈 / 快，但漏约束、无否决理由
    |
    +--[V2] 约束+能力+验收 / 慢，但可追溯、可验收
    |
[Trade-off]
得到可追溯与可验收 / 失去"秒出结论"的爽感 / 适用边界: 方案评审与选型环节

正确性：V1 只判断技术栈匹配，会把合规与集成问题漏到实施期；V2 把不可违反约束与能力证据纳入判定，判断面变宽。

稳定性：V1 的结论强依赖输入里的 capabilities 字段是否填写完整；V2 增加了默认约束兜底，但默认约束本身需要维护，这又引入了新的依赖。

复杂度：V1 约 30 行，V2 约 60 行，多出来的部分几乎全是数据结构与记录逻辑，而不是算法。

成本：V2 要求评审前准备能力分级与约束清单，这是真实的人力成本，无法靠工具省掉。

适用范围：V1 适合快速筛选，V2 适合正式评审。两者不是替代关系，是前后两道闸门。

遗留问题：能力分级的"熟悉"是主观判断，没有客观校准；恢复演练结果尚未回流到判定中。

同一份输入
两种活法
快有快的险
慢有慢的值

09、洞见

9.1 生成成本下降，判断成本上升

反直觉判断：工具变强不必然让架构师变轻松。生成这一步被压缩掉的成本，会在验证这一步重新长出来，而且长在更靠后的位置——实施期。越早承认这一点，越早把精力放到约束与验收上。

9.2 能力圈的边界是约束，不是技术栈

反直觉判断：决定你能不能判断的，往往不是你懂多少框架，而是你能拿到多少约束。同一个团队，在合规边界清晰的场景下判断很准，边界一模糊就立刻失准。所以能力圈要先问约束，再问技术。

9.3 否决理由比结论更像资产

结论会过时，理由不会。一条"因为团队无人维护服务网格而否决"的记录，半年后换个项目依然成立。把否决理由结构化留存，等于给组织装了一份判断的免疫记忆。

9.4 验收清单是判断的回执

判断对不对，不看会上说得多好，看交付时缺了几项。成本、恢复、集成写进清单，判断才有闭合回路；写不进去的判断，本质上还是一次表态。

洞见不在新
只在前文里
说得再漂亮
不如一次证

10、系统落地

原来有什么：一份靠经验攒起来的方案模板，加上评审会上口头形成的取舍。判断过程不可追溯，人一走就断档。

本篇新增什么：四样东西。约束登记清单、能力圈过滤规则、结构化否决记录、三项验收清单，以及一个能跑的最小判定脚本。

现在能做什么：在评审之前，对每个候选方案给出"可实施 / 需补证 / 否决"的判断，并附上理由与验收项。评审从投票变成对证据的核对。

还缺什么：能力分级的客观校准依据；合规约束库的持续维护；恢复演练结果自动回流；跨项目的决策库检索。

下一步如何演进：先把否决记录积累成可检索的组织资产，再把恢复演练结果接入判定，最后才考虑用模型辅助生成候选方案——顺序不能反，先有判断骨架，再谈生成效率。

原来靠经验
现在靠记录
缺的是证据
补的是流程

11、小结

Q1 → 生成便宜了，但图的漂亮程度与可实施性无关
Q2 → 判断更难，是因为判断输入(约束/能力/合规)没跟上生成速度
Q3 → 代价由维护方与业务承担，返工、验收缺口、恢复失败都是账
状态 → 可交付: 一套最小可跑的方案判定脚本 + 约束/取舍/验收三段记录规范

问题有答案
能力有边界
交付有清单
判断有回执

12、作业

12.1 理解题：为什么"能生成架构图"不等于"架构方案可实施"？

参考答案：生成解决的是方案空间的生产问题，可实施要回答的是维护主体、合规边界与集成条件。前者可以在几秒内完成，后者必须由具体的人、具体的约束和具体的验收标准来确认。缺了后半段，图只是素材。

12.2 实战题：拿一个你手上真实的候选方案，写出它的约束清单与验收清单。

参考答案：约束清单至少包含三类——不可违反的合规约束、不可突破的成本与容量约束、不可牺牲的恢复目标。验收清单至少覆盖成本、恢复、集成三项，每项都要能被检验：成本给预算口径，恢复给 RTO/RPO 与演练记录，集成给接口清单与联调计划。写完后再逐条问：这条能证伪吗？

12.3 排障题：方案评审通过，实施期才发现团队无人维护某组件，怎么排查？

参考答案：先看判定输入里有没有能力证据字段，再看这个字段有没有参与判定。常见根因是把"技术可行"直接当成"可实施"，能力维度从未进入判定路径。修复方式是把能力证据分级并设置阈值，低于阈值的组件直接触发否决理由记录，而不是留到实施期暴露。

12.4 架构判断题：是否应该用更强的模型直接产出最终架构方案？

参考答案：不应该以此为目标。模型强弱影响的是候选方案的质量与多样性，不影响约束识别、取舍记录与验收验证。合理的分工是：模型负责生成候选，人负责定义约束、记录否决理由、编写验收清单。判断责任无法外包给生成能力。

题目不动手
永远是他人的
跑一遍再说
错一遍才算

13、思考

回到开篇那个冲突：图越来越容易生成，判断却越来越难做。真正的分水岭不在工具，而在你是否愿意承认自己的判断边界。

能力圈给出的不是限制，而是分工：圈内的事自己拍板，圈外的事必须先补证据。约束识别、取舍记录、交付验证，这三件事构不成炫技的素材，却是架构师在 AI 时代唯一无法被生成能力替代的部分。图越容易生成，判断越需要证据。

图越易生成
判断越要证
圈内再动手
圈外先问清