开篇先亮观点Humanising LLM Outputs Is Dumb这个说法最近在 LLM 相关讨论里经常出现。我的看法是这句话有一半是对的。LLM 输出里带点拟人感在很多演示场景里确实好看但放到真实工程里过度追求“像人”往往是最不划算的优化方向。它不一定会提升体验反而可能让解析变难、结果变长、错误变多。这篇文章想拆清楚的是什么时候“人性化”有用什么时候真的应该关掉以及怎么用参数和提示词把模型输出调到一个可控的状态。我会先解释“人性化输出”到底指什么然后按任务类型区分场景再给一套可落地的参数和提示词调整方法最后聊一聊怎么评估输出质量。整个过程更偏实操不会只停留在概念层面。1. 先搞清楚“人性化输出”到底指什么1.1 你以为的“像人”和模型实际输出的差别先说一个容易混淆的点LLM 的默认输出本来就自带“人味”。因为模型是在大量自然语言文本上训练的你不加任何约束时它会倾向于给你一句完整的话甚至带点礼貌用语。比如你问“帮我提取这个订单的信息”模型可能直接回复“好的我帮你找到了订单信息订单号是 12345金额是 299 元。”这句话很自然看起来也很“人性化”。但如果你的下游是一个自动记账程序它希望拿到的是干净的字段而不是一句完整的对话。程序解析“好的我帮你找到了”这句话就是灾难。所以这里要区分两个概念拟人化风格包括语气词、礼貌语、自我解释、反问、感叹、过渡句。自然语言能力模型能理解你的意图并用人类能看懂的话回答。很多人说的“人性化输出”通常指的是前者。但真正有价值的是后者。你把输出搞得越“像人”往往越难程序化处理。1.2 拟人化不等于自然语言自然语言也不等于好输出再往下拆一层。就算输出是给人看的也不一定需要拟人化。举个例子你让模型写一封请假邮件。好的输出应该是开门见山说请假时间说清楚请假原因给出工作交接安排语气礼貌但不过度而不是满屏的“你好呀”“希望你能理解哦”“真的很抱歉打扰你啦”。后者确实有“人味”但读起来很累信息密度太低。我见过很多团队在调提示词时最常犯的错误就是让模型“写得更像真人一点”。结果模型开始加开场白、加结束语、加“如果你有任何问题请随时告诉我”。这些内容放在邮件里没问题放在结构化输出里就是在制造噪音。所以判断一个输出好不好不是看它像不像人而是看它有没有完成任务。2. 哪些场景里过度拟人化真的会拖后腿2.1 结构化任务提取、分类、代码生成第一个要关掉“人味”的场景就是结构化输出。典型任务包括信息抽取从文本里提取人物、时间、订单号、金额分类打标判断用户意图、情感倾向JSON 输出让模型返回配置、参数、对象结构代码生成让模型生成函数、SQL、正则表达式这些任务有一个共同点下游程序会直接消费输出。模型一旦加了“好的”“这个功能可以这样实现”“我帮你分类如下”这类话程序就要多写一堆清理逻辑。我之前遇到过一个项目模型抽取订单状态时偶尔会在结果前面加“抱歉我再看一下”。就是这一句话导致整个数据管道处理失败。后来排查了好久问题不是模型能力不够而是提示词里写了“请以友好方式回复”。所以如果你的任务是结构化输出提示词里最好明确写“不要解释不要寒暄直接输出结果。”2.2 客户服务、创意写作里反而需要“人味”这不是说“人性化”在所有场景里都一无是处。在纯对话场景比如客服机器人、聊天助手、情感陪伴类产品适当的拟人化能显著提升用户感受。用户问“你们为什么扣我钱”如果你让模型直接输出“你于 2025-01-01 消费 99 元”虽然信息准确但用户会觉得冷漠。加上“我帮你查了一下”这种缓冲语体验确实会好。创意写作也一样。你让模型帮你写一个短视频脚本、写一段朋友圈文案如果输出像说明书一样干巴巴效果就很差。这时候需要让模型带一点语气和情绪。问题在于很多团队的默认提示词是“请你像一个温暖贴心的客服”但没定义输出结构。模型就开始自由发挥每句话都带语气词十次回复十个样。这种“人味”是不可控的。2.3 边界判断先问输出给谁消费我总结了一个简单的判断标准可以帮你快速决定要不要保留“人味”首要问题输出是给人读还是给机器读给机器读关闭拟人化限制格式输出 JSON、CSV、纯文本字段。给人读再看用户期望。是希望快速得到答案还是希望得到陪伴感第二个问题如果给人读用户能在 10 秒内找到关键信息吗如果一段客服回复读完还要找重点那就是过度拟人化。比如“亲非常理解您的困惑也非常感谢您联系我们我们已经帮您查看了订单信息您的订单确实已经发货了呢。”这句话里面其实真正的信息只有“订单已发货”。前面全是废话。好的客服回复应该是“您的订单已发货预计 3 日内送达。这是运单号SF1234567890。”不一定要写“相信您能理解”用户需要的是信息不是表演。3. 用参数和提示词控制“人味”的实操方法3.1 最小可跑通测试先固定输出格式在调整任何参数之前先做一个最小测试。这个过程很简单但很关键。建议用一个固定输入跑三种提示词版本无约束版本“请回复以下问题……”带角色版本“你是一位客服助手请回复用户查询。……”带格式约束版本“请回复用户查询要求直接给出结论不超过 50 字不要使用问候语和结束语。”然后对比输出。你会发现第三种提示词已经能解决大部分“太啰嗦”的问题。这一步的作用是建立基线。不要一上来就调 temperature、top_p先把提示词里的目标说清楚。3.2 温度、top_p、惩罚项怎么调如果你已经加了格式约束还是觉得输出太“放飞”再去调采样参数。下面是一组常见参数的作用注意不同框架可能叫法不同。参数作用推荐范围经验temperature控制随机性。越低越确定越高越多样结构化任务 0.1-0.3对话 0.5-0.8不要直接拉满到 1.0容易跑题top_p核采样控制候选 token 的范围0.8-0.9和 temperature 二选一调即可frequency_penalty惩罚重复词越高越不容易复读0.1-0.5用来减少“好的”“嗯”之类的口头禅presence_penalty鼓励讨论新主题越高越愿意换方向0.0-0.3用在头脑风暴场景结构化任务基本不用我自己在跑批量提取任务时一般把 temperature 固定在 0.2 以下。不是因为它一定最好而是这样输出更稳定便于回归对比。如果遇到输出偶尔带几句多余的话可以试试 frequency_penalty 开到 0.3 左右。但不要叠加太猛否则模型会变得很“干”甚至出现语法问题。3.3 系统提示词写法角色、格式、边界一个工程化提示词至少包含四个部分角色定义让模型知道它是谁。任务描述让模型知道要做什么。输出格式让模型知道结果长什么样。边界约束让模型知道什么不能做。我经常用的一套模板是这样的你是一个信息提取助手。 从用户输入中提取字段订单号、金额、商品名称、下单时间。 输出格式为 JSON{order_id: , amount: , product: , order_time: } 不要输出任何解释、问候语和多余内容。如果某个字段不存在填 null。这套模板的重点是“不要输出任何解释”这句话在控制拟人化上特别有效。如果你希望输出偏口语化把约束改成你是一个亲切的客服助手。 直接回答用户问题语气自然避免重复套话。 首句直接给出结论不要使用“好的呢”“亲亲”等过度亲昵表达。你会发现即使不写“不要拟人化”你也能通过限定表达边界来控制“人味”。3.4 批量任务里如何统一输出风格单个问题跑通了下一步就是批量任务。批量任务里最常见的问题不是“像不像人”而是风格不稳定。比如你让模型给 100 条评论写回复。第一条可能很简洁第二条突然开始加“感谢您的反馈”第三条又变成了“非常抱歉给您带来不便”。原因是模型在每个独立请求里都会重新采样提示词里没有足够强的约束。我的经验是批量任务先不用急着调参数先把提示词里的示例给足。可以在提示词里加少量 few-shot 示例请根据用户评论生成回复要求 1. 开头直接回应问题。 2. 如果涉及具体订单先说明处理状态。 3. 结尾不追加多余问题。 示例 用户评论发货太慢了等了一周还没到。 回复您的订单由于物流天气原因延迟预计明天更新物流信息。有了示例模型风格会稳定很多。如果你跑的框架支持后处理还可以在生成之后加一步校验。比如检测输出开头是否包含“你好”“您好”“抱歉”等高频词用正则去掉。或者把输出再次交给模型让模型“精简为 100 字以内”。但这会增加一次调用成本和时间都会翻倍适合对效果要求高的场景。这里需要注意一点不同 LLM 框架对参数支持不一样。有的框架有 top_p有的没有有的框架默认关闭 frequency_penalty。不要因为网上教程写了某个参数就硬往自己环境里套。先确认你的框架支持多少个采样参数再决定怎么调。4. 输出质量评估不要只看“像不像人”4.1 四个判断指标评估 LLM 输出质量尤其是控制“人味”后的结果我建议用四个指标指标说明好结果表现完整性该有的信息有没有字段齐全没有漏项可解析性程序能不能直接消费JSON 合法字段名正确一致性同一类请求下输出风格是否统一多次结果结构相同可读性人读起来是否流畅关键信息突出废话少这四个指标里最容易被忽视的是“一致性”。很多人只看一两个例子觉得“看起来不错”但一跑批量就发现问题。比如模型有时候输出 JSON有时候输出带 markdown 代码块的 JSON。这种不一致会让解析程序时不时出错。4.2 用样例集做回归别靠感觉调我建议准备一个固定的小型样例集不用太大10 到 20 条即可。每条样例都要有明确的“期望结果”和“可接受结果”。期望结果最理想的输出。可接受结果虽然不完美但能解析且信息正确。每次改完提示词或参数至少在样例集上跑一遍记录有多少条达到期望结果有多少条达到可接受结果有多少条完全失败如果一条提示词从“期望 8 条”变成“期望 9 条”就算进步。如果只是某一个 case 变好但其他 case 开始加废话那就是整体变差了。这个流程不复杂但非常有效。它能避免你陷入“调了一下午最后靠主观感觉选了一个版本”的情况。4.3 输出太啰嗦、太正式、太口语化分别怎么改我把最常见的三个问题拆开列一下排查方向输出太啰嗦。先看提示词里有没有要求“详细解释”。如果有改成“直接给结论”。再看输出里是不是频繁出现“首先、其次、最后”这类连接词。可以在提示词里写“不要使用过渡句不要列出步骤除非用户要求”。输出太正式。这通常是角色定义太严肃导致的。把“你是一个助手”改成“你是一个朋友”或者“你是一个有过类似经历的人”。也可以用 few-shot 给一两个偏口语的示例。输出太口语像在演戏。这个往往不是角色问题而是模型在模拟“亲切”。可以在提示词里加一句“语气自然不要过度使用语气词不要出现‘呢’‘哦’‘啦’等词”。你也可以在后处理里用简单的字符串替换把这些高频语气词删掉。真正排查时建议顺序是先看输入是否正常再看提示词是否写清楚边界最后才动采样参数。很多问题不是参数不够好而是提示词里给模型的“表演空间”太大了。5. 我的观点人性化是一个选项不是默认值5.1 什么时候可以打开“人味”如果你的场景满足下面两点可以保留甚至强化拟人化输出直接面向终端用户。内容不是硬数据而是体验的一部分。典型例子是闲聊机器人、情感陪伴类应用、抖音文案生成、小红书风格文案辅助。这些场景里用户要的本来就是一种“有人在和自己说话”的感觉你给一段干巴巴的说明反而不符合预期。但即使这些场景我也不会让模型无约束地自由发挥。我会在提示词里要求“语气友好但保持信息密度”同时规定一个最大长度。这样做是为了避免模型每次回复都像客服话术生成器。5.2 什么时候必须关掉反过来下面这些情况我会强制关闭拟人化后端 API 直接返回给程序数据管道里做字段抽取生成 SQL、代码、配置文件批量生成内容需要统一格式任何需要二次编辑和校验的场景在这些场景里“人性化”就是噪音。你优化得越好反而可能让下游处理越不稳定。5.3 给新手的落地建议如果你刚开始做 LLM 应用不知道该不该让输出更“像人”我给你一个更稳妥的顺序先不考虑拟人化跑一个最简版本。把输出格式固定在一种结构上。让第三方人物或者程序来解析你的输出看是否顺利。再根据反馈决定是否调整语气和风格。大部分项目在第三步就能发现问题。这时候你会立刻理解很多“人性化”的需求其实是产品需求说得不够清楚导致的。是产品想要一个“温柔客服”但没有定义温柔客服该说什么、不该说什么。把“人味”当成一个需要控制的维度而不是一个加分项。这样你的 LLM 输出才不会变成一个看起来合理、实际很难用的半成品。最后留一个小建议下次你再听到“能不能让输出更像真人”这个需求时先反问一句这个输出最终是给人读还是给机器读如果两边都有就分开处理。给机器的那份保持结构化给人的那份再做二次润色。分开之后两边都能做好你也少踩很多坑。