Claude Code 的源码揭示了一个一致的哲学：用确定性工程处理控制问题，用概率性 AI 处理智能问题。这不是关于赶时髦——而是理解每种方法在哪些地方擅长。

核心原则

用确定性机制处理可以用规则解决的事情。把 AI 留给需要判断的事情。

这一原则贯穿 Claude Code 的整个架构。让我们检查具体例子。

例子 1：用正则表达式做情绪检测

当 Claude Code 检测到用户挫败感时，它不会调用 LLM 来分析情绪。它使用正则表达式：

const negativePattern = /\b(wtf|wth|ffs|omfg|shit|dumbass|horrible|
awful|piss(ed|ing)? off|what the (fuck|hell)|fucking? broken|
fuck you|screw (this|you)|so frustrating|this sucks|damn it)\b/;

export function matchesNegativeKeyword(input: string): boolean {
  return negativePattern.test(input.toLowerCase());
}

为什么用正则而不是 LLM？

方法	延迟	成本	一致性	精确率
正则	<1ms	$0	100%	对显式模式高
LLM	100-500ms	$$	可变	对细微差别高，对明显情况低

对于检测显式挫败感，正则胜出：

速度：即时检测，无 API 调用
成本：免费
可靠性：相同输入总是产生相同输出
精确率：捕获重要明显情况

LLM 在以下情况更好：

检测细微挫败感（"有趣的选择..."）
混合信号
上下文相关的语气

但对于明显情况？正则正确。

例子 2：XML 标签作为内部协议

Claude Code 大量使用 XML 标签，但不像"提示词工程技巧"。它们是内部协议：

graph LR
    A[定义协议] --> B[用标签编码]
    B --> C[统一管道]
    C --> D[按规则消费]
    
    A: xml.ts 定义标签
    B: wrapInSystemReminder()
    C: smooshSystemReminderSiblings()
    D: UI 渲染、模型解析

协议设计

标签集中定义（xml.ts），而不是分散在提示词中
内容编码带有标签后再进入管道
管道处理通过统一逻辑处理带标签的内容
消费者按文档化规则解析标签

为什么这很重要

没有协议：

提示词工程变得分散、不一致
模型基于训练而非显式定义来解释标签
UI 渲染依赖于模型输出格式
系统行为变得不可预测

有协议：

标签有显式语义
模型收到一致指令
UI 确切知道如何渲染
系统行为可审计

例子 3：结构化输出作为工具

Claude Code 不要求模型"请输出 JSON 格式"。它把结构化输出做成工具：

flowchart TD
    A[Schema 定义] --> B[创建工具]
    B --> C[模型使用工具]
    C --> D{验证通过？}
    D -->|否| E[返回错误]
    E --> C
    D -->|是| F[存储结果]

强制机制

Schema 验证在服务端发生，而不是通过提示词
模型必须使用工具来产生结构化输出
无效结果自动触发重试
只有有效结果进入工作流

这与以下方式根本不同：

// 坏方法
"请以包含字段 name、age、occupation 的 JSON 格式输出你的响应"

// 好方法
const structuredOutputTool = {
  name: 'structured_output',
  description: '提交结构化结果',
  input_schema: {
    type: 'object',
    properties: {
      name: { type: 'string' },
      age: { type: 'number' },
      occupation: { type: 'string' }
    },
    required: ['name', 'occupation']
  },
  validate: ajv.validate(schema, result)
};

模式：工程约束层

Claude Code 实现了分层约束方法：

层级	机制	控制什么
生成前	正则、规则	可以尝试什么
生成中	工具 schema、协议	输出如何格式化
生成后	验证、重试	输出是否可接受
失败时	回退逻辑	约束失败时发生什么

为什么分层重要

单层约束失败：

纯提示词 = 模型可以忽略
纯验证 = 浪费生成
无回退 = 边缘情况下系统崩溃

多层约束成功：

规则在生成前防止明显失败
工具在生成期间强制结构
验证捕获剩余问题
回退确保优雅降级

概率性方案的成本

用 LLM 处理可以用规则解决的事情是昂贵的：

延迟影响

正则情绪检测: <1ms
LLM 情绪检测: 100-500ms
用户感知: 500ms = "慢"

成本影响

1000 次情绪检查用正则: $0
1000 次情绪检查用 LLM: $0.10-1.00
规模化后：显著

一致性影响

正则: 相同输入 → 相同输出（确定性）
LLM: 相同输入 → 相同输出（概率性，但经常变化）

何时使用每种方法

使用确定性工程当：

模式定义良好
漏报可接受
延迟重要
成本重要
一致性关键

使用 LLM 当：

模式模糊
上下文重要
细微差别重要
边缘情况占主导
规则会过于复杂

决策框架

def use_llm_vs_rule(pattern_type, requirements):
    if is_well_defined(pattern_type) and requirements.latency < 50ms:
        return "RULE"
    if requires_context_or_nuance(pattern_type):
        return "LLM"
    if requires_fuzzy_matching(pattern_type):
        return "LLM"
    if cost_budget < threshold and accuracy_threshold is low:
        return "RULE"
    return "LLM"  # 不确定时默认 LLM