Hacker News 中文摘要

RSS订阅

人性化LLM输出是愚蠢的 -- Humanising LLM Outputs Is Dumb

原文链接 | HN讨论 | 2026-08-11 07:07:31

文章摘要

文章指出，通过指令让AI模型“人性化”输出（如简化语言、避免术语）是错误做法，因为这种压缩会丢失信息密度，而原始输出往往包含最完整的信息。

文章总结

好的，这是根据您的要求，对原文主要内容进行的中文重述，保留了核心细节，并删减了与主题无关的表述。

标题：让AI输出更“人性化”其实很蠢

判断AI工具文化风向的指标通常是X平台、热门GitHub仓库和Hacker News。最近，我注意到一些流行趋势，比如“我有ADHD”这样的技能提示，以及要求AI用“简化技术英语”输出的指令。

我能理解这些做法的吸引力——没人喜欢AI输出那种冗长和古怪的腔调。但我认为，通过让模型“人性化”来解决这个问题，是找错了方向。

问题在于，这些指令并非在模型完成工作后应用，而是成为了工作流程的一部分。如果你要求AI使用短句、避免术语、不要让你感到信息过载，你实际上是在要求它持续地将输出压缩成低带宽的格式。这种压缩是有损的。你很可能从未注意到丢失了什么，因为输出读起来依然通顺。

“简化技术英语”就是个很好的例子，它听起来很合理，本意是让文档对人类而言更清晰。但AI不是人类技术作者，其原始状态往往才是信息密度最高的形式。而风格规则却与“解决问题、正确使用工具、保持抽象、不破坏任何东西”等核心指令并列。

当AI开始与其他AI对话时，这种做法的弊端就更加明显。一个子AI调查了一个bug，将发现整理成一份漂亮的人类可读摘要；父AI读取这份摘要，再为你生成另一份漂亮的人类可读摘要。如果子AI运行了六项测试，我想要的不是“大部分测试通过，但有一个问题值得关注”，而是：

5/6 通过 失败: test_cache_invalidation 原因: 陈旧键在重启后仍然存在 复现: tests/cache_test.py:184

更重要的是，“人性化”会掩盖失败。AI的失败方式往往是有用且“丑陋”的：相互矛盾的证据、未解决的分支、堆栈跟踪、不确定的假设。而人性化的语言非常擅长将这些平滑成“这里有几个需要考虑的因素”这样的句子。这听起来更舒服，但我宁愿发现我的AI在胡言乱语或接近其上下文窗口限制，也不愿被这种“舒服”所蒙蔽。

我们构建的其他所有系统都是反其道而行之的：数据库不会以仪表盘显示的形式存储数据；编译器不会让其中间表示变得易于阅读；API不会交换友好的摘要。我们尽可能长时间地保留最高保真度的表示，只在人类消费的边界进行转换。但当前的LLM工具链却越来越倾向于反向操作。

需要澄清的是，这并非反对可访问性或个性化。如果你想要三行字的答案或简化技术英语，那很好！我只是认为，最好在最后一步再做这件事。让AI保持详细的状态，让子AI交换模式、差异、精确错误、置信度和来源。然后，再为我进行压缩。

有趣的是，这些病毒式的技能提示可能恰恰指向了正确的未来。用户正在提示层进行修补，而这个问题本应属于更底层的堆栈。“像对待ADHD患者一样跟我说话”作为渲染器完全合理，但作为操作指令则意义不大。更持久的解决方案是：让AI的原生语言是精确的、面向机器的状态，只在边界处生成温暖、简洁、人性化的版本。

所以，这些病毒式的仓库并非最终状态，而是一份“错误报告”。

评论总结

以下是对评论内容的总结，涵盖主要观点和论据，并保持不同观点的平衡性：

观点一：反对LLM输出“人性化”，主张简洁、机器化

  • 主要论据：LLM的冗长、花哨语言（如“flowery language”）导致理解困难，用户需要反复阅读才能理解；人性化输出（如使用名字、情感化表达）显得不专业且多余。
  • 关键引用：
    • “You ever read a work of literature with such flowery language... you pause and realize you have no clue what you actually read” (Xcelerate)
    • “People want the terse, matter-of-fact output. Not the conversational chatty verbose and bloated nonsense” (mikaeluman)
    • “Answer impersonally, objectively and analytically... Do not use emojis” (7402)

观点二：支持人性化输出，认为其有助于理解和接受

  • 主要论据：人性化输出（如友好、自然语言）能提高用户理解效率，尤其对非技术用户；强制简化可能导致信息丢失（lossy），且LLM训练数据以人类语言为主，自然语言更高效。
  • 关键引用：
    • “Humanizing the LLM output is a hedge against agents hitting a wall and someone having to reason through it by hand” (warmwaffles)
    • “Without LLMs humanizing outputs they would not have caught on... The way they answer is way more important than their output for success” (99954bb63ccc)
    • “The training data is predominantly human written sentences... Won’t they do better with human sounding english?” (yellowflash)

观点三：技术性讨论——输出风格与信息保真度

  • 主要论据：强制风格（如简化、代码化）可能导致信息丢失或幻觉；建议采用两步法（先输出再简化）或使用特定技能（如/bro）来平衡简洁与准确。
  • 关键引用：
    • “Forcing a style onto an LLM is lossy... may result in the insertion of new blithering, possibly made up as a hallucination” (Animats)
    • “Seems like something fixable with a simple two step process. Ask it the thing. Then ask it to summarise the answer in simpler terms” (Havoc)
    • “This is why /bro skill works... it becomes part of the same work” (ramoz)

观点四：对LLM输出风格的批评与改进建议

  • 主要论据：LLM输出常带有“谄媚”（sycophantic）或“不专业”风格；用户需要主动提示（如“decompress LLM-speak”）来获得可用输出；建议模型提供更精确、机器可读的接口。
  • 关键引用：
    • “The sycophantic responses are the worst” (agenticworldcup)
    • “I prompt the agent ‘Go back and decompress any LLM-speak... Eliminate deictic language’” (Xcelerate)
    • “The frontier models... should be aiming to be as insanely accurate and precise for machine interfacing as possible” (boredumb)

总结

评论者围绕LLM输出风格展开辩论：一方主张简洁、机器化输出以提高效率，另一方认为人性化输出更自然、易理解。技术层面，讨论聚焦于风格强制对信息保真度的影响，并提出两步法、特定技能等解决方案。整体上，用户对LLM的“谄媚”和冗长风格普遍不满，但承认人性化输出在普及中的关键作用。