LLM输出人性化是愚蠢的

# 让LLM输出人性化是个蠢主意 对我来说，判断AI工具文化和情绪转向的最大信号通常是X、病毒式传播的GitHub仓库和Hacker News。 最近我经常看到的一个信号是像 [I have ADHD](https://github.com/ayghri/i-have-adhd) 这样的技能，以及 Agents.md 指令，例如 [只使用ASD-STE100简化技术英语](https://x.com/levelsio/status/2086046112142545061) 来输出。 我理解这种吸引力——没有人真正喜欢LLM输出的冗长和那些特定怪癖。但我真的认为，通过让模型人性化来解决这个问题是错误的抽象。 问题在于，这些指令并非在模型完成工作后才应用，而是成为工作本身的一部分。如果你告诉智能体使用短句、避免术语、永远不要让你不堪重负、只包含最重要的细节，你实际上是在要求它不断地将其输出压缩成一种低带宽格式。 这种压缩是有损的。 你可能永远不会注意到丢失了什么，因为输出读起来仍然很流畅。 ASD-STE就是一个很好的例子，因为它听起来非常合理。它旨在让文档*对人类来说*毫不含糊。但智能体不是人类技术写作者，原始状态往往是可用的信息密度最高的表示。与此同时，这些风格规则与“解决任务、正确使用工具、保持抽象、不要破坏任何东西”等指令放在同一个指令列表中。 一旦智能体开始与其他智能体对话，这就变得更加奇怪。 子智能体调查一个 bug，将其发现变成一份漂亮的人类可读摘要，父智能体读取该摘要，然后为你再变成另一份漂亮的人类可读摘要。 如果子智能体运行了六个测试，我不想要： > 大多数测试都通过了，虽然有一个问题值得调查。 我想要： `` 5/6 PASS FAIL: test_cache_invalidation CAUSE: stale key survives restart REPRO: tests/cache_test.py:184 `` 更重要的是，人性化掩盖了失败。 智能体会以有用而丑陋的方式失败：相互矛盾的证据、未解决的分支、堆栈跟踪、不确定的假设。人类散文非常擅长把这些平滑成这样的句子： > 这里有几个考虑因素。 这听起来更好。 但我宁愿发现我的智能体在幻觉或接近其 token 窗口，也不愿对此感到满意。 我们构建的其他每个系统都以相反的方式工作——数据库不会以仪表盘显示数据的格式存储数据，编译器不会让它们的 IR 读起来赏心悦目，API 不会交换友好的摘要。 我们尽可能长时间地保持高保真表示，并在人类消费它的边界处进行转换，但 LLM 工具化正在越来越倾向于反其道而行之。 我们在进化，只是方向反了。 需要说明的是，这些都不是反对可访问性或个性化。 如果你想要三行式回答或简化技术英语，很好！我只是认为最好在最后再做这件事。 让智能体保持详细状态，让子智能体交换模式（schemas）、差异（diffs）、精确错误、置信度、来源（provenance）。然后再为我压缩。 我认为最棒的部分是，这些病毒式传播的技能可能实际上指向了正确的未来。 用户正在提示层修补这个问题，而这个问题本应属于技术栈更下层。 “像我有多动症一样跟我说话”作为一个渲染器完全合理，但作为操作指令就很不合理。持久化的版本应该是：智能体的母语是精确的、面向机器的状态，而温暖、简洁、面向人类的版本只在输出边界生成。 所以那些病毒式传播的仓库不是最终状态，而是一份 bug 报告。