先亮明结论：这句话不是反对 AI，而是反对“AI 是万能药”的营销话术。从工程视角看，AI 确实在改变一部分工作方式：代码补全、文档解析、知识库问答、批量内容生成、Agent 编排，这些都真实可用。但 AI 没有改变的东西同样要命：数据治理、评测体系、推理成本、延迟预算、幻觉兜底、人工复核流程。本文不打算给“AI 改变一切”或者“AI 无用论”站队，而是把“哪些环节已经改变、哪些环节还没改变、工程上怎么落地”拆开来讲。适合正在做 AI 应用开发、模型部署、Agent 落地评估，或者被老板一句“这能不能全自动”问住的开发者阅读。
文章会围绕四个关键问题展开：模型和产品之间的落差在哪里；当前 AI 应用的真实能力边界；本地部署和调 API 怎么选；以及部署之后怎么验证效果、怎么处理批量任务、怎么排查故障。如果你关心 AI 工程实践、模型部署和 Agent 开发，这篇可以直接往下看。
1. 核心矛盾速览：AI 能干什么，和“改变一切”差在哪
说“AI 在改变很多工作流”是准确的。说“AI 在改变一切”从工程角度看立不住。我们可以把这种矛盾拆成一张表：
| “AI 改变一切”的说法 | 工程现实 |
|---|---|
| AI 能替代人思考 | 模型只能根据训练数据和上下文做概率推断，没有理解，只有统计相关性 |
| AI 能做完整任务 | 大部分能跑通的都是“工作单元”，依赖人工定义输入、校验输出、处理异常 |
| AI 部署完就能自动运行 | 实际生产需要评测集、监控、回退机制、成本控制、数据合规 |
| AI 输出一定正确 | 幻觉是模型固有特性，只能降低，不能完全消除 |
| AI 会淘汰大部分岗位 | 更常见的形态是“人 + AI”协作，人的角色从执行者变成审核者和流程设计者 |
这里面的核心问题不是模型能力有没有提升，而是“模型能力”和“可交付产品”之间隔着一整套工程系统。
在开发阶段，模型能回答一个问题、能生成一段代码、能总结一篇文档，这些都很容易演示。但放进真实业务场景时，你必须回答的问题会变成：
- 用户输入超长怎么办？
- 模型输出格式不稳定怎么办？
- 模型引用了一段不存在的政策条款怎么办？
- 一次并发请求成本要多少？
- 批量处理一万条文本要跑多久？
- 失败任务怎么重试？
这些问题没有一个能靠换一个更大的模型解决。所以更稳妥的判断是：AI 正在把一部分重复劳动变成可自动化流程，但“改变一切”的说法低估了工程落地的复杂度。
2. 已经真实改变的环节：AI 编程、RAG、Agent、内容生成
虽然“改变一切”是夸张表述，但有几个场景确实因为大语言模型发生了实质变化。理解这些场景能帮你判断自己的业务该不该投入。
2.1 AI 编程辅助已经进入日常工作
现在不少开发者已经离不开 AI 编程工具。自动补全、单测生成、代码解释、仓库级别问答，这些不只是“好玩”，而是能直接减少上下文切换时间。
比较典型的工作流是：
- 先写一个函数签名和注释。
- 让模型生成初版实现。
- 人工审查逻辑和边界条件。
- 让模型补测试用例。
- 跑测试，发现问题后把报错信息回贴给模型，反复修改。
这里的关键不是“代码完全不用人写”，而是“初稿成本大幅下降”。在写胶水代码、配置文件、测试桩、CRUD 接口这类低风险代码时，效率提升非常明显。但涉及核心算法、支付逻辑、权限边界时，建议不要盲信模型。
用 AI 编程有一个要注意的点：模型的输出质量取决于你给的上下文是否充分。直接把一个仓库塞给模型，和把相关类、调用关系、错误日志整理好再提问，结果差距非常大。
2.2 RAG 让知识库问答变得可用
RAG（检索增强生成）是目前落地最广的 AI 应用方向之一。它先把文档切块、向量化、建索引，然后在用户提问时检索相关片段，拼进提示词，再让模型基于这些片段生成回答。
使用 RAG 的主要原因是缓解幻觉。当模型不依赖自己的记忆，而是依赖检索回来的文档片段，回答的可追溯性会高很多。
一个最简流程如下：
# 简化流程，实际实现需要替换为具体的切分和检索参数 1. 文档预处理：PDF/Word/HTML 转纯文本 2. 文本切分：按标题或固定长度切块 3. 向量化：调用 Embedding 模型生成向量 4. 建立索引：写入向量数据库 5. 用户提问：向量检索 Top-K 相关片段 6. 拼接提示词：把片段灌进Prompt，再调用大模型 7. 返回回答：附上引用来源这套流程看起来简单，但在生产环境里最容易出问题的环节不是向量检索本身，而是文档质量。如果原始文档本身就有错误、版本混乱、格式残缺，那么无论向量模型多强，检索回来的内容也是错上加错。
2.3 Agent 编排开始从玩具走向任务线
Agent 的概念这几年反复变化，从早期“插件式工具调用”，到现在的“多轮推理 + 工具调用 + 记忆管理”。当前更接近实用的形态是：
- 用户提出一个目标。
- Agent 拆解成子任务。
- 每个子任务调用一个工具或模型。
- Agent 基于工具返回结果决定下一步。
- 最终汇总输出。
典型的工具包括搜索引擎、代码执行器、数据库查询、内部 API、文档操作等。从开发角度看，Agent 本质是一个有状态的工作流引擎，把模型放进循环里，让模型决定调用什么工具。
这种模式适合有一定容错空间的场景。比如信息收集、报告初稿生成、日志初步分析。但一旦涉及强一致性、强权限控制、资金操作，Agent 直接自动执行的风险会很高。更稳妥的做法是让 Agent 产出“操作建议”，由人工确认后再执行。
2.4 内容生成和批量处理已经是成熟场景
文本总结、标题生成、翻译、产品描述扩写、广告文案批量改写，这些内容生成类任务已经被大模型处理得很好。原因是这类任务的输入输出边界清晰，质量评估相对直观。
内容生成的效率提升不在“单条生成”，而在“批量任务”。当你有上千条纪要要总结、几百个页面要抽取结构化字段、几十个视频脚本要转成文案时，手工处理根本跟不上。此时用脚本调用模型接口，加上合适的并发和重试机制，可以把交付时间从几天压缩到几小时。
但这不意味着“生成完就能直接用”。内容生成必须保留人工审核环节，尤其是涉及对外发布、法律条款、医疗建议、金融信息的场景。
3. 没有改变的三个底层问题：成本、幻觉、评估
判断一个 AI 项目能不能长期跑下去，不看演示效果，看三个指标：单位成本、幻觉率、评估成本。
3.1 成本是比模型能力更硬的约束
很多人只在生成时关注效果，忽略了成本。成本不只是 API 账单，还包括：
- 开发成本：提示词调试、RAG 调优、Agent 工具开发。
- 推理成本：每次调用的 token 费用或本地 GPU 电费。
- 维护成本：模型版本升级、向量库重建、检索效果回归。
- 算力成本：训练微调一次的人力、GPU、数据标注。
- 失败成本：错误回答导致的人工返工和信任损失。
尤其是批量任务，必须控制单条成本。如果一条任务要调用多次模型，每一次都使用长提示词，账算下来可能比人工还贵。
更合理的做法是“分级调用”：简单任务用小模型，复杂任务用大模型，能通过规则判断的先交给规则。不要把所有请求都一股脑丢给最贵的模型。
3.2 AI 幻觉不是 bug，是模型特性
大语言模型本质上是在做下一个 token 的概率预测，它没有“现实校验”机制。训练数据里的错误、信息过时、用户提示词里的误导，都可能让模型生成与事实不符的内容。
把幻觉率压到零是不可能的，工程上只能做三件事：
- 降低幻觉：用 RAG 提供事实依据，要求模型只基于检索内容回答。
- 提高可追溯性：输出时附上来源引用，让用户或下游系统能核对。
- 加人工复核：对高风险输出做强制审核。
有些团队试图靠“在提示词里写不要编造”来解决问题，效果极其有限。更好的方式是让模型在拿不准时说“不知道”，但这也需要你在提示词和评测层面反复迭代。
3.3 没有评测体系，就没有优化方向
这是最多团队忽略的一环。模型换一个、提示词改一句、RAG 检索参数调一下，效果是变好还是变差？如果没有固定测试集，答案只能靠“感觉”。
工程上建议尽早建立三层评测：
- 单测级：给每条用例定义通过条件，比如是否包含关键字段、格式是否合规。
- 回归级：准备一百条覆盖常见场景的输入，定期跑一遍，观察通过率。
- 人工抽检：对线上输出抽样，让业务人员判断质量。
评测集不需要一开始就很大，但必须覆盖真实业务输入。评测结果要落到可量化指标，比如字段抽取准确率、链路完成率、答非所问占比、返工率。
没有评测体系的 AI 项目，后期迭代时基本是在碰运气。
4. 本地部署还是调用 API：按需求做选择
部署方式经常被简化成“本地部署更强”或者“API 更快”，真实判断维度要麻烦一些。放一张对比表：
| 维度 | 本地部署 | 云 API |
|---|---|---|
| 数据出域 | 可控，数据留在自己机器/内网 | 需要评估数据安全协议 |
| 硬件成本 | 一次性 GPU 投入，后期用电和运维成本 | 按 token 付费，无一次性硬件投入 |
| 并发能力 | 取决于 GPU 显存和推理框架，扩展要加卡 | 平台侧负责扩容 |
| 模型切换 | 自己下载和管理模型文件 | 依赖服务方提供模型版本 |
| 维护难度 | 需要处理 CUDA、框架、依赖、模型版本 | 服务方处理大部分基础设施 |
| 适合场景 | 数据敏感、离线环境、高频海量调用 | 快速验证、弹性并发、团队小无运维 |
如果你做的是数据敏感场景，比如内部文档分析、隐私数据抽取、离线环境部署，本地部署是更安全的选择。这里的“更安全”指的是数据范围可控，但仍要注意模型许可协议和数据合规要求。
如果你只是做原型验证，或者调用量波动很大，先用 API 跑通业务逻辑更省事。等验证了真实效果和成本，再决定要不要迁移到本地。
4.1 本地部署显存怎么观察
本地部署大模型时，显存占用是首先要盯住的指标。启动推理服务后，可以用以下命令观察：
# 每 1 秒刷新一次 GPU 使用情况 nvidia-smi -l 1重点看两列：显存占用（Memory-Usage）和 GPU 利用率（Volatile GPU-Util）。显存占用决定你的模型能不能跑起来，GPU 利用率决定推理服务有没有真正用满显卡。
如果你使用量化模型，显存需求会明显低于原版权重。以 7B 量级模型为例，常见量化格式部署后，按上下文长度和量化精度不同，显存占用通常在 4GB 到 8GB 附近波动。更准确的数据必须以你本机实际加载后的 nvidia-smi 输出为准，不要拿网上某个测试结果当精确标准。
当出现“显存不足”时，方向不是继续下载更大的模型，而是两条路：一是换更小的量化版本，二是降低并发数或缩短上下文长度。
4.2 兼容 OpenAI 格式的接口调用
现在大量本地推理框架和服务都支持兼容格式的 API，比如http://127.0.0.1:8000/v1/chat/completions。如果你的服务也兼容这个格式，那么以前写在应用层的调用代码，改动成本会很低。
下面给一个 Python 调用模板，实际服务地址和模型名需要按你自己的环境调整：
import requests import json API_URL = "http://127.0.0.1:8000/v1/chat/completions" MODEL_NAME = "your-model-name" payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": "你是一个严谨的技术助手，不确定时请直接说明。"}, {"role": "user", "content": "请把下面这段话总结成三句话：..."} ], "temperature": 0.7, "max_tokens": 1024 } response = requests.post(API_URL, json=payload, timeout=120) result = response.json() print(json.dumps(result, ensure_ascii=False, indent=2))调用成功后，响应里会包含choices数组，第一个元素里的message.content就是模型生成的文本。拿到生成文本之后，应用层还要再做一道输出校验，不能直接信任。
4.3 Java 技术栈的接入思路
如果团队是 Java 技术栈，常见的做法是通过 HTTP 调用上面这种兼容接口。也可以用 Spring AI 这类集成框架来统一管理模型调用，它对多种模型服务做了抽象，可以降低模型供应商切换的维护成本。
用 Spring AI 时，通常会做这几件事：配置模型端点、定义 Prompt 模板、封装对话服务、把返回结果映射成 Java 对象。接入思路和调用普通 HTTP 服务类似，但框架帮你管理了对话历史、工具调用和部分解析逻辑。
不过要提醒一点：框架只是减少样板代码，它不会自动解决评测、幻觉和控制成本的问题。无论用什么框架，业务侧都必须有输出校验和异常兜底。
5. 批量任务与接口工程化
AI 应用从“单条调用成功”推进到“批量任务稳定跑完”，中间还需要加一批工程能力。
5.1 批量任务设计
批量任务通常有这几个步骤：准备输入、按批次调用、写日志、失败重试、结果落盘。直接写一个 Python 脚本示意：
import json import time import requests from pathlib import Path API_URL = "http://127.0.0.1:8000/v1/chat/completions" INPUT_DIR = Path("./inputs") OUTPUT_DIR = Path("./outputs") MODEL_NAME = "your-model-name" # 失败重试次数 MAX_RETRY = 3 def call_model(text: str) -> str: payload = { "model": MODEL_NAME, "messages": [{"role": "user", "content": text}], "temperature": 0.3 } for attempt in range(MAX_RETRY): try: resp = requests.post(API_URL, json=payload, timeout=120) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] except Exception as e: print(f"attempt {attempt + 1} failed: {e}") time.sleep(2 * (attempt + 1)) return "" def main(): OUTPUT_DIR.mkdir(exist_ok=True) for file_path in INPUT_DIR.glob("*.txt"): text = file_path.read_text(encoding="utf-8") output = call_model(text) out_file = OUTPUT_DIR / (file_path.stem + ".out.md") out_file.write_text(output, encoding="utf-8") print(f"{file_path.name} -> {out_file.name}") if __name__ == "__main__": main()这个脚本里的重试逻辑比较粗糙。真实场景还要加：错误码分类、超时区分、死信队列、断点续跑。比如某些输入本身格式有问题，那重试一百次也没用，应该直接标记为失败，让下游人工处理。
5.2 接口服务的稳定性设计
接口服务上线后，需要关注几个点：
- 超时设置：模型推理通常比普通接口慢，要区分“连接超时”和“读取超时”。
- 并发限制：不能把请求无限打给推理服务，最好在应用层加一个并发信号量。
- 兜底内容：模型超时或服务异常时，返回一个可解释的错误信息，而不是空结果。
- 日志追踪：每次请求记录模型名、输入长度、输出长度、耗时、是否重试。
在做批量任务时，建议输出结构化日志。比如每处理一条就写一行 JSON，包含输入路径、输出路径、耗时、成功失败状态。后续排查问题会省很多时间。
6. 生产级 AI 应用的关键工程组件
如果你要建的不只是一个脚本，而是一个稳定运行的 AI 应用，通常需要补上几个关键组件。
6.1 提示词管理
把提示词全部散落在业务代码里，后面迭代基本要崩溃。建议用配置文件或独立的提示词模板文件统一管理，每个提示词带上版本号。
prompts: summary: version: v3 system: "你是一个文档总结助手，只基于提供的文本输出，不要补充事实。" user: "请总结以下内容。要求：分点输出，每点不超过50字。\n{{text}}" extract: version: v1 system: "你是信息抽取助手，只输出JSON格式。" user: "从下面文本中抽取：合同编号、签署日期、甲方名称。\n{{text}}"这样改提示词就知道改的是哪个版本，出问题可以回退。
6.2 输出校验与结构化解析
如果业务需要模型返回 JSON，单纯“在提示词里要求输出 JSON”并不可靠，模型偶尔会夹带解释文字。工程上要加一道解析校验：
import json def parse_json_output(text: str): # 先尝试直接解析，失败时做兜底处理 try: return json.loads(text) except json.JSONDecodeError: # 一些模型会在JSON前后加说明，做一次提取 start = text.find("{") end = text.rfind("}") if start != -1 and end != -1: return json.loads(text[start:end + 1]) raise ValueError("output is not valid JSON")更稳的方案是使用支持结构化输出的推理框架，让模型在解码阶段就约束输出格式。这样能大幅降低解析报错率。
6.3 评测集与回归
建议每个 AI 应用维护一个testcases.json，字段大致设计如下：
{ "testcases": [ { "id": "case_001", "input": "用户投诉说无法登录账号", "expected": { "category": "账号问题", "should_include": ["登录", "账号"] } } ] }跑测试时，把输入喂给应用，然后检查输出是否满足 expected 条件。你可以每天或每次改动模型、提示词后跑一遍。评测通过率下降，能很快定位是哪次改动引起的。
7. 性能观察与资源占用评估
模型服务上线以后，最怕的就是“好像能跑，但不知道跑到什么程度”。建议从四个维度持续记录：
| 维度 | 观察方式 | 关键信号 |
|---|---|---|
| 显存 | nvidia-smi / 推理框架监控 | 是否接近上限、是否随着并发增长快速升高 |
| 延迟 | 每次请求的开始时间、结束时间 | 平均延迟、P95 延迟是否在可接受范围 |
| 吞吐 | 每分钟完成请求数 | 是否支撑业务峰值 |
| 成本 | token 用量统计、GPU 利用率 | 每千条任务的成本趋势 |
显存观察对本地部署尤其重要。模型加载后显存基本是固定的，但推理时的中间激活值、KV Cache 会随上下文长度和并发数变化。长文本任务会明显提高显存占用。
如果出现服务不稳定，优先观察延迟是不是出现“周期性飙升”。这个现象通常说明推理服务有排队，请求堆积后大量超时。解决方向是限制并发，或者增加推理实例，而不是单纯调大超时时间。
8. 常见问题与排查方法
把团队在 AI 应用落地里最常见的几类问题整理如下：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 本地服务启动后请求一直超时 | 模型未加载完成、显存不足、并发过大 | 查看服务日志，运行 nvidia-smi 检查显存 | 等模型加载完成，降低并发，或换小模型 |
| 模型有时返回不符合格式的内容 | 提示词约束不严格、模型对复杂格式不敏感 | 检查返回原文，复现请求 | 增加输出格式样例，或使用结构化输出能力 |
| 批量任务中途大量失败 | 部分输入格式非法、上游 API 限流 | 查看失败日志中的错误码 | 区分重试与失败，把非法输入单独过滤 |
| RAG 回答与文档不一致 | 检索召回片段不相关、提示词允许模型自由发挥 | 打印检索到的片段，核对提示词 | 调整切分块大小、提高 Top-K 召回，或约束模型只基于片段回答 |
| 调用接口返回 429/限流 | 并发超限、token 消费超速 | 查看调用日志和返回头 | 加并发限制、退避重试、分级调用模型 |
| 同一段输入多次输出不稳定 | 温度参数过高、模型随机性大 | 固定 seed，降低 temperature | 对稳定输出场景设置 temperature=0 或 0.2 附近 |
| 线上效果与测试集差距大 | 测试集和真实输入分布不一致 | 抽取线上失败样本加入测试集 | 持续用真实样本补充评测集 |
这里强调一个习惯：不要只记录“模型返回了什么”，要记录“输入是什么、用了哪个模型版本、哪个提示词版本、处理耗时是多少”。没有上下文记录，排查问题只能靠猜。
9. 合规与使用边界
AI 应用要跑在生产环境，能力之外还要关注数据和内容合规。
- 涉及个人隐私数据，要用脱敏、权限控制、审计日志。
- 涉及人脸、声音等生物特征数据，必须取得明确授权，并限制使用范围。
- 涉及版权素材，确认输入素材和生成内容的使用授权。
- 涉及法律法规、医疗、金融等专业内容，AI 输出只能作为辅助材料，必须有专业人员审核。
- 本地部署不等于完全合规，模型许可协议、训练数据来源、数据存储位置都要纳入评估。
不要为了演示效果去规避这些限制，也不要因为“模型能跑”就忽略业务边界。合规问题在项目上线后暴露，代价远大于前期准备。
10. 下一步：三个值得先做的验证
回到“AI 是否改变一切”这个问题。我建议不要停留在辩论层面，而是选三个具体任务做验证。
第一个，选一个你日常最耗时的文本处理任务，用 RAG 或批量生成搭一个最小原型，记录处理时间前后对比。第二个，挑一段低风险代码，让 AI 编程工具生成初版并补测试，看看人工修改占比到底是多少。第三个，在你自己的业务里挑一百条历史输入，设计一个简单的评测集，跑一遍真实 AI 流程，看通过率是多少。
这三个验证会给你一个比“AI 改变一切”更准确的信息：AI 在哪里能替你省时间，在哪里只能算“看着很聪明”。对技术人来说，这个答案比口号有用得多。
