1. 从一次无人机巡检任务说起为什么几个例子就能让大模型干活去年秋天我帮一个做电力巡检的朋友调试一套无人机自动识别系统。他们的场景很具体无人机沿着输电线路飞拍回来的图里要标出绝缘子破损、销钉缺失、防震锤位移这几类缺陷。传统做法是收集几千张标注图训练一个目标检测模型调参、增强、迭代前后折腾两三个月。但那次他们换了个思路——用一个大模型只在提示词里塞了六张示例图每类两张配上简短的文字说明结果模型在测试集上的表现居然能到可用水平。朋友当时问了我一句话“它凭什么我又没给它训练就给了几个例子。”这个问题问到了点子上。In-Context Learning中文一般叫上下文学习也有人叫“情境学习”就是这件事的学名。它指的是模型在不更新任何参数的前提下仅凭提示词里给出的少量示例就能对新输入做出合理推断。配合Few-shot的示例组织方式这套方法在UAV场景里特别吃香因为无人机任务往往类别细、样本少、需求变得快你不可能每换一个任务就重新训一个模型。这篇内容适合谁看如果你是做无人机应用开发、边缘侧视觉任务、或者刚接触Prompt Engineering想找个具体场景落地的工程师那接下来的东西应该对你有用。我会把“为什么几个例子就管用”这件事拆开讲清楚然后落到 UAV 任务里给你一套能直接抄的提示词组织方法和实操步骤。不聊虚的只讲我踩过的坑和验证过的做法。2. 大模型“看一眼就会”的底层逻辑拆解2.1 预训练阶段到底存下了什么要理解上下文学习得先知道大模型在预训练时干了什么。你可以把预训练想象成让一个人读了整个互联网的文本——不是精读是泛读读的时候一直在做一件事预测下一个词。这个动作看起来简单但为了预测得准模型被迫学会了大量隐含规律。比如它读到“绝缘子表面出现裂纹可能导致”后面大概率跟“放电”或“击穿”读到“无人机在强风环境下姿态”后面大概率跟“失稳”或“调整”。这些规律不是被人写进去的是模型从海量文本里自己压缩出来的。关键在于这些规律以参数的形式分布在模型的数十亿甚至上千亿个权重里。你可以把预训练后的模型看成一个巨大的、高度压缩的“任务模式库”。它没见过你的具体任务但它见过无数类似的结构输入是什么样、输出该是什么样、中间的逻辑关系怎么走。当你给出几个示例时实际上是在激活这个模式库里对应的那一小片区域。这里有个常见的误解很多人以为 Few-shot 是让模型“学会”了新任务。更准确的说法是模型本来就有这个能力示例的作用是告诉它“现在要用哪一种能力、按什么格式输出”。就像你面对一个知识面极广的专家不需要教他电力知识只需要告诉他“现在帮我按这个格式标注缺陷”他就能上手。2.2 示例在注意力机制里扮演什么角色Transformer 架构的核心是自注意力机制。简单说模型在处理每一个词的时候会去看输入序列里其他所有词计算它们之间的关联强度。当你把几个示例拼进提示词示例里的输入和输出就变成了注意力可以“参照”的锚点。我打个比方。你走进一个陌生的厨房要做一道没做过的菜。如果灶台上空空如也你只能凭经验猜。但如果旁边摆着三盘已经做好的样品你一眼就能看出“哦原来是要切成这个大小、用这个火候、摆成这个样式”。示例在提示词里的作用就是那三盘样品——它们不改变你的厨艺水平但极大地缩小了你的搜索空间。具体到技术层面模型在处理新输入时注意力权重会自然地向示例中结构相似的部分倾斜。比如你给的两个缺陷示例都是“局部放大图 缺陷名称 位置描述”那么新图片进来时模型会优先关注图片的局部区域并按照“名称 位置”的格式组织输出。这种模式匹配不需要梯度更新完全在前向传播中完成。2.3 为什么 UAV 场景特别适合这套方法无人机应用有几个鲜明特点。第一任务类别经常变。今天巡检电力线明天可能查河道排污后天可能看农田病虫害。每换一个任务就重新训练模型成本高到不现实。第二样本获取难。无人机拍到的某些缺陷比如特定型号的销钉缺失可能整个数据集里就几十张标注还贵。第三边缘部署受限。无人机上算力有限你不可能带一个需要频繁微调的大模型上去。Few-shot 配合 Prompt Engineering 恰好对上这些痛点。不需要重新训练改提示词就行几个示例就能启动样本压力小推理时模型参数不变部署相对轻量。当然这不意味着它万能后面我会讲什么情况下它会翻车。3. 面向 UAV 任务的 Prompt Engineering 实操框架3.1 提示词的结构设计四段式模板我在 UAV 任务里反复用过一个四段式结构实测下来比较稳。这四段分别是角色设定、任务描述、示例区、新输入区。每一段都有它存在的理由不是凑数。角色设定放在最前面比如“你是一个无人机巡检图像分析助手负责识别输电线路缺陷”。这句话的作用是激活模型在预训练中见过的相关文本模式。模型见过大量技术文档、巡检报告、缺陷描述角色设定相当于给它一个“频道”让它往那个方向靠。任务描述要具体到输出格式。不要写“识别图片中的缺陷”要写“判断图片中是否存在绝缘子破损、销钉缺失、防震锤位移三类缺陷输出格式为缺陷类型 | 置信度 | 位置描述”。格式越明确模型越不容易跑偏。示例区是核心。每个示例包含一张图或图的描述和对应的标准输出。示例的数量、顺序、多样性都有讲究下一节展开讲。新输入区放待分析的图片或描述后面跟一个空的输出占位符比如“输出”。这个占位符很重要它告诉模型“该你填了”。3.2 示例怎么选数量、顺序与多样性先说数量。Few-shot 里的“few”通常是 2 到 5 个。我试过 1 个、3 个、5 个、10 个在 UAV 缺陷识别任务里3 到 5 个的收益最明显超过 5 个之后提升很小但提示词长度和推理成本线性增长。如果任务特别简单比如只判断“有缺陷/无缺陷”1 到 2 个就够。如果类别多、边界模糊5 个左右比较稳妥。顺序方面有个反直觉的发现把最典型、最清晰的示例放在最后效果往往更好。原因是模型对靠近输出位置的上下文更敏感最后一个示例相当于“最近的参照”。我一般把最容易混淆的类别示例放中间把最标准的放最后。多样性比数量更重要。如果你给三个示例都是绝缘子破损那模型遇到销钉缺失时可能硬往绝缘子上靠。我的做法是每个类别至少一个示例如果类别超过五个就选最容易混淆的那几个类别各给一个。另外示例的拍摄角度、光照条件、背景复杂度也要有差异让模型知道“这些变化不影响判断”。3.3 输出格式约束让模型说“人话”也“说对话”UAV 任务里模型输出最终要被程序解析所以格式约束不是可选项。我常用的做法是在任务描述里给出一个明确的模板然后在每个示例的输出里严格遵循这个模板。比如缺陷识别任务模板可以是缺陷类型: [绝缘子破损/销钉缺失/防震锤位移/无缺陷] 置信度: [高/中/低] 位置: [图像中的相对位置描述] 建议: [是否建议人工复核]这里有个细节置信度用“高/中/低”而不是百分比。原因是模型对数值的校准往往不准给个 0.87 反而误导。用离散等级模型更容易保持一致后续程序也好处理。还有一个技巧是在示例里故意包含一个“无缺陷”的样本。很多团队只给缺陷示例结果模型看什么都像缺陷。加一个正常样本能显著降低误报率。4. 完整实操从零搭建一个 UAV 缺陷识别 Few-shot 流程4.1 环境与模型选择先说模型选择。UAV 场景对推理延迟敏感如果做边缘部署7B 到 14B 参数的模型是比较现实的区间。再大推理速度跟不上再小理解能力不够。如果做地面站处理可以上更大的模型但要注意显存占用。我实测过几个开源模型在缺陷识别任务上的表现。Qwen2.5-7B 在中文技术文本理解上比较稳对格式指令的遵循度也高。LLaMA 系列英文强但中文缺陷描述偶尔会飘。具体选哪个建议你拿自己的数据跑一遍因为不同模型对提示词结构的敏感度差异很大。部署方式上如果只是验证效果用 Ollama 拉一个量化版本最快一条命令的事。如果要上生产vLLM 的吞吐更好支持连续批处理适合多路无人机同时回传的场景。边缘设备上可以考虑 llama.cpp 的量化推理7B 模型 INT4 量化后大概 4GB 左右很多机载计算单元能跑。4.2 提示词模板的完整写法下面是我在电力巡检任务里实际用过的提示词模板做了脱敏处理你可以直接改成自己的类别。你是一个无人机输电线路巡检图像分析助手。你的任务是分析无人机拍摄的线路部件图像判断是否存在以下三类缺陷绝缘子破损、销钉缺失、防震锤位移。如果均不存在输出“无缺陷”。 输出必须严格遵循以下格式 缺陷类型: [绝缘子破损/销钉缺失/防震锤位移/无缺陷] 置信度: [高/中/低] 位置: [描述缺陷在图像中的相对位置] 建议: [建议人工复核/无需复核] 以下是示例 示例1 图像描述一张俯拍图像画面中央的绝缘子串右侧第二片表面有明显裂纹裂纹呈放射状。 输出 缺陷类型: 绝缘子破损 置信度: 高 位置: 画面中央偏右绝缘子串第二片 建议: 建议人工复核 示例2 图像描述一张侧拍图像防震锤整体向线路外侧偏移约一个锤身宽度连接处无明显变形。 输出 缺陷类型: 防震锤位移 置信度: 中 位置: 画面左下防震锤与线路连接处 建议: 建议人工复核 示例3 图像描述一张正视图像绝缘子串、销钉、防震锤均处于正常位置表面无可见损伤。 输出 缺陷类型: 无缺陷 置信度: 高 位置: 不适用 建议: 无需复核 现在分析以下图像 图像描述[待分析图像的描述] 输出这个模板有几个设计点值得说。第一示例里图像描述用的是自然语言不是图片本身。这是因为很多部署环境不支持多模态输入用文字描述更通用。如果你用的是多模态模型可以把描述换成图片占位符。第二每个示例的输出都严格对齐格式一个字符都不差。模型对格式的模仿能力很强你给什么格式它就学什么格式。第三最后一个示例是“无缺陷”放在最后能强化“不要过度报警”的倾向。4.3 参数配置与推理设置提示词写好了推理参数也得调。我常用的配置是温度 0.1 到 0.3top_p 0.9最大输出长度 256。温度低是为了保证输出稳定UAV 任务不需要创意需要一致性。top_p 0.9 是留一点余地避免完全死板导致某些边界情况处理不了。有个坑我踩过最大输出长度设得太短模型输出到一半被截断格式就乱了。256 对于上面那个模板是够的但如果你类别更多、位置描述更细可能要加到 512。建议先跑一批测试看输出长度的分布取 95 分位再留点余量。还有一个参数是重复惩罚。有些模型在 Few-shot 模式下会反复输出示例里的内容尤其是当新输入和某个示例比较像的时候。重复惩罚设 1.1 左右能缓解但别设太高否则模型会刻意避开示例里的词反而影响判断。4.4 效果验证与迭代跑完第一批测试别急着上线。我一般会做三件事。第一统计格式合规率。如果模型输出有 5% 以上不符合模板说明提示词约束不够要回去改。第二看混淆矩阵。哪两类缺陷最容易混就针对性地加一个区分示例。第三人工抽检低置信度的输出。模型标“低”置信度的样本往往确实是边界情况这些样本值得单独拿出来分析。迭代的时候每次只改一个变量。要么加示例要么改格式要么调参数。同时改多个你分不清是哪个起了作用。我见过有人一次改五处效果好了也不知道为什么好下次换个任务又抓瞎。5. 常见问题与排查技巧实录5.1 模型不按格式输出怎么办这是最高频的问题。表现是模型输出了一段自然语言但没有按你给的模板来。原因通常有三个示例里的格式不够统一、任务描述里的格式说明不够靠前、或者模型本身指令遵循能力弱。排查顺序先检查示例确保每个示例的输出格式完全一致连标点符号都一样。然后检查任务描述把格式要求放在最前面不要藏在段落中间。如果这两步都做了还不行换一个指令遵循更强的模型试试。有些小模型在 Few-shot 下格式遵循确实差这不是提示词能解决的。5.2 示例多了反而变差这个现象我遇到过。当时从 3 个示例加到 8 个准确率反而掉了。后来分析发现新增的示例里有两个标注本身就有争议模型被带偏了。Few-shot 的示例质量比数量重要得多。一个模糊的示例破坏力大于三个清晰示例的收益。另一个原因是上下文长度。示例太多提示词变长模型对每个示例的注意力被稀释反而抓不住重点。UAV 任务里我建议示例控制在 5 个以内除非你的类别确实多到 5 个覆盖不了。5.3 新类别加入后旧类别识别变差这是典型的“灾难性遗忘”在提示词层面的表现。你加了新类别的示例模型注意力被新内容吸引旧类别的模式匹配变弱。解决办法不是加更多旧示例而是重新平衡示例的分布。每个类别至少一个容易混的类别多给一个。另外把类别列表在任务描述里完整列出让模型知道“总共有这些类别”而不是只从示例里推断。5.4 排查速查表问题现象可能原因排查动作解决方向输出格式混乱示例格式不统一逐字对比示例输出统一示例格式格式说明前置准确率低于预期示例质量差或有歧义人工复核示例标注替换模糊示例每类至少一个示例增加后变差上下文过长或示例冲突减少示例数量检查冲突控制在5个以内去冲突新类别影响旧类别示例分布失衡统计各类别示例数重新平衡任务描述列全类别输出重复示例内容重复惩罚过低检查重复惩罚参数调到1.1左右低置信度样本多任务边界模糊分析低置信度样本补充边界示例或细化类别定义5.5 几个我踩过的坑第一个坑用图片直接做示例。早期我试过把图片编码后塞进提示词结果发现模型对图片的理解远不如对文字描述的理解稳定。后来改成“人工描述 模型分析”的混合模式准确率反而上去了。如果你的场景必须用图片建议用多模态模型并且图片要预处理裁掉无关区域。第二个坑忽略示例的拍摄条件。有次示例全是晴天拍的测试时遇到阴天图片模型置信度普遍偏低。后来在示例里加了不同光照条件的样本问题缓解。UAV 任务的环境变化大示例的环境多样性要刻意保证。第三个坑把提示词写得太“礼貌”。早期我写“请你仔细分析这张图片如果有缺陷请指出”模型有时候会回“好的我来分析”。后来改成直接的指令式“分析以下图像按格式输出”废话少了很多。大模型对指令式表达的遵循度通常更高。6. 从 Few-shot 到 Zero-shot什么情况下可以省掉示例跑通 Few-shot 之后我建议你试一件事把示例全部删掉只留任务描述和格式模板看效果掉多少。这个测试能帮你判断模型对这个任务的理解有多深。在我的电力巡检任务里Zero-shot 的准确率大概是 Few-shot 的 70% 到 80%。也就是说示例确实在起作用但模型本身对“绝缘子破损”这类概念有基础理解。如果你的任务类别是模型预训练中常见的比如“人”“车”“建筑”Zero-shot 可能就够用。如果是高度专业的类别比如“某型号销钉的特定缺失形态”Few-shot 几乎是必须的。还有一个折中方案叫“One-shot”只给一个最典型的示例。在类别少、边界清晰的任务里One-shot 的性价比很高。我有个做河道巡检的朋友只判断“有漂浮物/无漂浮物”One-shot 就搞定了提示词短推理快维护也简单。判断标准很简单先跑 Zero-shot如果准确率能到 85% 以上就别加示例了省 token 省时间。如果掉到 60% 以下Few-shot 跑不掉。中间地带One-shot 或 Two-shot 试试看。7. 提示词工程的边界它不能解决什么说了这么多 Few-shot 的好处也得讲讲它的边界。第一它不能替代领域知识。如果你自己都说不清“绝缘子破损”和“绝缘子污秽”的区别模型更分不清。提示词工程的前提是你对任务有清晰的定义。第二它不适合需要精确数值输出的任务。比如让你估算缺陷尺寸Few-shot 给出的数值往往不准。这种任务还是得靠专门的回归模型或者传统视觉方法。第三它对长尾类别的覆盖有限。如果某个缺陷类型在示例里没出现模型基本不可能自己发现。Few-shot 的“举一反三”是在类别框架内的泛化不是无中生有。第四推理成本随示例增加而增加。UAV 场景对延迟敏感示例多了每次推理的 token 数上去响应时间就下来。这个权衡要提前算清楚。8. 一个可复用的 UAV 提示词工程检查清单最后给你一份我在实际项目里用的检查清单每次新建一个 UAV 识别任务按这个过一遍能省不少返工。任务定义是否清晰到可以用一句话说清输入和输出类别列表是否完整有没有遗漏的边界类别每个类别是否至少有一个示例示例的拍摄条件是否有差异光照、角度、背景示例输出格式是否完全统一连标点都一致任务描述里的格式要求是否放在最前面是否包含一个“无缺陷/正常”示例温度是否设在 0.1 到 0.3 之间最大输出长度是否留了足够余量是否跑过 Zero-shot 基线做对比是否统计过格式合规率和混淆矩阵低置信度样本是否有人工复核机制这份清单不是死的你可以根据自己任务的特点增删。但核心逻辑不变示例要清晰、格式要统一、边界要覆盖、参数要保守、验证要量化。把这几点做到Few-shot 在 UAV 任务里的表现通常不会让你失望。我在实际使用中发现最容易被低估的是“无缺陷示例”的作用。很多团队为了省事示例全是缺陷样本结果模型上线后误报率高得离谱。加一个正常样本往往比加三个缺陷样本还有用。这个细节希望你别踩同样的坑。