大模型这个词已经从论文标题走进了招聘要求，但很多人对它的掌握停留在「会调 API」和「知道 Transformer 这个词」之间。第 18 期训练营面向的正是这段空档：能跑通示例，却说不清推理为什么贵；能改提示词，却不知道怎么把模型接进一条真业务链路。下面按能力缺口拆开讲，你可以对照自己的情况决定要不要跟。

缺口一：把大模型当黑盒调，原理说不清

会写 messages 数组不等于理解模型在做什么。这一部分要补的是：自注意力到底在算什么、位置编码解决的是什么问题、为什么上下文一长成本就上去了、温度与采样参数如何影响输出稳定性。

补完这块，你至少要能回答：同一个问题问两次答案不同，是模型的问题还是参数的问题？为什么给模型更多上下文有时反而更差？推理显存被什么吃掉？

缺口二：提示词靠试，不成体系

提示工程不是堆「请你扮演一位专家」。课程要练的是结构化做法：把任务拆成指令、约束、示例三段；用少样本示例控制输出格式；用思维链处理需要推理的任务；把不稳定的自由输出收敛成可解析的结构。

配套练习会围绕同一任务的迭代展开——先写一版能跑的，再看它在边界输入下怎么崩，然后一步步加约束修回来。能做完这个过程，你就不会再把「调不好」归结为模型不行。

缺口三：只会单轮对话，不会搭应用

从对话框到应用之间，隔着检索、记忆、工具调用三件事。这一段的重点：

检索增强：文档怎么切、向量怎么召回、召回结果怎么塞回提示而不撑爆上下文。
记忆与状态：多轮对话里哪些信息该留下、哪些该丢弃，会话状态放在哪一层。
工具调用：让模型决定什么时候去查数据库、调接口，以及调用失败后怎么兜底。
编排：把上面几块串成一条可复现的流程，而不是写死在一个脚本里。

练习以可运行的小系统为单位，做完你应该能回答：我的应用在什么情况下会答错，错在检索、提示还是模型本身？

缺口四：做得出来，但不敢上线

能演示和能上线是两回事。这里补的是评估与成本：怎么构造一批能反复跑的测试用例来衡量改动有没有变好；怎么用缓存、分流、小模型兜底把单次调用成本压下来；输出里出现不该出现的内容时，在哪一层拦截。

这部分不要求你成为运维专家，但要能在被问「这个功能一个月烧多少钱、坏了怎么发现」时给出具体数字和办法。

看完应能回答的问题

给你一段业务需求，你能判断该用提示工程解决，还是必须上检索或微调吗？
模型输出格式总是不对，你的排查顺序是什么？
上下文超限时，你优先砍哪部分内容，依据是什么？
你怎么证明一次改动让效果变好了，而不是碰巧？

如果这几个问题里有三个以上你答不上来，这期内容对你有用；如果全都能答，缺的可能是工程规模上的经验，而不是这门课能补的。缺什么补什么，别在已经会的地方反复花时间。