先搞清楚模型一定会错在哪
AI-FDE转型之路·AI工程01-LLM能力与边界
一、第一件事不是学怎么调模型
做 AI 交付，第一件事不是学怎么调模型，也不是选哪家的大模型，而是它能做什么，它不能做什么，它什么地方容易出错，一定要知道AI能力与边界。
我认为这是整个 AI 工程卷里投入产出比最高的一件事。花两小时，能省掉后面两个月反复返工。因为客户不会因为你用了什么模型给你加分，只会因为它答错一次扣分。这个岗位的成败，从来不取决于最好那次表现，取决于最差那次。
二、AI是什么东西
可以用一句话：
AI（人工智能）本质上是一类让机器通过数据、模型和算法，获得感知、理解、生成、预测、决策和执行能力的技术。
进一步拆开：
AI ≠ 一个具体的软件，也 ≠ LLM。
可以理解成：
人工智能 AI
│
├── 感知
│ ├── 计算机视觉
│ ├── 语音识别
│ └── 多模态
│
├── 理解与推理
│ ├── 机器学习
│ ├── 深度学习
│ └── LLM
│
├── 生成
│ ├── 文本
│ ├── 图片
│ ├── 音频
│ └── 视频
│
└── 行动
├── Agent
├── 工具调用
└── 自动化执行
三、那 LLM 是什么？
LLM = Large Language Model，中文通常翻译为：大语言模型
LLM 是 AI 中负责“语言与知识处理”的一种模型。
主流国内外大语言模型包括：
OpenAI 的 GPT 系列、Anthropic 的 Claude 系列、Google 的 Gemini 系列、Meta 的 Llama 系列，以及国内的阿里通义千问（Qwen）、DeepSeek、月之暗面 Kimi、智谱 GLM、字节跳动豆包、百度文心等。
它们最核心的能力不是“知道答案”，而是：
根据上下文，对下一步最可能出现的内容进行预测，并在大规模参数中形成对语言、知识、代码和问题模式的统计表示。
LLM的本质只是在预测下一个词是什么，一直在做预测，只是预测变成了您认为的答案而已。
中国的首都是，它下一个词的权重最高可能就是北，再次是京。
四、LLM不是在查答案
很多人对大模型的默认想象是一个"智能搜索框"——你问，它去库里找，找到了念给你。这个想象是错的，而且错得很危险。
它在干的事，更像让一个读过很多书的人凭记忆回答你：你问一句，他根据前面那些字，按概率觉得下一个字最可能是什么，接着往下写。他确实读过很多东西，所以他经常是对的；但他是在"补全"，不是在"查找"。
差别在哪？查找找不着会说"没有"，补全不会说“没有”。他记不清的时候会顺着语气编一个，编得很顺，标点都对，读起来比真话还像真话。这就是幻觉的来源，不是模型坏了，是它的工作方式本来就这样。
理解这一点之后，有一个判断就顺理成章了：凡是依赖"精确事实"的场景，都不能裸用模型。 要么给它材料（后面讲检索），要么给它在答不出来时闭嘴的路径（拒答），要么承认这个场景不该做。
这些就需要通过工具来解决，需要通过Agent、skills、MCP接口。
五、四类必错场景
我把它归成四类。这四类不是我拍的，是从制度问答项目里几百条错误答案倒推出来的，命中率很高。
| 类别 | 识别信号 | 例子 | 该怎么做 |
|---|---|---|---|
| 时效性 | 答案依赖"最近发生的" | 本月刚修订的制度、最新挂牌利率、昨天的公告 | 必须接检索或外部数据源，不能靠模型记忆 |
| 专有长尾 | 内部系统名、产品代码、部门缩写、行内术语 | "信贷系统的 ZX07 模块谁维护" | 进知识库，且要做术语对齐；答不出就拒答 |
| 数字与计算 | 涉及算数、统计、跨表汇总 | "这三个季度一共多少笔" | 交给工具算，别让模型直接给数 |
| 多跳与超纲 | 要串三段以上材料，或材料里根本没有 | "按 A 制度第 3 条，这种情况走 B 流程还是 C 流程" | 拆成多步；材料里没有的明确说没有 |
识别信号我建议背下来，比背概念有用。客户现场你只有几十秒判断时间，能立刻说出"这条属于专有长尾，得先补术语表"，比回去查资料强得多。
顺带说一句我自己的教训。早期我做制度问答，第一版上线后客户投诉"答得不准"，我的第一反应是模型不行，想换一个更大的。后来我们把错误答案摊开分类，发现近一半是文档解析的问题——表格被切碎了、扫描件 OCR 把编号识别错了。这属于后面的内容，但教训我先放这儿：看到"答不准"就换模型，是成本最高、效果最差的第一步反应。
六、什么算会了
给自己定的标准是两条：
- 随便给一个业务场景，三十秒内能说出它大概率落在哪一类，以及兜底动作是什么。
- 能说清楚"哪些问题应该拒答",而不是硬答。硬答的代价远高于拒答--客户发现一次编造,后面十次正确答案他也不信了。
自检三个问题，答不上来就回去再看一遍：
客户问"你们这个会不会胡说"，你怎么回答？只说"我们做了优化"是不够的，要说得出哪类问题我们拒答、拒了之后走什么路径。
你手上项目里，命中"时效性"类的问题占比大概多少？（示例数字，只用于估算：制度类问答里通常在 20%–40% 之间，按项目校准）
你的系统现在有没有"拒答"这个动作？还是无论怎样都要吐一句？
七、动手任务
把你的问答系统里最近二十条真实用户问题拉出来，按上面四类归个类，数一下每类各占多少，再标出"其实应该拒答"的比例。
这个动作花不了半小时，但它是后面所有优化的地基。你连错在哪都分不清，改 Prompt、换模型、加检索都是蒙的。做完你会发现，分类结果往往跟你凭印象猜的差很远——我当时以为主要是时效性问题，实际排第一的是专有长尾。
八、坑
别用"语气自不自信"判断对不对。 模型的流畅度和准确率基本无关,越顺的答案越危险,因为人不会去核查。我现在的习惯是:凡是答案里带具体数字、日期、条款编号的,一律要看引用来源。
别问模型"你有把握吗"。 让它自评置信度，得到的多半是礼貌性的谦虚或者莫名其妙的自信，都不靠谱。真正的把握来自检索命中、格式校验、规则校验这些外部手段，不是它自己说的。
别把四类当成"要消灭的问题"。 消灭不掉。你要做的是让每一类都有确定的处理方式：能补材料的补材料，该拒答的拒答，该转人工的转人工。承认它会错，然后设计错了之后怎么办——这才是交付。
《AI-FDE 转型之路》：写给不写代码的 IT 实施 / 售前 / 运维 /普通人，把已有的交付能力「AI 化」。全系列至少55 篇，六大模块 53 项技能。
想先看看自己缺什么:AI-FDE 技能自评地图,53 项打分,出一张雷达图。AI-FDE 转型之路 · 开篇