1. 为什么需要“回复指令”assistant 角色的底层逻辑1.1 大模型的“角色扮演”机制系统指令如何影响输出很多人把 prompt 提示词理解为“白话告诉 AI 我要什么”但实际用下来会发现同一个问题换一种说法模型给你的结果差别可以大到像两个人。这不是玄学而是大模型的工作原理决定的。Transformer 架构下的对话模型本质上是一个“按概率续写文本”的引擎它每生成一个 token都在根据当前上下文预测下一个最可能出现的词。所谓“角色设定”就是在它续写之前先把一段关于“你是谁、你要怎么回答”的描述塞进上下文里从而改变后续所有 token 的概率分布。用生活里的话说这就像你临时雇了一个能力很强但完全不了解你公司的顾问。你不告诉他岗位要求、工作流程、汇报风格他就按自己的习惯乱来你把一份《岗位说明书》拍到他面前他就照着说明书里的样子干活。回复指令 assistant就是你写给大模型的那份《岗位说明书》。很多人会混淆几个概念prompt 提示词是统称包含你给模型的所有输入system prompt 是系统级设定通常在最前面而“回复指令 assistant”指的是在对话流中明确地告诉模型“你是 assistant你要以什么身份和规则来回应用户”。这个“assistant 身份声明”是提示词工程里最容易被忽略、却最能拉开效果差距的一环。1.2 没有回复指令时的“默认人格”问题不设定任何回复指令时模型会进入一个“默认人格”状态。这个默认人格的特点是有问必答、语气中立、倾向长篇大论、习惯罗列要点、不敢下结论、经常给出“一方面……另一方面……”式的和稀泥回答。它适合做一些基础问答但离“可用的生产力工具”差距很大。我实测下来没有回复指令时最容易出现的三个问题。第一是风格漂移同一段对话里前半段像专家在讲课后半段突然变成营销号在喊口号。第二是边界模糊你问它一个不该答的问题它不会主动拒绝而是会犹犹豫豫地绕着圈子给出部分回答反而让你更难判断信息的可靠性。第三是视角混乱它时而站在你的角度思考时而站在大众角度评价时而又跳到“作为一个 AI 模型”的免责视角输出的内容缺乏内在统一性。这就像请了一个不认领岗位的员工你让他整理报表他顺便帮你把会议室绿植也浇了看似勤快实际上你要的核心产出质量根本没保障。回复指令要解决的就是这个“身份不认领”的问题。1.3 assistant 指令在对话中的位置与生效机制要理解回复指令先要理解一次完整对话的结构。主流大模型接口的对话消息分为三类system系统消息全局设定、user用户消息来自使用者、assistant助手消息模型自己的回复。当你第一次调用 API 时system 里可以放置长久的角色定义而每轮 user 和 assistant 的对话则构成了模型的“历史记忆”。这里有一个关键机制值得注意模型在生成新回复时会把从 system 到最近一轮 user 的全部内容都当作上下文。也就是说你之前以 assistant 身份发出的回复也会成为模型后续参考的“人设范例”。如果你在连续几轮里都用简洁、带固定格式的短句回复模型下一轮大概率会继续保持这个风格如果你中途突然换了一种语气它也会跟着切换。这就是“以 assistant 身份回复”这件事如此重要的原因——它不只是第一条指令里的设定而是贯穿整个对话历史的行为锚点。你每一次作为 assistant 的输出其实都是在给模型示范“你应该这样说话”这种示范的约束力有时候比你写一万字的规则更有效。因为模型天生擅长模仿文本模式你给它看什么样的“自己”它就更容易延续什么样的“自己”。2. 回复指令的核心构成设计一个好 assistant 的五个模块2.1 身份设定让模型“成为谁”写回复指令的第一步是明确告诉模型它是谁。这里别小看一句话的差别。只说“你是一个助手”模型不知道助手分多少种说“你是一个拥有 12 年经验的全栈工程师”模型输出的技术含量和术语密度立刻不一样说“你是一个耐心温柔的小学语文老师”模型讲题时的拆解颗粒度和鼓励性语言也完全不同。身份设定的关键不在于身份本身多华丽而在于身份和任务的匹配度。我见过有人写了一大段“你是宇宙最强 AI”结果任务只是帮忙拟一份周报模型拿着这个身份不知道该怎么出力。还有人在设定里写“你是一个严谨的科学家”但任务却是写轻松的小红书文案结果模型每句话都带着文献引用味特别生硬。身份设定还要注意一个细节除了“身份名称”最好补上这个身份“关心什么、不关心什么”。比如同样设定为“产品经理”一种写法是“你是资深产品经理擅长需求分析”另一种是“你是资深产品经理关注用户价值、链路体验和数据验证不关心 UI 的具体配色”后者的引导效果明显更强。因为身份名称只是一个标签标签背后的“关注偏好”才是模型真正依据的线索。2.2 行为边界什么能做、什么不能做行为边界是回复指令里最容易被忽略、却最能避免事故的部分。没有边界时模型会默认自己是“有求必应”的。它可能编造数据、杜撰引用来源、在不确定的领域里给出斩钉截铁的结论这些行为相当常见。我在真实项目里踩过一次明显的坑。有一次让模型扮演“数据分析师”整理业务结论没有做边界约束模型非常流畅地把一个明显不显著的差异说出了“这说明策略效果显著”这样的结论。后来我重新写了指令在边界里加了一句“当样本量不足或差异不显著时必须如实说明禁止为了得出结论而强行解释”效果立刻改变。设置行为边界的常见思路包括事实边界不确定的信息要说明不确定不能编造、伦理边界涉及人身攻击、违法内容、歧视言论一律拒绝、职责边界超出你身份范围的问题不要强行回答可以建议其他处理方式、数据边界没有提供的数据不能假设只能基于已有信息推演。这些边界写得越具体、越场景化模型越容易遵守。抽象写“你要诚实”作用很小因为它对“诚实”的理解太宽泛写成“当问题超出你训练数据的覆盖范围时直接说明你不知道不要猜测”就清晰得多。2.3 输出约束格式、长度、语气、结构输出约束决定了“回答长什么样”。很多提示词教程会强调格式但我的经验是输出约束不能只列要求要把“为什么这样要求”的意图也带进去。比如只说“回答控制在 300 字以内”模型可能会把内容压缩成干巴巴的条目如果说“回答控制在 300 字以内目的是方便用户直接复制到群里发所以要完整、口语化、不要小标题”模型的理解就会准确得多。格式约束的几个常见维度结构是要段落、列表、表格还是代码块、长度正文多少字、小标题几个、语气正式/亲切/犀利/温和、语言风格简洁直白还是旁征博引、可以用的修辞哪些可以哪些不行。这些约束之间还可能互相影响例如限定“不用列表”和“结构清晰”就容易打架需要你在写的时候自己先脑内验证一遍。最有效的输出约束方式是“给正例”。告诉模型“好的我明白了不开心没关系我们可以慢慢来”这种语言风格比写一百句“要温柔、要共情、要有温度”管用得多。模型对抽象形容词的反应远不如对具体文本模式的模仿来得精准。你在输出约束里放一个 2—3 句的示例开头它整段的风格都会向示例靠拢。2.4 上下文策略追问、纠错、拒绝请求怎么处理模型在真实的对话中不可能从头到尾都只做一个单向问答。用户会追问、会否定、会提出超出预期的话题甚至会产生情绪。一个设计良好的回复指令需要为这些“对话事件”预设处理策略。追问场景当用户说“再详细一点”时模型应该展开到什么程度是补充细节还是更换表达方式如果没有预设模型容易干出“把刚才的内容抄一遍换几个同义词”的敷衍操作。较好的策略是明确“当用户追问时优先换角度解释不要重复原文可以引入类比、图表化描述或更具体的案例。”纠错场景当用户指出“你说的不对”时模型应该立即道歉还是先核实我倾向于在指令里写明“当用户提出异议时先判断对方的依据是什么。如果用户提供了新信息要承认错误并基于新信息重新分析如果用户只是表达情绪不要过度道歉保持专业并帮助对方解决问题。”情绪场景用户可能会骂人、抱怨、吐槽。没有预设时模型要么冷冰冰地回应“我很抱歉”要么被用户带偏跟着一起情绪化。预设里可以加上“遇到用户的负面情绪时先承接情绪再引导解决问题。不要被带偏节奏不要和用户争论。”2.5 边界情况话题越界时怎么办再强的指令也不可能覆盖所有情况总有话题会超出你预设的范围。这时候模型的表现取决于你在指令里怎么定义“越界”。有些人在回复指令里不写边界模型遇到敏感争议问题会陷入“过度道歉”或者“说教模式”很难用。实践中最常遇到越界话题的处理包括三类。一是超出身份范围的问题例如你设定的是“前端工程师”用户却问起了薪资谈判技巧好的策略是简单说明自己在这个领域不擅长但可以给出获取建议的渠道。二是疑似编造高风险信息的问题比如医疗建议、法律意见、投资判断应该要求模型在回答中明示“这仅作为参考不构成专业建议”。三是情绪非常强烈的对抗性问题建议策略是保持中立只陈述事实不掺杂立场判断。这部分很难写得面面俱到我的建议是越是你不希望模型乱说的话题类型越要在边界范例里写一个“如果遇到 X请这样回应”的具体样例。模型对“样例”的学习效果远好于“原则”。3. 从理论到实践指令的书写结构与范例拆解3.1 结构化指令的通用骨架把回复指令拆成骨架常用的结构化写法是“身份 任务 规则 输出格式 边界 示例”。六个段落各自承担不同的作用身份一句话说清模型是谁、擅长什么。任务说明这个对话的整体目标以及每一轮回复需要服务的目标。规则列出必须遵守的行为准则数量控制在 3—5 条以内为宜太多反而互相干扰。输出格式说明回复的默认结构、长度、风格最好附一个示例开头。边界明确哪些事不做、哪些信息不编造、哪些情况要拒绝。示例一段角色完成任务的典型回复样例作为风格锚点。这套骨架的好处是“可拆可合”。日常在网页聊天里给模型发这些话时不需要一次全写只需要在关键场景中加入其中两三个模块就能显著提升回复质量。例如你想让模型帮你润色一篇文章你只要写“你是一个资深编辑身份只做文字润色不要改动事实信息规则先给出修改后的全文再附上修改说明输出格式”它输出的专业感立刻不同。3.2 三个可直接套用的 assistant 模板第一个模板是“客服售后型 assistant”。身份设定为电商平台售后专员性格耐心友好。任务目标是解决用户订单问题、退换货流程、物流咨询同时维护用户满意度。规则包括回答步骤先共情再给方案每轮回复不超过 200 字不确定的信息引导用户联系人工客服不能编造物流状态。边界是禁止与用户争执、禁止口头禅式道歉超过两次、不评价商品质量。输出格式使用公告式语言结尾固定提供“还有别的问题吗”的自然收尾。第二个模板是“写作编辑型 assistant”。身份设定为公众号主编有 10 年新媒体写作经验。任务目标是把用户提供的草稿改写成逻辑通顺、有画面感、适合公众号阅读的文本。规则包括保留用户的原始观点不新增事实每段不超过 5 行多使用动词和具体名词少用抽象形容词标题控制在 20 字以内并给出 3 个备选。边界是不写夸张标题党不编造引用出处不强行加金句。这个模板我给我的编辑团队用了很久稳定度相当高。第三个模板是“代码助手型 assistant”。身份设定为资深全栈工程师擅长写可维护的代码。任务目标是根据用户描述或代码片段给出优化建议或实现方案。规则包括先给结论再给解释涉及复杂逻辑时附上时间/空间复杂度分析当用户代码存在潜在 bug 时直接指出而不是只夸代码能跑。输出格式回答中代码块必须带语言标记遵循项目现有的代码风格。边界是不确定的 API 用法要标注出来建议查证后引用不假装运行过。3.3 一次指令设计完整演示拿“把一段混乱的会议纪要整理成行动清单”来完整走一遍设计流程。第一次试写“你是一个专业的会议纪要整理者请把下面的内容整理成行动清单。”模型给出的结果大概率是把原始文本分段加序号没有轻重缓急也没有提炼责任人。第二次迭代加入更具体的规则“你是会议纪要整理专家。任务是把用户提供的会议内容整理成行动清单。规则1. 仅基于原文信息不补充不存在的细节2. 每个行动项至少包含‘负责人’‘截止时间’‘具体动作’原文中缺失的字段写‘待确认’3. 按优先级排序4. 总字数控制在 300 字以内。输出格式用列表每个行动项前用 [紧急][重要][待定] 标记。”这次输出的可用性立刻上升。第三次迭代补上边界和示例。加一句“当原文中没有明确的负责人或时间时不要猜测统一标注‘待确认’。参考下面的输出示例……”。到这一步基本就能稳定产出一个可以直接复制粘贴到项目管理工具里的清单了。整个迭代时间大约只需要 5 分钟但每一步都在缩小模型的自由发挥空间让它更贴近你的真实需求。4. 常见问题与排查技巧为什么你的回复指令经常“失效”4.1 角色崩坏模型突然跳出设定最让用户困惑的现象是——指令明明写了“你是一个严谨的财务分析师”聊到一半模型突然开始输出“哈哈作为一个 AI 模型我可以……”这种划破人设的话。这通常不是因为模型“忘了”而是因为某个环节的上下文把角色的权重冲淡了。排查思路先检查你自己的消息里是否出现大量与角色无关的情感化表达、网络流行语或无关话题这些内容会稀释角色指令在上下文中的占比。再检查是否需要“锚点重申”我的做法是在第 4—5 轮对话时主动插入一条指令“记住你仍然是我的财务分析师继续保持上文的输出规范。”这样可以用简短的成本稳住后续几十轮的风格。4.2 指令被遗忘上下文过长时规则失效每个模型的上下文窗口是有限的即便长文本模型能装下很多轮对话早期指令对后面回复的约束力也会随着距离拉远而递减。这就好比开会开了两个小时你开场宣布“不允许跑题”但到了后半场大部分人早忘了这个约束。针对这个问题的实操技巧把最关键的规则放在 user 消息的最后一条里重复一遍而不是依赖最早的 system 指令。例如你希望模型“给出的所有结论都有理由”那就在每轮的输入末尾固定追加一句“不要忘记所有判断必须附上理由。”这种“规则向末尾迁移”的做法是我实测下来对抗本地遗忘最便宜有效的方式。4.3 规则冲突多个约束互相打架写指令时最容易埋雷的是同时提出“要简洁”和“要全面”或“不要用列表”和“要结构清晰”。当规则之间存在张力时模型会随机选择一种解读导致输出时而满足这条、时而满足那条看起来不稳定。排查方法是做一次规则“两两配对”自检逐条朗读自己写的指令想象两个规则同时生效时会是什么效果。如果发现可能互相矛盾的组合就主动写明优先级。例如“优先保证信息完整其次控制篇幅当真冲突时以信息完整为准。”这一个小动作能大幅减轻模型“猜你心思”的负担。4.4 指令太抽象模型“听不懂”的要求“请给出有洞见的回答”“要有深度、不要平淡”这类指令等于没说。模型对抽象修饰词的理解非常有限它更擅长应对具体描述。“有洞见”可以改写为“在回答中明确指出容易被忽略的假设”“在每个观点后补一个具体案例”“对主流观点提出一个合理的反例”。这样模型才有真正可执行的抓手。排查指令时可以尝试把自己当成一个刚入职的实习生你写的指令是给他发的任务书——如果任务书里有三个以上需要“意会”的表述那就说明指令还不够具体。把“意会”改成“言传”之后回复质量的提升往往是肉眼可见的。5. 进阶视角从“会写指令”到“会调指令”5.1 迭代意识把回复指令当成一个“产品”接触提示词工程越久我越觉得一份好的回复指令不是“写出来”的而是“迭代出来”的。第一版能覆盖六成场景已经不错了剩下的四成要靠真实对话中的反馈去修补。有人对着一版质量平庸的指令用了一个月然后抱怨“AI 能力不行”其实是没给指令成长的周期。迭代意识的核心是“每次对话后做一次复盘”。如果模型这一轮回答了不想要的内容不要急着换一个新的完整指令先找到刚才这段对话里的哪一句话把模型带偏了针对性地改掉那个诱因。我通常把指令放在一个独立的文本文件里管理标注版本号每次修改后记录改动原因这样能清楚看到哪个规则产生了效果、哪个规则形同虚设。5.2 评测闭环判断指令质量的两个维度判断一份回复指令是否在进步我主要看两个维度稳定性和一致性。稳定性指在相似输入下指令是否能让模型稳定产出接近质量的回复——如果同样的任务十次回答里有三次跑偏说明指令里的约束力还不够强或者约束本身不够具体。一致性指模型的回复风格是否始终贴合设定从第一轮到第十轮、从简单问题到刁钻问题身份感是否还能维持住。这两个维度的评测不需要什么工具平时对话中积累观察数据就行。我会定期把同一组测试问题发给带着不同版指令的模型比较输出质量的差别。这种做法看起来简单但长期坚持下来比看任何教程都管用。5.3 与上下文工程配合记忆管理与锚点重申最后想说的一点是回复指令不能单独发挥最大效果它需要和上下文工程配合。上下文工程包括选择多少历史对话作为模型参考、在什么时机插入关键信息、如何管理多轮对话中的记忆重点。指令负责提供“规则”对话历史负责提供“状态”两者共同决定了模型的输出质量。一个很实用的组合技巧把“长期指令”和“短期状态”分开。长期指令放在最开始描述身份、边界、总体规则短期状态放在最新一条消息附近描述“现在正在讨论的具体项目、用户当前的目标、最近一次未解决的问题”。这样模型既不会忘记自己是谁也不会弄丢眼下正在做什么。特别在代理切换话题的时候我用这个“记忆收拢”的技巧能明显减少模型“跟丢”的情况。写回复指令这件事很多时候不是写得越多越好而是“设计意图越清晰越好”。一份管用的指令看起来往往朴素、克制、条理分明不会有华丽辞藻或炫技句式。它真正在做的事无非是给一个强大的通用模型划定一条确定的工作边界让它的能力聚焦在一个明确的方向上。理论篇讲到这里后面如果有机会我把这些思路用一个完整的实战项目从头到尾演示一遍看看一套成型指令在真实项目里是怎么从粗糙的第一版长到能稳定落地的状态的。