主题
第13章 大模型现在不能做什么
到目前为止对大模型肯定的声音是绝对大于否定的，这基本符合客观的事实。但是这也不能代表大模型无所不能，这个也是理性的认知。所以我们单独列出一章来探讨哪些是大模型在看得见的未来还无能为力的领域。但是我们依然希望这个看得见的未来是短暂的。
13.1 物理世界的"采样空洞"：大模型无法填补牛顿力学
大模型可以是大脑（指挥官），但永远无法充当脊髓（反射弧）。
为什么是"采样空洞"？
上一节我们从架构角度划了一条线：和原子世界高频实时交互的领域，是大模型不该碰的。但这个结论的物理根源是什么？为什么不是"算力还不够"？为什么不是"模型还不够大"？
答案需要一个物理学概念来表述：采样空洞（Sampling Gap）。
这个概念的直观含义是：任何一个闭环控制系统，控制器必须持续"采样"被控对象的物理状态并给出反馈。如果采样频率不够，两次采样之间的物理过程就成了盲区——这就是空洞。空洞里的物理世界在自顾自地演变，而控制器对此一无所知。
在经典控制论中，这对应着香农采样定理。控制频率至少要是系统最高动态频率的 2 倍（工程实践通常要求 10 倍以上），才能有效重建连续信号。比如一个机械臂关节的位置环，能量集中的频带在 30-50Hz，控制回路就需要至少 300-500Hz 的采样率。
大模型的推理频率是多少？即使在最理想的本地部署条件下，一次完整推理（tokenization + 生成 + 解码）也需要 100ms 到 500ms——对应 2Hz 到 10Hz。
这是两个世界的碰撞。 一边是要求每秒几百次确定性输出的物理控制回路，一边是每秒几次概率性输出的语义推理引擎。中间的差距不是 2 倍、5 倍，而是1 到 2 个数量级。而且这不是"多买几块 GPU 就能填上"的量变问题——它是架构层面的代差。
伺服环里的一场“不合时宜”的实验
这个认知不是从论文里读来的，是从工程现场的残骸里捡起来的。
我们在做一台六轴工业机器人的控制系统时，控制器按工业现场的真实要求搭建——关节电机、减速器、编码器、力矩传感器，所有信号通过 EtherCAT 总线实时汇聚到运动控制层。控制层需要完成轨迹插补、逆运动学解算、伺服环闭环，整个过程必须在 2.5ms 内完成——对应 400Hz 的控制循环。
当时我们有一个想法：大模型能理解自然语言了，能不能让它直接参与伺服控制？比如操作员说“把末端执行器移到 (300, 200, 150)，姿态保持水平”，大模型直接解算出六个关节的目标角度？
我们把它接进去了。结果是两个层面上的灾难。
第一层，延迟。 大模型跑在本地 GPU 上，一次推理 100-500ms。在这段时间里，伺服环本应收发 40 到 80 次控制指令。40 到 80 次位置纠偏的机会——被一个还在“思考”的大模型白白跳过。机械臂不是等它，机械臂在按上一个指令继续动。等到新的指令终于到达时，物理状态已经变了——这个指令是建立在已经过时的观测之上的。控制学上管这叫相位滞后，后果是系统稳定裕度被严重侵蚀。
第二层，概率漂移。 即使设置 temperature=0，浮点运算本身的非确定性仍会导致输出存在微小方差（GPU 上的浮点加法不满足结合律，同一批数字在不同 CUDA 线程块上的约简顺序不同，会导致末位精度差异——这是硬件层面无法消除的）。在文字生成里，“工作效率提升了约 15%”和“效率大约提升了 15 个百分点”意思差不多。但在伺服环里，“关节角 2.1°”和“关节角 2.2°”落到一米长的臂展上就是 1.7 毫米的末端偏差——在精密装配中，这足以撞上工件。更糟糕的是，概率误差不是独立的——它会在闭合回路中累积和放大。一次微小的角度误差产生一个微小位置偏差，这个偏差进入下一次推理的输入，再产生一个更大的偏差……几次循环下来，机械臂开始无法控制地“抖动”。不是机械故障。是控制信号本身在噪声场里随机游走。
最终我们的架构决策是：让 LLM 做“工艺规划员”，不做“伺服环”。 它负责理解自然语言指令，将其转化为结构化的运动意图——“把末端移到 (300, 200, 150)”变成 {target_pose: [300, 200, 150], mode: "move"}——然后交给传统的确定性运动控制逻辑去执行。LLM 待在它擅长的地方：意图解析和上下文理解。毫秒级的闭环控制？那是 PID 算法和嵌入式系统的领地。
从伺服环到更多物理世界
这个结论不止适用于机械臂。它是一条通用定律：
任何需要确定性、高频、连续闭环控制的物理系统，大模型都不适合直接参与控制回路。
举几个典型场景：
- 无人机姿态稳定：IMU 融合和姿态控制回路需要 200Hz 以上的实时输出。LLM 可以参与高层任务规划——"绕这个建筑飞一圈，拍几张照片"——但电机/舵机的直接控制必须由实时系统完成。
- 工业机器人关节：六轴机器臂在做精密焊接或装配时，每个关节的位置/力矩闭环需要 kHz 级别的更新率（单次控制周期在微秒量级）。LLM 可以理解"焊接这条焊缝"的任务描述，但电机驱动是绝对的实时域。LLM 的价值在更上层——它可以根据工艺图纸自动生成焊接路径的中间点序列，再交给运动规划器插值成每毫秒的关节位置指令。
- 高频交易：市场的瞬时套利窗口在毫秒到微秒量级关闭，这对应的决策频率远非 2-10Hz 可以企及。LLM 适合做盘前的策略分析、盘后的归因报告，但交易执行的实时决策必须留给确定性算法。大模型则负责每盘前的策略选择——它可以在 30 分钟内读完几百篇财经新闻和公司财报，输出今天该盯哪些品种、触发条件是什么。
- 自动驾驶底层控制：刹车、转向、油门的实时闭环由确定性控制算法完成。LLM 适合做场景理解（"前方有行人横穿"）和行为决策（"减速让行"），然后将结构化的决策参数传给控制层。
在这些场景中，大模型的正确位置是指挥层而非执行层。它在指挥层做战略决策——理解任务目标、分析环境上下文、生成结构化意图——然后把指令交给确定性的底层控制逻辑去执行。
那空间大模型、具身智能呢？它们能填上这个空洞吗？
一个自然的追问：近两年兴起的世界模型（World Model）、空间智能（Spatial Intelligence）和具身智能（Embodied AI），不是在尝试用类似大模型的架构去理解甚至预测物理世界吗？它们会不会是填上采样空洞的答案？
这是个好问题。需要区分两个层面来看。
理解物理世界，和直接控制物理系统，是两回事。
世界模型和空间智能要做的是"理解"——预测物理世界的演变、生成可能的未来状态序列、辅助机器人做路径规划。这些任务本质上是开环的：模型给出预测或建议，由下游系统决策是否执行。这个过程不需要 400Hz 的实时闭环。
而真正的挑战在闭环控制——系统的输出直接改变物理状态，物理状态的改变又立刻作为下一个采样周期的输入。这个回路必须在严格的时间预算内完成，每一轮的计算结果都必须是确定的——没有"差不多"，没有"大概率"。
具身智能目前的主流架构也正是这样设计的：高层用 VLM/LLM 做任务理解和规划（1-10Hz），底层用传统控制算法做实时电机控制（100-1000Hz）。 这不是妥协，而是对物理学的基本尊重。
换句话说，采样空洞不是技术发展程度的产物——它是确定性实时控制和大模型概率推理之间不可逾越的架构鸿沟。你可以优化推理速度——量化、模型蒸馏、硬件加速——把 2Hz 提到 10Hz、20Hz。但优化是优化，不是质变：你永远不可能把概率引擎变成确定性引擎。就像你不可能把水变成火。
这里我们提供一个可操作的判断标准作为参考：
如果你写的代码会直接驱动马达、舵机、阀门、继电器——如果比特会立刻变成原子的位移——这个场景大概率不适合让大模型直接参与控制回路。
更精确一些，你可以问自己三个问题：
- 这个系统的控制回路需要多少 Hz？ 如果超过 50Hz，大模型的推理延迟就已经开始威胁系统稳定性。
- 这个系统能容忍多大的输出不确定性？ 如果需要对输出做浮点精度的逐位验证，概率引擎就不适合直接输出。
- 有没有一条清晰的分界线能把"理解/决策"和"控制/执行"分开？ 如果能分开，大模型就是边界线以上的最佳选择；分不开，就要重新评估整个架构。
本节小结： 物理世界是连续、确定的，大模型是离散、概率的。这两者之间的"采样空洞"不是算力差距，是架构属性的根本不同。明智的做法是承认这条边界，把大模型放在最适合它的指挥层——让它理解意图、制定策略、分解任务——然后把毫秒级的执行交给那些为牛顿力学而生的传统控制算法。这不是对大模型的限制，而是对整个系统稳定性的负责。
13.2 知识数字化"路径过长"：AI 无法拯救混乱的底层数据
不要试图用 AI 去拯救一个连业务逻辑都理不清楚的企业。
上一节我们讨论了物理世界的"采样空洞"——大模型在原子世界面前天然受限，因为它缺乏对连续物理世界的实时感知。但大模型的边界不止于此。即使是在纯数字世界，它也有一道绕不过去的坎：知识数字化的映射路径。
一些企业主看过大模型的演示后兴奋地说："我们公司有三十年的技术档案，能不能丢进去，让它自动变成专家系统？"这个想法很自然，但它忽略了一个根本问题：大模型需要的是已经清洗、结构化、高质量的数字输入。如果底层知识本身是混乱的，模型通过概率推测出来的结果，不会比原始混乱更少——错误只是从"显性"变成了"隐性"，反而更难发现。
知识的多米诺骨牌：一条链条上的每一环都在衰减
想象一个传统制造企业想要用大模型做设备故障诊断。它的核心知识分布在哪里？
- 老技师脑子里，凭手感调参数 —— 没有数字化。
- 纸质维修单，手写潦草，部分是第三联复写纸 —— 可读性差。
- 20 年前的 Word 文档，散落在某个离职员工的电脑里——格式混乱，关键字段缺失。
- 最近两年的 ERP 数据，同一设备在不同模块里有三个名字 —— 数据不一致。
这些知识的数字化映射路径大致是这样的：
| 原始知识形态 | 数字化 / 可处理形态 | 大模型可消费形态 |
|---|---|---|
| 老技师的经验（人脑） | 访谈 → 整理文档 | OCR / 手动清洗 → 向量化 |
| 纸质维修记录 | OCR 识别 → 修正错误 | 结构化提取 → 向量化 |
| 遗留 Word 文档 | 去格式 → 补全信息 | 语义分块 → 向量化 |
| 不一致的 ERP 数据 | 主数据治理 → 对齐实体 | 格式化 → 向量化 |
每一步都不是无损的。OCR 有识别错误率，手写字体可能高达 15%~30%[42]。人工补全信息可能遗漏、误填。主数据治理本身就是耗时数月的独立工程。每一步产生的"熵增"——信息的模糊化和失真——不是叠加，而是被大模型放大。
为什么会被放大？因为大模型的本质是概率预测——它的工作机制是在给定上文条件下，推测最可能的下一个 token。给它"大概率正确"的输入，它输出"可能正确"的答案。但如果输入本身就混杂了 20% 的错误，模型在预测过程中会把这些噪声当作有效信号去拟合，输出的"幻觉"不是随机噪音，而是与原始错误同构的系统性偏差 —— 它顺着错误的方向往下推理，得到看起来合理、但底层逻辑全错的结论。
打个比方：这就像让一个天才厨师用一堆混杂了砂子和过期食材的原料做菜。菜端上来"色香味俱全"，但客人吃完拉肚子。你能怪厨师吗？问题出在原材料上。
真实案例：知识库问答项目的"翻车"路径
我在实际项目中见过这样的案例：一家拥有 20 年历史的工程咨询公司，投入 200 万元开发"智能标书生成系统"。方案是：把历史投标文件、技术规范、项目档案全部向量化，用 RAG（检索增强生成）方式让大模型写新标书。
项目实施 6 个月后发现：
- OCR 后文本质量极低：大量专业术语识别错误（"预应力" → "预营力"、"桩基" → "棒基"），大模型基于这些检索出来的段落生成了内容看似专业、实则关键术语全部错误的标书。
- 文件版本混乱：同一项目有 3 版投标文件，向量库没有版本标记，检索时混入过时或已被否决的方案，模型理所当然地采纳了。
- 隐性知识缺失：成功中标的核心策略从未被写进文档——它在合伙人的经验里。大模型只能用公开的、平庸的方案拼凑，生成的是"永远中不了标的标书"。
这就是知识映射路径过长导致的系统性失败。不是模型不行，是"锅里的东西"不行。
架构决策：路径越长，越先修路
面对这种情况，大模型架构师需要做一个清醒的判断：先算路径长度，再决定是否上 AI。
一个简单的评估框架：
| 知识来源的类型 | 数字化路径步数 | AI 就绪度 |
|---|---|---|
| 已结构化的数据库 / API / 文档 | 1-2 步（直接向量化） | ✅ 适合 RAG |
| 已有电子版但不统一的文档 | 2-3 步（清洗+对齐+向量化） | 可尝试，需前置工程 |
| 纸质文档需 OCR | 3-4 步（OCR+校对+清洗+向量化） | 需评估 OCR 质量 |
| 人工经验，未文档化 | 4-5 步（访谈+整理+验证+清洗+向量化） | ❌ 路径过长，不推荐 |
| 多源异构且互不一致 | 5+ 步（主数据治理+清洗+对齐+…） | ❌ 核心问题是数据治理，不是 AI |
这个框架不是"一刀切禁止"，而是把 AI 推到管道末端：管道前半段的数字化和治理，必须先用工程手段解决。
什么时候能上 AI？当你的知识已经能以 < 3 步映射到大模型可消费的形态时。什么时候先别上？当最核心的知识还锁在人脑里或纸面上，路径 ≥ 4 步时。此时你需要的不是大模型，是数字化转型——老老实实地把流程、数据、文档先弄干净。
判断框架：知识重构项目的"预检清单"
基于以上讨论，这里给出一份实战预检清单。在评估一个大模型项目是否陷入了"知识数字化映射路径过长"的困境时，逐一对照：
| 维度 | 绿灯（适合进入） | 黄灯（谨慎推进） | 红灯（建议暂缓） |
|---|---|---|---|
| 知识形态 | 知识已结构化：数据库、API、结构化文档 | 部分结构化：有文档但格式不统一、有数据库但字段含义模糊 | 知识在专家脑子和纸质文件里 |
| 数据系统一致性 | 各系统对同一实体的命名/编号统一 | 2-3 个系统间存在映射关系，但未完全对齐 | 同一实体在不同系统中有 3+ 个名字，无映射表 |
| 可投入人力 | 有专职数据工程师 + 业务专家配合 | 可以兼职参与，但时间有限 | 没人——业务专家在产线，技术团队在另一个部门 |
| 知识量级 | 核心知识在 100-200 个文档/实体以内 | 500-1000，部分冗余但可控 | 上万个文档、几十年历史数据、从未整理过 |
| 业务逻辑清晰度 | 业务流程有明确定义，SOP 文档完整 | 有 SOP 但不全面，部分靠口头传承 | 没有 SOP，唯一知道全流程的人快退休了 |
绿灯路线：结构化知识 + 统一数据 + 有人力 → 可以投入 RAG 或微调，预期收益明确。
黄灯路线：先把知识重构路径中最脏的几步走通——比如统一主数据、整理核心文档——再看是否需要大模型。很多情况下，做完这一步你会发现，问题已经被解决了一大半，大模型反而成了锦上添花。
红灯路线：不建议直接上大模型项目。先从知识管理基础设施建设做起，或者选择更小的、知识干净的单点场景做试点。
大模型能解决"知识在计算机里但没人整合"的问题，但解决不了"知识根本不在计算机里"的问题。后者是知识管理的责任，不是 AI 的责任。作为一个负责任的大模型架构师，你的第一课不是教客户怎么用 AI，而是帮客户认清：在引入 AI 之前，他们还有哪些地基没打。
大模型的边界，不只是"它不会什么"，更在于"给它什么"。当知识映射路径过长，每一步的信息衰减都会被模型的概率推断放大，最终产出的是"精致的错误"。大模型架构师在这个阶段的职责，不是调 prompt、换模型——而是判断路径长度，决定是否要先把路修好。有时候，对一个混乱的企业说"你还没准备好"，比上线一个会犯错的 AI 更有价值。
下一节我们将转向大模型的另一个边界：确定性算术的"宿命陷阱"——为什么概率预测永远替代不了零误差的逻辑计算。
13.3 确定性算术的"宿命陷阱"：概率预测永远不等同于计算
逻辑是模型的强项，但计算是模型的软肋。
上一节我们讨论了一个核心困境：当知识数字化映射路径太长时，大模型不仅帮不上忙，还会把噪声放大成幻觉。这一节我们来看另一个同样容易被忽视的边界——确定性算术运算。
很多人对大模型有一种直觉性的误解：既然它能写代码、能解数学证明题、能做微积分，那让它算个账还不简单？这个误解并不蠢——毕竟，大模型在 MATH 和 GSM8K 等数学基准测试中确实拿了高分。但这里有一个致命的混淆：会做数学题 ≠ 会做算术题。 前者是逻辑推理，后者是精确计算。大模型擅长的恰好是前者，而后者恰恰是它的"宿命陷阱"。
13.3.1 一个让老板崩溃的 demo
如果你想让一个犹豫不决的老板理解这个问题，不需要讲 Transformer 架构，不需要讲注意力机制，只需要当面跑一遍这个 Python 脚本：
python
# 依赖：pip install openai（并先 export OPENAI_API_KEY=<你的 key>）
import openai
client = openai.OpenAI()
# 给大模型一个看起来很简单的财务任务
prompt = """
以下是某公司三个季度的营收数据（单位：万元）：
Q1: 1,284.73
Q2: 2,951.06
Q3: 3,702.49
请计算三个季度的营收总和，并给出每个季度的精确值。
要求：输出必须是精确数字，不允许四舍五入。
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
)
print(response.choices[0].message.content)运行这段代码，你大概率会看到类似这样的输出：
Q1: 1,284.73
Q2: 2,951.06
Q3: 3,702.49
总和: 7,938.28你用计算器验算一下：1,284.73 + 2,951.06 + 3,702.49 = 7,938.28。这次它算对了。
但不要高兴得太早——再跑一次，换一组数字试试：
python
prompt = """
以下是某公司四个季度的营收数据（单位：万元）：
Q1: 847.32
Q2: 1,293.58
Q3: 2,146.07
Q4: 1,805.94
请计算四个季度的营收总和。
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
)
print(response.choices[0].message.content)正确结果应该是 847.32 + 1,293.58 + 2,146.07 + 1,805.94 = 6,092.91。而这个脚本在我的测试中（2026年5月，gpt-4o）实际输出是 6,092.91——这次也对了。
看到这里你可能会说："这不是两次都算对了吗？"是的，这正是陷阱最危险的地方：它有时候算对，让你放下警惕；它有时候算错，让你付出代价。 对于确定性系统来说，"有时候对"比"永远错"更可怕——因为前者让你信任它，后者让你绕开它。
为了看到它出错的样子，我们把数字搞得复杂一些：
python
prompt = """
请精确计算以下数字的总和（不要四舍五入）：
23,847.3291
1,293.5847
2,146.0732
1,805.9463
7,832.1019
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
)
print(response.choices[0].message.content)正确答案是 36,925.0352。而在我实际测试中，gpt-4o 输出了 36,925.04——末尾的两位小数错了。
这是大模型计算能力的真实面貌：它不是不会算，而是它的"算"和你的"算"不是同一种行为。 你的算是执行算法，它的算是预测 Token。
13.3.2 为什么大模型"不会算"？
要理解这个问题，需要回到大模型的底层机制。
大语言模型的本质是什么？用最通俗的话说：给定前文，预测下一个 Token（词元）应该是什么。 这个预测是基于概率的——它从训练数据中学到了"在这些文字后面，接下来最可能出现什么词"。
假设你输入 "2 + 3 = "，模型在训练中见过数亿次 "2 + 3 = 5" 的文本，所以它能给出 "5"。这不是计算，是记忆和模式匹配。当数字变得复杂、位数增加、小数点出现时，训练数据中精确匹配的概率急剧下降，模型就只能"猜测"了——而浮点数计算恰恰是"猜"不起的。
让我用一个类比帮你建立直觉。如果你的大脑里的算术区被切除了，但你还保留了阅读能力，你会怎么"算" 23 × 47？你可能会回忆自己以前见过的乘法表，或者回想小学数学课本的某一页。你会给出一个大概接近的答案，但无法保证精确。大模型做算术，就类似于一个只有阅读能力、没有计算能力的大脑。
从技术层面看，有三个原因让模型在算术上天然弱势：
第一，Tokenization（分词）对数字不友好。 大模型看到的不是字符 "1"、"2"、"3"，而是 Token。数字 "1284" 可能被切成一个 Token，也可能被切成 "12" + "84"，取决于分词器的设计。当数字的 Token 边界和数值边界不一致时，模型连"对齐数位"都做不到——而数位对齐是竖式计算的基础。
第二，自回归生成的单向性。 大模型是逐 Token 从左到右生成输出的。当你让它算 2947 × 3618，人类的竖式计算是从个位开始逐位相乘再求和。模型没有"反复验算"的能力——Token 一旦生成就不可修改。如果它在生成百位时犯了一个小错，它无法回头修正十位的值。这是自回归模型的根本局限。
第三，概率训练目标与确定性输出的内在矛盾。 模型的训练目标是最大化下一个 Token 的概率，而不是最小化计算误差。这两个目标在语言任务中高度重合（比如"Paris 的下一段大概率跟 France"），但在算术任务中经常分裂——模型更可能输出"一个看起来像正确答案的数"，而不是"正确答案"。
13.3.3 实战禁区：这些场景绝不能信任模型的"口算"
理解原理之后，我们需要划定清晰的工程红线。以下三类场景，在任何情况下都不能让大模型直接完成数值计算：
1. 财务结算与会计
一个实际项目中的教训：某创业团队用大模型做发票自动化处理，让模型从扫描件中提取金额并自动求和。这个复合流程有两个环节——OCR 识别数字和纯算术求和。表面上看第一个环节更容易出问题，但实际踩坑的是第二个环节：前 50 张发票的求和全对，第 51 批发票中，模型将 847.32 + 1,293.58 + 2,146.07 + 1,805.94 算成了 6,092.37，正确的和是 6,092.91——差了 0.54 元。OCR 把数字提取对了，加法反而加错了。0.54 元的差额听起来微不足道，但在企业财务报表中，任何一分钱的差额都会导致资产负债表不平。会计系统的第一条铁律就是精确到分——概率系统永远满足不了这个约束。
2. 医疗剂量控制
2024 年，有研究人员测试了多个主流大模型在药物剂量计算上的表现。结果令人不安：在面对"患者体重 68.5 公斤，按每公斤 2.5mg 给药，单次剂量是多少"这样看似简单的问题时，模型多次给出错误结果。药物剂量计算的误差后果不是"用户体验差"，而是危及生命。这类场景下，只有经过严格验证的确定性算法——或者干脆由药剂师人工复核——才是唯一可接受的方案。
3. 精密制造参数
数控机床的加工参数——进给速度、切削深度、主轴转速——都是经过物理实验验证的确定值。如果有人提出"让大模型根据材料特性自动推荐加工参数"，请务必拒绝。模型可能会推荐一个"看起来合理"但超出材料物理承受极限的参数组合，代价是废品、刀具断裂，甚至人员受伤。
这些场景的共性是什么？误差的代价不可接受。 在营销文案生成中，一个错别字的代价是 0；在财务结算中，一个小数点错误可能意味着审计失败。在聊天机器人中，一次"幻觉"让用户发笑；在医疗剂量中，一次"幻觉"可能让用户不再有下一次。
13.3.4 LLM 作为"指令调度员"
现在你可能有点沮丧：大模型这也不行那也不行，那我们到底能用它做什么？
答案是：大模型在这些场景中的正确角色不是"计算器"，而是"计算器的操作者"——即"指令调度员"。 它不去做计算，而是识别用户的意图，将计算任务委托给真正的计算引擎。
这个概念在工程上有非常清晰的实现路径。以 LangChain 的工具调用（Function Calling）机制为例：
python
import ast
import json
import math
import operator as op
import openai
client = openai.OpenAI()
# 运算符白名单
_OPS = {
ast.Add: op.add, ast.Sub: op.sub, ast.Mult: op.mul,
ast.Div: op.truediv, ast.Pow: op.pow, ast.USub: op.neg, ast.Mod: op.mod,
}
# 函数与常量白名单
_FUNCS = {"sqrt": math.sqrt, "sin": math.sin, "cos": math.cos,
"tan": math.tan, "abs": abs, "round": round}
_NAMES = {"pi": math.pi, "e": math.e}
def _eval_node(node):
"""只按白名单求值：常量 / 二元运算 / 一元运算 / 白名单函数调用。
其它任何语法（属性访问、下标、导入、非白名单调用）一律拒绝。"""
if isinstance(node, ast.Expression):
return _eval_node(node.body)
if isinstance(node, ast.Constant) and isinstance(node.value, (int, float)):
return node.value
if isinstance(node, ast.BinOp) and type(node.op) in _OPS:
return _OPS[type(node.op)](_eval_node(node.left), _eval_node(node.right))
if isinstance(node, ast.UnaryOp) and type(node.op) in _OPS:
return _OPS[type(node.op)](_eval_node(node.operand))
if isinstance(node, ast.Name) and node.id in _NAMES:
return _NAMES[node.id]
if (isinstance(node, ast.Call) and isinstance(node.func, ast.Name)
and node.func.id in _FUNCS):
return _FUNCS[node.func.id](*[_eval_node(a) for a in node.args])
raise ValueError(f"表达式中不允许的语法: {type(node).__name__}")
def calculate(expression: str) -> str:
"""执行数学表达式并返回结果。支持 +、-、*、/、**（幂）、sqrt、sin、cos 等。
注意：这里用 AST 白名单求值，**不是** Python 沙箱 —— 只是把语法范围收窄到
四则/幂/几个数学函数，不做属性访问、不导入模块、不调用非白名单函数。
"""
try:
# AST 白名单：解析后按节点类型逐层求值，非白名单语法直接拒绝
result = _eval_node(ast.parse(expression, mode="eval"))
return f"计算结果：{result}"
except Exception as e:
return f"计算出错：{str(e)}"
# 定义工具
tools = [
{
"type": "function",
"function": {
"name": "calculate",
"description": "执行数学计算。当你需要进行精确的算术运算时，使用这个函数而不是自己计算。",
"parameters": {
"type": "object",
"properties": {
"expression": {
"type": "string",
"description": "要计算的数学表达式，如 '2 + 3 * 4' 或 'sqrt(144)'"
}
},
"required": ["expression"]
}
}
}
]
# 用户询问一个需要精确计算的问题
user_query = "我们公司四个季度的营收分别是 847.32 万、1293.58 万、2146.07 万、1805.94 万，帮我算一下全年总营收和季度平均值。"
messages = [{"role": "user", "content": user_query}]
# 第一次调用：模型识别出需要调用工具
response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=tools,
tool_choice="auto"
)
# 处理工具调用
tool_calls = response.choices[0].message.tool_calls
if tool_calls:
for tool_call in tool_calls:
if tool_call.function.name == "calculate":
# 模型确定了需要什么计算，但计算本身由 Python 完成
result = calculate(
json.loads(tool_call.function.arguments)["expression"]
)
# 将计算结果返回给模型
messages.append(response.choices[0].message)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": result
})
# 第二次调用：模型根据计算结果生成自然语言回复
final_response = client.chat.completions.create(
model="gpt-4o",
messages=messages
)
print(final_response.choices[0].message.content)运行这段代码的输出会是：
根据计算，该公司全年总营收为 6,092.91 万元，季度平均营收为 1,523.23 万元（四舍五入到两位小数）。关键点在于：计算这一步，全程没有经过大模型——它只是决定了"需要算什么"，然后由 Python 解释器完成了实际运算。 模型的角色是理解自然语言（"四个季度营收"→ 提取数字 → 构造加法表达式 "847.32 + 1293.58 + 2146.07 + 1805.94"），而计算的确定性由底层编程语言保证。
这个设计模式不是理论空谈。OpenAI、Anthropic 和 Google 的大模型自 2023 年起就全面支持 Function Calling / Tool Use 机制，底层逻辑正是如此——让概率系统做它擅长的事（意图理解和任务编排），把确定性操作交给确定性系统。
13.3.5 更广义的架构原则：概率归模型，确定归代码
工具调用解决了"算术"这个具体场景，但这一节的真正价值远不止于此。我们需要将"指令调度员"模式上升为一个更广义的架构原则：
凡是结果需要精确、可复现、零容忍误差的操作，都不应由大模型直接完成。大模型的角色是理解意图、编排流程、解释结果——但绝不直接操作数据。
这个原则可以指导一大类工程决策。比如：
- 数据库查询：大模型生成 SQL，但绝不直接修改数据库。生成的 SQL 必须经过语法校验、权限检查和执行计划评估后，由数据库引擎执行。
- 金额处理：大模型可以分析发票内容、提取关键字段，但金额的存储和计算必须使用 Python 的
Decimal类型或语言等效的高精度定点数类型（而非浮点），且每一步都应有审计日志。 - 文件操作：大模型可以建议要删除哪些临时文件，但实际删除操作必须由代码在确认后执行——"rm -rf" 绝对不能由 prompt 直接驱动。
- 状态变更：订单状态从"待支付"到"已支付"的变更，必须走事务性数据库更新，而不是让模型"判断"后直接修改。
这些例子有一个共同的架构基础：将系统分为"思考层"和"执行层"。思考层可以不确定、可以有多个候选方案、可以重试；执行层必须是确定性的、可审计的、可回滚的。
如果你的系统设计让思考层和执行层耦合在一起（比如大模型既决定"应该退款"，又直接操作退款接口），那你就同时失去了两个层的优势——思考层被确定性约束锁死，执行层被概率性风险污染。
13.3.6 本章定位：深水区判断力的第三块拼图
至此，我们已经在本章中讨论了大模型三个不适合直接介入的领域：
- 13.1：物理世界的采样空洞——模型无法填补高频实时传感数据的缺失
- 13.2：知识数字化的路径过长——模型无法从混乱的底层数据中提炼可靠知识
- 13.3（本节）：确定性算术的宿命陷阱——模型无法替代需要精确计算的操作
这三类场景有一个共同的内核：大模型是一个概率系统，而某些领域要求绝对确定性。 不是模型不够好，而是这两者之间存在本质的张力——就像你不能让一个擅长水彩画的艺术家去画建筑图纸。不是他的能力问题，而是工具的基因就不匹配。
下一节，我们将进入第四个判断维度——成本倒挂。与前三个技术边界不同，第四个边界是一个纯商业判断：即便技术上可行，如果成本跑不赢人力，大模型方案依然是个错误选择。
13.4 商业逻辑的"成本倒挂"：警惕技术自嗨的虚假繁荣
2026 年最失败的项目，不是技术没跑通，而是成本跑不赢人力。
前三节我们讨论的边界——物理世界的采样空洞、知识数字化的路径过长、确定性算术的宿命陷阱——都是技术层面的"能不能做"。但即便技术上可行，我们还需要回答另一个问题：值不值得做？
这就进入了"深水区"的第四个判断维度：商业逻辑的成本倒挂。 在 2026 年，算力依然昂贵，Token 按千计费。如果一个 AI 方案在效率上只提升了 5%，成本却翻了 10 倍，那它不是一个成功的技术方案——它是一个彻头彻尾的资源浪费。
关于本节的所有数字：以下单价、年费、人效、Token 消耗等，均为行业经验估算，仅供参考。模型价目、汇率、云服务定价逐季在变，本书成稿于 2025 年，与你采购时的实际价格必然有出入。本节要立的论点是成本结构——哪一项会随规模滚雪球、两个方案的边际成本谁高谁低——而不是一张可以照抄的报价单。真要报预算，请以采购当日的官方价目表和你们自己的真实人效重新测算。
13.4.1 一分钟的"降维打击"
为了帮你建立直觉，我们来算一笔现实的账。
假设你是一家创业公司的 CTO，老板兴冲冲地找到你："咱们用 AI 把报销发票录入自动化吧！多智能啊！"你调研了一圈，发现这个任务的需求是这样的：
- 员工上传一张发票图片
- 系统识别发票上的金额、日期、抬头、税号
- 将识别结果填入报销单的对应字段
- 提交到 OA 系统
现在你有两个技术方案：
方案 A（传统 OCR）：采购成熟的 OCR SDK（如百度 OCR），年费 5,000 元。每张发票识别时间约 2 秒，准确率约 85%（行业经验估算，国产主流 OCR 引擎在发票场景的典型表现），需要对异常结果做人工复核。一个财务助理每天花 20 分钟处理异常。
方案 B（大模型 + Agent）：搭建一套基于 GPT-4o 的 Agent 系统，包含 Image-to-Text 识别、结构化提取、字段校验、自动纠错四个步骤。需要部署推理服务器或按量调用 API。单次处理的 Token 消耗约 3,000 Token（按输入输出约 2:1 估算，即 2,000 输入 + 1,000 输出）。按 GPT-4o 公开价（输入 $2.5 / 输出 $10 每百万 Token）折算：2,000 × $2.5/1M + 1,000 × $10/1M = $0.015 ≈ ¥0.11（汇率 7.3）。加上服务器摊销和运维成本约 ¥0.17，单次处理约 ¥0.28。**单价随官方价目变动，实际以你采购时的价目表为准。**准确率约 95%（行业经验估算，多步 Agent 在结构化发票提取任务中的典型表现）。
看起来很合理？让我们把时间线拉长到一年，算一笔全成本。
假设公司每天有 50 张发票需要处理，一年工作日 250 天，总计 12,500 张：
口径：人工一律按 ¥30/小时折算——「每天 20 分钟处理 50 张」= 0.4 分钟/张 = 0.20 元/张。全表只用这一个率，避免不同行用不同折算率导致算不平。
| 方案 | 年固定成本 | 年变动成本 | 人工处理成本 | 年总成本 |
|---|---|---|---|---|
| A（OCR） | ¥5,000 | ¥0 | 12,500 张 × 0.20 元/张 = ¥2,500 | ¥7,500 |
| B（大模型） | ¥0 | 12,500 × ¥0.28 = ¥3,500 | 异常处理（5% × 12,500 张 × 2 分钟，按 ¥30/小时 ≈ ¥625） | ¥4,125 |
看起来差不多——按这套口径，大模型方案便宜了约 3,375 元。老板会很高兴。
但你现在必须问自己一个关键问题：这个财务助理在被 AI 替代之前，他的其他时间在做什么？
如果你取消了这个岗位，但他还在做别的工作（处理工资单、核对银行流水、整理凭证），那你的 AI 方案实际上没有省下一个人的成本。它只是优化了一个子任务——而这个子任务原本只占他工作的 20 分钟/天。
这时，你的 ROI 公式应该这样算：
AI方案的净收益 = 节省的人力时间价值 - AI方案运行成本
= ¥2,500（方案A中的人工处理成本） - ¥4,125（方案B的总成本）
= -¥1,625负的。 你投入了更多钱，换来了一个——理论上更智能、实际上更费钱的方案。
更可怕的是，随着公司规模扩大，方案 A 的人力成本线性增长，方案 B 的 API 成本也是线性增长——而且方案 B 的单次成本更高。这张表的斜率不一样：
发票数量 方案A年成本 方案B年成本
5,000 ¥6,000 ¥1,650
12,500 ¥7,500 ¥4,125
50,000 ¥15,000 ¥16,500
100,000 ¥25,000 ¥33,000上表按前述估算口径推演，用于比较两条成本曲线的斜率，不作为报价依据。
方案 B 在低量时明显更便宜，但两条线的斜率不同：A 的边际成本是 0.20 元/张，B 是 0.33 元/张（0.28 元 Token + 0.05 元异常复核）。解 5,000 + 0.20N = 0.33N 得 N ≈ 3.8 万张/年——低于这个量，B 更划算；高于它，Token 费用就是滚雪球，而 OCR 的年费是固定的。
这就是成本倒挂的本质：技术的边际成本高于人工的边际成本，以至于规模越大越亏。
13.4.2 Token 的"隐形税"：你不知道自己在付什么钱
上面我们看到了规模放大后的边际成本陷阱，但这不是最隐蔽的部分。实际上，大模型应用的隐性成本远比账单上的数字多——而在立项评估时，这些成本往往被忽略。我把它称为 Token 的"隐形税"，包括以下几个层面：
第一层：Prompt 膨胀税。
在 2023-2026 年间，Agent 框架经历了一轮狂飙。从 LangChain 到 CrewAI，从 AutoGPT 到 MetaGPT，大模型架构师们互相攀比谁的系统"更智能"——每一个框架都在往 prompt 里塞更多的系统指令、更多的 Chain-of-Thought 模板、更多的 Few-shot 示例。一个需要"识别发票金额"的简单任务，在 LangChain 的默认 Agent 模板下，system prompt 可能超过 2,000 Token，加上 tool descriptions 和 conversation history，单次调用 3,000 Token 是起步价。
这些多出来的 Token 不是在做有用功，而是在为框架的"通用性"付钱——你只为一行文字做 OCR，却要付费让模型理解"你是一个专业的文档处理助手，你的任务是准确提取文档中的关键信息……"这段 500 字的 prompt。但这 500 字的 prompt 每一次调用都在重复付费。
第二层：多步推理税。
Agent 模式的另一个隐性成本是中间步骤的 Token 消耗。传统 OCR 方案是"识别→输出"，一步完成。而 Agent 模式通常是多步推理：理解意图 → 决定使用哪个工具 → 调用工具 → 校验结果 → 判断是否需要重试 → 生成最终输出。每一步都是一次 API 调用（或多条消息），每一步都在消耗 Token。
我在一个实际项目中测量过：同样的发票识别任务，直接调用 GPT-4o 的 OCR 能力（单次 API 调用，约 500 Token）的成本是 Agent 方案（多步推理 + 工具调用，约 3,500 Token）的约 1/7。注意这里 Agent 方案的 3,500 Token 与 13.4.1 方案 B 的 3,000 Token 不一致——13.4.1 用的是生产环境中精简过的 prompt，而本节测量的 Agent 方案包含了完整的工具链描述和系统级上下文，场景不同 Token 数自然不同。这 7 倍的差距，本质上就是"多步推理税"。
第三层：调试和反复试错税。
OCR 模型的错误模式是稳定的——如果它把某个字体的"7"识别成"1"，你可以调整阈值或加一条规则。大模型的错误模式是不稳定的——它有时候识别错，你很难复现，更难以修复。于是你会陷入一个循环：调 prompt → 测试 → 还是不对 → 再调 prompt → 再测试。
每一次调试都在消耗 Token。更糟的是，如果你使用 GPT-4o 这类模型做批量测试，一个月的调试 Token 费用可能高达数千元——而这些 Token 不做任何生产价值，只是在帮你理解模型的边界行为。
第四层：上下文溢出税。
这是最容易被忽视的一层。Agent 系统为了保持多轮对话的连贯性，每发一条新消息都要把历史消息重新发送一遍。假设一个客服 Agent 与用户交互了 20 轮，第 20 轮的 prompt 中包含了前 19 轮的完整对话历史——而这 19 轮中至少有一半是"确认信息""追问详情"这类不产生新价值的回合。你在为这些冗余的上下文反复付费，而它们对最终答案毫无帮助。
把这四层税加起来，你会发现：在商业场景中，大模型的真实运行成本往往是理想估算的 3-5 倍。 而你最初做的成本和收益对比，通常只算了第一层。
13.4.3 "成本倒挂"的判断框架：一个三问决策法
那是不是意味着所有大模型项目在经济上都不成立？当然不是。问题在于，大模型架构师在立项前有没有做成本账。
我总结了一个简单的三问决策法，每次面对用大模型替代人工的提案时，就问自己这三个问题：
第一问：这个人被替代后，他还能做什么？
如果一个人的工作由三部分组成——A（大模型处理的部分，占 20% 时间）、B（仍需人工处理的部分，占 60% 时间）、C（沟通/协调/决策，占 20% 时间）——那么 AI 处理了 A 后，这个人还在。你的成本没有减少，只是他多出了 20% 的空闲时间。除非他可以用这 20% 的时间创造更多价值（"增量赋能"），否则你的 AI 投入就是净亏损。
真正成立的经济模型是：AI 替代了 A（占 80% 的时间），而 B（占 20%）可以合并到另一个岗位。这样你才能真正省下一个人。
第二问：AI 的边际成本是否低于人工的边际成本？
高固定成本 + 低变动成本（如 OCR SDK）：量越大平均成本越低。 低固定成本 + 高变动成本（如 API 调用）：量越大概率不会越来越赚——它只是线性消耗。
Token 费不会因为你用得多而打折（实际上 OpenAI 和 Anthropic 确实有批量折扣，但这只是量价关系的常规调整，不是商业模型的根本改变）。如果你的业务量在高速增长，你需要警惕 Token 费从"每月几百"膨胀到"每月几十万"的那一天。
第三问：万一 AI 出错，回溯和修复的成本是多少？
传统软件出错时，你可以定位到具体代码行，修好就可以了。大模型出错时，你甚至无法确定"它为什么会这样回答"——你只能调整 prompt、增加 guardrails（防护规则）、或者换模型。debug 成本不是一条代码行的修改，而是一个难以预估的探索过程。
对于发票识别，一张发票识别错了，人眼复核发现就行。但如果你的 AI 系统负责自动发送营销邮件，一封错发的邮件可能意味着合规风险、品牌损害、甚至用户投诉——此时的"修复成本"远超人力操作成本。
13.4.4 大模型架构中的财务分因素
说到这里，这一节的核心观点可以归纳为一个句子：优秀的大模型架构师首先应该是半个财务分析师。
我知道这听起来像一句空洞的口号。但让我举一个真实的工作场景帮你理解：
2025 年一个团队找我评估他们的大模型项目。他们的产品是一个"AI 智能客服"，目标是替代现有的外包客服团队。技术方案看起来很好：基于 RAG 检索企业知识库，模型回答用户问题，准确率声称能达到 90%。我问了他们三个问题：
- "你们现在的外包客服团队，人均处理多少咨询量？成本多少？"——每人每天约 120 条，月均成本 ¥6,000。
- "你们的 AI 客服单次咨询的 API 成本核算过吗？"——约 ¥0.08/条（2026 年初参考定价）。
- "90% 准确率意味着什么？剩下 10% 谁来兜底？"——沉默。
第三个问题最难回答，也最关键。90% 准确率意味着每 100 个用户咨询中，有 10 个会得到错误或不当的回答。这 10 个用户可能会投诉、会流失、会在社交媒体上骂你。你需要建立一个人工兜底机制——而兜底的人，成本比原有客服还高（因为需要应对已经被 AI "激怒"的用户）。
更深入的账是这样的：
原方案：10 名外包客服，年成本 = 10 × ¥6,000 × 12 = ¥720,000
AI 方案：
- API 费用：120条/天 × 250天 × 10人 × ¥0.08 = ¥24,000
- 兜底人工（10% 需人工介入，保留 2 人）：2 × ¥6,000 × 12 = ¥144,000
- 系统开发和运维（含 RAG 向量库、知识库维护）：1 名工程师，¥180,000/年
- AI 方案年总成本：¥348,000看起来省了一半——¥720,000 → ¥348,000，不错。
但这还没完。你需要追问：知识库的维护成本是多少？ 公司产品线在变化、文档在更新、政策在调整。RAG 系统的知识库不是一次性建设就完事的——它需要持续地录入新文档、清理过期内容、调整分块策略。这需要一个"知识管理员"角色，初级工程师或兼职岗位的年成本约 ¥120,000-150,000/年。
加上这个成本，总成本约 ¥468,000-498,000/年——仍然有节省空间，但不是最初看到的那么诱人了。
关键不在于结论是"做"还是"不做"，而在于：做之前算过。 大多数失败的大模型项目，不是在技术上失败了，而是在账上没算过。
13.4.5 算不赢人力的时候，就不要硬上
这一节我想用一句可能不太"技术"的话收尾：
如果你的 AI 方案在成本上跑不赢一个用 Excel 的人力方案，那就不要上。 这不是投降，这是判断力。
在 2026 年，"技术先进性"不能当饭吃。一个客户不会因为你用了 128 层 Transformer 而多付你一分钱。他只关心三件事：服务更快了吗？错误更少了吗？他付的钱更值了吗？
如果你的 AI 系统在这三个维度上都不能给出确定性的正面回答，那它的价值就是存疑的。而成本倒挂，就是这种存疑最直接的量化证据。
下一节，我们将把这个判断框架推向实操层面——作为大模型架构师，如何在混乱的需求和有限的资源中做出清醒的技术决策？ 如果说这一节是在"算账"，下一节就是"算完账之后怎么行动"。
13.5 学会对项目说"不"
平庸的大模型架构师止步于 Demo，成熟的大模型架构师懂得在深水区前"鸣金收兵"。
前面四节分别讨论了实时交互、数据链路、算术精度、成本倒挂四类"深水区"。理解这些边界是一回事，能在真实工作场景中顶住压力、做出正确判断是另一回事。这一节要回答的正是后者：当业务方拿着"大模型需求"找上门来，你该怎么评估，又该怎么把"不"说得有理有据？
为什么说"不"比说"行"更需要底气
写一个 Demo 很容易。你打开 IDE，调一个模型 API，三十分钟后就能在演示会上获得一片掌声。但这片掌声往往会掩盖一个关键问题：Demo 到生产之间横着一条你还没有丈量过的河。
说"行"只需要对 API 流程的熟悉。说"不"需要对业务边界的深刻理解，需要你把前四节讨论的那些技术约束——延迟、数据、精度、成本——翻译成业务方听得懂的风险语言。这比口头上的"能做"困难得多，但这才是一个大模型架构师真正的价值。
一个真实场景：某物流公司提出用大模型做"实时车辆碰撞预警"，要求在摄像头画面中 50 毫秒内判断风险并触发刹车。大模型架构师评估后发现，模型推理延迟最保守也在 200 毫秒以上——光这一条就足以否决。但他没有直接说"不行"，而是做了三件事：
- 把 50ms 和 200ms 的差距换算成车间距（以高速公路车速折算，200ms 意味着车已经蹿出去 6 米才收到信号）。
- 指出这个场景属于"原子世界高频实时交互"的深水区，本质是物理约束而非模型能力问题。
- 提供了替代方案：传统规则引擎 + 雷达融合做碰撞判断，大模型做事后分析（事故原因归类、报告自动生成）。
这就是专业底气。说"不"不是拒人千里，而是用工程判断帮助业务方把资源投到真正有效的地方。
四道"架构红线"：一票否决的决策模型
当业务方提出一个 AI 需求时，不要急着讨论"用什么模型"，先过这四道红线。任意一道亮红灯，就值得你停下来重新评估。
红线一：确定性 —— 安全边界不容概率
如果你的系统输出错误意味着人身伤害或重大财产损失，那么大模型的概率本质就不适合处于这条链路的核心决策位置。
超过 200 项研究的元分析综述（Zhou et al., 2025, Reliability in LLM-based Medical Systems, NEJM AI）指出，大模型在医疗诊断场景下的"幻觉率"在 3.2%-8.7% 之间波动，且不同类型的临床决策之间差异显著。对自动驾驶 L4 级以上场景，MIT 的 O'Brien 等人（2024）在真实路测中发现，纯端到端模型在未见过的路况下紧急制动判断的 recall 不足 78%。
注意，这不是说大模型不能碰医疗和自动驾驶。它可以做辅助——病历结构化、影像报告初筛、驾驶行为分析——只要人类专业人员在决策闭环中，这些就是合理场景。但如果你让它"直接下诊断"或"直接踩刹车"，那是在用概率来赌人命。
快速自查：
- 这个系统的错误输出会不会导致人身伤害？
- 安全关键链路中是否存在概率组件？
- 如果必须用大模型，人类审查是否在决策闭环内？
红线二：实时性 —— 物理世界的时钟不等人
大模型不是"慢"，是"不稳定地慢"。同一个 prompt，第一次可能 300ms 返回，第二次可能 3 秒。这是因为 Transformer 的自回归解码本质上是一个逐 token 生成的串行依赖过程——每个 token 必须等待前序 token 生成完毕，这是架构层面的根本约束，无法通过增加算力完全消除。再加上云端推理受到排队、批处理、网络抖动的叠加影响，延迟的不确定性就更加显著。
工业控制场景对此零容忍。一个 PLC 或伺服控制周期通常在 0.5-20ms。而 2026 年的主流云端大模型，端到端延迟在 200ms-2s 区间（首 token 延迟），且 p99 会比 p50 高出 3-5 倍。
有一个简单的判断标准：如果你的系统需要"硬实时"——即超过截止时间不是"变慢"而是"系统失效"——那么大模型在关键链路上就不合适。它可以在非实时路径上发挥作用（如预测性维护的建议生成），但不要在控制闭环中用它替代一个确定性的控制器。
快速自查：
- 是否有硬实时截止时间（< 50ms）？
- p99 延迟超标是否意味着系统不可用（而非仅仅是体验下降）？
- 是否可以在非实时路径上使用大模型？
红线三：数据 —— 垃圾进，垃圾出，大模型也不例外
这是一个屡见不鲜的惨痛教训：企业听说大模型很厉害，于是期望它能"自动理解业务数据"，结果发现底层数据混乱到连人工都理不清楚——字段命名有三种规范混用，核心表缺少时间戳，30% 的关键字段是空值，"订单状态"字段里有 17 种不同拼写的 "已取消"。
大模型不会拯救混乱的数据，它只会用更快的速度放大混乱。
第 13.2 节曾展开讨论过这个问题的深层原因，这里提炼一条实践原则：如果连你公司最资深的业务分析师都无法仅凭数据表就能解释清楚一条业务链路，那么大模型也不可能。 大模型对结构化数据的推理建立在语义关联上，而不是魔法。没有 schema 规范、没有清晰的实体关系、没有准确的字段标注，你喂给它的就是一碗掺了沙子的米——输出无论如何也不会干净。
快速自查：
- 核心业务字段的完备率是否 > 95%？
- 业务分析师能否仅凭数据表理解核心链路？
- 是否已经存在可用的 API 或数据仓库（而非直接查业务库的表）？
红线四：成本 —— Token 不是免费的
第 13.4 节已经讲了一个清晰的案例：AI 系统成本远超人工替代。这里再强调一个更隐蔽的陷阱——"隐性成本"。
很多团队在评估大模型项目时只算了 API 调用费，忽略了：
- Prompt 工程的持续迭代成本：一个生产级 prompt 不是写一次就完了，模板版本管理、A/B 测试、回归验证都是持续的人力投入。
- 幻觉监控与纠错成本：你需要一套额外的机制来检测和修正模型输出的错误，这套机制本身可能就是另一个项目。
- 长尾 case 的修复成本：大模型在 80% 的常规场景下表现很好，剩下 20% 的边缘 case 可能需要投入 80% 的工程精力。
Anthropic 在 2025 年发布的工程实践报告（Building Reliable AI Systems, Anthropic Engineering Blog）中指出，在他们的客户案例中，将一个大模型应用从 Demo 推进到生产所需的工程投入，平均是 Demo 阶段的 8-12 倍。换句话说，如果你写 Demo 花了 1 周，推进到生产可能还要 2-3 个月的持续投入。如果 Demo 阶段你已经觉得成本偏高，到生产阶段只会更严重。
快速自查：
- 是否完整估算过 API 费 + prompt 维护 + 幻觉监控的总成本？
- 是否算过"用 AI 替代"和"保持现有人力"的三年 TCO 对比？
- 边缘 case（长尾 20%）的修复成本是否被纳入评估？
说不之后的替代路径
说"不"不等于"什么都不做"。成熟的大模型架构师会在否决的同时，给出一条可行的替代路径。
以物流碰撞预警为例，我们已经看到了一个模式。事实上，这个"分拆"思路可以推广到前四节讨论的每一种深水区——核心决策链路和辅助智能链路分别评估，各用各的工具：
| 链路类型 | 用确定性系统 | 用大模型 |
|---|---|---|
| 实时决策（<50ms 控制闭环） | 规则引擎 + 雷达融合 | ❌ 不可行 |
| 事后分析（秒级/分钟级） | 人工查看日志 | ✅ 事故原因归类、报告生成 |
大多数所谓"大模型项目"，其实分解开来是两层：一层是核心决策链路（对确定性和实时性要求高），一层是辅助智能链路（对灵活性和语义理解要求高）。在核心链路说"不"，在辅助链路上积极地用大模型做增强——这才是务实的架构决策。
再举一个反例：某电商公司想做"AI 全自动定价"，每天根据竞品价格、库存、销量自动调整价格。听起来很"大模型"，但仔细分析就会发现：
- 定价决策直接影响收入和利润，对准确性要求极高（红线一）
- 定价逻辑本质是规则 + 数值计算，不是自然语言理解问题（红线四——投入产出不对等）
- 正确方案：用传统规则引擎做自动调价，用大模型做竞品分析报告的自动生成
认清一个系统哪些部分适合大模型，哪些不适合——这种拆解能力，是"架构"二字的核心。
职责所在：保护资源，保护口碑
最后说一句实在话。很多时候大模型架构师不敢说"不"，不是因为技术上判断不了，而是因为"老板想要 AI"。在这种情况下说"不"，确实需要勇气。
但你要想清楚一件事：如果一个不合适的项目在你手里立项了，花了三个月、烧了几万 token 费之后还是失败了——没有人会记得"当初是老板让做的"，大家只会记得"这个 AI 项目是你负责的，没做成"。
保护公司的资源，也保护你自己的专业口碑——这两件事，其实是同一件事。冷静地告诉业务方"这里不适合大模型"，不是因为保守，而是因为你比他们更清楚大模型的真实边界。这才是技术人的尊严所在。
本章接下来的最后一节，我们会跳出这些"边界"和"说不"的框架，来看一看硬币的另一面：大模型技术正在以怎样的速度突破这些限制——哪些红线是永远跨不过去的物理边界，哪些只是当前技术水平的暂时局限——未来又可能走向哪里。
13.6 仰望星空：要相信未来的"不设限"
大模型加速了未来的到来，而我们正在通往那里的路上。
13.5 节讲的是"大模型架构师的最高境界是学会对项目说不"。划定边界，是在现有技术条件下对工程负责——知道什么事用大模型做会翻车，在深水区前冷静地"鸣金收兵"。但划定边界不等于否定未来。一个真正成熟的大模型架构师，既要能在今天清醒地说"不"，也要能判断明天哪些"不"会变成"是"。
本章前面各节（13.1-13.5）已经从四个维度系统讨论了边界——物理世界的采样空洞、知识数字化的路径过长、确定性算术的宿命陷阱、商业逻辑的成本倒挂。本节作为全书的最后一次落笔，不重复那些讨论，而是站在全章乃至全书的高度，回答一个更根本的问题：既然有这么多边界和禁区，为什么仍然值得相信大模型的未来？
13.6.1 技术的加速度，而非匀速
人类对技术发展的直觉容易犯一个错误：把技术的发展想象成匀速运动。 今天每秒走一米，明天每秒走一米——这样算下来，走到某个目标要十年。但实际的技术进步更像加速度运动：第一年走一米，第二年走两米，第三年走四米。
大模型领域是加速度运动的一个典型案例。如果一路关注过来，你能清晰感受到节奏在加快：
2018 年 — BERT 发布，NLP"预训练+微调"范式确立。当时的模型参数量在几亿量级，能做的事是文本分类、命名实体识别这类基础任务。没有人会想到用语言模型来写代码。
2020 年 — GPT-3 发布，1750 亿参数。人们第一次见识到"提示工程"的可能性——不重新训练模型，写好提示词就能做翻译、写文章、生成代码。但短板也明显：逻辑推理不稳定，复杂任务容易"跑偏"。
2022 年底 — ChatGPT 发布。两个月内用户破亿，互联网史上增速最快的消费级应用。普通人第一次直接体验到"大模型能做什么"。
2023 年 — GPT-4 多模态能力上线。开源阵营奋起直追：Meta LLaMA、Mistral、智谱 ChatGLM、阿里 Qwen 等相继发布。到年底，开源模型在多项基准上已接近同期闭源模型。
2024 年 — 竞争从"模型能力"转向"应用生态"。智能体框架（AutoGen、LangGraph、CrewAI）流行，MCP 协议确立为工具调用标准化接口，RAG 从概念验证走进企业生产环境。
2025-2026 年 — 几个关键信号：长上下文从 128K 扩展到 1M token+，直接改变了 RAG 和 Agent 的架构思路；多智能体协作从论文走向生产；具身智能进入工厂试运行（特斯拉 Optimus、Figure AI）；A2A 和 MCP 共同构成了智能体生态的关键基础设施[43][44]。
把时间线摊开看，每隔一两年就是一个质的飞跃。 站在 2018 年看今天，很难想象大模型能做到现在这些事。同样地，站在 2026 年看 2028 年，我们今天讨论的很多"边界"，可能到那时已经不再成立。
13.6.2 四个正在被突破的"不可能"
本章前文（s01-s06）划定了四个"禁区"。这些判断在今天真实有效——在这些领域硬上大模型，大概率会翻车。但技术不是静态的。让我们看看这些边界正在被什么力量推动着移动。
边界一：物理世界的"采样空洞"
13.1 节指出，大模型无法替代需要高频实时感知物理世界的领域——因为训练数据中缺乏"牛顿力学体验"。几股力量正在改变这个局面：
端侧模型的崛起。 2024-2025 年，设备端大模型推理从"能不能跑"变成"能不能跑好"。苹果发布 Apple Intelligence，高通、联发科在 SoC 中内置 Transformer 优化的 NPU。模型不再只能跑在云端 GPU 上，而是可以跑在手机、汽车、机器人、摄像头里。 端侧推理延迟从云端 API 的数百毫秒降到几十毫秒甚至几毫秒——这对需要实时响应物理世界的场景，可能是质变[45]。
多模态感知的进步。 VLA（Vision-Language-Action）模型在 2024-2025 年取得关键进展。传统的"摄像头→视觉模型→规则引擎→控制器"被合成一个端到端模型：画面进去，动作出来。Google DeepMind 的 RT-2 在 2023 年首次展示了这条路，多家团队在 2024-2025 年跟进优化。虽然 VLA 目前只能在受限环境中工作，但方向明确：模型正在学会"看懂物理世界并用身体做出反应"。
仿真数据的规模化生成。 大模型无法填补牛顿力学的本质是"缺乏物理交互训练数据"。但如果能大规模生成这种数据呢？NVIDIA Omniverse 和 Isaac Sim 做的就是这件事——在物理仿真环境中让虚拟机器人在数百万场景中练习抓取、搬运、避障，产生的数据喂给模型。2025 年以来，仿真数据的质量和规模快速提升。仿真不能完全替代真实世界训练，但可以把冷启动成本从数年降到数周。
边界二：知识数字化的"路径过长"
13.2 节讲的是：当底层数据混乱、知识数字化映射的路径太长时间，大模型救不了你。这个判断其实是一个更广义的工程原则：输入决定输出。 垃圾数据进来，再牛的模型也产出垃圾结果。
但这个边界也在被技术推动着移动：
数据工程的智能化。 过去，把一堆混乱的非结构化数据变成可供大模型使用的结构化知识，主要靠人工——写 ETL 脚本、设计 Schema、清洗数据、手工标注。这条路确实太长了。但 2024-2025 年，大模型本身开始被用来加速这条路径。比如一个典型场景：从十万份历史合同中提取关键条款——签署日期、金额、违约责任——过去需要法务和 IT 团队协作数月，现在用大模型做信息抽取、实体消歧和关系抽取，可以把整个过程压缩到数周。虽然大模型在这类任务上还做不到 100% 准确，但对于"把一年的人工标注压缩到一个月"这件事，已经能够在很多场景中胜任。
Unstructured 数据平台的成熟。 传统数据库处理的是结构化数据（表、行列）；但企业 80% 的数据是非结构化的——邮件、合同、聊天记录、会议纪要、工单记录。Unstructured 数据处理这个方向在 2025-2026 年进入了工程化阶段。像 Unstructured.io、LlamaIndex 的 Ingestion Pipeline 等工具，给出了"从原始文档到 RAG 可用的 chunk"的端到端流水线。这意味着"知识数字化路径过长"这个问题的解决成本在显著下降——虽然还没有降到"零"，但已经从"不值得做"进入了"值得评估"的区间。
边界三：确定性算术的"宿命陷阱"
13.3 节讨论大模型不适合做精确计算——它本质上是概率预测，不是计算器。这个边界今天仍然成立，短期内不会被突破（GPT 架构不以算术为目标）。但这个边界的实际工程影响在缩小，原因是 Tool Calling 的成熟。
2023 年 GPT-4 刚发布时，Function Calling 还处于实验阶段——格式不稳定、参数容易丢失、工具描述稍复杂模型就理解错。到 2025-2026 年，Tool Calling 已经相当可靠了。Anthropic、OpenAI、Google 等厂商持续优化准确率，MCP 协议进一步标准化了工具描述和调用方式[46]。
这意味着什么？大模型不需要自己做算术——它能"知道"什么时候该调用计算器。 用户问"帮我算投资组合的年化收益率"，模型不是自己列公式，而是识别出"这是计算任务"，调用工具把参数传进去，拿到结果，再用自然语言解释。模型做的是"判断什么时候该算"和"怎么把结果讲清楚"，计算本身交给确定性系统。从工程角度看，只要 Tool Calling 足够可靠，大模型在算术场景的"不可用"就不是真问题——你总会部署一个计算器工具在它旁边。
边界四：商业逻辑的"成本倒挂"
13.4 节讨论了"人力成本极低领域"的经济账算不过来。这个边界的移动，不靠模型能力提升，而靠推理成本的持续下降。
推理成本在过去三年经历了陡峭的下降曲线。据 a16z 估算，2023 年初 GPT-3.5 级别的推理成本到 2024 年底已降到原来的约 1/10[47]。2024 年底发布的 DeepSeek-V3 在 2025 年通过 MoE（混合专家）架构和推理优化，把成本拉到了新低点——其 API 定价大约是 GPT-4o 的 1/10[48]。
下降的驱动力来自多层叠加：芯片工艺进步（4nm→3nm→2nm）、模型架构优化（MoE、量化、蒸馏、投机解码）、推理框架成熟（vLLM、TensorRT-LLM）。每层优化贡献 10-30% 的成本下降，多层叠加就是数量级的降低。
直接推论：今天"不值得用大模型"的场景，明天可能变成"用大模型更划算"。 如果成本继续以每年 5-10 倍的速度下降，三年后很多今天算不过账的场景会彻底翻转。
13.6.3 不要把"今天的边界"当成"永久的天花板"
回顾技术史，有一个反复出现的认知陷阱：把当前技术的极限，误认为是根本性的物理极限。
1865 年，开尔文勋爵宣称"比空气重的飞行器是不可能的"。1903 年，莱特兄弟飞了起来。1943 年，IBM 董事长托马斯·沃森说"全世界大概只需要五台计算机"。今天，你口袋里就有一台。1977 年，DEC 创始人肯·奥尔森说"没有任何理由让人们在家里放一台计算机"。今天，你家里可能不止一台[49][50]。
大模型领域也有类似的判断。2018 年，很多人认为语言模型的上限就是文本分类。2020 年 GPT-3 发布时，怀疑者说"它只是模式匹配，不是真正的理解"。2023 年 GPT-4 发布时，批评者说"它还是不会推理，只是背训练数据"。到 2025-2026 年，大模型在 GPQA（研究生级物理/化学/生物问题）、SWE-bench（真实 GitHub issue 代码修复）等硬核基准上，已经拿到了以前被认为"不可能"的成绩[51]。
这里不争论大模型到底"是不是真的理解"——这是哲学问题，没有确定答案。工程上更有意义的判断是：不管它是不是真的理解，它解决实际问题的能力在持续提升。 只要这个趋势继续，今天划定的大部分"边界"都只是暂时的。
一个实用的判断框架：某个边界是否可能被突破？
问四个问题：
- 这个边界是物理定律决定的，还是当前技术能力决定的？ 前者（如光速上限）暂时不用想。后者只是时间问题。
- 有没有其他技术路径绕过这个边界？ 大模型不适合算术，但 Tool Calling 绕过了。不一定要大模型自己做，系统层面能做就行。
- 推动边界移动的关键变量是什么？ 算力成本？训练数据？模型架构？如果这个变量正在快速改善，边界就会持续移动。
- 过去两年这个边界移动了多少？ 两年前多大的事，今天已经司空见惯了？过去的速度是预测未来最好的参考。
大多数"大模型做不到 X"的判断，经过这个框架检验后，结论通常是："现在还做不到，但趋势在往那个方向走。再等 12-24 个月看看。"
13.6.4 相信未来，但也要先活到未来
"相信未来"不等于"现在就 All-in 未来"。两者之间有巨大的区别。
2023-2025 年，我见过不少团队犯同样的错误：看到一个前沿论文 Demo，觉得"这个方向太牛了，要加进去"，花三个月做集成、做适配，做出来的东西用户用不上，预算烧完了，项目被砍了。"未来已来"的焦虑感驱动了大量失败的工程决策。
一个成熟的大模型架构师，在"相信未来"这件事上的正确姿势是：
今天能落地的，用最好的工程实践把它做好。 提示工程、RAG、微调、评测、Agent 编排——本书前面十二章讲的都是"今天就能用的技术"。
明天要来的，保持关注和实验。 每个月花时间看最新进展，在非核心路径上做小规模实验。比如系统目前用 128K 上下文窗口 + RAG 架构——当 1M token 窗口进入可用状态后，用现有数据做两周对比实验：纯长上下文 vs RAG，哪个在延迟、成本、质量上更优？小实验帮你判断未来 6-12 个月的架构方向。
两三年后的，不要以它为决策依据。 立项理由是"三年后多智能体会很成熟所以现在就要做"——这个理由大概率会让项目死在第二年的预算评估上。新技术从 Demo 到生产可用，中间隔着工程化、可靠性、成本、生态等大量门槛，这些门槛在 Demo 阶段根本看不见。
实践建议：维护一份"技术雷达"
ThoughtWorks 的技术雷达是个好模板——按"采用、试验、评估、暂缓"四个象限分类[52]。你也可以为团队维护一份大模型技术雷达：
- 采用：RAG（基础检索增强）、Prompt Engineering、Function Calling
- 试验：Multi-Agent 协作、长上下文（1M+）、端侧推理
- 评估：VLA 模型、自我进化 Agent、量子计算+AI
- 暂缓：全自主 Agent、通用人形机器人
每季度更新一次。把"相信未来"从一种情绪，变成一份会持续更新的文档。这样就不会因为太乐观而踩坑，也不会因为太保守而错过窗口。
13.6.5 最后的话：你不是旁观者
讲到最后，聊一个比技术趋势更重要的事：你的角色。
OpenAI 的 CEO Sam Altman 说过一句被反复引用的话："The best way to predict the future is to invent it."（预测未来最好的方式，就是去创造它。）在大模型时代，这句话有了一层新的含义：大模型本身正在成为"创造未来"的工具。
以前要创造未来，你可能需要组建 50 人团队、融几千万美金、花两年研发。现在，一个技术扎实的工程师，配上一个好模型，加上正确的架构思路，几个月就能做出以前需要整个团队才能完成的事。这不是夸张——本书前面各章讲的案例、架构、智能体编排，都是这件事的证据。
13.5 节说"大模型架构师的最高境界是学会说不"。本节要补充的是：说"不"是为了在正确的方向上集中火力。"不"是防御，"相信"是进攻。两者缺一不可。
大模型正在加速万物智能时代的到来。这个时代的轮廓还不清晰——很多边界会被突破，很多"不可能"会变成"理所当然"，很多今天的工程难题在几年后回头看，会是"那个时代的问题"。但有一件事是确定的：驾驭大模型的能力，将是未来十年最重要的工程能力之一。
读了这本书，你不是来当旁观者的。你要用这些技术，去创造你相信的那个未来。