02-模块一-全景认知第02讲-AI 架构师技术栈全景图 - 传统架构能力 + AI 新技能的完美融合模块一-全景认知

模块一-全景认知 | 第02讲：AI 架构师技术栈全景图 - 传统架构能力 + AI 新技能的完美融合

开场：「会调模型」不等于「会做架构」

过去两年，技术社区里很容易把两类人混为一谈：一类人能写很炫的 Prompt、能搭一个 RAG Demo、能在周末 hackathon 里做出像模像样的聊天机器人；另一类人能在白板上把系统边界画清楚，能在压力下做 CAP 取舍，能把一次重大重构拆成可交付的里程碑，并让团队在冲突目标里达成共识。

本讲的目标很简单：把第二类人的底盘讲清楚，再把第一类人的新技能正确插到工程体系里。你会看到一张完整的「AI 架构师技能树」，以及一张「工具对照表」——不是为了堆名词，而是为了让你在团队里 说同一种语言、选同一种工具链、把 CodeSentinel 做成可演进平台。

一句话总结本讲结论：传统架构能力决定系统能不能长期活；AI 新技能决定你在高变更速率下还能不能守住长期。两者不是替代关系，而是乘法关系。

全局视角：从「技能清单」到「可执行工程体系」

为什么需要「融合栈」而不是「新栈取代旧栈」

AI 编码工具带来的典型变化是：实现层产出加速，但 系统层约束并不会自动出现。如果你只有传统架构能力，你可能擅长画边界，却缺乏把边界编码成机器可执行规范与审核产物的能力；如果你只有 AI 新技能，你可能能快速生成代码，却缺乏判断「这份快是否以可维护性为代价」的框架。

因此，AI 架构师的定义在本课程里非常务实：能用架构原则定义系统，能用工程手段让原则落地，能用 LLM 提升语义层面的审计带宽，同时保持确定性与可观测性。

Mermaid：AI 架构师「双螺旋」能力模型

flowchart TB
  subgraph Classic["传统架构能力（确定性底盘）"]
    C1[Clean Architecture / 分层与依赖规则]
    C2[DDD / 限界上下文 / 聚合]
    C3[微服务 / 模块化单体 / 边界演进]
    C4[分布式系统 / 一致性 / 容错]
    C5[系统设计 / 容量 / 成本 / SLO]
  end

  subgraph Modern["AI 时代新技能（高带宽增强）"]
    M1[AGENTS.md / 规范即代码]
    M2[AI Code Review / 结构化审计]
    M3[LLM 应用架构 / RAG / Agent]
    M4[面向架构的提示工程 / 上下文打包]
    M5[数据与密钥边界 / 合规治理]
  end

  Classic <-- 互相约束与增强 --> Modern
  Classic --> Platform["CodeSentinel 平台能力"]
  Modern --> Platform

Mermaid：技能树（学习路径与模块映射的总览）

mindmap
  root((AI架构师技能树))
    传统架构底盘
      Clean Architecture
      DDD战略战术
      SOLID与演进
      微服务与EDA
      分布式与CAP
      系统设计面试级能力
    AI工程增强
      规范写作与版本化
      LLM编排与工具调用
      RAG与向量索引
      观测成本与安全
      多模型路由与降级
    平台与治理
      PR门禁
      证据链报告
      质量评分卡
      技术债务度量
      团队协作契约

核心知识点：传统能力逐项拆解（你真正要会用的是什么）

1）Clean Architecture：不是分层洁癖，而是依赖方向治理

Clean Architecture 常被误读成「多造几个目录」。它的工程价值在于：把不稳定的东西（框架、数据库、UI）推向外层，把稳定的核心规则留在内层，并用依赖规则防止「外层需求把内层污染」。

在 AI 时代这一点更重要：模型生成的代码最容易出现「为了省事直接调用基础设施」。因此 AI 架构师必须会把原则讲成 可检查规则，例如：

domain 不引用 fastapi
application 不直接访问 ORM Session
infrastructure 实现接口，但不反向要求 application 了解自己细节

这些规则未来会进入 CodeSentinel 的 架构合规策略包。

2）DDD：战略设计比战术模式更决定成败

