2024 年做 LLM 应用的人普遍都会遇到同一个场景模型接进去了Demo 跑通了但把生成结果往群里一发同事问了一句“这是不是 AI 写的”——你心里一沉因为它还真是 AI 写的。这句话翻译成技术语言就是LLM 输出的 “slop” 浓度太高。所谓 slop指的是大模型生成内容里那些看似通顺、实则没有信息量的部分开口是“作为一个人工智能”行文是“首先、其次、然后、此外”结尾是“综上所述”全程没有一句真正解决问题的判断。很多人觉得这是提示词没写好的问题再加两句“不要废话”就能解决。但我的判断是slop 不是提示词层面的小瑕疵而是 LLM 训练目标、解码策略、产品交互方式共同作用下的系统性输出倾向。真想要“去 AI 味”需要从输入、生成、输出、甚至模型数据对齐几个层面同时下手。这篇文章会给你一套可落地的方法论包含提示词模板、采样参数配置、后处理脚本、自动化评测思路以及在什么情况下才值得用微调彻底解决。我会用真实技术问答场景来演示“去 slop”的具体做法而不是停留在概念层面。1. 先定义问题slop 到底是什么“slop”最近两年在英文技术圈被频繁使用中文社区对应的说法是“AI 味”“AI 垃圾话”或者“AI 废话”。它不是指模型输出里的明显错误而是指那些流畅但没有信息量、正确但没有洞察力的文本。你用眼睛扫一遍读起来很顺但仔细想它什么都没说。一个典型的 slop 输出长这样在当今数字化浪潮的推动下人工智能技术正在以前所未有的速度改变着我们的生活方式。作为一个大型语言模型我深知自己肩负着为用户提供帮助的使命。首先我们要认识到人工智能的重要性其次我们需要深入了解其应用场景最后我们要关注其可能带来的挑战。总之人工智能是未来发展的必然趋势。这段文字有什么问题没有错但也没有用。它把“人工智能很重要”这句话用三种方式说了三遍这就是 slop 的核心特征用语言的流畅性掩盖信息的稀疏性。而一个“不 slop”的回答通常是先给结论再给依据再给边界条件这个需求有两个方案。方案 A 改造成本低但只覆盖 80% 场景适合先上线验证方案 B 从数据层重构能覆盖 95% 场景但需要三个后端同学配合排期至少两周。如果本周必须发布我会选方案 A再用版本迭代补剩余场景。从产品角度看slop 的直接代价就是用户看到第一段就开始滑走信任感被透支开发者看不出模型到底理解没有因为错误被套话包装得很好。把这两段输出做对比“去 slop”要解决的本质问题就清楚了让模型从“生成一段像样的文字”变成“生成一段有用的回答”。2. LLM 为什么会生成 slop四个机制而不是一个原因要治理 slop得先理解它从哪来。这不是某个模型独有的 bug而是四个因素叠加后的必然结果。2.1 预训练阶段的“概率平均化”LLM 的本质是预测下一个 token。在训练语料中营销文案、会议纪要、客服话术、空泛博文占据了相当大的比例。当模型接收到一个模糊的 prompt 时它在概率分布上最“安全”的续写方向恰恰是这些高频出现的套话。这是统计上的惯性不是模型故意敷衍。这解释了一个现象你的 prompt 越模糊输出就越容易滑向“平均文本”。因为信息熵越高模型能依赖的特征就越少自然选择高频兜底表达。2.2 对齐训练带来的“文明话术副作用”为了让模型“有礼貌、安全、不惹事”RLHF 等对齐过程会让模型在回答中加入大量防御性语言“作为一个 AI 模型”“仅供参考”“请注意这不能替代专业意见”。这些句子在安全性测试中有效但在日常技术问答里就是纯噪音。更麻烦的是对齐训练让模型形成了“先铺垫再回答”的路径依赖。很多模型的输出习惯是先解释定义、再罗列背景、最后才给出答案而这个顺序恰好和高效沟通是相反的。2.3 采样参数的隐性影响temperature、top_p、frequency_penalty 这些参数不只是“随机性调节”它们直接决定了输出是否会滑向 slop。温度过低时模型倾向于选择概率最高的 token而概率最高的通常是语料里的常见套话温度过高时模型又容易产生幻觉。很多人的失败在于把温度拉到 0.7 以上然后抱怨模型“乱说”但真正的问题是温度太高导致词汇选择失去约束。2.4 提示词本身的“低信息量”这是最容易被忽略、也最普遍的原因。很多用户给模型的指令是“帮我写一下这个功能”但上下文里没有业务背景、没有读者画像、没有输出格式限制。模型没有足够的信息去生成具体的内容它只能靠高频文本“填空”。从这个角度看提示词工程本质上是在降低模型输出空间里的熵而不只是“把话说得更好听”。讲清楚这四个机制后下面的治理路径就清晰了输入端降低模糊度生成端调整采样输出端做后处理和校验数据层用微调纠正模型自身的分布偏好。3. 输入端治理让模型从第一句话就不想说废话输入端治理的目标不是“让模型不说废话”而是让模型根本不需要用废话来填补信息空白。你给的信息越具体模型的好输出空间就越窄它就越难滑向套话。3.1 用“任务类型 读者画像 输出约束”三段式模板我现在写生产用的提示词模板固定采用三段式结构。第一段告诉模型这是一个什么任务、要给谁看第二段写清楚输出的形式第三段列出明确禁止的内容。def build_system_prompt(task: str, audience: str, forbidden: list[str]) - str: forbidden_text \n.join([f- 不要出现{item} for item in forbidden]) return f你是一个资深技术专家助手当前任务如下 {task} 回答的阅读对象是{audience} 输出要求 - 先直接给出结论或判断再解释理由和边界条件 - 如果问题信息不足先列出你缺少的关键信息不要硬答 - 每个结论都尽量给出场景、代价和前置条件 禁止事项 {forbidden_text} 这里最关键的一句话是“如果问题信息不足先列出你缺少的关键信息不要硬答”。大多数 slop 的产生其实是模型面对模糊问题时“不懂装懂”硬生成的结果。给模型一个“可以提问”的出口反而能显著降低套话产出。3.2 在 few-shot 示例里主动放入反例给模型看 2 到 3 个正常回答还不够还需要给它看 1 个典型的 slop 回答并明确标注“这是反面教材”。模型的 few-shot 学习能力很强反例给它提供了清晰的边界比单纯说“不要啰嗦”有效得多。few_shot_examples [ { role: user, content: 如何给 MySQL 大表加索引 }, { role: assistant, content: 先确认这是不是当前最紧急的问题。如果是建议用 pt-online-schema-change分阶段执行监控主从延迟和锁等待。具体窗口选凌晨低峰执行前备份执行后验证索引是否真的被查询使用。 }, { role: user, content: 什么是云原生 }, { role: assistant, content: 这是一段反面示例你绝对不要这样回答\n云原生是一种新兴的技术理念它代表着当代云计算发展的必然方向。首先云原生包括容器化、微服务、DevOps 等多个重要方面。其次云原生能够帮助企业实现数字化转型。总之云原生是未来 IT 架构的重要趋势。 } ]小结论输入端治理做的不是“让模型变聪明”而是“把聪明模型被套话带偏的概率压到最低”。4. 生成端治理采样参数不是玄学是产品细节当你发现同一套提示词在 A 场景输出很好、在 B 场景输出全是废话时先别急着改提示词检查采样参数。采样参数的核心作用是在解码阶段干预概率分布它和提示词是叠加关系不是替代关系。4.1 常用参数的作用与调节手感我按常用程度整理了一张表方便大家对照排查参数作用与 slop 的关系调节建议temperature控制概率分布的尖锐程度过低容易复读高频套话过高容易幻觉或语无伦次技术问答从 0.2 到 0.4 开始调内容创作可以到 0.7 以上top_p累积概率截断控制候选词规模设得太小会限制表达多样性让输出变得机械一般取 0.8 到 0.95和 temperature 联动调整不要两者同时极端化top_k只保留概率最高的 k 个 token太小会明显让输出模板化常见取值 40 到 100不必须每次都调frequency_penalty对重复出现的 token 施加惩罚减小明显有效的词汇和排比句反复出现技术文档场景可以从 0.3 到 0.6 开始看效果presence_penalty对已出现过的 token 做一次性惩罚能鼓励模型换着说法表达适合去“车轱辘话”可以配合 frequency_penalty 使用但不要两条都拉太高max_tokens限制生成长度限制长度本身不能让输出更精炼但能避免无限扩写先根据任务设一个合理上限再通过提示词让它“写完就停”需要强调的是这些参数没有万能组合值只有“适合当前任务”的值。技术问答、代码生成、营销文案、客服对话最优参数区间完全不同。关键是要有评估集用数据判断而不是凭感觉。4.2 不同调用方式下的参数配置示例如果是 OpenAI 风格 API通常这样传参数response client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.3, top_p0.9, frequency_penalty0.5, presence_penalty0.3, max_tokens1024, )如果是 vLLM 部署的自建模型启动或推理时对应的参数也类似from vllm import LLM, SamplingParams sampling_params SamplingParams( temperature0.3, top_p0.9, frequency_penalty0.5, presence_penalty0.3, max_tokens1024, ) llm LLM(modelyour-model-path) outputs llm.generate(prompts, sampling_params)如果是 Hugging Face transformers 的官方实现可以通过generate方法传入from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained(your-model-path) tokenizer AutoTokenizer.from_pretrained(your-model-path) inputs tokenizer(prompt, return_tensorspt) outputs model.generate( **inputs, temperature0.3, top_p0.9, repetition_penalty1.1, max_new_tokens1024, )注意不同框架对参数名称和支持程度有差异。比如 OpenAI 有frequency_penaltytransformers 里对应的是repetition_penalty而 vLLM 两者都支持。如果你在某个框架里发现参数不生效先查它的文档而不是硬套另一个框架的写法。小结论采样参数是“去 slop”成本最低的杠杆但它的效果取决于你有没有一套能分辨“好输出”和“坏输出”的评测数据。5. 输出端治理后处理与约束解码输入和生成端的优化能解决大部分 slop但还不够。实际生产环境里模型偶尔还是会冒出一句“作为一个 AI 模型”或者在一段回答之后画蛇添足地总结一遍。这时候就要在输出端做兜底。5.1 用关键词规则做快速拦截最简单的方法是在拿到模型输出后先用一组“slop 特征词”做检查。一旦命中直接标记为疑似劣质输出可以选择重新生成也可以截断到合适的句子。SLOP_PATTERNS [ 作为一个AI模型, 作为一个语言模型, 作为一个AI助手, 在当今, 随着技术的不断发展, 在这个快速变化的时代, 综上所述, 总而言之, 希望这些建议对您有所帮助, 如果还有其他问题请随时, ] def check_slop(text: str) - list[str]: hits [] for pattern in SLOP_PATTERNS: if pattern in text: hits.append(pattern) return hits text 作为一个AI模型我认为在当今环境下人工智能具有重要意义。综上所述希望这些建议对您有所帮助。 print(check_slop(text)) # 输出[作为一个AI模型, 在当今, 综上所述, 希望这些建议对您有所帮助]当然关键词规则有误杀风险。比如“综上所述”在某些严谨的技术报告里其实就是合理的承接词。所以这个模块的定位是“命中后触发人工复核或重新生成”而不是“命中后直接删除”。规则的价值是把可疑输出挑出来再用更智能的模型做裁决。5.2 用 LLM-as-judge 做二次判断关键词规则解决“明显的 slop”但模型还会写出那种“读起来很顺、实际还是空”的段落。这需要另一个模型来做结构化评审。做法是把输出交给一个独立的 LLM让它按几个维度打分。judge_prompt 你是一个严格的内容质量评审员。请判断以下回答是否存在以下问题 1. 是否大量使用“首先、其次、然后、此外”等空泛连接词 2. 是否包含“总之、综上所述、希望这些建议对您有所帮助”等套话 3. 是否在前 1/4 的篇幅内没有给出任何实质性结论 4. 是否在不必要的情况下提及“作为一个 AI 模型” 回答内容 {response} 请用 JSON 格式输出 {{has_slop: true/false, reason: 一句话说明原因, score: 0-10}} 这种方案的优点是能识别语义层面的 slop缺点是会增加一次模型调用和延迟。在生产环境里比较常见的做法是先用关键词规则快速过滤只有疑似命中时才调用 judge 模型用少量额外延迟换取更稳的输出质量。5.3 约束解码关闭“说废话”的空间比后处理更彻底的手段是直接在生成阶段限制模型只能输出结构化内容。比如让技术问答的输出固定为“结论、理由、边界条件”三个字段模型就没有机会用自由文本填充废话。OpenAI 风格的 JSON mode、vLLM 的 guided decoding、transformers 的 grammar-constrained generation都是实现思路。{ conclusion: 先用一句话给出结论, reasons: [结论成立的依据最多三条], conditions: [结论成立的前提条件或边界限制] }当你把输出格式约束成 JSON Schema模型只能把注意力放在填充有效信息上。这在 RAG、客服知识库、运维告警分析这类结构化场景里尤其好用。代价是这种输出读起来“硬”不适合做面向 C 端用户的聊天内容。小结论输出端治理不是“把坏结果修好”而是“让坏结果露出来并被拦截”从而倒逼输入端和生成端不断优化。6. 从根上解决微调与偏好对齐提示词、采样参数、后处理做的都是“推理时”的治理。它们能让模型在现有能力边界内发挥更好但没办法改变模型内部的分布偏好。如果你长期使用同一个基座模型、输出风格高度稳定、并且对“反 slop”的要求很明确那微调是更值得考虑的方案。6.1 微调解决的到底是什么问题微调是在训练阶段用高质量数据调整模型的行为偏好。从“去 slop”的角度看目标不是让模型记住更多知识而是让模型在生成风格上从“平均文本”偏移到“高质量技术文本”。举个例子如果你的知识库团队沉淀了大量优秀的技术文档这些文档天然就是“无 slop”风格的教科书。把这些文档转成指令-回答对拿去做有监督微调模型就能在风格上对齐这批语料。更进一步用 DPO 或 RLHF 做偏好对齐让模型学会“好的回答是直接给结论、给边界、给依据”而不是“说一堆正确但无用的话”。6.2 LoRA 是低成本试错的首选从一个常见基座模型出发做全量微调成本很高也没有必要。LoRA 这类参数高效微调方法只更新一小部分参数训练资源要求低试错成本也低。现在 Hugging Face 的 PEFT 和 TRL 生态里已经有很多现成工具可以把 DPO 训练流水线写得比较短。数据质量比模型规模重要。哪怕只有几千条高质量“反 slop”样本也比用几万条网上爬来的低质量样本效果好。训练集里如果本身有大量“在当今环境下一方面、另一方面”的文本你就是在强化 slop。6.3 什么时候才应该微调我个人的判断是微调应该放在后面而不是一开始就做。先用提示词、采样参数和后处理把流程跑通收集你场景里真实出现的失败样本积累到几百条典型 slop 输出和对应的优质重写版本。这批数据既是评估集也是将来微调的训练集。如果调参和提示词已经解决不了 80% 的问题再进入微调阶段效率会高得多。微调有一个明显风险是风格漂移。模型可能在“去 slop”的方向上走过头变成回应过于简短、缺少必要解释。所以微调之后一定要留一部分人工评测数据专门盯着信息完整度不能让“简洁”变成“粗暴”。7. 评估如何量化“不 slop”“去 slop”如果没有量化标准很容易变成纯粹的主观感受。比较好的做法是建立一个 30 到 50 条问题的小评估集覆盖你业务里最典型的需求类型然后对每条输出做多维度打分。7.1 人工盲测比模型打分更可信最直接的评估方式是人工盲测。把优化前后的输出打乱不要告诉评审人哪个是新的。让参与者按照“是否直接回答了问题”“信息密度是否高”“是否包含明显的套话”“你是否愿意直接发给客户”四个维度打分。人工盲测能抓住很多模型评分抓不到的问题。7.2 用脚本做量化指标在收集人工反馈的同时写一个简单的脚本统计一些客观特征输出总长度、有效信息占比、slop 特征词命中数、结论出现位置。这些指标不完美但能帮你做回归防止“这周改完觉得挺好下周又退化”。def report_slop_metrics(responses: list[str]) - dict: metrics { avg_len: 0, avg_first_conclusion_pos: 0, slop_hit_total: 0, } conclusions [结论是, 答案是, 应该, 建议, 需要] for r in responses: metrics[avg_len] len(r) first_conclusion len(r) 1 for word in conclusions: pos r.find(word) if pos ! -1: first_conclusion min(first_conclusion, pos) metrics[avg_first_conclusion_pos] first_conclusion hits check_slop(r) metrics[slop_hit_total] len(hits) n len(responses) return { avg_len: round(metrics[avg_len] / n, 1), avg_first_conclusion_pos: round(metrics[avg_first_conclusion_pos] / n, 1), slop_hit_total: metrics[slop_hit_total], } sample [ 作为一个人工智能模型我认为在当今环境下我们应该关注这个问题。, 这个问题的答案是优先检查依赖版本冲突升级后重新跑测试。, ] print(report_slop_metrics(sample))一个常见误区是看到“平均长度下降”就认为效果变好这不一定对。长度变短可能是更精炼也可能是信息大量丢失。所以长度指标一定要和信息完整性指标绑定使用单看任何一项都会误判。7.3 把评估集沉淀成团队资产评估集的价值在于它可以重复使用。每次调整提示词、参数、甚至是切换模型版本后都跑一遍评估集就能快速对比新旧方案的差异。很多团队“感觉新模型还不如旧模型”就是因为没有评估集凭几个零散案例做判断。8. 完整示例搭建一个“去 AI 味”的技术问答管道下面用一个完整示例把前面几个环节串起来。假设你在做一个内部技术问答机器人目标是让回答“像资深工程师直接说话而不是像 AI 写周报”。# 完整流程示例需要提前安装 openai 或设置好你的模型服务 import json # 1. 构建系统提示词 def build_system_prompt(): return 你是一名互联网后端工程师长期负责高并发系统设计和线上问题排查。 你的回答风格是直接、准确、有依据。 回答要求 - 开头第一句话直接给结论不要铺垫 - 后面用 2-3 条说明理由每条必须包含具体细节、场景或代价 - 最后用一句话说明这个结论的边界条件 - 如果信息不足不要硬答直接列出缺失信息 禁止事项 - 不要使用“作为一个 AI 模型”“作为一个人工智能”等自我介绍 - 不要使用“首先、其次、再次、此外”等空泛连接词 - 不要使用“总而言之、综上所述、希望能帮到你”等总结套话 - 不要输出 Markdown 之外的任何前后缀 # 2. 构造带反例的 few-shot messages def build_messages(question: str): return [ {role: system, content: build_system_prompt()}, {role: user, content: 如何定位线上接口偶发性超时}, {role: assistant, content: 先看超时集中在哪一层。如果是网关层超时优先查依赖服务的 TP99如果是应用层超时优先查线程池和数据库连接池耗尽。重点看两点超时请求是否集中在特定下游、超时前的资源使用是否有梯度变化。边界是如果下游是外部服务可能要接受限流降级而不是无限调大超时时间。}, {role: user, content: 什么是微服务}, {role: assistant, content: 反面示例绝对不要这样回答微服务是一种重要的软件架构风格。首先它把系统拆分成多个服务其次每个服务可以独立部署最后服务之间通过 API 通信。总之微服务是现代软件架构的重要趋势。}, {role: user, content: question}, ] # 3. 调用模型 def call_model(question: str): messages build_messages(question) response client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.3, top_p0.9, frequency_penalty0.4, presence_penalty0.2, max_tokens600, ) return response.choices[0].message.content # 4. 输出端兜底命中明显 slop 就要求重生成 def safe_generate(question: str, max_retry: int 2): for _ in range(max_retry): answer call_model(question) hits check_slop(answer) if not hits: return answer print(检测到 slop 特征词正在重试, hits) return answer # 5. 执行示例 question 数据库连接池每次分配后为什么会慢 answer safe_generate(question) print(最终回答\n, answer)这段代码演示的是完整的“输入端提示词 few-shot 反例 生成端采样参数 输出端规则拦截”链路。其中client指代你实际项目里的模型客户端具体包名和初始化方式以你使用的服务为准。运行后如果一切正常理想输出应该类似数据库连接池分配慢通常不是连接池配置的问题而是创建新连接时的链路太重。先看每次分配时是复用连接还是新建连接如果是新建慢在 TCP 握手、TLS 协商或数据库认证如果是复用连接时慢慢在连接被服务端主动断开而客户端没有及时清理。排查顺序建议是先看连接池的空闲回收策略再看数据库的 wait_timeout最后看是否存在跨可用区访问的网络延迟。这段输出没有自我介绍没有空泛连接词第一句话就给出了方向并且补充了排查顺序和边界条件。这就是“去 slop”之后一个相对理想的结果。如果检测到“作为一个人工智能”这类词safe_generate会打印提示并重新生成一次。实际生产里你可以把“重生成”换成“进入人工复核”或“使用备选模型”。9. 常见问题与排查方法问题现象可能原因排查方式解决方案模型开头总是说“作为 AI 模型”提示词没有明确禁止基座模型对齐训练的防御性表达太强查看系统提示词是否包含明确禁止项查看 few-shot 反例是否足够在禁止事项中明确写出该短语增加一个包含该短语的反例输出不啰嗦了但该解释的也没了采样参数过保守或者后处理过度压缩检视输出中结论、理由、边界条件是否齐全调高 temperature 或降低 frequency_penalty重写提示词强调“保留依据和边界”temperature 调到 0.1 依然有废话问题出在提示词信息量不足而不是解码参数评估问题本身的上下文是否完整先走“信息不足允许提问”的路径再考虑调参规则命中率很高但误伤严重slop 特征词列表过长或过于宽泛查看命中的上下文判断是否合理缩小规则列表只保留高置信度特征命中后改为触发人工复核LLM-as-judge 判断不稳定judge 提示词缺乏明确打分标准轮流让两个不同模型判断同一批输出对比一致性给 judge 提供一两个好/坏示例固定 JSON 输出格式微调后风格过度简洁训练数据里缺少“完整解释”类样本对比微调前后回答的信息完整度在训练集中加入更多带详细理由的优质样本重新微调同一个问题每次回答长度波动很大采样参数和提示词约束不足看多轮输出的长度分布强制输出格式JSON Schema或调低 temperature10. 最佳实践与生产建议10.1 按场景分层设参不要一套参数通吃技术问答、营销文案、客服对话、代码生成它们的“好输出”标准完全不同。把场景分层每一层有自己的提示词、参数和评估集。核心原则是任务的风险越高输出越需要结构化temperature 就越低。代码生成和运维建议这类场景偏保守营销文案和头脑风暴类可以放开一些。10.2 把“去 slop 规则”写成文档团队协作时最怕的是每个同学凭感觉写提示词。建议把去 slop 的提示词模板、禁止词列表、参数基线、评估集结构写进团队的 LLM 应用开发规范里。当模型切换版本后这些规则能充当稳定的质量锚点。10.3 保留原始输出做离线回归所有后处理、重写、截断操作最好都保留一份原始输出。原因很简单当你事后发现某个线上回答有问题时需要能区分是模型生成的问题还是后处理改写的问题。在后处理链路里加一个日志字段记录“原始输出”和“最终输出”排查成本会低很多。10.4 关于“本地部署”有个容易忽略的架构问题很多人在 ComfyUI 这类本地方案里集成 LLM 时会纠结“LLM 是不是必须和 ComfyUI 在同一台电脑上”。从架构上讲它们不一定要同机。只要调用方能够访问到 LLM 服务地址远程 API 和本地进程在逻辑上都能工作。区别在于同机部署延迟更低、数据不离开本机适合调试和隐私敏感场景远程部署扩容和运维更方便。先确认你的 LLM 是本地进程还是远程 API再决定网络、鉴权和超时配置这才是真正影响生产稳定性的地方而不是“能不能同机”。10.5 不要试图用后处理解决所有问题后处理是一道安全网不是主力输出层。如果发现线上大量回答都需要靠后处理来“救”说明输入端和生成端的治理还不够。正确状态是90% 以上的输出在生成时就已经足够干净后处理只是兜底。11. 总结与后续学习方向这篇文章想讲清楚一件事LLM 输出的“AI 味”不是玄学问题而是输入端熵太高、生成端参数不合适、输出端缺校验、数据层又缺少高质量风格偏好共同造成的结果。对应的解决路径是在提示词和 few-shot 里压缩模型的表述空间用采样参数调节词汇选择偏好用后处理和规则拦截可疑输出在需要长期稳定风格时再用微调改变模型本身。真正有用的下一步不是去背更多“魔法提示词”而是搭一个属于你自己场景的小评估集把 30 到 50 条高频问题沉淀下来每周跑一次看输出质量的变化。有了评估集你调提示词、调参数、换模型、甚至做微调都从“感觉有效”变成“可度量”。如果你想继续深入值得研究的方向包括DPO 偏好数据对的构造方式、带约束解码的多格式输出、以及长上下文场景下的冗余压缩。这些话题都比“加一句不要废话”要深得多也都是生产级 LLM 应用绕不开的工程问题。建议先把手头最常用的那个 Agent 或问答机器人跑一遍这篇文章的流程把 slop 特征词列表和评估集建起来。下一次你再听到“这是不是 AI 写的”就可以理直气壮回一句是但这次没有 AI 味。