1. 从一句调侃说起大模型“斩杀线”到底指什么“斩杀线”这个词最早来自游戏圈指的是把对手血量压到某个阈值以下一套连招就能直接带走的那条临界线。放到大模型语境里它被借用来形容一种很微妙的心理预期某个模型在某个能力维度上只要跨过某条线就能对同类产品形成“降维打击”让对手没有还手余地。过去一年多这条线被反复提起也被反复“重新定义”。我最早注意到这个说法是在一批评测榜单刷屏的时候。那阵子几乎每隔几周就有人喊“某模型越过了斩杀线”配上一张跑分截图评论区立刻分成两派一派说“这下稳了”另一派说“榜单而已实测再说”。结果没过多久同一批人又开始说“斩杀线被斩杀了”。这个反转本身就很有意思——它说明大家逐渐意识到那条线可能根本不存在或者说它一直在移动。先把概念说清楚。所谓大模型的“斩杀线”通常指三类东西一是能力阈值比如代码通过率、数学推理准确率、长文本召回率跨过某个百分比二是成本阈值比如每百万token的推理价格降到某个区间三是体验阈值比如响应速度、上下文长度、多轮稳定性达到“可日常使用”的水平。这三条线里前两条容易被量化第三条最玄学也最容易被营销话术包装。那“被斩杀了”又是什么意思我的理解是原本被当作“一锤定音”的那条线被现实拆穿了。拆穿的方式有很多种——可能是榜单本身被发现有水分可能是实测场景和跑分场景差距太大也可能是对手用更低的成本做出了接近的效果让“越线”这件事失去了稀缺性。换句话说不是某条线被谁跨过去了而是“用一条线定生死”这套叙事本身被现实斩杀了。这篇文章我想聊的就是这件事。它适合两类人看一类是正在选型、被各种榜单和“越线”说法搞晕的开发者另一类是单纯好奇大模型行业在发生什么、为什么风向变得这么快的观察者。我会尽量把“为什么这条线靠不住”“实测该怎么看”“选型该盯什么”讲透中间穿插一些我自己踩过的坑和常用的判断方法。不吹不黑只讲能落地的部分。2. 斩杀线叙事是怎么被造出来的2.1 榜单、跑分与“一图流”传播要理解“斩杀线”为什么流行得先理解它的传播载体。最典型的载体就是一张跑分图横轴是模型名纵轴是某个指标某个模型一枝独秀旁边配一句“越线了”。这种图传播效率极高因为它把复杂的模型能力压缩成一个数字读者不需要懂技术细节看一眼就能站队。但问题也出在这里。跑分图天然会丢掉三样东西测试集和真实场景的分布差异、推理成本、稳定性。我见过太多这样的情况某个模型在公开测试集上分数很高换到自己的业务数据上表现直接掉一个档次。原因不复杂——公开测试集往往经过清洗题目类型集中而真实业务数据是脏的、长的、带上下文的。用一句大白话说就是“考试考得好不代表干活干得好”。还有一个更隐蔽的问题指标本身可以被优化。比如代码生成任务如果只看“通过率”模型可能会倾向于生成更保守、更模板化的代码牺牲可读性和扩展性来换通过率。数学推理任务里如果只看最终答案模型可能会跳过中间步骤导致过程不可信。这些优化在跑分上体现为“越线”在真实使用中却可能是隐患。2.2 成本线为什么比能力线更容易被“斩杀”相比能力线成本线被“斩杀”的速度更快也更彻底。原因在于成本是可以被工程手段直接压下来的量化、蒸馏、缓存、批处理、更高效的注意力实现每一项都能实打实地降低单位推理成本。当某个模型把价格打到某个区间原本靠“能力越线”建立的优势很快就会被“够用且便宜”稀释掉。我自己的体会是成本线一旦被跨过就很难再退回去。因为用户的心理预期会被锚定既然有人能做到这个价那贵的就是不划算。这跟能力线不一样——能力线可以被“场景适配”绕开成本线是硬碰硬的。所以你会看到很多“斩杀线”叙事最后都落脚到价格上因为价格是最容易比较、最没有争议的维度。但成本线也有陷阱。低价往往伴随着限流、排队、上下文缩水、并发限制这些隐性成本。我踩过一次坑某服务单价极低但高峰期排队严重实际吞吐还不如贵一点但稳定的服务。算总账的时候省下来的钱被等待时间和重试成本吃掉了。所以看成本线不能只看单价要看“有效成本”——也就是在满足你SLA的前提下单位有效产出的成本。2.3 体验线最容易被忽略也最容易被反噬体验线是最难量化的但恰恰是用户最敏感的。响应速度、多轮一致性、长上下文里的“中间遗忘”、工具调用的成功率这些都不太出现在跑分图里却直接决定一个模型能不能被日常使用。我印象很深的一次对比两个模型在同一个问答任务上跑分接近但一个回答干脆利落另一个喜欢绕圈子、加免责声明、重复问题。前者用起来“顺手”后者用起来“累”。这种差异在榜单上看不出来但在实际工作流里会被放大——你每天要跟它交互几十次每次多花十秒一天就是好几分钟一个月就是几个小时。体验线被“斩杀”的方式往往是反噬某个模型靠营销把体验预期拉得很高用户实际用下来发现不稳定口碑迅速下滑。这种反噬比能力线被超越更致命因为它伤的是信任。信任一旦丢了后面再想拉回来成本极高。3. 为什么“一条线定生死”越来越不成立3.1 场景碎片化没有万能模型只有适配模型大模型落地到今天已经很难找到一个“通吃”的场景。写代码、做客服、处理文档、做数据分析、生成营销文案每个场景对模型的要求都不一样。代码场景看重逻辑严谨和长上下文客服场景看重响应速度和话术一致性文档场景看重召回和引用准确数据分析场景看重工具调用和数值计算。这意味着“斩杀线”这个概念本身就站不住——你在A场景越线不代表在B场景也能越线。我见过一个模型在代码任务上表现惊艳换到合同审阅就频繁漏项。也见过一个模型在中文客服场景里非常稳但一到英文技术问答就开始胡编。所以现在我做选型第一件事不是看总分而是把场景拆成具体任务逐个测。3.2 评测滞后榜单永远追不上真实需求公开榜单的更新速度远远赶不上真实需求的变化。一个新场景出现从有人提出需求到形成稳定的评测集中间可能隔好几个月。这几个月里大家只能靠零散的实测和口口相传来判断信息非常不对称。更麻烦的是榜单的题目类型往往偏“标准答案”而真实需求里大量是开放式、多约束、需要权衡的任务。比如“帮我写一份既专业又不失亲切的周报”这种任务没有标准答案榜单根本测不了。所以你会发现很多在榜单上“越线”的模型一到开放式任务就露怯。3.3 成本与能力的动态平衡成本和能力不是两条平行线它们会互相影响。一个模型能力越强往往越贵但工程优化又能把成本压下来。这种动态平衡意味着“斩杀线”的位置一直在变。今天你觉得某个价格是“斩杀线”明天可能就被新的优化方案打破了。我自己的做法是不追线追区间。把可接受的成本区间和能力区间画出来在这个区间里选最稳的而不是选“最越线”的。因为越线的东西往往不稳定而稳定才是长期使用的关键。4. 实测视角怎么判断一个模型是不是“真越线”4.1 自建小评测集比公开榜单更靠谱公开榜单可以看但不能全信。我的习惯是针对自己的业务场景建一个小而精的评测集通常50到200条就够。这些样本要覆盖典型任务、边界情况、容易出错的case、以及你特别在意的维度。建评测集有几个要点。第一样本要来自真实数据不要自己编编出来的样本往往太干净。第二标注要统一最好有明确的评分标准比如1到5分每个分数对应什么表现。第三要留出盲测集不要把所有样本都用来调prompt否则测出来的分数会虚高。我一般会分两轮测第一轮用固定prompt看基础能力第二轮用优化过的prompt看上限。两轮分数差距大的模型说明它对prompt敏感实际使用中需要更多调优成本。4.2 关注“失败模式”而不是“平均分”平均分很容易掩盖问题。一个模型平均分85但失败的那15%全是关键任务那它就不适合你。所以我更关注失败模式它在什么情况下会错错得离谱还是错得接近有没有规律常见的失败模式有几类长上下文遗忘前面说的后面忘、指令漂移多轮之后偏离初始要求、格式崩溃要求JSON却输出散文、过度自信错了还说得头头是道。这些在平均分里看不出来但会直接影响可用性。我通常会做一个失败模式表把每次出错的情况记下来跑够一定样本后统计分布。如果某个失败模式占比超过10%我就会重点评估它能不能通过工程手段缓解比如加校验、加重试、拆任务。4.3 成本核算别只看单价成本核算要算总账。除了token单价还要算重试成本失败重试消耗的token、人工校验成本需要人检查的比例、延迟成本等待时间对业务的影响、集成成本接入和调优的人力。我一般会用一个简单的公式有效成本 (token成本 重试成本) / 成功率 人工校验成本。这个公式不精确但能帮你把隐性成本显性化。很多时候单价低的模型算下来有效成本反而更高因为它成功率低、重试多。5. 选型实操我现在的判断框架5.1 先定场景再定指标选型第一步不是看模型是看场景。把你要解决的问题写清楚输入是什么、输出是什么、成功标准是什么、失败代价有多大。然后根据场景定指标而不是反过来。比如做客服辅助成功标准可能是“回答准确且不越权”失败代价是“误导用户”。那指标就应该包括事实准确率、拒答率、越权回答率。而不是只看“回答流畅度”。指标定好了再去测模型方向就清晰了。5.2 分层测试基础能力、场景能力、工程能力我一般分三层测。基础能力看通用理解、生成、推理用公开评测集快速筛。场景能力用自建评测集看它在你的具体任务上表现如何。工程能力看API稳定性、并发、限流、文档质量、错误码是否清晰。这三层里工程能力最容易被忽略但最影响长期使用。我遇到过文档写得含糊、错误码不明确的服务接入成本极高出问题排查半天。也遇到过文档清晰、错误码规范的服务接入顺畅出问题一眼就能定位。这种差异在选型初期不明显但用久了差距巨大。5.3 小流量灰度别一上来就全量选型定了之后不要一上来就全量切换。先小流量灰度跑一段时间观察真实表现。灰度期间重点看线上失败率、用户反馈、成本波动、延迟分布。这些数据比任何评测都真实。灰度期我一般会设一个“熔断阈值”比如失败率超过某个值就自动回滚。这样即使新模型有问题也不会影响整体业务。灰度跑稳了再逐步放量。6. 常见问题与排查技巧实录6.1 跑分高但实测差怎么排查这是最常见的问题。排查思路是先看测试集和真实数据的分布差异是不是真实数据更长、更脏、更多轮。再看prompt是否一致跑分用的prompt可能经过精心设计实测用的prompt可能很随意。最后看解码参数温度、top_p这些设置不同表现差异很大。我一般会做对照实验用同一批真实数据分别用跑分prompt和实测prompt跑看差距有多大。如果差距主要来自prompt那就优化prompt如果来自数据分布那就考虑微调或者换模型。6.2 成本突然飙升怎么定位成本飙升通常有几个原因流量上涨、重试增多、上下文变长、并发超限导致排队。排查时先看监控把成本拆成“成功请求成本”和“重试成本”看是哪部分涨了。如果是重试成本涨了说明失败率上升要查失败原因。如果是上下文变长说明输入变复杂了要考虑截断或者摘要。如果是并发超限说明需要扩容或者限流。我踩过一次坑某服务并发限制很低流量一上来就排队重试导致成本翻倍。后来加了本地队列和限流成本才稳住。6.3 多轮对话“越聊越偏”怎么缓解多轮偏离是常见问题缓解方法有几个定期重述目标每隔几轮把核心要求再说一遍、限制轮数超过一定轮数就重新开始、状态外置把关键信息存在外部每轮注入。我一般会用状态外置把用户意图、已确认信息、待办事项存成一个结构每轮带上这样模型不容易忘。还有一个技巧是角色锚定在system prompt里明确角色和边界减少漂移。但要注意system prompt太长也会稀释注意力所以要精简。6.4 常见问题速查表问题现象可能原因排查方向缓解手段跑分高实测差数据分布差异、prompt不一致对照实验优化prompt、微调、换模型成本飙升重试多、上下文长、并发超限拆解成本构成限流、截断、扩容多轮偏离上下文遗忘、指令漂移检查轮数和prompt状态外置、定期重述格式崩溃解码参数不当、prompt不明确检查温度和格式约束加格式校验、重试延迟波动大排队、限流、网络看延迟分布本地队列、多服务备份7. 一些踩坑之后的个人体会“斩杀线”这个词我现在基本不用了。不是因为它错而是因为它太容易让人偷懒——偷懒去追一个数字而不是去理解自己的场景。我自己的经验是选型这件事没有捷径就是把场景拆细、把评测做实、把成本算清、把灰度跑稳。这四件事做到位比看一百张跑分图都有用。还有一个体会是不要迷信任何单一模型。我现在的工作流里通常会同时接两到三个服务按任务类型路由。简单任务用便宜的复杂任务用贵的关键任务双跑校验。这样既控制了成本又提高了稳定性。多服务备份还有一个好处某个服务出问题的时候可以快速切换不至于卡死。最后说一个很实在的技巧把prompt当代码管理。版本化、可回滚、有测试。很多人prompt改来改去最后不知道哪个版本好用。我一般会用git管理prompt每次改动都跑一遍评测集确认没退化再上线。这个习惯帮我避免了好几次“改了一个词整体效果崩了”的事故。大模型这个领域变化太快今天的热词明天可能就过时了。但有些东西是不变的对场景的理解、对数据的尊重、对成本的敏感、对稳定的追求。把这些抓住不管“斩杀线”怎么变你都不会太被动。 
长河君 · 2026/10/20 19:01:10 · 阅读 1.2k 大模型“斩杀线”被斩杀：选型别追线，追区间
1. 从一句调侃说起大模型“斩杀线”到底指什么“斩杀线”这个词最早来自游戏圈指的是把对手血量压到某个阈值以下一套连招就能直接带走的那条临界线。放到大模型语境里它被借用来形容一种很微妙的心理预期某个模型在某个能力维度上只要跨过某条线就能对同类产品形成“降维打击”让对手没有还手余地。过去一年多这条线被反复提起也被反复“重新定义”。我最早注意到这个说法是在一批评测榜单刷屏的时候。那阵子几乎每隔几周就有人喊“某模型越过了斩杀线”配上一张跑分截图评论区立刻分成两派一派说“这下稳了”另一派说“榜单而已实测再说”。结果没过多久同一批人又开始说“斩杀线被斩杀了”。这个反转本身就很有意思——它说明大家逐渐意识到那条线可能根本不存在或者说它一直在移动。先把概念说清楚。所谓大模型的“斩杀线”通常指三类东西一是能力阈值比如代码通过率、数学推理准确率、长文本召回率跨过某个百分比二是成本阈值比如每百万token的推理价格降到某个区间三是体验阈值比如响应速度、上下文长度、多轮稳定性达到“可日常使用”的水平。这三条线里前两条容易被量化第三条最玄学也最容易被营销话术包装。那“被斩杀了”又是什么意思我的理解是原本被当作“一锤定音”的那条线被现实拆穿了。拆穿的方式有很多种——可能是榜单本身被发现有水分可能是实测场景和跑分场景差距太大也可能是对手用更低的成本做出了接近的效果让“越线”这件事失去了稀缺性。换句话说不是某条线被谁跨过去了而是“用一条线定生死”这套叙事本身被现实斩杀了。这篇文章我想聊的就是这件事。它适合两类人看一类是正在选型、被各种榜单和“越线”说法搞晕的开发者另一类是单纯好奇大模型行业在发生什么、为什么风向变得这么快的观察者。我会尽量把“为什么这条线靠不住”“实测该怎么看”“选型该盯什么”讲透中间穿插一些我自己踩过的坑和常用的判断方法。不吹不黑只讲能落地的部分。2. 斩杀线叙事是怎么被造出来的2.1 榜单、跑分与“一图流”传播要理解“斩杀线”为什么流行得先理解它的传播载体。最典型的载体就是一张跑分图横轴是模型名纵轴是某个指标某个模型一枝独秀旁边配一句“越线了”。这种图传播效率极高因为它把复杂的模型能力压缩成一个数字读者不需要懂技术细节看一眼就能站队。但问题也出在这里。跑分图天然会丢掉三样东西测试集和真实场景的分布差异、推理成本、稳定性。我见过太多这样的情况某个模型在公开测试集上分数很高换到自己的业务数据上表现直接掉一个档次。原因不复杂——公开测试集往往经过清洗题目类型集中而真实业务数据是脏的、长的、带上下文的。用一句大白话说就是“考试考得好不代表干活干得好”。还有一个更隐蔽的问题指标本身可以被优化。比如代码生成任务如果只看“通过率”模型可能会倾向于生成更保守、更模板化的代码牺牲可读性和扩展性来换通过率。数学推理任务里如果只看最终答案模型可能会跳过中间步骤导致过程不可信。这些优化在跑分上体现为“越线”在真实使用中却可能是隐患。2.2 成本线为什么比能力线更容易被“斩杀”相比能力线成本线被“斩杀”的速度更快也更彻底。原因在于成本是可以被工程手段直接压下来的量化、蒸馏、缓存、批处理、更高效的注意力实现每一项都能实打实地降低单位推理成本。当某个模型把价格打到某个区间原本靠“能力越线”建立的优势很快就会被“够用且便宜”稀释掉。我自己的体会是成本线一旦被跨过就很难再退回去。因为用户的心理预期会被锚定既然有人能做到这个价那贵的就是不划算。这跟能力线不一样——能力线可以被“场景适配”绕开成本线是硬碰硬的。所以你会看到很多“斩杀线”叙事最后都落脚到价格上因为价格是最容易比较、最没有争议的维度。但成本线也有陷阱。低价往往伴随着限流、排队、上下文缩水、并发限制这些隐性成本。我踩过一次坑某服务单价极低但高峰期排队严重实际吞吐还不如贵一点但稳定的服务。算总账的时候省下来的钱被等待时间和重试成本吃掉了。所以看成本线不能只看单价要看“有效成本”——也就是在满足你SLA的前提下单位有效产出的成本。2.3 体验线最容易被忽略也最容易被反噬体验线是最难量化的但恰恰是用户最敏感的。响应速度、多轮一致性、长上下文里的“中间遗忘”、工具调用的成功率这些都不太出现在跑分图里却直接决定一个模型能不能被日常使用。我印象很深的一次对比两个模型在同一个问答任务上跑分接近但一个回答干脆利落另一个喜欢绕圈子、加免责声明、重复问题。前者用起来“顺手”后者用起来“累”。这种差异在榜单上看不出来但在实际工作流里会被放大——你每天要跟它交互几十次每次多花十秒一天就是好几分钟一个月就是几个小时。体验线被“斩杀”的方式往往是反噬某个模型靠营销把体验预期拉得很高用户实际用下来发现不稳定口碑迅速下滑。这种反噬比能力线被超越更致命因为它伤的是信任。信任一旦丢了后面再想拉回来成本极高。3. 为什么“一条线定生死”越来越不成立3.1 场景碎片化没有万能模型只有适配模型大模型落地到今天已经很难找到一个“通吃”的场景。写代码、做客服、处理文档、做数据分析、生成营销文案每个场景对模型的要求都不一样。代码场景看重逻辑严谨和长上下文客服场景看重响应速度和话术一致性文档场景看重召回和引用准确数据分析场景看重工具调用和数值计算。这意味着“斩杀线”这个概念本身就站不住——你在A场景越线不代表在B场景也能越线。我见过一个模型在代码任务上表现惊艳换到合同审阅就频繁漏项。也见过一个模型在中文客服场景里非常稳但一到英文技术问答就开始胡编。所以现在我做选型第一件事不是看总分而是把场景拆成具体任务逐个测。3.2 评测滞后榜单永远追不上真实需求公开榜单的更新速度远远赶不上真实需求的变化。一个新场景出现从有人提出需求到形成稳定的评测集中间可能隔好几个月。这几个月里大家只能靠零散的实测和口口相传来判断信息非常不对称。更麻烦的是榜单的题目类型往往偏“标准答案”而真实需求里大量是开放式、多约束、需要权衡的任务。比如“帮我写一份既专业又不失亲切的周报”这种任务没有标准答案榜单根本测不了。所以你会发现很多在榜单上“越线”的模型一到开放式任务就露怯。3.3 成本与能力的动态平衡成本和能力不是两条平行线它们会互相影响。一个模型能力越强往往越贵但工程优化又能把成本压下来。这种动态平衡意味着“斩杀线”的位置一直在变。今天你觉得某个价格是“斩杀线”明天可能就被新的优化方案打破了。我自己的做法是不追线追区间。把可接受的成本区间和能力区间画出来在这个区间里选最稳的而不是选“最越线”的。因为越线的东西往往不稳定而稳定才是长期使用的关键。4. 实测视角怎么判断一个模型是不是“真越线”4.1 自建小评测集比公开榜单更靠谱公开榜单可以看但不能全信。我的习惯是针对自己的业务场景建一个小而精的评测集通常50到200条就够。这些样本要覆盖典型任务、边界情况、容易出错的case、以及你特别在意的维度。建评测集有几个要点。第一样本要来自真实数据不要自己编编出来的样本往往太干净。第二标注要统一最好有明确的评分标准比如1到5分每个分数对应什么表现。第三要留出盲测集不要把所有样本都用来调prompt否则测出来的分数会虚高。我一般会分两轮测第一轮用固定prompt看基础能力第二轮用优化过的prompt看上限。两轮分数差距大的模型说明它对prompt敏感实际使用中需要更多调优成本。4.2 关注“失败模式”而不是“平均分”平均分很容易掩盖问题。一个模型平均分85但失败的那15%全是关键任务那它就不适合你。所以我更关注失败模式它在什么情况下会错错得离谱还是错得接近有没有规律常见的失败模式有几类长上下文遗忘前面说的后面忘、指令漂移多轮之后偏离初始要求、格式崩溃要求JSON却输出散文、过度自信错了还说得头头是道。这些在平均分里看不出来但会直接影响可用性。我通常会做一个失败模式表把每次出错的情况记下来跑够一定样本后统计分布。如果某个失败模式占比超过10%我就会重点评估它能不能通过工程手段缓解比如加校验、加重试、拆任务。4.3 成本核算别只看单价成本核算要算总账。除了token单价还要算重试成本失败重试消耗的token、人工校验成本需要人检查的比例、延迟成本等待时间对业务的影响、集成成本接入和调优的人力。我一般会用一个简单的公式有效成本 (token成本 重试成本) / 成功率 人工校验成本。这个公式不精确但能帮你把隐性成本显性化。很多时候单价低的模型算下来有效成本反而更高因为它成功率低、重试多。5. 选型实操我现在的判断框架5.1 先定场景再定指标选型第一步不是看模型是看场景。把你要解决的问题写清楚输入是什么、输出是什么、成功标准是什么、失败代价有多大。然后根据场景定指标而不是反过来。比如做客服辅助成功标准可能是“回答准确且不越权”失败代价是“误导用户”。那指标就应该包括事实准确率、拒答率、越权回答率。而不是只看“回答流畅度”。指标定好了再去测模型方向就清晰了。5.2 分层测试基础能力、场景能力、工程能力我一般分三层测。基础能力看通用理解、生成、推理用公开评测集快速筛。场景能力用自建评测集看它在你的具体任务上表现如何。工程能力看API稳定性、并发、限流、文档质量、错误码是否清晰。这三层里工程能力最容易被忽略但最影响长期使用。我遇到过文档写得含糊、错误码不明确的服务接入成本极高出问题排查半天。也遇到过文档清晰、错误码规范的服务接入顺畅出问题一眼就能定位。这种差异在选型初期不明显但用久了差距巨大。5.3 小流量灰度别一上来就全量选型定了之后不要一上来就全量切换。先小流量灰度跑一段时间观察真实表现。灰度期间重点看线上失败率、用户反馈、成本波动、延迟分布。这些数据比任何评测都真实。灰度期我一般会设一个“熔断阈值”比如失败率超过某个值就自动回滚。这样即使新模型有问题也不会影响整体业务。灰度跑稳了再逐步放量。6. 常见问题与排查技巧实录6.1 跑分高但实测差怎么排查这是最常见的问题。排查思路是先看测试集和真实数据的分布差异是不是真实数据更长、更脏、更多轮。再看prompt是否一致跑分用的prompt可能经过精心设计实测用的prompt可能很随意。最后看解码参数温度、top_p这些设置不同表现差异很大。我一般会做对照实验用同一批真实数据分别用跑分prompt和实测prompt跑看差距有多大。如果差距主要来自prompt那就优化prompt如果来自数据分布那就考虑微调或者换模型。6.2 成本突然飙升怎么定位成本飙升通常有几个原因流量上涨、重试增多、上下文变长、并发超限导致排队。排查时先看监控把成本拆成“成功请求成本”和“重试成本”看是哪部分涨了。如果是重试成本涨了说明失败率上升要查失败原因。如果是上下文变长说明输入变复杂了要考虑截断或者摘要。如果是并发超限说明需要扩容或者限流。我踩过一次坑某服务并发限制很低流量一上来就排队重试导致成本翻倍。后来加了本地队列和限流成本才稳住。6.3 多轮对话“越聊越偏”怎么缓解多轮偏离是常见问题缓解方法有几个定期重述目标每隔几轮把核心要求再说一遍、限制轮数超过一定轮数就重新开始、状态外置把关键信息存在外部每轮注入。我一般会用状态外置把用户意图、已确认信息、待办事项存成一个结构每轮带上这样模型不容易忘。还有一个技巧是角色锚定在system prompt里明确角色和边界减少漂移。但要注意system prompt太长也会稀释注意力所以要精简。6.4 常见问题速查表问题现象可能原因排查方向缓解手段跑分高实测差数据分布差异、prompt不一致对照实验优化prompt、微调、换模型成本飙升重试多、上下文长、并发超限拆解成本构成限流、截断、扩容多轮偏离上下文遗忘、指令漂移检查轮数和prompt状态外置、定期重述格式崩溃解码参数不当、prompt不明确检查温度和格式约束加格式校验、重试延迟波动大排队、限流、网络看延迟分布本地队列、多服务备份7. 一些踩坑之后的个人体会“斩杀线”这个词我现在基本不用了。不是因为它错而是因为它太容易让人偷懒——偷懒去追一个数字而不是去理解自己的场景。我自己的经验是选型这件事没有捷径就是把场景拆细、把评测做实、把成本算清、把灰度跑稳。这四件事做到位比看一百张跑分图都有用。还有一个体会是不要迷信任何单一模型。我现在的工作流里通常会同时接两到三个服务按任务类型路由。简单任务用便宜的复杂任务用贵的关键任务双跑校验。这样既控制了成本又提高了稳定性。多服务备份还有一个好处某个服务出问题的时候可以快速切换不至于卡死。最后说一个很实在的技巧把prompt当代码管理。版本化、可回滚、有测试。很多人prompt改来改去最后不知道哪个版本好用。我一般会用git管理prompt每次改动都跑一遍评测集确认没退化再上线。这个习惯帮我避免了好几次“改了一个词整体效果崩了”的事故。大模型这个领域变化太快今天的热词明天可能就过时了。但有些东西是不变的对场景的理解、对数据的尊重、对成本的敏感、对稳定的追求。把这些抓住不管“斩杀线”怎么变你都不会太被动。