很多团队只学了实体、值对象、仓储，却在战略层失败：同一个词在两个团队含义不同，导致系统无法演进。AI 架构师要特别关注：

限界上下文（Bounded Context）：哪些模型允许同名不同义？
上下文映射：合作关系、防腐层、开放主机服务等如何选？
聚合边界：一致性边界在哪里，事务边界在哪里？

当你用 AI 生成模块时，如果没有上下文地图，模型会「自动补全」出一堆看似合理但语义冲突的类型名——这就是治理要前置的原因。

3）微服务 / 模块化单体：先解决边界，再解决部署

微服务不是目的，独立演进与故障隔离才是。AI 时代常见误区是：AI 帮你拆了很多服务，但共享库、数据库、配置、日志格式没有同步治理，最终形成「分布式单体」。

AI 架构师需要掌握：

什么时候该模块化单体（减少网络与运维复杂度）
什么时候该拆分（团队规模、发布频率、故障爆炸半径）
服务间通信模式（同步 REST/gRPC、异步消息、Outbox）

4）分布式系统：把「会背八股」变成「会做取舍」

你需要的不只是名词表，而是能在评审中指出：

这个接口是否需要 幂等键
这次改动是否引入双写或 跨服务事务幻想
缓存一致性策略是否匹配业务容忍度
超时、重试、熔断是否可能放大故障（重试风暴）

5）系统设计：把业务需求翻译成可运维架构

系统设计能力在 AI 时代反而更值钱，因为 AI 很容易给出「通用模板答案」。人类架构师的价值在于把约束讲清楚：QPS、延迟、成本上限、一致性、合规、团队技能栈。

核心知识点：AI 时代新技能逐项拆解（你要补的不是「更多 prompt」）

1）AGENTS.md / 规范文件：让 AI 默认走对路

AGENTS.md（以及各工具生态的规则文件）本质是 把团队共识结构化。好的规范包含：

项目结构与禁止事项（比「请写干净代码」有用一万倍）
测试与提交要求
安全红线（密钥、日志、依赖来源）
领域术语表（减少模型胡编业务词）

2）AI Code Review：从「聊天式建议」到「可门禁的报告」

AI 审核的关键不是「像人一样挑刺」，而是：

输出结构化 findings（严重级别、维度、证据）
与静态分析互补（先规则后模型）
能解释「违反了哪条团队规则」（可追溯）

这正是 CodeSentinel 的产品形态。

3）LLM 应用架构：RAG、Agent、工具调用如何组合

你需要理解典型组件：

检索：代码库、文档、历史 PR、规范库
编排：多步推理、工具调用、失败重试
结构化输出：JSON schema / Pydantic 校验
运行与治理：缓存、限流、密钥、数据脱敏、观测

4）面向架构的提示工程：上下文打包（Context Packing）

架构师使用 AI 的方式与普通开发不同：你会更强调：

输入边界（相关模块、接口契约、非目标）
决策记录（ADR 摘要）
风险优先级（性能 vs 交付 vs 安全）

5）安全与合规：默认假设「模型不可信」

平台侧必须假设：

提示注入、数据泄露、供应链风险都存在
因此要有 脱敏、最小权限、审计日志、人工裁决点

核心知识点：技能如何互补（1+1>2 的典型组合）

Clean Architecture + 规范文件：把依赖规则写进 AGENTS.md，同时让 CodeSentinel 扫描 import 图做双重校验。
DDD + RAG：把上下文地图与术语表向量化，审核时检索「该改动是否引入跨上下文耦合」。
分布式基础 + AI 审核：让模型重点解释「这次改动对超时/重试/幂等的影响」，但仍由规则引擎校验是否缺少幂等键字段。
系统设计 + 多模型路由：低成本模型做初筛，高能力模型只在 blocker 疑似时触发（成本与质量平衡）。

对照表：技能领域 → 典型工具 / 实践（不求全，但求可落地）

