1. 为什么需要一份人机交互协议大多数人跟大模型打交道的方式其实停留在许愿阶段。想到什么说什么问完一句等结果结果不满意就换个说法再问一遍。这种方式在偶尔用用的场景下没什么问题但一旦你每天要处理几十个任务、要在多个模型之间切换、要把输出结果直接对接给下游流程靠随口问就会暴露出三个致命问题结果不稳定、经验无法沉淀、协作无法传递。我最初也是这么用的。直到有一次我需要连续三天用大模型处理一批结构化的文本数据第一天调好的提示词第二天换个对话窗口重新说一遍输出格式就变了第三天想把这套方法交给同事对方听完我的口头描述复现出来的效果跟我差了十万八千里。那次之后我才意识到问题不在于模型不够聪明而在于我从来没有把怎么跟它说话这件事当成一件需要设计的事情来对待。所谓人机交互协议说白了就是一套你自己定义的、跟大模型协作时的固定规则集合。它规定了你怎么描述任务、怎么提供上下文、怎么约束输出格式、怎么处理异常结果、怎么在多轮对话中保持一致性。它不需要多复杂但必须足够明确明确到你可以把它写下来交给另一个人对方照着做能复现出接近的结果。这份协议解决的核心问题是把跟大模型对话从一门手感活变成一套可重复、可迭代、可传授的工程方法。它适合所有已经把大模型纳入日常工作流的人——不管你是写代码的、做内容的、搞数据分析的还是单纯想让自己问问题的效率高一点。如果你只是偶尔问问天气或者让它帮你写个请假条那确实用不上但如果你每天跟它打交道超过十次这套东西值得你花时间建立起来。我把它命名为V2.00是因为第一版是我自己在用的草稿经过大概两个月的反复调整才定型。下面我把这套协议的完整结构拆开讲包括每个部分为什么这么设计、实际用起来效果如何、以及我在打磨过程中踩过的那些坑。2. 协议的第一层任务描述的结构化模板2.1 为什么说清楚比说得多更重要很多人有一个误区觉得给大模型的提示词越长越好信息越多越好。实际测试下来真正影响输出质量的是信息的结构而不是信息的数量。一段三百字但逻辑混乱的描述效果远不如一段一百字但层次分明的指令。我试过一个很典型的对比。同样是让模型帮我整理一份会议纪要第一种写法是把会议背景、参会人、讨论内容、我的期望全部混在一段话里扔过去第二种写法是分成背景任务输出要求三个明确的段落。结果第二种写法的输出质量明显更稳定格式几乎不需要二次调整。原因很简单模型在处理结构化输入时能更准确地识别出哪些是约束条件、哪些是背景信息、哪些是它需要执行的动作。所以协议的第一条规则就是任何一次任务请求必须包含三个基本要素——背景Context、任务Task、约束Constraint。我把它简称为CTC结构。2.2 CTC结构的具体写法背景部分要回答的是这件事的来龙去脉是什么。不需要长篇大论但必须让模型知道它面对的是什么场景。比如你要它帮你写一封邮件背景里至少要说明收件人是谁、你和对方是什么关系、这封邮件的目的是什么。任务部分要回答的是你具体要它做什么。这里最容易犯的错误是任务描述太模糊。比如帮我优化一下这段文字优化什么是让语言更简洁还是让语气更正式还是修正语法错误不同的优化目标对应完全不同的处理方式。我的做法是任务描述里必须包含一个明确的动词比如改写提取分类翻译生成。约束部分要回答的是输出应该长什么样。这包括格式要求JSON、Markdown表格、纯文本、长度要求不超过多少字、至少包含几个要点、风格要求正式、口语、技术文档风格、以及禁止事项不要使用某些词汇、不要添加解释性文字。我实际用下来CTC结构能把一次对话的有效率从大概六成提升到八成以上。所谓有效率就是第一次输出就能直接用的比例。剩下的两成需要微调但至少方向不会跑偏。2.3 一个完整的CTC示例拿一个实际场景来说。我需要模型帮我从一堆用户反馈里提取出功能需求并且按优先级分类。用CTC结构写出来大概是这样背景我有一批来自产品试用用户的文字反馈大约50条内容涉及功能建议、bug报告和使用体验。这些反馈的语言风格不统一有的很简短有的写了一大段。任务请从每条反馈中提取出核心诉求判断它属于功能新增功能优化缺陷修复体验改进中的哪一类并给出一个1到5的优先级评分。约束输出为Markdown表格包含四列——原始反馈摘要、诉求提取、分类、优先级。优先级评分标准是影响核心流程的为5影响次要功能的为3纯体验建议的为1。不要添加额外的解释文字。这个结构写出来不到两百字但模型拿到之后基本不需要追问就能给出可用的结果。对比一下那种帮我看看这些反馈里有什么需求的写法差距非常明显。2.4 模板的灵活变体CTC结构不是死板的。有些场景下背景可以省略比如你只是让它做一个纯粹的数学计算有些场景下约束可以放宽比如你在做头脑风暴不希望被格式限制。但有一条原则我始终坚持任务和约束不能同时模糊。如果任务描述本身就不够具体那约束就必须写得很细如果约束很宽松那任务描述就必须精确到没有歧义。这个原则帮我省了很多来回修改的时间。很多时候输出不理想不是因为模型能力不够而是因为我在任务和约束这两端同时留了太多模糊空间模型只能靠猜猜错是必然的。3. 上下文管理的策略与边界3.1 多轮对话中的信息衰减问题大模型的对话上下文是有窗口限制的这一点大家都知道。但实际使用中更隐蔽的问题是即使没有超出窗口限制随着对话轮次增加模型对早期信息的注意力也会衰减。我做过一个简单的测试在一段对话的第3轮给出一个关键约束到第15轮再问一个相关问题时模型有相当概率会忽略那个约束。这不是模型的bug而是注意力机制的特性决定的。长对话中越靠近当前轮次的信息权重越高越早的信息越容易被稀释。所以协议的第二层规则是关于上下文管理的关键约束必须重复重要背景必须前置。我的做法是在任何超过5轮的对话中如果某个约束对后续所有输出都适用我会每隔几轮就重新声明一次。比如记住所有输出都用JSON格式这句话我不会只说一次而是在每次提出新任务时都带上。听起来有点啰嗦但实测下来能显著降低格式跑偏的概率。3.2 什么时候该开新对话很多人习惯在一个对话窗口里处理所有事情觉得这样模型能记住之前的上下文。但实际上不相关的任务混在同一个对话里反而会互相干扰。我总结了一个简单的判断标准如果新任务和之前的任务在领域、格式要求、角色设定上没有任何关联就开新对话。比如你先让模型帮你改了一段代码然后接着让它帮你写一份市场分析报告。这两个任务之间没有任何共享的上下文放在同一个对话里模型可能会把代码讨论中的某些术语或风格带到报告里产生莫名其妙的输出。分开处理各自干净。反过来如果是一系列相关的任务比如先让模型分析数据再基于分析结果写结论再根据结论生成建议这种就应该放在同一个对话里因为后面的任务依赖前面的输出。3.3 上下文压缩的实操方法当一个对话确实需要很长又不想开新窗口的时候我会做一次上下文压缩。具体操作是让模型自己总结当前对话中已经确认的关键信息然后我把这个总结复制出来开一个新对话把总结作为背景重新贴进去。这个方法的妙处在于它把可能已经衰减的早期信息以浓缩的形式重新放到了上下文的最近位置。我通常会在对话进行到20轮左右的时候做一次压缩压缩后的新对话能恢复到接近初始状态的理解准确度。压缩的提示词我一般这么写请把以上对话中已经确认的关键信息整理成一段背景说明包括任务目标、已确定的约束条件、已经完成的部分、尚未解决的问题。不要添加任何新的分析或建议只做信息汇总。拿到汇总之后新对话的第一条消息就是这段背景加上下一个具体任务。实测下来这种做法的信息保真度比直接继续长对话要高不少。3.4 上下文里不该放什么有一条经验是我踩了坑才总结出来的不要在上下文里放你自己的思考过程。什么意思呢就是不要跟模型说我觉得可能是因为……我猜大概是……我不确定是不是……。这些表达会污染模型的判断它可能会把你的猜测当成事实来对待。正确的做法是只提供事实和明确的需求。如果你确实需要模型帮你分析原因那就把现象描述清楚让它自己去推理而不是你先给一个可能错误的假设把它带偏。我举个例子。有一次我处理一个数据异常的问题我跟模型说我觉得可能是编码格式的问题你帮我看看怎么解决。结果它顺着我的思路给了一堆编码相关的方案但实际问题出在数据源本身的字段缺失上。后来我改成这批数据出现了以下异常现象[具体描述]请分析可能的原因它给出的排查方向就全面得多。4. 输出格式的约束与后处理4.1 为什么必须约束输出格式如果你只是把大模型的输出读一读然后自己消化格式其实无所谓。但如果你要把输出直接对接给下游流程——比如粘贴到表格里、导入到代码中、传给另一个模型——那格式就是生命线。我最初做数据提取的时候没有约束格式模型每次输出的结构都不一样。有时候用列表有时候用段落有时候加了一堆解释性文字。每次都要手动整理效率极低。后来我强制要求所有提取类任务必须输出JSON情况才彻底改观。约束格式的核心技巧是给出一个具体的示例。光说输出JSON不够因为JSON的结构可以千变万化。你要给出一个字段名和嵌套关系的样例模型才能准确理解你要的是什么。4.2 常用格式的约束模板我整理了几种最常用的输出格式及其对应的约束写法可以直接拿来用格式类型适用场景约束写法要点JSON结构化数据提取、API对接给出完整字段示例标明必填和可选字段Markdown表格对比分析、清单整理指定列名和列顺序说明每列的内容要求有序列表步骤说明、优先级排序说明排序依据限制条目数量纯文本段落文案撰写、内容生成指定字数范围、语气风格、禁止事项代码块代码生成、配置编写指定语言类型、是否包含注释、命名规范拿JSON举例我通常会这样写约束输出为JSON格式结构如下{items: [{id: 数字, title: 字符串, category: 字符串, priority: 数字}]}。不要输出任何JSON之外的文字不要使用Markdown代码块包裹。最后那句不要使用Markdown代码块包裹很关键。很多模型默认会把JSON放在代码块里输出如果你要直接解析这个输出代码块的反引号就会造成问题。明确禁止之后输出就是干净的纯JSON文本。4.3 输出后处理的自动化思路即使约束写得再好模型的输出偶尔还是会有小瑕疵。比如JSON里多了一个尾逗号或者表格里某一行多了一列。这些瑕疵如果靠人工检查量大之后根本看不过来。我的做法是写一个简单的后处理脚本对输出做自动校验和修复。以JSON为例我会用Python写一个校验函数尝试解析输出如果失败就做几件事去掉首尾的非JSON字符、修复常见的尾逗号问题、检查字段是否完整。大部分小瑕疵都能被自动修复只有少数需要人工介入。import json import re def clean_and_parse(text): # 去掉可能的代码块标记 text re.sub(r^(?:json)?\s*, , text.strip()) text re.sub(r\s*$, , text) # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: # 修复尾逗号 text re.sub(r,\s*([}\]]), r\1, text) try: return json.loads(text) except json.JSONDecodeError: return None这个脚本不长但帮我省了大量的手动修正时间。核心思路就是能自动修的就自动修修不了的再人工看。后处理脚本不需要多完美能覆盖八成以上的常见问题就值回票价了。4.4 格式约束的边界有一点需要注意格式约束不能过度。如果你把输出格式限制得太死模型可能会为了满足格式要求而牺牲内容的准确性。比如你要求每个字段不超过10个字模型可能会把一些需要详细说明的内容强行压缩导致信息丢失。我的经验是格式约束应该约束结构而不是约束内容。你可以规定输出三个要点但不要规定每个要点不超过20字。结构性的约束帮助模型组织输出内容性的约束则可能造成信息损失。5. 异常处理与迭代机制5.1 输出不符合预期时的排查顺序模型输出不理想的时候很多人的第一反应是换个说法再问一遍。但盲目重试的效率很低因为你不知道问题出在哪里换的说法可能只是碰巧对了下次遇到类似情况还是不会处理。我总结了一个排查顺序每次输出不理想的时候按这个顺序检查任务描述是否明确模型是否清楚地知道你要它做什么动词是否具体约束是否完整输出格式、长度、风格是否都说清楚了上下文是否有干扰之前的对话内容是否可能影响当前任务的判断信息是否充足模型是否拥有完成任务所需的所有信息任务是否超出能力边界这个任务是否本身就不适合当前模型处理按这个顺序排查大部分问题都能定位到具体原因。我实际用下来排在第一和第二位的问题占了七成以上——也就是说大部分时候不是模型不行而是我没说清楚。5.2 迭代式追问的技巧当第一次输出方向大致正确但细节需要调整时不要重新问一遍而是基于现有输出做迭代。迭代式追问的关键是具体指出哪里不对、希望改成什么样。比如模型给你写了一段产品介绍你觉得语气太正式了。不要重新说帮我写一段产品介绍语气轻松一点而是说把上面这段介绍的语气改得更口语化保留所有产品特性描述但把书面语替换成日常表达。后者的好处是模型不需要重新理解整个任务只需要在现有输出的基础上做定向修改。这样既保留了已经正确的部分又精确地解决了问题。我通常会在迭代两到三次之后得到满意的结果比重新问一遍快得多。5.3 建立自己的提示词库协议的最后一条规则是关于经验沉淀的把好用的提示词存下来。我见过太多人每次用大模型都是从零开始写提示词之前调好的版本用完就忘了下次遇到类似任务又得重新调。我的做法是建一个简单的文本文件按任务类型分类存放提示词模板。每次调出一个好用的版本就把它存进去标注适用场景和注意事项。时间长了这个库就成了我最高效的生产力工具。遇到新任务先翻翻库里有没有类似的模板有的话改一改就能用没有的话从头写写完再存进去。这个库不需要多复杂一个Markdown文件就够了。关键是要坚持记录并且在每次使用后根据实际效果做微调。我现在的库里大概有四十多个模板覆盖了数据提取、文案撰写、代码生成、信息整理等常见场景。大部分日常任务都能在五分钟内找到可用的起点。5.4 什么时候该放弃当前方案有一种情况需要特别说明当你按照排查顺序检查了一遍发现任务描述没问题、约束也完整、上下文也干净但模型就是做不好这时候可能意味着这个任务本身不适合用大模型来做。我遇到过几次这种情况。有一次我需要模型对一批数据做精确的数值计算涉及多步公式推导。不管我怎么优化提示词结果总是有细微的数值偏差。后来我意识到这种需要精确计算的任务用代码来做远比用模型来做靠谱。模型擅长的是理解和生成不是精确计算。识别任务边界很重要。大模型适合处理模糊的、需要理解的任务比如文本分类、内容生成、信息提取不适合处理精确的、需要严格计算的任务比如数值运算、逻辑验证、大规模数据处理。把合适的任务交给合适的工具比硬要用一个工具解决所有问题要高效得多。6. 协议落地后的实际变化6.1 效率提升的具体数据这套协议我从草稿到定型大概用了两个月定型之后又用了三个月。最直观的变化是任务完成时间。以我日常处理最多的数据提取任务为例之前处理一批50条的数据从写提示词到整理输出大概需要40分钟现在用固定的CTC模板加上JSON格式约束同样的工作量大概15分钟就能完成而且输出可以直接导入下游流程不需要手动整理。另一个变化是结果的一致性。之前同一个任务每次做的结果格式都不一样现在因为约束固定了不同时间、不同对话窗口做出来的结果结构完全一致。这对于需要批量处理的任务来说非常重要。6.2 协作场景下的价值这套协议最大的价值其实体现在协作上。之前我把任务交给同事需要花大量时间解释你要怎么问它输出大概长什么样遇到问题怎么调整。现在我把协议文档和提示词库一起给对方对方照着做就能复现出接近的结果。我印象很深的一次是我需要临时把一个数据整理任务交给同事处理。我把对应的提示词模板和输出格式要求发过去对方之前完全没有用过这套方法但照着模板操作第一次输出就基本可用。这在以前是不可想象的以前至少要来回沟通三四轮才能对齐预期。6.3 持续迭代的方向协议本身也在不断迭代。我目前在做的一个改进方向是把常用的提示词模板做成参数化的形式。比如数据提取的模板把数据来源提取字段输出格式做成可替换的变量用的时候只需要填几个空就能生成完整的提示词。这样进一步降低了使用门槛也减少了每次重新组织语言的时间。另一个方向是建立输出质量的自动评估机制。目前判断输出好不好还是靠人工看量大之后容易疲劳。我在尝试写一些简单的规则来对输出做初步筛选比如检查JSON是否合法、检查必填字段是否缺失、检查输出长度是否在合理范围内。这些规则能过滤掉明显不合格的输出减少人工检查的工作量。这套协议没有什么高深的技术核心就是把跟大模型协作时的那些隐性经验显性化、结构化、可复用化。它不需要你懂模型内部的原理只需要你愿意花一点时间把自己平时问问题的习惯整理成一套固定的规则。一旦建立起来你会发现跟大模型协作的效率和质量都会有明显的提升。 
长河君 · 2026/10/18 5:30:51 · 阅读 1.2k 人机交互协议V2.00：结构化提示词与上下文管理实战指南
1. 为什么需要一份人机交互协议大多数人跟大模型打交道的方式其实停留在许愿阶段。想到什么说什么问完一句等结果结果不满意就换个说法再问一遍。这种方式在偶尔用用的场景下没什么问题但一旦你每天要处理几十个任务、要在多个模型之间切换、要把输出结果直接对接给下游流程靠随口问就会暴露出三个致命问题结果不稳定、经验无法沉淀、协作无法传递。我最初也是这么用的。直到有一次我需要连续三天用大模型处理一批结构化的文本数据第一天调好的提示词第二天换个对话窗口重新说一遍输出格式就变了第三天想把这套方法交给同事对方听完我的口头描述复现出来的效果跟我差了十万八千里。那次之后我才意识到问题不在于模型不够聪明而在于我从来没有把怎么跟它说话这件事当成一件需要设计的事情来对待。所谓人机交互协议说白了就是一套你自己定义的、跟大模型协作时的固定规则集合。它规定了你怎么描述任务、怎么提供上下文、怎么约束输出格式、怎么处理异常结果、怎么在多轮对话中保持一致性。它不需要多复杂但必须足够明确明确到你可以把它写下来交给另一个人对方照着做能复现出接近的结果。这份协议解决的核心问题是把跟大模型对话从一门手感活变成一套可重复、可迭代、可传授的工程方法。它适合所有已经把大模型纳入日常工作流的人——不管你是写代码的、做内容的、搞数据分析的还是单纯想让自己问问题的效率高一点。如果你只是偶尔问问天气或者让它帮你写个请假条那确实用不上但如果你每天跟它打交道超过十次这套东西值得你花时间建立起来。我把它命名为V2.00是因为第一版是我自己在用的草稿经过大概两个月的反复调整才定型。下面我把这套协议的完整结构拆开讲包括每个部分为什么这么设计、实际用起来效果如何、以及我在打磨过程中踩过的那些坑。2. 协议的第一层任务描述的结构化模板2.1 为什么说清楚比说得多更重要很多人有一个误区觉得给大模型的提示词越长越好信息越多越好。实际测试下来真正影响输出质量的是信息的结构而不是信息的数量。一段三百字但逻辑混乱的描述效果远不如一段一百字但层次分明的指令。我试过一个很典型的对比。同样是让模型帮我整理一份会议纪要第一种写法是把会议背景、参会人、讨论内容、我的期望全部混在一段话里扔过去第二种写法是分成背景任务输出要求三个明确的段落。结果第二种写法的输出质量明显更稳定格式几乎不需要二次调整。原因很简单模型在处理结构化输入时能更准确地识别出哪些是约束条件、哪些是背景信息、哪些是它需要执行的动作。所以协议的第一条规则就是任何一次任务请求必须包含三个基本要素——背景Context、任务Task、约束Constraint。我把它简称为CTC结构。2.2 CTC结构的具体写法背景部分要回答的是这件事的来龙去脉是什么。不需要长篇大论但必须让模型知道它面对的是什么场景。比如你要它帮你写一封邮件背景里至少要说明收件人是谁、你和对方是什么关系、这封邮件的目的是什么。任务部分要回答的是你具体要它做什么。这里最容易犯的错误是任务描述太模糊。比如帮我优化一下这段文字优化什么是让语言更简洁还是让语气更正式还是修正语法错误不同的优化目标对应完全不同的处理方式。我的做法是任务描述里必须包含一个明确的动词比如改写提取分类翻译生成。约束部分要回答的是输出应该长什么样。这包括格式要求JSON、Markdown表格、纯文本、长度要求不超过多少字、至少包含几个要点、风格要求正式、口语、技术文档风格、以及禁止事项不要使用某些词汇、不要添加解释性文字。我实际用下来CTC结构能把一次对话的有效率从大概六成提升到八成以上。所谓有效率就是第一次输出就能直接用的比例。剩下的两成需要微调但至少方向不会跑偏。2.3 一个完整的CTC示例拿一个实际场景来说。我需要模型帮我从一堆用户反馈里提取出功能需求并且按优先级分类。用CTC结构写出来大概是这样背景我有一批来自产品试用用户的文字反馈大约50条内容涉及功能建议、bug报告和使用体验。这些反馈的语言风格不统一有的很简短有的写了一大段。任务请从每条反馈中提取出核心诉求判断它属于功能新增功能优化缺陷修复体验改进中的哪一类并给出一个1到5的优先级评分。约束输出为Markdown表格包含四列——原始反馈摘要、诉求提取、分类、优先级。优先级评分标准是影响核心流程的为5影响次要功能的为3纯体验建议的为1。不要添加额外的解释文字。这个结构写出来不到两百字但模型拿到之后基本不需要追问就能给出可用的结果。对比一下那种帮我看看这些反馈里有什么需求的写法差距非常明显。2.4 模板的灵活变体CTC结构不是死板的。有些场景下背景可以省略比如你只是让它做一个纯粹的数学计算有些场景下约束可以放宽比如你在做头脑风暴不希望被格式限制。但有一条原则我始终坚持任务和约束不能同时模糊。如果任务描述本身就不够具体那约束就必须写得很细如果约束很宽松那任务描述就必须精确到没有歧义。这个原则帮我省了很多来回修改的时间。很多时候输出不理想不是因为模型能力不够而是因为我在任务和约束这两端同时留了太多模糊空间模型只能靠猜猜错是必然的。3. 上下文管理的策略与边界3.1 多轮对话中的信息衰减问题大模型的对话上下文是有窗口限制的这一点大家都知道。但实际使用中更隐蔽的问题是即使没有超出窗口限制随着对话轮次增加模型对早期信息的注意力也会衰减。我做过一个简单的测试在一段对话的第3轮给出一个关键约束到第15轮再问一个相关问题时模型有相当概率会忽略那个约束。这不是模型的bug而是注意力机制的特性决定的。长对话中越靠近当前轮次的信息权重越高越早的信息越容易被稀释。所以协议的第二层规则是关于上下文管理的关键约束必须重复重要背景必须前置。我的做法是在任何超过5轮的对话中如果某个约束对后续所有输出都适用我会每隔几轮就重新声明一次。比如记住所有输出都用JSON格式这句话我不会只说一次而是在每次提出新任务时都带上。听起来有点啰嗦但实测下来能显著降低格式跑偏的概率。3.2 什么时候该开新对话很多人习惯在一个对话窗口里处理所有事情觉得这样模型能记住之前的上下文。但实际上不相关的任务混在同一个对话里反而会互相干扰。我总结了一个简单的判断标准如果新任务和之前的任务在领域、格式要求、角色设定上没有任何关联就开新对话。比如你先让模型帮你改了一段代码然后接着让它帮你写一份市场分析报告。这两个任务之间没有任何共享的上下文放在同一个对话里模型可能会把代码讨论中的某些术语或风格带到报告里产生莫名其妙的输出。分开处理各自干净。反过来如果是一系列相关的任务比如先让模型分析数据再基于分析结果写结论再根据结论生成建议这种就应该放在同一个对话里因为后面的任务依赖前面的输出。3.3 上下文压缩的实操方法当一个对话确实需要很长又不想开新窗口的时候我会做一次上下文压缩。具体操作是让模型自己总结当前对话中已经确认的关键信息然后我把这个总结复制出来开一个新对话把总结作为背景重新贴进去。这个方法的妙处在于它把可能已经衰减的早期信息以浓缩的形式重新放到了上下文的最近位置。我通常会在对话进行到20轮左右的时候做一次压缩压缩后的新对话能恢复到接近初始状态的理解准确度。压缩的提示词我一般这么写请把以上对话中已经确认的关键信息整理成一段背景说明包括任务目标、已确定的约束条件、已经完成的部分、尚未解决的问题。不要添加任何新的分析或建议只做信息汇总。拿到汇总之后新对话的第一条消息就是这段背景加上下一个具体任务。实测下来这种做法的信息保真度比直接继续长对话要高不少。3.4 上下文里不该放什么有一条经验是我踩了坑才总结出来的不要在上下文里放你自己的思考过程。什么意思呢就是不要跟模型说我觉得可能是因为……我猜大概是……我不确定是不是……。这些表达会污染模型的判断它可能会把你的猜测当成事实来对待。正确的做法是只提供事实和明确的需求。如果你确实需要模型帮你分析原因那就把现象描述清楚让它自己去推理而不是你先给一个可能错误的假设把它带偏。我举个例子。有一次我处理一个数据异常的问题我跟模型说我觉得可能是编码格式的问题你帮我看看怎么解决。结果它顺着我的思路给了一堆编码相关的方案但实际问题出在数据源本身的字段缺失上。后来我改成这批数据出现了以下异常现象[具体描述]请分析可能的原因它给出的排查方向就全面得多。4. 输出格式的约束与后处理4.1 为什么必须约束输出格式如果你只是把大模型的输出读一读然后自己消化格式其实无所谓。但如果你要把输出直接对接给下游流程——比如粘贴到表格里、导入到代码中、传给另一个模型——那格式就是生命线。我最初做数据提取的时候没有约束格式模型每次输出的结构都不一样。有时候用列表有时候用段落有时候加了一堆解释性文字。每次都要手动整理效率极低。后来我强制要求所有提取类任务必须输出JSON情况才彻底改观。约束格式的核心技巧是给出一个具体的示例。光说输出JSON不够因为JSON的结构可以千变万化。你要给出一个字段名和嵌套关系的样例模型才能准确理解你要的是什么。4.2 常用格式的约束模板我整理了几种最常用的输出格式及其对应的约束写法可以直接拿来用格式类型适用场景约束写法要点JSON结构化数据提取、API对接给出完整字段示例标明必填和可选字段Markdown表格对比分析、清单整理指定列名和列顺序说明每列的内容要求有序列表步骤说明、优先级排序说明排序依据限制条目数量纯文本段落文案撰写、内容生成指定字数范围、语气风格、禁止事项代码块代码生成、配置编写指定语言类型、是否包含注释、命名规范拿JSON举例我通常会这样写约束输出为JSON格式结构如下{items: [{id: 数字, title: 字符串, category: 字符串, priority: 数字}]}。不要输出任何JSON之外的文字不要使用Markdown代码块包裹。最后那句不要使用Markdown代码块包裹很关键。很多模型默认会把JSON放在代码块里输出如果你要直接解析这个输出代码块的反引号就会造成问题。明确禁止之后输出就是干净的纯JSON文本。4.3 输出后处理的自动化思路即使约束写得再好模型的输出偶尔还是会有小瑕疵。比如JSON里多了一个尾逗号或者表格里某一行多了一列。这些瑕疵如果靠人工检查量大之后根本看不过来。我的做法是写一个简单的后处理脚本对输出做自动校验和修复。以JSON为例我会用Python写一个校验函数尝试解析输出如果失败就做几件事去掉首尾的非JSON字符、修复常见的尾逗号问题、检查字段是否完整。大部分小瑕疵都能被自动修复只有少数需要人工介入。import json import re def clean_and_parse(text): # 去掉可能的代码块标记 text re.sub(r^(?:json)?\s*, , text.strip()) text re.sub(r\s*$, , text) # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: # 修复尾逗号 text re.sub(r,\s*([}\]]), r\1, text) try: return json.loads(text) except json.JSONDecodeError: return None这个脚本不长但帮我省了大量的手动修正时间。核心思路就是能自动修的就自动修修不了的再人工看。后处理脚本不需要多完美能覆盖八成以上的常见问题就值回票价了。4.4 格式约束的边界有一点需要注意格式约束不能过度。如果你把输出格式限制得太死模型可能会为了满足格式要求而牺牲内容的准确性。比如你要求每个字段不超过10个字模型可能会把一些需要详细说明的内容强行压缩导致信息丢失。我的经验是格式约束应该约束结构而不是约束内容。你可以规定输出三个要点但不要规定每个要点不超过20字。结构性的约束帮助模型组织输出内容性的约束则可能造成信息损失。5. 异常处理与迭代机制5.1 输出不符合预期时的排查顺序模型输出不理想的时候很多人的第一反应是换个说法再问一遍。但盲目重试的效率很低因为你不知道问题出在哪里换的说法可能只是碰巧对了下次遇到类似情况还是不会处理。我总结了一个排查顺序每次输出不理想的时候按这个顺序检查任务描述是否明确模型是否清楚地知道你要它做什么动词是否具体约束是否完整输出格式、长度、风格是否都说清楚了上下文是否有干扰之前的对话内容是否可能影响当前任务的判断信息是否充足模型是否拥有完成任务所需的所有信息任务是否超出能力边界这个任务是否本身就不适合当前模型处理按这个顺序排查大部分问题都能定位到具体原因。我实际用下来排在第一和第二位的问题占了七成以上——也就是说大部分时候不是模型不行而是我没说清楚。5.2 迭代式追问的技巧当第一次输出方向大致正确但细节需要调整时不要重新问一遍而是基于现有输出做迭代。迭代式追问的关键是具体指出哪里不对、希望改成什么样。比如模型给你写了一段产品介绍你觉得语气太正式了。不要重新说帮我写一段产品介绍语气轻松一点而是说把上面这段介绍的语气改得更口语化保留所有产品特性描述但把书面语替换成日常表达。后者的好处是模型不需要重新理解整个任务只需要在现有输出的基础上做定向修改。这样既保留了已经正确的部分又精确地解决了问题。我通常会在迭代两到三次之后得到满意的结果比重新问一遍快得多。5.3 建立自己的提示词库协议的最后一条规则是关于经验沉淀的把好用的提示词存下来。我见过太多人每次用大模型都是从零开始写提示词之前调好的版本用完就忘了下次遇到类似任务又得重新调。我的做法是建一个简单的文本文件按任务类型分类存放提示词模板。每次调出一个好用的版本就把它存进去标注适用场景和注意事项。时间长了这个库就成了我最高效的生产力工具。遇到新任务先翻翻库里有没有类似的模板有的话改一改就能用没有的话从头写写完再存进去。这个库不需要多复杂一个Markdown文件就够了。关键是要坚持记录并且在每次使用后根据实际效果做微调。我现在的库里大概有四十多个模板覆盖了数据提取、文案撰写、代码生成、信息整理等常见场景。大部分日常任务都能在五分钟内找到可用的起点。5.4 什么时候该放弃当前方案有一种情况需要特别说明当你按照排查顺序检查了一遍发现任务描述没问题、约束也完整、上下文也干净但模型就是做不好这时候可能意味着这个任务本身不适合用大模型来做。我遇到过几次这种情况。有一次我需要模型对一批数据做精确的数值计算涉及多步公式推导。不管我怎么优化提示词结果总是有细微的数值偏差。后来我意识到这种需要精确计算的任务用代码来做远比用模型来做靠谱。模型擅长的是理解和生成不是精确计算。识别任务边界很重要。大模型适合处理模糊的、需要理解的任务比如文本分类、内容生成、信息提取不适合处理精确的、需要严格计算的任务比如数值运算、逻辑验证、大规模数据处理。把合适的任务交给合适的工具比硬要用一个工具解决所有问题要高效得多。6. 协议落地后的实际变化6.1 效率提升的具体数据这套协议我从草稿到定型大概用了两个月定型之后又用了三个月。最直观的变化是任务完成时间。以我日常处理最多的数据提取任务为例之前处理一批50条的数据从写提示词到整理输出大概需要40分钟现在用固定的CTC模板加上JSON格式约束同样的工作量大概15分钟就能完成而且输出可以直接导入下游流程不需要手动整理。另一个变化是结果的一致性。之前同一个任务每次做的结果格式都不一样现在因为约束固定了不同时间、不同对话窗口做出来的结果结构完全一致。这对于需要批量处理的任务来说非常重要。6.2 协作场景下的价值这套协议最大的价值其实体现在协作上。之前我把任务交给同事需要花大量时间解释你要怎么问它输出大概长什么样遇到问题怎么调整。现在我把协议文档和提示词库一起给对方对方照着做就能复现出接近的结果。我印象很深的一次是我需要临时把一个数据整理任务交给同事处理。我把对应的提示词模板和输出格式要求发过去对方之前完全没有用过这套方法但照着模板操作第一次输出就基本可用。这在以前是不可想象的以前至少要来回沟通三四轮才能对齐预期。6.3 持续迭代的方向协议本身也在不断迭代。我目前在做的一个改进方向是把常用的提示词模板做成参数化的形式。比如数据提取的模板把数据来源提取字段输出格式做成可替换的变量用的时候只需要填几个空就能生成完整的提示词。这样进一步降低了使用门槛也减少了每次重新组织语言的时间。另一个方向是建立输出质量的自动评估机制。目前判断输出好不好还是靠人工看量大之后容易疲劳。我在尝试写一些简单的规则来对输出做初步筛选比如检查JSON是否合法、检查必填字段是否缺失、检查输出长度是否在合理范围内。这些规则能过滤掉明显不合格的输出减少人工检查的工作量。这套协议没有什么高深的技术核心就是把跟大模型协作时的那些隐性经验显性化、结构化、可复用化。它不需要你懂模型内部的原理只需要你愿意花一点时间把自己平时问问题的习惯整理成一套固定的规则。一旦建立起来你会发现跟大模型协作的效率和质量都会有明显的提升。