1. 接活那晚我先想清楚了一件事晚上七点我接到一个有点急的需求某个国产对话模型的应用版本内部代号叫 K3要在第二天早上前完成一轮体验优化。反馈意见听起来很朴素——“回答太长太啰嗦关键信息不突出偶尔还一本正经地编细节”。这个描述我太熟悉了表面看像模型能力问题实际大概率是提示词没写到位、上下文管理粗糙、输出格式缺少约束。当时摆在我面前的是两个约束其一我没有一整个团队来慢慢调参试错其二留给我的时间只有一个晚上。所以我先定了技术路线用人手之外的第二套大脑来干诊断和方案设计——也就是借用一个国外闭源旗舰对话模型做“教练”。下文我把它叫做 O 模型。它不算什么银弹但指令遵循能力和文本诊断能力确实在线用来做代码式的逐段提示词审查、错误归因、重写优化非常合适。这篇记录写给谁看一类是做 AI 应用落地、负责提示词调试和 Bot 体验的开发者另一类是产品经理、AI 解决方案工程师想知道“AI 优化 AI”这个工作流到底怎么落地。我会把一晚上的时间规划、测试集设计、评分方式、踩坑点全部展开尽量让你看完能照搬思路。为什么想到用 AI 优化 AI而不是纯人工重写道理很简单K3 这类模型暴露的问题往往分布在几十条不同的提示词场景里人工一条条读、一条条改一晚上根本跑不完。而强模型能同时做三件事把失败案例归纳成规律、按规律生成新提示词版本、再对改写后的输出做快速校验。人只需要在关键节点把关效率能拉开一个数量级。这个思路在平时做优化时也通用只是这晚因为时间紧被逼着把流程压缩到了极致。需要注意一点用 AI 辅助优化不等于把问题丢给 AI 就不管了。我的底线是所有改动都必须能在具体案例上看到效果差异改完还必须人工通读一遍提示词确认没有引入新的约束漏洞。AI 负责批量产出人负责方向和质量验收这个分工是整个“一晚上奇迹”能成立的前提。2. 动手前先做基准测试给 K3 建一张“成绩单”严格来说接到需求后的第一个任务不是改提示词而是先回答“现在到底有多差”。没有基线后面所有改动都是自说自话。晚上 7 点到 9 点我基本都花在搭测试集和跑基准上。这一步很枯燥但它决定了整个优化方向对不对。2.1 测试题目集30 条覆盖三类典型问题我给 K3 建了一个测试集规模不大就 30 条问题但刻意分成三类第一类是高频问题用户日常真的会问的比如“帮我总结一下这段对话里的待办事项”“这份文档的核心观点是什么”。这类要测的是回答是否直接命中用户诉求。第二类是边界问题包括长文本输入、连续追问、包含明显错误信息的问题比如“如果用户说昨天已经退款了但系统里没记录怎么回应”。这类主要看模型的稳定性和纠错能力。第三类是格式要求问题比如要求输出 JSON、表格、分步骤清单或者要求“先给结论再解释”。这类直接反映输出格式约束有没有生效。测试集我放在一个表格里每一行记录问题原文、所属类别、K3 优化前回答、问题定位。这样后面改完提示词同一批问题再跑一遍结果一对比就很直观。别小看这个动作很多团队优化模型体验全凭感觉今天觉得回答长了就加一句“要简洁”明天觉得不够详细又改回来最后模型行为像过山车。测试集就是给这种反复横跳踩刹车的。2.2 评分方式人工打分加 O 模型复盘30 条问题我要求自己每条都给出四维评分准确度、完整度、格式合法率、简洁度。准确度就是回答有没有事实性错误有没有编造完整度看用户关注的点是否都覆盖到了格式合法率专门看结构化输出场景下字段是否齐全、类型是否正确简洁度则是主观分评价是不是啰嗦、重点是否突出。人工打分有个客观问题30 条全自己看时间上可以接受但评判标准不一定稳。所以我又做了一步把所有回答统一丢给 O 模型让它按同样四个维度给出诊断并指出每条回答里最明显的三个问题。这样等于有了第二裁判。人工打分和 O 模型诊断不一致的条目我再自己看一遍以最终判断为准。整套基准跑到晚上 9 点结果出来了格式合法率只有 62%有一类高频问题里超过一半的回答信息位置靠后用户要翻到第三段才看到核心结论。简洁度更惨好几天问题被判定为“有明显冗余表述”。这里我想强调评分不是为了证明 K3 差而是给晚上的改动提供靶子。每个分数低的地方对应一个明确的优化动作。比如格式合法率低那就说明输出约束没做好信息位置靠后就说明提示词里缺少“先结论后展开”的结构要求。有了这张成绩单后面每一步优化都不是拍脑袋。2.3 一晚上的时间分配为什么是“诊断大于修改”我给自己定的时间预算是诊断和基准占 2 小时提示词重写占 2 小时批量验证占 2 小时针对性修补和灰度确认占 1 小时留 1 小时缓冲。很多人一接到优化需求就急着改提示词恨不得第一小时就把新版上线。但我实际做过好几次类似任务最大的教训是如果不知道病根在哪改十版提示词也未必中靶。花两个小时把失败案例吃透我会知道“啰嗦”到底是模型风格问题还是指令层次问题“乱编”到底是上下文没有兜底还是系统提示词缺少“不确定就说不确定”的规则。这些判断才是优化的原材料。反过来盲目加限制词只会让回答变得越来越生硬甚至牺牲原有能力。所以当晚我宁可压缩后面的验证时间也不肯压缩前面的诊断时间。3. 核心优化动作三个方向先把 80% 的问题解决掉基准测试暴露的问题可以归纳成三个根因人设与回答结构缺失、输出格式约束不足、上下文管理太粗。针对这三个根因我把优化动作收敛成三块分别对应系统提示词重写、Few-shot 与格式模板设计、上下文管理机制调整。这三块做完基本覆盖了当天反馈里的绝大多数问题。3.1 重写系统提示词先把“角色”和“回答结构”立起来原来的系统提示词只有一句话——“你是一个智能助手请回答用户的问题。”这种写法放在半年前还能用放到今天就是浪费模型能力。K3 本身是有一定推理和总结能力的问题在于它不知道该用什么样的口吻、按什么顺序组织回答。就像一个很有经验的员工但没被告知汇报格式只能自由发挥发挥的结果自然参差不齐。我重写后的系统提示词核心增加三个层次第一层是角色定调明确 K3 是一个面向业务场景的助手回答必须克制、专业、信息密度高。第二层是回答结构明确要求“结论先行、证据随后、可选项放最后”且具体细节要用分点或表格承载不允许大段连续文字堆砌。第三层是行为边界当信息不确定时必须明说“我不确定”并给出建议的确认路径禁止编造数据。以“总结对话待办”这个问题为例优化前的回答通常是一段 200 字以上的连贯叙述要点淹没在中间。优化后K3 会先列出“本次对话共识别出 3 项待办”再用表格把待办事项、负责人、截止时间放进去最后补充一句“其中第 2 项需要你再次确认截止时间”。结构一变用户的信息获取成本立刻降下来了。这里有一个值得说的技巧系统提示词不是越长越好但也不是越短越好。长度要让人设、结构、边界三个部分形成层次。我用过一种写法把“角色定义”“回答规则”“禁忌行为”分三个区块写区块之间留空行模型对规则的遵循率明显高于一锅炖的写法。你可以理解为给模型划清楚的章节它自己也知道哪些是重点。3.2 用 Few-shot 和输出模板把“自由发挥”关起来光有系统提示词还不够因为规则是抽象的模型可能理解了但不知道要多严格。这时候 Few-shot 示例就派上用场了。我选了三个高频场景每个场景给一条“问题-理想回答”示例直接放进提示词末尾。这比写十句“你要简洁”“你要结构化”都管用因为示例把抽象规则变成了可见的样板。比如在格式要求类问题上我要求 K3 输出 JSON 时就必须严格按照预定义的字段结构来。我不只告诉它“输出 JSON”还把字段名、类型、是否必填写清楚。举个例子如果要求它返回一个包含“观点摘要”和“支持细节”的对象我会在提示词里这样写{ 观点摘要: 字符串不超过50字, 支持细节: [字符串数组每项不超过30字], 置信度: 0到1之间的数字表示对答案的把握 }这样做有几个好处一是 K3 输出的 JSON 解析失败率大幅下降因为每条字段的名字和格式都有了明确参照二是后续做自动化流程时下游程序可以稳定地按固定路径去取值不需要写一堆兼容逻辑。当晚我把格式合法率从 62% 拉到了 92%靠的就是这招。这里还要提一个容易被忽略的参数温度。K3 这类模型默认温度可能偏高回答会更有“创造性”但也更容易跑偏。在需要稳定输出的场景里我把温度降下来K3 的措辞会收敛很多重复性也变好。注意这不是所有场景都适用——如果任务是创意写作、头脑风暴那温度该高还是高。关键是要区分场景不能一套参数走天下。3.3 上下文管理防止 K3 聊着聊着“忘了自己是谁”第三个根因是上下文管理。K3 在长对话里的一个问题上下文窗口有限系统提示词如果被大量历史消息挤占模型对初始指令的遵循度会越来越低。这就像开会时间拖太久大家慢慢忘了会议主题。针对这个问题我做了两个动作。第一个动作是压缩长期记忆。在会话轮次超过一定阈值时把前面的对话内容做一轮自动摘要用摘要替换原始历史记录。摘要保留关键事实和用户诉求丢弃寒暄和重复表达这样既节省上下文空间又不丢失核心信息。第二个动作是强化关键指令。我要求 K3 在每轮回答前先快速回顾一下最新的系统提示词摘要尤其是行为边界和回答结构部分。这个做法不是所有模型都支持但 K3 实测有效回答的稳定性明显提升。还需要注意一个细节系统提示词里如果包含了过多示例示例本身也会占据上下文空间。所以 Few-shot 的数量不是越多越好。我一般控制在每个场景 1 到 2 个高质量示例超过 3 个反而可能让模型迷失分不清哪个是标准。当晚我对比过 3 个示例和 1 个示例的效果差异不大但前者提示词体积明显更大响应速度也略有下降。4. 一晚上的实操流水账从 7 点到凌晨 2 点的真实节奏光说理论容易飘我把当晚的时间轴完整放出来你会发现大部分时间投在了“验证”而不是“写提示词”上。这个过程不求花哨但每一步都有明确产出。4.1 晚上 7 点到 9 点先给问题归类建档如前面说的这个时段用来搭测试集、跑基准。实际操作上我会打开一个记录表把 30 条问题的原始回答都粘贴进去并给每个问题打标签比如“结论滞后”“冗余解释”“格式缺失”“信息编造”。标签打得细后面统计规律就方便。比如当晚统计下来“结论滞后”出现频率最高占所有问题的三成以上“格式缺失”次之。这两个数字直接决定了我当晚的主攻方向。很多人觉得这个环节太费时间但我要说一句实在话如果没有这一步后面你根本不知道改完的提示词到底有没有效果全凭感觉。做工程优化最怕的就是感觉。数字化记录能让你在晚上 11 点累到不想动的时候还能用客观数据说服自己继续推进。4.2 晚上 9 点到 11 点让 O 模型当“提示词教练”这个阶段是我和 O 模型协作最密集的时候。我把评分表里失败案例的原始回答发给 O 模型附上一句话“请分析这组回答的共同问题并给出系统提示词层面的修改建议。”然后我不盲信输出而是让它针对每个根因给出具体改写文案。举个例子针对“结论滞后”我要求 O 模型帮我重写“回答结构”这一段规则。它给出的初版挺好但我觉得语气有点生硬于是追加了一条指令“保持规则明确但语气要像资深同事给自己人提要求不要像官方文档。”这个追加很关键因为提示词最终是给模型读的模型的语气会直接影响回答风格。如果规则写得像官僚文件K3 产出的回答也会透着一股僵硬感。这里也提醒一句O 模型的输出是上限很高的草稿但不代表可以直接抄。它给出的提示词有可能过度约束导致模型回答变得机械。我会做一轮“最小集测试”把它的建议先加到系统提示词里跑 10 条测试问题看是否带来新问题。如果有新问题再局部回退。整个过程大概迭代了四五轮每轮 20 到 30 分钟。加上人工通读确认最终落在系统提示词里的版本其实是多次筛选的产物。4.3 晚上 11 点到凌晨 1 点批量验证与差异对比提示词改完后真正的考验才开始。我把优化后的系统提示词部署到测试环境然后把同一份 30 条测试题全部跑一遍再按之前的评分维度重新打分。这一步我做了两个对照组第一组是“原始提示词原参数”第二组是“新提示词调整后参数”。对比结果我直接做成表格。我没有把整个表格贴出来只提其中几个关键数据格式合法率从 62% 升到 92%结论滞后类问题从 10 条降到 3 条准确度没有明显回退。这个结果说明提示词重写和格式模板设计是有效的。不过我也注意到一个副作用有几条创意类问题的回答变得过于保守发散性明显下降。这是因为温度降低和结构约束同时生效把模型的“想象力”也压住了。这个副作用在后半夜拿来专门处理了。我的方案是分场景配置参数结构化输出场景用低温度和严格格式模板开放式问答场景保留原始温度和更少结构约束。说白了提示词和参数不是一套走天下而是按任务类型做配置分组。这个思路很多团队都在用但真正落地时要注意分组不是越细越好否则维护成本会失控。我当时只分了三组覆盖绝大多数业务场景。4.4 凌晨 1 点到 2 点针对剩余问题做定向修补对照测试结果还有几个问题属于“顽固分子”。比如有一类问题用户询问的内容本身有歧义K3 还是会直接按最可能的意思回答没有先澄清假设。这不是提示词能完全解决的但在提示词层面至少可以加一条规则“当问题存在两种以上合理解读时先补充一句‘我按 XX 理解你的问题’再给出答案。”实测效果不错用户看到这句话就算理解有偏差也不会觉得 K3 答非所问。还有一个顽固问题某些长文档总结场景下K3 会把文档中不重要的细节也纳入总结导致回答还是偏长。我用了一个比较讨巧的办法在提示词里加入“让我用三个要点概括”这样的引导句式K3 会自动把信息压缩到三个要点且每个要点只保留一句话。这个技巧简单但非常实用遇到“总结提取”类任务都可以套用。后半夜的每项修补我都重复同一套流程提假设、改提示词、跑 10 条相关问题、看结果、决定保留或回退。凌晨 2 点最后一轮验证通过我把所有改动整理成变更说明发出去然后关机休息。整个流程下来真正用于“写提示词”的时间占比其实不高大量时间消耗在“验证假设——修正假设”这个循环里。但正是这个循环保证了第二天上线时不至于翻车。5. 一晚上踩过的坑常见问题速查表这一节我单独整理出来因为任何一个坑都可能让优化白干。以下问题基本都是当晚真实遇到过的或者是我之前类似项目里踩过的整理成速查格式方便你以后对照排查。5.1 过拟合测试集提示词越来越长泛化越来越差优化过程中最容易犯的错就是盯着 30 条测试问题不断修补最后提示词变成了一个针对测试集定制的“缝合怪”换一批新问题立刻露馅。这个坑的典型信号是测试集准确率很高但一到真实用户场景就表现平平。我给的解决方案是每个根因只做一次改进不要反复在同一处叠加规则同时保留一组“留出集”也就是 10 条不在测试集里的新问题每次改完提示词都用留出集做抽查。如果留出集表现下降说明改动过拟合了需要回退。5.2 温度参数一半业务场景被默认参数坑过默认温度设置对很多模型来说都偏“活泼”表现在回答里就是语气随意、结构松散、容易跑题。我第一次给 K3 调低温度后格式合法率立刻提升了十几个百分点。但温度也不是越低越好我把温度压到接近最低值后回答变得机械重复一点泛化能力都没有。个人经验一般在 0.3 到 0.6 之间比较稳妥具体值要按场景测试不要直接抄别人的配置。5.3 JSON 输出解析失败字段名不一致是最大元凶结构化输出最容易出的问题是字段名“漂移”。提示词里写的是“关键词列表”模型可能输出成“关键字数组”。解决这个问题的办法就是前面说的在提示词里直接给出 JSON 模板并且把字段描述写清楚。注意模板里的字段名不要用中英混合要统一否则模型很容易在“摘要”和“summary”之间来回切换下游解析逻辑根本没法稳定。5.4 模型风格来回横跳系统提示词被历史对话“冲淡”长对话里模型前几轮回答风格正常后面逐渐变回默认风格这种现象多半是系统提示词被上下文冲淡。解决办法我在 3.3 里提过定期压缩历史消息同时在每轮回答前让模型回顾关键指令。还有一个土办法把最关键的两三条规则在对话中间再重复一遍相当于给模型设置“路标”。这个方法不优雅但实测有效短期迭代时可以应急。5.5 提示词改成长篇小说模型反而“变笨”我见过很多新手把系统提示词写到几千字事无巨细全都规定一遍结果是模型在处理简单问题时变得小心翼翼回答效率明显下降。这个现象的解释是过多约束占用了注意力资源模型反而抓不住核心指令。我的经验是系统提示词控制在 800 字左右规则条数控制在 5 到 8 条其余细节放到 Few-shot 示例里体现。规则要少而精示例要多而准。常见问题典型信号快速缓解方案过拟合测试集测试集高分但真实场景失效增加留出集每根因只改一次温度参数不适回答随意、格式松散降到 0.3-0.6按场景分组配置JSON 解析失败字段名漂移、类型错误提示词内置 JSON 模板系统指令被冲淡长对话风格漂移定期压缩历史重复关键规则提示词过长模型变笨、回答保守精简到 800 字内规则 5-8 条6. 最后分享几个可以立刻用上的技巧按我一贯的习惯正文到问题速查这里已经算是完整的交付了。不过既然标题强调“一晚上”我还是想补充三个能直接提升速度的小技巧算是给准备实践的人一些抓手。第一个技巧是“批量改写提示词之前先让强模型输出一份修改清单”。不要一上来就让它重写全文而是先问“请列出当前系统提示词中可能导致 XX 问题的句子按可疑程度排序”。这个做法的好处是你能看到强模型的判断依据而不是只拿到一个黑盒版本。根据清单决定改哪里、怎么改效率和透明度都更高。第二个技巧是“准备一个标准对比模板”。把优化前和优化后的回答并排放在一起重点标出差异点。很多时候直观的并排对比比评分表更让人信服尤其是要跟同事或客户解释优化效果时。我当晚发给客户的验收报告里就是每个关键场景配一张对比截图一眼就能看出差别。第三个技巧是“给自己留一个回滚点”。每次改提示词之前把当前版本导出一份存档。如果改坏了一键回滚不用靠记忆恢复。这个习惯在时间紧、夜里头脑发昏的时候特别有用。当晚我至少回滚过两次都是因为改到某一版发现引入新问题直接退回上一版再另找方案。我个人在实际操作中的体会是所谓“一晚上优化”靠的不是超常发挥而是流程上的刻意压缩。诊断永远花在修改前面验证永远花在追加规则前面留出集永远比测试集更值得信任。这套流程熟练以后不只是通宵赶工能用平时任何模型迭代都可以按这个骨架来做。 K3 这次优化能在一个晚上内完成我自己并不觉得意外因为流程对了剩下的就是一次次循环验证直到数据说话。