技能领域	你要达成的能力	常见工具与实践（示例）	本课程对应模块
Clean Architecture	依赖方向可检查	import-linter、模块边界测试、分层目录契约	模块二 + 模块四（合规）
DDD	上下文一致性与演进	事件风暴产出、上下文地图、ADR	模块二
微服务 / EDA	边界清晰、消息可靠	Kafka/RabbitMQ、Outbox、契约测试	模块二
分布式基础	容错与一致性取舍	超时/重试策略、幂等、Saga/补偿叙事	模块二
系统设计	约束驱动的拓扑	容量估算、缓存、分片、读写分离讨论框架	模块二
规范工程	规范可版本、可执行	AGENTS.md、CODEOWNERS、规则解析引擎	模块三
AI Code Review	结构化审计与门禁	LangChain、LLM JSON mode、策略包	模块四
LLM 应用架构	可观测、可替换	FastAPI、向量库、OpenTelemetry、提示模板管理	模块五
协作治理	质量文化落地	PR 模板、评分卡、技术债务看板	模块六

代码实战：把「技能映射」写进 CodeSentinel 的插件接口

下面示例展示一种工程化思路：把不同技能领域映射为可插拔的 PolicyChecker， orchestrator 负责排序（先确定性、后概率性）。这会让后续课程添加静态规则、LLM 审核、RAG 引用变得自然。

# app/policies/base.py
from __future__ import annotations

from typing import Protocol

from app.schemas.review import Finding, ReviewRequest


class PolicyChecker(Protocol):
    name: str

    async def check(self, req: ReviewRequest) -> list[Finding]:
        ...

# app/policies/architecture_import_guard.py
from __future__ import annotations

from app.schemas.review import Finding, ReviewDimension, ReviewRequest


class ArchitectureImportGuard:
    """
    传统架构技能 -> 可执行规则（示例）：
    后续可替换为真实 import 图分析或 AST 解析。
    """

    name = "architecture.import_guard"

    async def check(self, req: ReviewRequest) -> list[Finding]:
        findings: list[Finding] = []

        # 教学演示：如果约束里出现关键字，则产生 warn/blocker
        joined = "\n".join(req.constraints).lower()
        if "forbidden_layer" in joined:
            findings.append(
                Finding(
                    severity="blocker",
                    dimension=ReviewDimension.architecture,
                    title="检测到明确的层级违规约束被触发（示例）",
                    evidence=(
                        "constraints 中包含 forbidden_layer 标记。"
                        "请在 diff 中定位跨层 import，并改为依赖倒置。"
                    ),
                )
            )
        return findings

# app/policies/llm_semantic_draft.py
from __future__ import annotations

from app.schemas.review import Finding, ReviewDimension, ReviewRequest


class LLMSemanticDraftChecker:
    """
    AI 新技能 -> 语义审核（占位）：
    模块四将接入 LangChain，并加入：
    - 结构化输出解析失败重试
    - 证据引用（文件/函数）校验
    """

    name = "llm.semantic_draft"

    async def check(self, req: ReviewRequest) -> list[Finding]:
        # 教学占位：强调“概率性组件”默认不应直接给 blocker，除非强证据链路完善
        return [
            Finding(
                severity="info",
                dimension=ReviewDimension.maintainability,
                title="LLM 语义审核已排队（占位）",
                evidence=(
                    f"task_id={req.task_id}；"
                    "后续将把规范库检索结果作为上下文，输出带引用的 findings。"
                ),
            )
        ]

# app/services/review_orchestrator.py（扩展版片段）
from __future__ import annotations

from app.policies.architecture_import_guard import ArchitectureImportGuard
from app.policies.llm_semantic_draft import LLMSemanticDraftChecker
from app.schemas.review import ReviewRequest, ReviewResult


class ReviewOrchestrator:
    def __init__(self) -> None:
        # 顺序即策略：先确定性规则，再进入 LLM
        self._checkers = [
            ArchitectureImportGuard(),
            LLMSemanticDraftChecker(),
        ]

    async def run(self, req: ReviewRequest) -> ReviewResult:
        findings = []
        for c in self._checkers:
            findings.extend(await c.check(req))

        summary = (
            "本版本演示“技能映射=插件化策略”："
            "传统架构规则与 LLM 语义审核分层接入 CodeSentinel。"
        )
        return ReviewResult(task_id=req.task_id, summary=summary, findings=findings)

