这次想认真聊聊提示词模板这件事。最近在几个实际项目里我反复试用了好长一段时间所谓“Harness”式的提示词写法踩了不少坑也沉淀出一组可以复用的模板。借用一句话说Harness就是给大模型输出套上的“约束框架”听起来玄乎其实做法很朴素把角色、目标、约束、输入数据、输出格式、兜底策略这些要素系统性地组织成模板让模型每一次输出都在一个稳定的边界里展开。如果你受够了大模型“每次都换一个说法”或者想让团队里的提示词具备像代码一样的复用性这篇文章应该对你有用。我早期写提示词基本靠感觉先来一句“你是专家”然后把任务丢进去最后补几句“回答要详细、要准确”。单次任务用效果还行但凡是稍复杂的任务或者要把同一条提示词放到不同场景里反复用毛病立刻现出原形——格式偶尔跳、约束偶尔忘、换个人改两笔就废。后来我逐渐把提示词当成一个可维护的工程组件来设计“Harness”这个概念就在这个过程中帮了大忙。下面我会把思路、模板、参数和踩坑记录完整摆出来。1. Harness的核心思路把提示词从“对话”升级为“约定”1.1 为什么零散提示词容易翻车我遇到过不少这样的现象给模型一段材料让它“帮忙总结一下”它确实能总结但总结的颗粒度、口吻和结构每次都不一样。最离谱的一次我让它基于某份方案输出评审意见它硬是从“整体来说这个方案具有良好的前瞻性”开始写了一大段正确的废话完全没进入评审状态。问题出在哪大部分人写提示词把重心放在了“表达任务”上却忽略了大模型本身不是一个稳定执行器。它确实能理解自然语言但同样的指令会因为措辞、位置、上下文长度的影响产生完全不同的行为推断。零散提示词之所以翻车是因为“表达了意图”不等于“锁定了行为”——从意图到行为之间缺了一整套工程化的约束设计。所以我在实践中逐渐养成了一个习惯不再依赖一条“完美提示词”而是把提示词改造成一套“角色约定”。这也是Harness真正解决的问题。1.2 核心思路电气线束思维怎么理解Harness我会用电气线束作类比。复杂设备里一根根裸露的导线如果随便散着信号干扰和短路风险会很高线束的做法是把导线分组、编号、套护套、固定走向整个系统才可靠可维护。提示词里那些碎片化的指令就是导线Harness就是那个把指令分组、编号、固定顺序的“线束板”。具体到提示词Harness主要管四件事明确谁在执行角色、执行什么目标、在什么边界内执行约束、以什么形式交付输出结构。再加一个容易被忽略的兜底策略——做不到怎么办。这四个半要素完整了提示词才称得上“约定”。拿写方案评审来打比方如果没有角色约束模型会默认它是“啥都懂的通用助手”于是泛泛而谈如果给了它“资深架构评审人”的角色它的默认措辞、判断维度和关注重点都会往这个方向靠拢。1.3 从一次对话变成一套可复用资产我过去把提示词当成“一次性消耗品”用完就扔。同一类任务换一个输入我可能又从头开始写一遍提示词。后来改为Harness式写法之后最大的变化是提示词变成了一套可沉淀、可复用、可维护的资产。怎么算可复用一张模板只维护一份每次把新任务内容填进“变量区”就行。比如我每周都要做文档综述我只需要维护一份综述模板把本周材料替换进去输出结构永远是那五个固定段落。稳定性上来了迭代效率也上来了——后面版本管理那节我会专门讲怎么维护模板。2. Harness模板的组件拆解六个模块缺一不可2.1 六个模块逐个拆开讲经过反复测试我把一份Harness模板拆成了六个模块。这六个模块不是装饰每一个都对应一个实际问题。第一个是角色声明区。要写清楚模型“是谁”但别写“你是万能AI助手”这种空话最好让角色与任务强相关。写代码评审就定义“你是一名有多年开发经验的代码评审专家”做内容综述就定义“你是资深内容分析师”。角色绑定得越具体模型在细节没给到时自动补全的方向就越对。第二个是目标描述区。用一句话说清楚交付物是什么而且必须可度量。“帮我看一下代码”这类不算目标“输出一份按严重程度排序的代码缺陷清单”才算。目标里最好带上数量、字数、格式等刻度让模型有可校验的标准。第三个是输入数据区。用明确的边界标签把“待处理内容”和“系统指令”做物理隔离。常见做法是将输入包在“待评审方案‘……’”里面。不要小看这一步如果不隔离模型经常把材料本身也当作指令的一部分出现“读材料读着读着开始模仿材料口吻”的情况。第四个是约束规则区。写出不可触碰的边界比如“不得新增原始材料中没有的信息”“不修改代码只给建议”。约束一般给3到5条就够了再多权重会被稀释。注意约束要行为化别写“回答要专业”这种虚的要写“每个风险点必须标注影响程度和可能性”这种能直接照做的。第五个是输出结构区。直接给出Markdown骨架最好的做法是带着编号列出来“1总体评价2方案亮点3主要风险”。我实测下来模型对格式指令的遵循能力远高于对“写清楚一点”这类程度词的遵循能力。有些复杂场景我还会附带一小段结构示例遵循度会更高。第六个是回退策略区。它规定在信息不足、约束冲突、无法完成等问题出现时模型应该怎样做。比如“材料过短时在开头声明‘材料过短综述意义有限’”“如果方案信息不完整在回复第一行注明‘评审结论仅供部分参考基于不完整信息’”。这个模块是我加了之后觉得性价比最高的模型幻觉率有明显下降因为它终于有了合法的“说不知道”的出口不用靠瞎编来硬撑。2.2 参数化设计常量与变量分离一份Harness如果要复用必须把“常量”和“变量”分开。常量是角色、约束、输出结构这些任何场景都不变的框架变量是每次都要替换的任务内容、输入材料、特殊要求。我习惯在模板里用一对明显的占位符比如“{{输入}}”“{{任务}}”“{{代码}}”。要调用时就直接做字符串替换。这个习惯带来的好处是能够用程序化方式拼装提示词。比如在自动化脚本里可以预先读入模板文件、把运行时数据填进去、再拼装成最终提示词不用每次在代码里手写一长串自然语言指令。参数化还方便做模板分级。团队里维护一个模板库里面分“通用结构”和“场景模板”。通用结构只保存六模块框架场景模板是通用结构加特定约束后的成品。这样改一个通用约束例如“所有输出都必须中英文对照”只需要动一处所有场景模板同时更新。2.3 组件顺序位置偏差是隐藏的规则这里说一个很少被认真对待的细节大模型对提示词不同位置的注意力不是均匀分布的。开头部分的内容往往会被当成强约束结尾部分次之中间的内容容易被忽略。这有点像人读长篇通知开头结尾记得牢中间一段“看了但没进脑子”。所以我在排布Harness时会把最不能让步的约束放在开头和结尾。角色声明放最前面输出结构紧接着输入数据区放在整个提示词靠后的位置。目的是让模型在“即将开始生成输出”时离格式模板更近更容易照着写。而次要的说明性信息、背景解释等则放在中间位置即使模型注意力弱一些也不至于影响整体输出。还有一个来自实测的经验如果要引用某段材料最好把引用放在输出约束的前面而不是放在一大堆背景描述之后。这样模型在准备输出时能更快定位到关键内容生成质量会明显不一样。3. 一组可以直接落地的Harness模板下面四份模板都是我在实际工作中反复使用的你可以直接复制去改也可以照着结构自建一套。每一份后面我都会说明内部设计意图。3.1 技术方案评审模板这是一份适用于团队内部技术评审的模板输出非常稳定。角色你是一名拥有多年系统设计经验的架构评审人擅长从可维护性、性能、安全性、成本四个维度评审技术方案。目标基于给定的技术方案输出一份结构化评审意见。包含方案的合理点、风险点以及按优先级排序的改进建议。约束只评价给定方案里出现的内容不引入方案之外的额外推测每个风险点必须附带“影响程度”和“可能性”两个字段高/中/低不输出与评审无关的背景介绍和客套话当信息不足以判断时在对应条目上标注“待确认”。待评审方案“{{方案内容}}”输出结构 1总体评价不超过100字 2方案亮点不超过3条 3主要风险按严重程度排序每条含说明、影响程度、可能性 4改进建议每条对应一个风险编号 5待确认清单如无则说明“无”。注意如果待评审方案内容缺失或不完整请在回复第一行声明“方案信息不完整部分结论待补充”然后继续完成可评审的部分。这份模板的核心设计是三个第一把输出固化为五个编号段落截断了模型生成“自由结构”的空间第二用“影响程度”“可能性”两个固定字段要求模型做细化判断避免含糊其辞第三用“待确认清单”作为回退出口让模型敢于承认不确定之处。我实际用下来的感受是贴出这份模板后评审意见的信息密度提升了一大截少了很多空泛的“总体来看”。你还可以在里面再加一条“优先建议一条一策不与风险清单脱节”输出会更落地。3.2 文档综述与知识提取模板这份模板适合处理会议纪要、调研笔记、长文档归纳。它的特点是会逼着模型交代“疑问点”而不是像普通总结那样把材料“捋顺就完”。角色你是一名资深内容分析师擅长从长文档中提取核心信息并重新组织表达。目标根据给定的原始材料输出一份不超过800字的内容综述保留事实与逻辑结构删除重复和无关内容。约束不得新增原始材料中没有的信息不得改变原作者的因果逻辑关系统计数字必须沿用原文口径当原文内容不足以支撑某项结论时不得强行下结论。原始材料“{{材料}}”输出结构 1一句话核心结论 2背景与前提 3主要论点与依据 4尚存疑问或矛盾点 5可直接引用的关键句子。回退如果原始材料少于三句话在输出开头声明“材料过短综述意义有限”并只给核心结论和关键句。我特别想说说第四部分“尚存疑问或矛盾点”。很多总结类提示词默认模型只要把材料“顺一遍”就行于是模型遇到内部矛盾时倾向于遮掩。把“找出疑问点”设成显式任务后模型会主动去原文里找不一致的地方经常能挑出我想要的信息。这种“让模型做检查而非做美化”的思路也可以迁移到其他分析任务中去。3.3 代码缺陷分析模板这份模板给到做技术管理和架构评审的团队都适用。它能让模型在“发现真问题”和“避免误报”之间找到更好的平衡点。角色你是一名有多年开发经验的代码评审专家熟悉现代语言与主流框架的常见误用模式关注功能正确性、资源安全与边界情况。目标分析给定的代码片段输出可能存在的缺陷及对应修复方向。如果没有发现明显缺陷也要给出验证思路。约束不输出修改后的完整代码只描述修复方向每个缺陷必须给出“误用模式”和“可复现理由”不评价代码风格偏好只谈功能正确性、资源安全与边界情况区分“确定有问题的点”和“需要进一步确认的点”。待分析代码“{{代码}}”输出结构 1总体结论安全 / 个别风险 / 存在明显问题三选一 2缺陷列表编号、位置、原因分析、修复方向 3边界场景建议 4附带测试建议。代码评审场景里“区分确定性与怀疑”特别关键。很多模型在默认状态下为了显得负责会倾向于把不确定的地方也说成“有隐患”。这份模板用“误用模式”和“可复现理由”两个字段卡住了这种倾向——如果模型说不出具体的误用模式它就没法硬写。这个细节把输出的可信度拉高了很多。3.4 用户反馈归类与需求汇总模板最后一份是产品运营向的模板适合每天需要处理大量用户反馈的团队。角色你是一名经验丰富的产品运营分析师擅长在杂乱反馈中识别真实的用户诉求。目标将给定的用户反馈逐条归类到预设维度并对每个维度输出一段小结。预设维度功能缺失、体验问题、性能问题、付费意愿、建议新增、表扬与情绪表达。约束每一条反馈只归入一个主类别如确实跨类在备注中说明次类保留反馈中的原文关键词禁止改写用户原意摘录内容每条不超过50字没有反馈的维度输出“无”即可不要硬凑。反馈列表“{{反馈列表}}”输出结构每个维度下一行小结随后列出该维度下所有反馈摘录。这份模板的妙处在于“原始摘录”这个设定。很多提炼类任务会压缩信息导致结果无法溯源。要求摘录原文关键词等于给后续人工复核留下了抓手模型即便有转述偏差你也能快速对照原始反馈。如果你拿它来处理投诉信件甚至可以把“投诉渠道”“投诉来源时间”作为附加维度加进去。4. 配套参数设置与运行策略4.1 采样参数与任务类型怎么匹配光有好模板还不够模型的采样参数也决定了最终输出质量。我的经验比较直白结构化输出任务把温度temperature调到0.2到0.4top_p维持在0.9附近。温度越高模型越“有创造力”但在评审、综述、归类这些上下文里“有创造力”往往等同于“开始脑补”。举个例子同一个代码缺陷分析模板温度0.3时输出的缺陷基本都踩在点上温度0.8时覆盖面广了一截但混入的“疑似隐患”也多了人工后期还得逐个排除。所以严格任务坚持低温度别被“调高温度更聪明”的说法误导。反过来如果是头脑风暴、文案创意这类任务我可以把温度开到0.8以上但我会专门换一份“探索型模板”把约束条件刻意放松。模板和温度是一套组合拳一起搭配着用。4.2 版本管理与回归测试像维护代码一样维护模板Harness模板一定要像代码一样做版本管理。不要觉得这是小题大做。有一次我只把综述模板里的“不超过800字”改成“约800字”模型输出长度和结构就发生了明显偏移说明一个用词变化就足以改变全局行为。我的操作办法不复杂但很管用。先用表格维护一份模板清单记录模板名、适用场景、稳定输出样例、最近一次修改时间和改动说明。然后建一个小型的回归测试集大概十来个典型case每次改动模板后跑一遍重点看输出格式有没有变、关键字段有没有丢。这个小步骤救过我很多次。4.3 多轮对话里怎么维持Harness约束多轮连续对话是Harness最容易失效的场景。模型在第一轮还能遵守输出结构到了第三轮“角色”“约束”似乎就被淡忘了。解决思路是“分段注入”开场发完整Harness后续每一轮追问里追加几句微型Harness例如“继续沿用上一轮的角色和编号格式本次只看第三部分主要风险输出保持原格式”。另一个更隐蔽的坑是“任务切换”。如果你想在对话中途换任务最好明确告诉模型“当前任务已切换上一轮的输出格式约束不再生效”。不做这一步的话模型会把旧格式延续到新任务里生成的东西怎么看怎么别扭。5. 实战踩坑常见问题与排查记录5.1 模型死活不按输出结构走故障现象很典型模板里已经写了“1总体评价2方案亮点”模型仍然自顾自地开小标题。我的排查思路是三步先看输出结构是否太复杂嵌套四层列表的格式连人看起来都费劲模型也容易理解偏再看结构描述在提示词里的位置是不是被放到了中间区域导致注意力不足最后判断是否缺少一个可参考的结构样例。大多数情况下把输出结构精简到“编号短句”再挪到靠近尾部的位置问题就解决了。5.2 输出内容发散发飘不够聚焦这种现象多出现在综述类任务里模型很容易滑向“全面正确但什么也没说”的舒适区。排查时先检查目标描述里有没有给度量比如字数限制、条目数量再看约束区是否缺少“不得新增原始材料中没有的信息”这类底线。还有重要一点检查模板里有没有提供“信息不足”时的出口。没有出口模型就会自己找出口——最常见的就是编造。我加了回退策略后这类现象几乎消失。模板里那句“当原文内容不足以支撑某项结论时不得强行下结论”就是给模型“说不知道”的权限它不需要靠编来完成任务。5.3 长输入下模型忽略中间部分输入材料特别长时模型经常把材料前半段嚼得很细后半段草草略过。这背后有上下文注意力的问题也有“关键词密度”的问题。我的做法是先做预压缩把长材料单独发一轮让模型先提取摘要再把摘要喂给主模板。这样主模板的输入变短重点更集中。如果你必须在一个完整模板中处理长材料就把关键材料尽量放在提示词后部、输出约束之前。还可以在约束里写“回答时必须优先依据以下第几条材料”给模型一个明确的注意力锚点。5.4 模板太死板导致失去洞察Harness把稳定性给了输出但如果结构过于僵硬洞察力也会被锁死。有段时间我用严格模板做分析结果稳定漂亮可模型再也没提出过“方案外的新角度”——因为它被一堆字段绑住了。这不是缺陷是权衡。如果你需要探索式答案比如“这个方案有没有被忽视的路径”就不要继续套用严格模板。我一般会换一个“探索型模板”保留角色但把约束改成“允许提出冒险假设必须标注假设依据”把输出结构改成“开放列表”。这样既给了自由度又不至于完全失控。故障现象排查要点推荐解法模型无视输出结构结构是否复杂位置是否偏中有无结构示例拆短结构挪到首尾位置补一个示例内容发散目标是否可度量有无“不得扩充”约束有无信息不足出口增加度量和底线约束激活回退策略增加“待确认”项长输入忽略中间内容材料是否过长关键材料是否在中部预压缩长材料关键材料放后部显式引用材料编号输出无洞察模板约束过多模型不敢发散换探索型模板显式解除部分约束允许“冒险假设”我自己实践下来的感觉是Harness式写法最大的收获不是“输出更工整”而是把提示词从临时产物变成了可维护资产。你不再和模型“掰手腕”而是在搭好框架后把注意力放在真正需要判断的内容上。最后分享一个小习惯每次动手写提示词之前先默念一遍“角色、目标、约束、输出结构、回退”这五个词。如果发现自己只想写“角色任务”就准备发出去停一下多半需要补上后面的约束。有了这个习惯绝大部分输出不稳定问题可以从源头上避免。