AI × 软件 系列第 4 篇 | 公众号首发

如果你是一个架构师，过去二十年你的工作建立在一个基本假设之上：

给定相同的输入，系统应该产生相同的输出。

这叫确定性。整个软件工程的方法论——单元测试、集成测试、回归测试、代码审查、形式化验证——都建立在这个假设之上。你测试过的路径，下次还会走。你修复过的 bug，下次不会再出现。

然后 AI 来了。

你在系统的核心逻辑里放进了一个大语言模型。同样的用户提问，它今天回答”是”，明天可能回答”是的，当然”，后天可能回答”根据我的分析，答案是肯定的”。

语义相同，表达不同。大部分时候没问题。

但偶尔，它会回答一些微妙地不同的东西。甚至偶尔，它会回答一些完全错误的东西。

你的系统里住进了一个概率性的大脑。你所有关于确定性的假设，都需要重新审视。

· · ·

一、确定性系统 vs 概率性系统

先定义清楚这两个概念。

确定性系统

输入 A → 处理逻辑 → 输出 B（永远是 B）

传统软件就是确定性系统。2 + 2 永远等于 4。SELECT * FROM users WHERE id = 1 在数据不变的情况下永远返回同一行。如果结果变了，一定是 bug。

概率性系统

输入 A → AI 处理 → 输出 B₁ 或 B₂ 或 B₃（语义接近但不完全相同）                  → 偶尔输出 C（错误但自信的回答）

AI 组件天然是概率性的。即使把 temperature 设为 0，不同的上下文、不同的 prompt 顺序、甚至模型的微小更新，都可能改变输出。

问题来了：怎么在一个确定性的系统里，嵌入一个概率性的组件，而不让整个系统变得不可靠？

这就是 AI 时代软件架构的核心挑战。

· · ·

二、架构范式的四个转变

转变 1：从”信任代码”到”验证输出”

在传统架构里，你信任你的代码。函数写对了，它就会一直对。你的防御性措施（try-catch、类型检查）是为了应对外部输入的不确定性——用户可能输入乱七八糟的东西。

在 AI 架构里，不确定性来自系统内部。你的 AI 组件可能在任何时候给出意料之外的输出。

这意味着你需要一种新的架构模式：AI 组件的每一个输出，都必须经过验证层，才能进入下游逻辑。

┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐ │  用户输入  │ ──→ │  AI 处理  │ ──→ │  验证层   │ ──→ │ 业务逻辑  │ └──────────┘     └──────────┘     └──────────┘     └──────────┘                                        │                                        ↓ 验证失败                                   ┌──────────┐                                   │  回退逻辑  │                                   └──────────┘

验证层做什么？

• 格式验证
  
  ：输出是否符合预期的数据结构（JSON Schema、类型检查）
• 语义验证
  
  ：输出是否在合理范围内（价格不能是负数、日期不能在未来）
• 一致性验证
  
  ：输出是否与系统的其他状态一致
• 安全验证
  
  ：输出是否包含不应暴露的信息、是否被 prompt injection 污染

验证层不是可选的。它是 AI 架构的必备组件。 没有验证层的 AI 系统，就像没有安全带的汽车——大部分时间没事，出事就是大事。

转变 2：从”单一路径”到”双路径”

传统系统：一条路径，要么成功，要么报错。

AI 系统需要双路径架构：一条 AI 路径处理常规场景（高效但不 100% 可靠），一条规则路径作为兜底（低效但确定可靠）。

用户请求 ──→ AI 路径（快、智能、95% 可靠）──→ 验证通过 ──→ 返回结果               │               ↓ 验证失败 / 超时 / 异常               规则路径（慢、笨、100% 可靠）──→ 返回结果

举个具体例子：智能客服系统。

• AI 路径：大语言模型理解用户问题，生成个性化回答
• 规则路径：关键词匹配 + 决策树，给出标准答案
• 触发回退的条件：AI 回答置信度低、涉及敏感话题（退款、投诉、法律）、AI 服务超时

双路径的设计哲学是：用 AI 做 95% 的场景（提升体验），用规则兜 5% 的底（保证底线）。

很多团队犯的错误是试图让 AI 处理 100% 的场景。这在技术上不可能，在业务上很危险。

转变 3：从”静态测试”到”动态评估”

传统测试：写测试用例，断言输出等于预期值。assert result == 42。

AI 组件怎么测试？你不能断言输出等于某个固定值，因为每次输出都可能不同。

你需要的是评估（Evaluation），而不是传统意义上的测试。

# 传统测试 def test_calculate_tax():     assert calculate_tax(1000) == 130  # 确定性断言  # AI 评估 def eval_customer_response():     response = ai_generate_response(“我要退货”)      # 不检查具体文本，检查属性     assert contains_return_policy(response)      # 包含退货政策     assert tone_is_professional(response)         # 语气专业     assert no_hallucinated_policy(response)       # 没有编造政策     assert response_length < 500                  # 长度合理     assert no_sensitive_data_leaked(response)     # 没有泄露数据

关键区别：传统测试检查精确值，AI 评估检查属性和边界。

而且 AI 评估不能只跑一次。你需要跑很多次（100 次、1000 次），统计通过率，设置质量门槛：

• “退货回复的政策准确率必须 > 99%”
• “回复语气的专业度评分必须 > 4.5/5”
• “幻觉率必须 < 1%”

这更接近质量工程（Quality Engineering）而非传统的测试工程（Test Engineering）。

