1. 这套协议到底在解决什么问题跟大模型打交道这一年多我最大的感受就是大多数人根本不会提问。同一个模型有人能拿到可以直接落地的方案有人只能得到一堆正确的废话。差距不在模型本身在于你喂给它的指令结构。我最初也是那种帮我写个方案就完事的人结果就是反复追问、反复修正一轮对话下来token烧了不少产出还是不能用。后来我开始有意识地记录哪些提问方式能一次命中哪些必然翻车。攒了大概三四个月慢慢沉淀出一套自己固定使用的交互框架我把它叫做人机交互协议——听起来有点正式其实就是一份提问模板加协作规则。这份协议的核心目标有三个降低沟通轮次、提高输出可用率、让模型的行为可预测。它适合所有需要长期跟大模型协作的人——写代码的、做内容的、搞分析的、做产品的只要你不是偶尔问一句天气这套东西都能用上。V2.00这个版本号不是随便起的。V1是我最早的一版只有简单的角色设定加任务描述用了一段时间发现模型经常跑偏——要么过度发挥要么偷懒省略。V2做了比较大的重构引入了分层指令结构和状态确认机制稳定性提升明显。下面我把整套协议拆开讲包括每一部分为什么这么设计、实际怎么用、踩过哪些坑。2. 协议的整体架构与设计逻辑2.1 为什么是协议而不是提示词很多人把提示词当成一句话的事写一句你是一个资深工程师帮我看看这段代码。这种单点式指令的问题在于它没有约束模型的行为边界。模型不知道你要多详细、要不要举例、遇到不确定的地方该怎么办、输出格式是什么样。结果就是它按自己的默认习惯来而这个默认习惯往往跟你的预期不匹配。我把它叫协议是因为它本质上是一份双方协作的约定我告诉模型我是谁、我要什么、我期望你怎么回应、遇到分歧怎么处理。这跟网络通信里的协议是一个道理——双方得先握手约定好数据格式和交互规则后面才能高效传输。实际用下来带协议的对话比不带协议的平均少2到3轮追问。别小看这两三轮长对话里每一轮都在消耗上下文窗口早期省下来的空间后面能多塞不少有效信息。2.2 四层结构身份、任务、约束、反馈V2.00的协议分成四个层次我按优先级从高到低排列层级作用缺失后果身份层定义模型扮演的角色和知识背景输出泛泛而谈没有专业深度任务层明确要做什么、交付物是什么模型不知道终点在哪容易跑偏约束层规定格式、长度、风格、禁忌输出格式混乱需要大量后期整理反馈层约定不确定时的处理方式和确认机制模型瞎编或者沉默你无法判断可信度这四层不是随便分的。身份层放最前面是因为角色设定会显著影响模型调用哪些知识。你让它当资深后端工程师和当技术博主同样问一个数据库问题回答的侧重点完全不同。任务层紧随其后是因为模型需要先知道目标才能决定调用哪些能力。约束层和反馈层是V2新增的也是提升最明显的部分。2.3 V1到V2的关键改动V1的协议大概长这样你是一个资深XX帮我做XX要求XX。简单直接但问题很多。最典型的是模型经常自作主张——你让它写个函数它顺手把整个模块都重构了你让它分析数据它给你编了一组不存在的数字。V2改了三件事第一加了显式的输出格式约定。以前我说给我一个方案模型可能给段落、可能给列表、可能给表格每次都不一样。现在我会明确说用Markdown表格输出对比用有序列表输出步骤。第二加了不确定性声明机制。我会在协议里写一句如果某个信息你不确定直接标注不确定并说明原因不要编造。这一句加进去之后模型胡编的情况明显减少。第三加了分步确认。对于复杂任务我会要求模型先输出大纲让我确认再展开细节。这看起来多了一步但实际上省了后面大改的时间。3. 身份层与任务层的具体写法3.1 身份设定越具体越好但别编造身份层最常见的错误是写得太虚。你是一个专家——什么专家哪个领域的多少年经验这些信息直接影响模型调用知识的范围和深度。我的写法是这样的你是一位有10年以上一线经验的后端架构师熟悉高并发场景下的 系统设计对数据库选型、缓存策略、消息队列有大量实战经验。 你的表达风格直接、务实不说套话遇到不确定的地方会主动说明。这里有几个细节值得说。**10年以上一线经验这种量化描述比资深更有效因为它给了模型一个具体的经验锚点。熟悉高并发场景限定了知识范围避免模型在无关领域浪费篇幅。表达风格直接、务实**是在约束输出风格这个后面约束层还会再强调但身份层先定个调子。注意身份设定不要编造具体的真实人物或机构。我试过写你是某大厂的P8工程师效果跟资深架构师差不多但会引入不必要的联想。用抽象的能力描述就够了。3.2 任务描述说清楚交付物是什么任务层最容易犯的错是只说了动作没说结果。帮我优化这段代码——优化到什么程度优化哪个维度性能还是可读性输出是改后的代码还是优化建议我的习惯是用交付物倒推的方式写任务任务优化下面这段数据库查询代码。 交付物一份优化后的完整代码 一份说明文档说明每处改动 的原因和预期收益。 优化目标优先降低查询耗时其次减少数据库连接占用。这样写的好处是模型清楚知道终点在哪。交付物这个词很关键它会触发模型去组织一个完整的输出结构而不是零散地给几条建议。3.3 复杂任务的分步拆解如果一个任务超过模型单次能稳定处理的范围我会在任务层就做拆解。比如写一份完整的技术方案我会这样写任务撰写一份XX系统的技术方案。 分三步执行 第一步先输出方案大纲包含所有一级和二级标题等我确认。 第二步根据确认的大纲逐章展开内容。 第三步整体通读检查逻辑连贯性和遗漏点。这个分步机制是V2的核心改进之一。模型在长任务中容易中间塌陷——开头和结尾质量不错中间部分开始敷衍。分步执行相当于把长任务切成几个短任务每个短任务都在模型的注意力高峰区内完成。4. 约束层格式、长度与禁忌4.1 输出格式的显式约定约束层里最实用的就是格式约定。我总结了一个对应表什么场景用什么格式内容类型推荐格式原因步骤流程有序列表顺序明确便于执行对比分析Markdown表格多维度对照一目了然代码示例代码块语言标注可直接复制运行注意事项引用块视觉突出不易忽略概念解释段落加粗关键词便于快速扫读以前我不写这些模型就自由发挥。有一次我让它对比三个技术方案它用大段文字描述我看了半天才理清楚差异。后来我直接写用表格对比维度包括性能、成本、维护难度、适用场景输出质量立刻上了一个台阶。4.2 长度控制给区间不给上限不要太长这种指令基本没用模型对长的理解跟人不一样。我现在的写法是给一个区间每个要点的说明控制在150到250字之间。 整体输出不超过2000字。给区间比给上限好因为上限只告诉模型别超过但没告诉它至少要到多少。模型在不确定的时候倾向于简短结果就是该展开的地方一笔带过。给了下限它就知道这里需要足够的信息量。4.3 禁忌清单明确说不要什么这一条是我踩坑最多的地方。模型有一些默认行为如果你不明确禁止它就会一直做。我整理了一份常用禁忌清单不要用总之综上所述这类总结性套话不要在开头写这是一个很好的问题不要重复我的问题不要输出与任务无关的背景介绍不确定的信息不要编造直接标注提示禁忌清单要具体。不要写废话这种指令没用模型不知道什么算废话。要写成不要写随着技术的发展这类空泛开头它才能准确执行。5. 反馈层让模型的行为可预测5.1 不确定性声明机制这是V2里我个人认为最有价值的一条。大模型有个毛病它不知道的时候也会硬答。你问一个它没把握的数据它会编一个看起来合理的数字给你。我的做法是在协议里固定加一段如果你对某个信息不确定请在该信息后标注[不确定] 并简要说明你不确定的原因。不要用猜测的内容填充。实测下来加了这句之后模型标注不确定的频率明显上升而这些标注过的地方确实是我需要额外核实的地方。这相当于给模型装了一个置信度指示灯。5.2 分步确认的触发条件不是所有任务都需要分步确认那样太啰嗦。我设了一个触发条件当任务涉及三个以上独立模块或者预计输出超过1500字时启用分步确认。具体操作是在协议末尾加一句这个任务比较复杂请先输出执行计划我确认后再开始。模型会先给一个步骤列表我看一眼有没有理解偏差确认后再让它执行。这一步花不了多少时间但能避免方向错了白干的情况。5.3 纠偏指令的标准写法即使有协议模型偶尔还是会跑偏。这时候纠偏的方式很重要。我以前会说不对你理解错了然后重新解释一遍。这种方式效率低而且模型容易在同一个地方反复出错。后来我改成定位式纠偏第三部分第二段的理解有偏差。我的原意是XX不是YY。 请只修改这一段其他部分保持不变。关键是指出具体位置和说明偏差在哪然后限定修改范围。这样模型不会因为一处错误就把整个输出重写一遍避免引入新的问题。6. 完整协议模板与实战演示6.1 通用模板把前面几层拼起来我的通用协议模板是这样的[身份层] 你是一位有XX年经验的XX领域从业者擅长XX表达风格XX。 [任务层] 任务XX 交付物XX 执行方式XX是否需要分步 [约束层] 输出格式XX 长度要求XX 禁忌XX [反馈层] 不确定的信息标注[不确定]并说明原因。 如果任务理解有歧义先向我确认再执行。这个模板我存在备忘录里每次用的时候改几个空就行。熟练之后基本30秒能填完但省下来的是后面十几分钟的来回拉扯。6.2 实战案例技术方案撰写举个实际例子。我要写一份某内部工具的重构方案用协议写出来是这样你是一位有10年经验的后端架构师做过多个内部工具的重构 熟悉遗留系统改造的常见坑。表达直接不绕弯子。 任务撰写一份内部工具的重构方案。 交付物一份完整方案包含现状分析、重构目标、技术选型、 实施步骤、风险评估五个部分。 执行方式先输出大纲我确认后逐部分展开。 输出格式技术选型部分用表格对比实施步骤用有序列表 风险评估用表格风险项、概率、影响、应对措施。 长度每个部分300到500字整体不超过3000字。 禁忌不要写随着业务发展这类空泛开头不要重复我的描述。 不确定的信息标注[不确定]并说明原因。这套指令下去模型第一次输出的大纲基本就能用确认后展开的内容质量也稳定。对比以前那种帮我写个重构方案的提问效率差距是数量级的。6.3 实战案例代码审查再举一个代码审查的例子这个场景对约束的要求更高你是一位资深后端工程师熟悉Python和数据库性能优化。 任务审查下面这段代码找出性能问题和潜在bug。 交付物问题列表每个问题包含位置、问题描述、严重程度、 修复建议。 执行方式直接输出不需要分步。 输出格式用表格列为行号、问题类型、严重程度、说明、建议。 严重程度用高/中/低三档。 长度每个问题的说明控制在100字以内。 禁忌不要提代码风格问题只关注性能和正确性。这里不要提代码风格问题就是典型的禁忌约束。不加这句模型会给你一堆建议加注释变量名可以更清晰之类的废话把真正重要的问题淹没了。7. 常见问题与排查技巧7.1 模型不遵守约束怎么办这是最常见的问题。你明明写了不要用总结性套话它结尾还是来一句综上所述。我的经验是约束要放在靠近任务的位置而且要用否定句式明确说。如果放在协议最前面模型读到后面可能已经忘了。放在任务描述后面效果会好很多。另外如果某个约束特别重要我会在协议末尾再重复一遍相当于加粗强调。还有一个技巧用正面指令替代负面指令。与其说不要写套话不如说结尾直接给出最后一条建议不要另起总结段落。正面指令给了模型一个明确的行为替代方案比单纯禁止更有效。7.2 输出质量不稳定的排查思路同样一套协议有时候输出很好有时候很一般。我总结了几个排查方向现象可能原因排查方法内容变浅上下文太长注意力分散开新对话只带必要信息格式混乱格式约束不够具体补充格式示例跑题任务描述有歧义让模型复述任务再执行编造信息缺少不确定性声明补上反馈层指令其中上下文太长是最容易被忽略的。长对话里早期的指令会被后面的内容稀释。我的做法是一个任务一个对话任务完成后开新对话把需要延续的信息手动带过去。7.3 避坑清单最后整理一份我踩过的坑都是真金白银换来的不要在协议里写矛盾的要求。比如同时要求详细展开和简洁明了模型会无所适从。不要一次给太多任务。三个以上独立任务放在一个对话里后面的质量必然下降。不要用模糊的形容词。专业高质量深入这些词对模型没有约束力要换成可量化的描述。不要忽略模型的确认请求。如果模型问你是指A还是B一定要明确回答含糊过去它就会自己猜。不要迷信一次成功。再好的协议也有失手的时候关键是把纠偏成本降下来。这套协议我用了大半年中间改过好几版V2.00是目前最稳定的。但它不是终点模型在进化用法也得跟着调。我个人的体会是协议的价值不在于写得多漂亮而在于它逼你把需求想清楚。很多时候模型输出不好根源是我自己都没想明白要什么。把协议填一遍的过程其实就是把需求理一遍的过程。这个附加价值可能比省下来的那几轮对话更值钱。