开始生成博文1. 先搞明白LLM 的“动手能力”到底是谁给的我最早看到“LLMs Do It by Hand”这个标题时第一反应是有点想笑——大模型不是靠数据自动学出来的吗怎么还需要“手”来教但做了一段时间实际项目之后我彻底改观了所谓“大模型很聪明”其实大部分场景下是“背后有人用手把知识一点点喂给它”。这里的“by hand”不是指模型用手而是指我们这些工程师、产品经理、业务专家必须亲自动手把领域知识用一种模型能看懂、能遵循的形式组织好再注入进去。这就像教一个天赋不错但什么都不懂的学生你不能把一堆课本丢给他就算完事你得帮他把重点圈出来、把框架理清楚、把例子排好甚至得陪着他反复练习和纠错。很多刚接触 LLM 的人会有一个错觉我在 Prompt 里写一句“你是某领域专家”模型就能自动输出专家级回答。实测下来完全不是这样。模型在预训练阶段确实学到了海量通用知识但那些知识是胶着的、隐式的、没有结构的。当你要它处理一个特定领域的专业问题——比如医疗影像报告、工业设备故障诊断、农业种植决策——通用知识会不足甚至会把错误信息包装成可信的样子。这时候“手工注入领域知识”就成了绕不开的活儿。这篇文章想聊的就是“用手教 LLM”这件事本身。我会结合一些实际项目经验拆解为什么手工方式比纯自动微调更可靠、怎么设计结构化的领域知识注入方案、怎么像带新人一样一步一步把模型教会以及中间躲不开的那些坑。无论你是做 RAG 应用、做垂直行业大模型还是只是在调一个任务型 Agent这篇文章里的内容应该都能直接用上。2. 为什么非要用“手”自动训练的边界在哪2.1 预训练模型的知识是“死”的先做一个测试。你让一个通用大模型回答某个刚出现的新产品规格或者某个只有你们公司内部才有的流程制度它大概率会胡编。原因在于它的知识在预训练时就已经冻结了时间被切在一个固定的点。你后续不喂新知识它就不会知道。这个道理大家都懂但很多人没想通第二层即使喂了喂得不讲究它照样会用错。预训练模型内部的知识结构是“扁平”的或者更准确地说是语义上高度纠缠的。同一个词在不同领域里含义完全不同模型只靠概率分布去猜很难像人一样主动意识到“这里是哪个上下文”。比如“负荷”这个词在电力领域是功率在心理学领域是压力在健身领域是训练量。如果不在注入的时候就做好领域标定模型只能靠猜。猜错了就出现了那种“一本正经胡说八道”的经典场面。所以“by hand”的第一个含义就是你需要手动告诉模型这个业务场景里哪些概念是核心哪些概念之间是层级关系哪些规则是硬约束哪些只是参考。这比单纯堆几条资料要复杂得多但如果省略这一步后面的 RAG 或者微调都会变成在错误的语义地基上盖楼。2.2 自动化方法不是万能的有人说既然要注入知识那用 RAG检索增强生成不就行了吗把资料库接上去模型自己会检索。听起来很自动实际落地时你会发现RAG 的检索召回率、相关度排序、上下文截断策略每一项都需要手工调。更麻烦的是如果知识库里同一个概念出现了互相矛盾的描述模型会先采信检索结果的顺序而不是你自己的知识优先级。这时候你得手工设计一套知识冲突消解的规则。微调也类似。很多人以为微调是把资料丢上去让模型自学习,实际上做过的都知道微调前要花大量时间清洗数据、标注字段、设计训练样本格式。微调是要“手工”到数据标注层面而且微调完成后模型可能会产生灾难性遗忘把原本会的东西给丢了。这时候又得手工混入原始通用数据来平衡。我用一个类比来解释预训练模型像一个有很强推理天赋但缺乏行业训练的年轻人。RAG 相当于在他桌上放了一摞参考书他考试时能翻书但不知道哪本书权威、哪一章是重点。微调相当于把他送去一个培训班但培训班如果只教考试题他可能连基本的加减乘除都忘了。而“LLMs Do It by Hand”这套做法相当于你亲自当他的导师给他划重点、画知识树、布置阶梯式练习题并且每次答错了都当面纠正。这种方式慢但可控、可解释、效果好。所以“by hand”不是退步而是在当前技术条件下性价比最高的路径。3. 手工注入领域知识的三种主流姿势3.1 提示词里的“结构化教案”最轻量的手工注入方式是把领域知识直接写进提示词但绝不是“你是XX专家”那么敷衍。要像写教案一样把知识分层、分块、给例子、给反例。举一个我实际做过的例子给一个法律咨询助手注入交通事故赔偿规则。我最初的提示词是“你是交通事故法律专家请回答用户问题”。结果模型经常把责任划分的比例搞错还把不同地区的标准混在一起说。后来我改成结构化教案式提示词结构大致如下【知识领域】交通事故责任认定 【核心规则】 - 规则1机动车与非机动车驾驶人碰撞责任划分依据《道路交通安全法》相关条款。 - 规则2因超速导致事故超速方承担主要责任具体比例需结合现场证据。 【参考判例】 - 判例A某地法院判决超速20%以上承担70%责任。 - 判例B某地法院判决未观察路况承担30%责任。 【禁止事项】 - 不得直接给出具体赔偿金额必须提示个案差异。 - 不得混淆工伤赔偿与交通事故赔偿。 【输出格式】 - 先分析责任依据再给出结论。这样改完之后回答准确率明显提升。为什么有效因为模型是概率推理你把规则前置、例子跟上、禁止项压后等于画出了高概率的路径。这跟人学习时先看大纲再看细节再看易错点的顺序是一样的。这就是“by hand”最直接的体现你手动编写了这份教案。3.2 RAG 检索里的“知识骨架”RAG 不是简单地把一堆 PDF 扔进向量库。你会发现如果文档本身结构混乱、术语不统一检索效果惨不忍睹。所以手工部分至少包括三件事第一文档切分策略要手工设计。不能按固定字符切要按语义边界切——一个段落、一张表、一条流程说明要尽量完整。如果固定 500 字一刀切一个规则被切到两段模型检索到的信息就是残缺的。第二索引字段要手工标定。给每个知识块打上元信息比如所属章节、知识类型规则/案例/参数、适用条件、置信等级。这就像给书做目录和索引没有它检索就是瞎找。第三需要用知识图谱或 JSON 结构维护概念之间的层级关系。比如设备维修领域“液压系统”下面有“油泵”“阀门”“管路”“油泵”又有关联的“故障模式”“维修步骤”。把这些关系手工维护好检索时模型才能顺着关系链找到答案。单纯靠语义相似度匹配会频繁出现“字面很像但意思不对”的结果。我做过一个实验同样一个农业知识库直接丢进向量库检索的准确率在 65% 左右手工做了一轮“结构感知注入”——整理出农作物品类树、病虫害对照表、用药规则层级——之后准确率提升到 87%。中间唯一的变化不是模型不是向量库而是知识被手工整理成了有序的结构。3.3 微调数据集里的“人工标注”微调的数据集本身就是高度手工产物。你有多少条优质问答对模型就能学到多少。很多团队喜欢从网上扒公开数据集效果通常不好因为目标领域不同、表述习惯不同、约束条件不同。手工构造数据集时我的经验是先做一版“种子数据”把业务中最常见的 50 个问题逐一写出标准答案并在每个答案里标明推理过程。这个过程慢但让你看清模型到底该学到什么。之后再用种子数据去生成扩展数据。这里有个技巧让大模型基于种子数据改写表述方式而不是凭空生成内容。因为改写能保持语义骨架不变凭空生成容易跑偏。但改写的每一批结果都要人工抽检。别指望全自动流水线你抽检越多数据质量水平线越高。这就是“by hand”的第三个场景手工标注让模型真正习得领域推理习惯而不只是记住几个答案。4. 结构感知注入的实操拆解4.1 领域知识结构化的三层模型把领域知识手工注入模型我建议先按“实体-关系-约束”三层来组织。实体就是名词比如设备、零件、故障、维修动作。关系是实体之间的边比如“属于”“导致”“依赖”“防止”。约束是业务规则比如“温度超过80度时必须停机”“领用耗材必须先审批”。为什么要分这三层因为 LLM 最擅长的是语言模式匹配它不擅长理解隐性的业务逻辑。你把逻辑显式拆分出来它才能稳定复现。举个例子。做电力设备巡检助手时我整理的知识片段长这样实体变压器型号 T-V2额定容量 500kVA 实体温度表位置在变压器顶部量程 0-150℃ 关系变压器 - 配置 - 温度表 关系温度表 - 监控 - 变压器顶层油温 约束顶层油温高于85℃时触发告警并建议减载 约束顶层油温高于95℃时建议紧急停运把这种结构化数据转成提示词或微调样本模型回答维修建议时会先定位实体再检查约束最后生成结论。而不是一上来就拍脑袋说“建议检查绝缘油”虽然那也不算错但缺乏针对性和安全边界。手工做实体、关系、约束的梳理工作听起来枯燥却是整个方案里回报率最高的一步。我建议用表格管理每个实体一行每个关系一行然后让业务专家审核。这一步别省因为业务专家的隐性经验是模型学不到的。4.2 让模型“看得见”知识结构的提示格式结构梳理好了怎么“喂”给模型答案是用 XML 或 JSON Schema 这类带标签的格式千万别用一堆纯文本堆在那里。原因有两个一是带标签的格式能让模型更容易区分“知识元”的边界二是模型在训练时看过大量类似格式能更快把标签和语义关联起来。下面是一段实际使用过的提示模板片段knowledge entity name油泵 category液压组件 property name额定压力 value21MPa/ property name工作流量 value32L/min/ /entity rule idR1 levelhard condition泵出口压力低于15MPa/condition action首先检查溢流阀整定值其次检查油泵内泄漏/action /rule /knowledge使用时直接把这段 XML 放进 System Prompt再让用户问题带上当前状态信息。模型会倾向于按 rule 的 condition-action 结构去回答。如果不用 XML 而用散文模型容易漏掉条件。这个现象在实操中反复出现我甚至测试过“三级标题列表”格式效果都不如 XML 明确。还有一点结构感知注入不是一次性写的它要持续演进。规则变了、实体属性变了你只需要改 XML 里的对应行。模型本身不用重新训练提示词一变行为立刻变。这种“by hand”带来的敏捷性是微调给不了的。4.3 注入顺序也会影响效果同样的知识先讲什么后讲什么会影响模型的表现。我习惯按“目标-约束-示例”的顺序排列。先告诉模型在这个场景下要干什么再告诉它绝对不能做什么最后给几个正确示例。这样模型在生成时会被约束条件限制住再被示例校准语气和细节密度。如果你把示例放在最前面模型可能直接模仿示例而忽略约束。如果你把约束放太远模型输出到一半就可能越界。有一次我排错了顺序把规则放在一大段背景介绍之后结果模型回答问题时先豪迈地给了一通建议完全没提规则里“必须经过现场确认”的前提。后来我调整顺序把“必须现场确认”作为与用户问题直接相关的强制条件放在所有自由发挥之前效果立刻变了。这件事给我的启示是LLM 是概率模型你给它排的学案顺序其实就是优先级信号手工排列顺序本身就是一种编程。5. 像教育学生一样教育模型五个实操阶段5.1 摸底考——先知道模型现在几斤几两拿一个通用模型直接跑你的领域问题把输出保存下来。别急着挑错先看它哪些地方是模糊的、哪些地方有事实偏差、哪些地方措辞不够专业。这部分输出就是“摸底考试”。你要做的是给每类问题打一个“能力缺口”标签例如“术语理解缺失”“规则记忆错误”“推理步骤跳步”。后续所有手工干活都是针对这些缺口的别漫无目的地做。我习惯用一个表来记录问题ID、模型输出、标准答案、偏差类型、严重程度。这个表就是你的教学计划。一次只解决最影响业务结果的偏差类型不要贪多。5.2 备课——把知识拆成最小组件前面提到的实体-关系-约束结构就是备课过程。每一步都要问这个知识点模型自己可能已经知道吗如果知道就不用手工注入如果不知道或者经常用错就一定要显式写进去。比如“变压器”模型肯定知道但“变压器的顶层油温告警阈值”它大概率不知道就得写。备课阶段要特别注意量和质的关系。一次注入太多规则模型会顾此失彼。我建议每次提示词里结构化知识控制在 10 条核心规则以内超出部分依赖 RAG 检索。比如你有 100 条规则全部放进上下文不现实手工梳理出最常用的 8 条作为“常驻知识”剩下的按需检索。5.3 小步试教——用样例带着学给模型的题目要从易到难。先给它一个完全符合规则的标准案例让它照着规则推理再给它一个部分满足条件的案例考它是否有遗漏最后给它一个边界案例看它会不会突破约束。这个过程就是把以往带新人时用的“先模仿、再变式、后挑战”的教学方法搬到模型身上。比如教一个采购合规助手第一题“申请金额 5 万元属于标准采购问需要哪些审批流程”模型照着规则回答即可。第二题“申请金额 8 万元但属于紧急采购是否仍需要招标”模型需要识别紧急采购的例外条款。第三题“供应商是法人直系亲属金额 3 万元如何规避利益冲突”模型要综合多个约束。每一道题的答案都要人工确认并作为 few-shot 示例留在上下文里。这样下一次面对新问题时模型会参考刚“做对”的范例。这个循环很像批改作业——你改得越细模型下回错得越少。5.4 错题本——把失败案例变成正反馈模型做错了别只改 Prompt 再碰运气。我的做法是维护一个“错题本”每条记录包含错误输入、错误输出、为什么会错、标准输出、以及提炼出的新规则。然后把新规则回填到知识结构里形成闭环。这个步骤虽然繁琐但它是结构感知注入的精髓所在不是一次把知识写全而是通过试错把缺的知识手工补上。有一次我做一个医疗器械分类助手模型把“体外诊断试剂”归到“医疗器械”之外。我查了一下业务标准里它是第二类医疗器械。我在知识 XML 里增加了一条实体关系并在错题本里记录下“分类归属”这个高风险点。后续这个分类问题就再没犯过。如果不是用手工方式记录并回填这个问题会被淹没在各种泛泛的错误里。5.5 期末考试——用客观指标验收最后一个阶段是建立验收集。挑选 100 个典型问题覆盖所有规则、边界情况、常见误用场景。定期跑一遍计算准确率和格式合规率。这个验收集要人工标注而且要坚持在每次知识改动后重跑。没有验收集你所谓的“手感变好了”就只是自我安慰。有了验收集你可以看到每一次手工改动带来的净收益。我目前这个验收集不是一次建的而是每次踩坑后往里面塞新样本。现在已经积累了 400 多条。每次改动知识提示词跑一遍对比前后数值再决定是否发布。这种方式让模型迭代变得像软件工程一样有版本号、有测试报告。6. 常见问题与排查技巧实录6.1 注入了知识模型还是不用最典型的挫败感就是你把规则写得明明白白模型回答时就是不理。排查思路有三步。先看规则是不是离用户问题太远没有出现在模型的注意力范围内——调整方法是把核心规则放在 System Prompt 的末尾让模型“最后看到”。再看规则是不是与模型预训练时的常识冲突比如你规定“某故障必须先检查软件再检查硬件”但模型常识里认为硬件故障概率高它就会往硬件上靠。解决办法是在规则里加上“为什么”的解释给一个合理理由模型会更愿意遵循。最后看是不是规则相互矛盾——模型面对冲突会随机押宝可能这次遵循了下次就没遵循。6.2 知识注入后模型变“呆”了有时发现注入了大量领域知识后模型的发散能力和灵活性下降回答变得模板化。这其实是提示中结构过于刚性导致的。把知识结构从“强制顺序”改为“可选项”在 XML 里把规则标记为levelsoft表示参考而非硬性。比如“输出格式”可以做成软约束大不了后处理再格式化。领域知识的核心硬规则保留硬约束其余都往下放模型就能恢复一定的弹性。还有一个原因是一步注入了太多知识上下文被挤占模型失去了从用户问题中捕捉细节的空间。这时要果断删掉低频知识改为 RAG 按需检索。上下文窗口不是给你当仓库用的它是给模型做短期记忆用的。6.3 对“知识冲突”的处理实际项目中不同来源的知识之间经常打架。比如厂家手册说“油温高于70度继续运行”你们内部规程说“高于70度必须警戒”。这种冲突如果不处理模型会随机选择一个或者更糟两种都输出。手工处理冲突的方式是引入“优先级”字段。在知识结构里给每一份知识标记来源等级例如“现场规程 设备手册 行业通用说法”。在提示词里给模型一条优先级判据“当多个规则冲突时自动应用更高优先级规则并在回答末尾注明冲突点。”这样模型至少不会乱来。同时要在验收集里专门加入冲突场景确保模型稳定使用优先级逻辑。6.4 模型在中间步骤“忘了”前面学的知识长任务推理时模型经常会在第一步正确调用了知识到第三步就忘了。这个问题的本质是注意力漂移。解决办法有两种。一种是显式把中间结论写出来让模型像人做笔记一样把关键状态记录在输出流里。另一种是拆分成多个子任务每个子任务重新注入对应的知识片段。我用后者更多因为每个子任务的上下文更短知识不容易被挤掉。比如故障诊断场景我不让模型一次性回答“可能是什么故障、由什么原因导致、怎么维修”。我拆成三步第一步只做故障现象分类输入只有现象列表和分类规则第二步基于分类结果查询原因输入是原因表第三步给出维修步骤输入是维修 SOP。每步单独用一次模型调用。这样的效果远好于让模型在一个长上下文里从头算到尾。虽然多花几次 API 调用但正确率提升明显。6.5 手工内容如何避免“模型学到的是噪声”有时候业务专家交付的资料本身就混乱用词不一致、规则有例外但没写全、案例相互矛盾。如果把这些资料直接整理进知识结构模型学会的就是噪声。我的经验是先做一轮术语归一化确定一个标准词表把同义异形词全部统一。比如“紧急”“加急”“优先处理”统一为“紧急”。然后再做规则完整性审查每一条规则必须回答“在什么条件下适用”“在什么条件下不适用”。写不出来的先标注为“待确认”不要硬塞给模型。手工注入知识时要区分“事实性知识”与“规范性知识”。事实性知识描述世界是什么规范性知识描述应该怎么做。模型容易把规范当成事实导致它在无法满足条件时仍然机械执行。所以提示词里建议给规范知识加“条件不满足时如何应对”的提示。例如“当设备停机但现场无维修工时应升级为待计划维修而不是执行强制检查”。否则模型会教你一个无法落地的操作。7. 我的几个经验体会真正做过几个领域模型项目之后我愈发认同“LLMs Do It by Hand”这句话的分量。很多人追求自动化想一劳永逸地把知识倒进模型里结果都会在效果返工上交学费。反而是那些愿意花时间做实体关系梳理、写结构化 XML、维护错题本、搭验收集的团队最终做出了稳定可用的东西。有一个小技巧想分享如果你精力有限优先整理“规则类知识”因为这类知识的错误代价最高。比如医疗、工业、金融领域一条规则说错了可能造成实质影响。Model 在预训练时没有掌握这些规则必须靠手工。其次再整理“实体属性”类知识因为属性查错了至少可以通过后续校验发现。最不值得手工整理的是那些通用常识模型已具备你重复注入反而增加干扰。踩过几次坑之后我现在做任何注入方案都会先问自己三个问题这一次要解决的问题是模型不知道知识还是模型没有掌握使用知识的条件我手工标注了实体和关系吗验收集里有没有覆盖这个场景的测试这三个问题想清楚了项目一般不会跑偏。LLM 的潜力确实很大但它的发挥上限很大程度上取决于那个“by hand”的人有没有把知识整理成它听得懂的教学语言。这件事没有捷径但也正因为没有捷径它才成了我们这些从业者真正不可替代的价值所在。