你可以从这段代码读出本讲的主线：AI 架构师不是只会写文档的人，而是能把文档变成策略、把策略变成服务的人。

生产环境实战：选工具链时如何避免「工具越多，治理越弱」

1）先定义「策略来源」：团队规范到底是谁说了算？

工具链里常见混乱是：IDE 规则一套、CI 一套、LLM 提示一套，三套互相矛盾。建议明确：

单一事实来源（SSOT）：架构红线以 ADR + 规范库为准
可版本化：规范变更要走 PR，像代码一样审计
可映射：每条红线能映射到 CodeSentinel 的一个 checker 或一个提示模板段落

2）向量库不是越早越好，索引质量才是瓶颈

很多团队一上来就上向量检索，却把垃圾文档、过期 Wiki、互相矛盾的指南索引进去，RAG 会变成「引用胡说」。生产路径应是：

先清洗规范库与术语表
再做增量索引与版本戳
审核报告必须附带 引用片段与版本

3）LangChain 的价值在编排边界，不在「魔法」

在生产里，LangChain（或同类框架）解决的是：把多步流程标准化，并与观测系统对接。你要警惕：

隐式状态过大导致成本失控
工具权限过大导致安全风险
输出不稳定导致门禁误判

对应策略是：工具最小权限 + 结构化输出强校验 + 关键步骤人工复核点。

4）把技能树映射到团队岗位：不是每个人都同一深度

一个可落地的分工方式是：

架构师：维护上下文地图、ADR、策略包优先级
平台工程：维护 CodeSentinel、CI 门禁、观测与成本
业务工程：在规范内高效使用 AI，并承担合入质量

CodeSentinel 映射表：子系统 ↔ 技能（建议你打印贴在笔记首页）

CodeSentinel 子系统	依赖的传统技能	依赖的 AI 新技能	说明
FastAPI 网关与鉴权	系统设计、基础安全	密钥管理、提示注入防护	对外边界与最小权限
审核编排（LangChain）	模块化、依赖注入	Agent/工具调用、结构化输出	把流程工程化
规则引擎 / 策略包	Clean Architecture、DDD	规范解析、规则版本化	先确定性后概率性
RAG 索引子系统	文档治理、领域术语	向量库、召回评测	让引用可信
报告与看板	SLO/度量思维	质量评分与可视化	让治理可被管理

本讲小结：你不是在学「更多工具」，而是在拼一张可执行地图

mindmap
  root((第02讲小结))
    双螺旋模型
      传统底盘
      AI增强
    传统技能
      CleanArch
      DDD
      微服务EDA
      分布式
      系统设计
    AI技能
      规范工程
      AI审核
      LLM架构
      上下文打包
      安全合规
    工程落点
      CodeSentinel插件化
      策略包分层
      SSOT规范库

思考题

你们团队目前是否存在 三套规则互相打架 的现象？如果只能选一条作为 SSOT，你会选 ADR、CI 规则，还是 LLM 提示词？为什么？
就 CodeSentinel 而言，你认为第一版 MVP 更应该优先做 import 图规则，还是 RAG 引用式审核？你的判断依据是什么（成本、风险、团队熟练度）？
选一个你熟悉的业务域，写出 10 个「领域术语表」词条，看看它们是否能显著降低 AI 生成代码的语义漂移。

下一讲预告

下一讲进入模块一的关键论题：架构决策为什么不能交给 AI。我们会用 CAP 取舍、技术债务与组织动态等案例说明：AI 能解释原则，但无法替你承担权衡后果；并给出「何时用 AI、何时必须人类裁决」的决策树，同时把 CodeSentinel 的设计理念定位成 确定性外壳包裹概率性执行。

附录：本周练习（强烈建议完成）

画出你们系统当前的 上下文地图（哪怕很粗糙），并标出最容易被 AI 生成代码破坏的边界。
列出 5 条你认为必须自动化门禁的架构红线，把它们改写成 可检测 的陈述（例如「禁止出现 X 依赖 Y」）。

02-模块一-全景认知 第02讲-AI 架构师技术栈全景图 - 传统架构能力 + AI 新技能的完美融合