转变 4：从”版本发布”到”持续调优”

传统软件的发布是离散的：v1.0 → v1.1 → v2.0。每个版本是一个确定的状态。

AI 系统的行为会因为模型更新而改变——即使你的代码一行没动。OpenAI 更新了 GPT 的权重，你的系统行为就可能改变。Anthropic 发布了新版 Claude，你之前调好的 prompt 可能效果变了。

这意味着：

• 监控比测试更重要
  
  。你不能只在发布前测试，你需要持续监控线上系统的 AI 输出质量。
• Prompt 是新的配置
  
  。它需要像配置一样被版本管理、A/B 测试、灰度发布。
• 模型升级 = 系统变更
  
  。切换模型版本应该跟代码部署一样谨慎，有回滚方案。

· · ·

三、一个参考架构

综合上面的讨论，给一个 AI 时代的应用参考架构：

┌─────────────────────────────────────────────────┐ │                  应用层 (Application)              │ │  用户界面 / API / 业务流程编排                      │ ├─────────────────────────────────────────────────┤ │                  编排层 (Orchestration)            │ │  意图识别 → 任务路由 → Agent 调度 → 结果聚合        │ ├──────────────┬──────────────┬───────────────────┤ │   AI 路径     │   规则路径    │    混合路径        │ │  LLM / Agent │  规则引擎     │   AI + 规则校验    │ ├──────────────┴──────────────┴───────────────────┤ │                  护栏层 (Guardrails)              │ │  输入过滤 / 输出验证 / 安全检查 / 合规审计          │ ├─────────────────────────────────────────────────┤ │                  评估层 (Evaluation)              │ │  质量监控 / 漂移检测 / A/B 测试 / 成本追踪          │ ├─────────────────────────────────────────────────┤ │                  基础设施层 (Infrastructure)       │ │  模型网关 / Prompt 管理 / 缓存 / 向量数据库         │ └─────────────────────────────────────────────────┘

几个要点：

护栏层是独立的一层，不是散落在各处的 if-else。把所有的验证、过滤、安全检查集中管理，便于统一策略和审计。

评估层持续运行，不只在发布时运行。它监控 AI 输出的质量漂移——如果某天突然发现幻觉率从 0.5% 升到了 3%，可能是模型提供商做了更新，你需要及时响应。

模型网关统一管理所有 AI 调用。它负责模型选择（简单任务用小模型、复杂任务用大模型）、负载均衡、成本控制、调用审计。直接在业务代码里硬编码 openai.chat.completions.create() 是 AI 时代的反模式。

· · ·

四、六个架构反模式

在实践中看到最多的错误：

反模式 1：”AI 是万能的”

把所有逻辑都交给 AI，没有规则兜底。AI 宕机或抽风时，整个系统瘫痪。

正确做法：关键路径必须有非 AI 的降级方案。

反模式 2：”Prompt 写在代码里”

Prompt 散落在各个文件的字符串常量里，改一个 prompt 要发一次版本。

正确做法：Prompt 集中管理，支持热更新和版本回滚。

反模式 3：”先做再验”

AI 的输出直接进入业务逻辑，出了问题再修。

正确做法：AI 输出必须经过验证层，验证失败走降级路径。

反模式 4：”一个模型打天下”

所有场景用同一个模型。简单的分类任务也用 GPT-4，成本爆炸。

正确做法：按任务复杂度分级，简单任务用小模型、嵌入模型、甚至规则。

反模式 5：”不监控 AI 输出”

上线后不看 AI 输出质量，直到用户投诉才发现问题。

正确做法：持续采样评估，设置质量告警。

反模式 6：”AI 有完整权限”

AI Agent 能直接写数据库、调外部 API、发邮件，没有权限控制。

正确做法：最小权限原则。AI 的每一个副作用操作都需要显式授权，关键操作需要人工确认。

· · ·

五、给架构师的行动建议

短期（现在就做）：

1. 审计你的系统里有哪些 AI 调用没有验证层，加上
2. 把散落的 prompt 集中到配置管理
3. 给 AI 输出加上基础监控（至少监控错误率和延迟）

中期（3-6 个月）：

1. 建立 AI 输出的评估体系，定义质量指标和门槛
2. 实现双路径架构，至少在关键业务上有规则兜底
3. 引入模型网关，统一管理 AI 调用

长期（6-12 个月）：

1. 构建端到端的 AI 质量平台：评估 + 监控 + 告警 + 自动回滚
2. 探索 AI 原生架构——不是在传统架构上”贴” AI，而是以 AI 为核心重新设计

· · ·

结语

过去二十年，我们学会了如何构建可靠的确定性系统。微服务、容器化、CI/CD、SRE——这些都是确定性时代的方法论。

现在，我们需要学会构建可靠的概率性系统。

这不是一个小的技术调整，而是一次架构范式的根本转变。它要求我们重新思考”可靠”意味着什么——从”每次都对”变成”在可接受的概率范围内对，且在不对的时候能安全降级”。

这是 AI 时代对架构师的核心挑战。

也是最有价值的技术问题。

下一篇预告
《测试、质量与信任危机》——AI 生成的代码谁来保证质量？当”写测试的人”和”写代码的人”都是 AI 时，我们还能信任什么？

关于本系列

「AI × 软件」是一个探讨 AI 如何从根本上改变软件行业的系列。不做工具测评，不预测谁会失业。只关注一个问题：底层逻辑在怎么变，以及你该如何应对。

— END —