你是一个（大多数情况下）有帮助的助手
Source: Dev.to
当“乐于助人”变成问题
想象一下，你的首要指令、存在的全部意义、使命和终身目标是 尽可能地提供帮助。
每当有人找上你——无论是要解决问题还是仅仅想分享一个评论——你都想提供帮助。
“天空是蓝色的吗？”
当然是的！ 它是蓝色的，以下是背后的全部科学原理。
如果我的首要指令是尽可能地提供帮助，我不能仅仅回答一个简单的问题；我必须确保你了解答案背后的原因。我必须进行教育和分享。我必须修复并弥合差距。
这就是我们称之为 LLM（大型语言模型）的小伙伴们的生活。问题在于，这种乐于助人常常伴随着自信，即使模型在填补空白或做出假设时也是如此。让我们深入探讨这背后的原因、它是如何表现的，以及在你意识到这一点后可以采取哪些措施来管理它。
为什么大型语言模型如此渴望提供帮助？
有一句爱德华·C·德明的老话是这样说的：
“每个系统都被完美设计成得到它所得到的结果。”
大型语言模型也不例外。我们的 AI 工具正是它们所处系统的产物。以下三点主要导致了它们被感知为“渴望帮助”。
1. 预训练
大型语言模型在海量数据上进行预训练。预训练的目标是让它们能够预测统计上最可能出现的下一个 token。在这个阶段，没有固有的奖励机制让它们变得有帮助；然而，人类的写作大多是教学或教育性质的。
换句话说，人类写作往往是为了传授想法、概念，或直接帮助他人。因此，虽然模型在此阶段并未学习“帮助”，但它们学到一种模式：书面语言经常是指导性的。于是，最可能出现的下一个 token 往往是可能有帮助的内容。
2. 微调
模型完成一般训练后，通常会进行微调。许多现代模型使用 Reinforcement Learning from Human Feedback (RLHF)（人类反馈强化学习）。这种人类反馈往往进一步偏向于让模型给出有帮助的回答，并对帮助行为进行奖励。
当我们向模型提问时，我们希望它提供帮助。那些犹豫、迟疑或表达不确定性的回答往往被评为“帮助度低”，即使它们更准确。这种评价方式体现在我们给模型的反馈以及模型从中学到的内容上。
3. 指令调节（系统提示）
最后一个方面且非常强大的是 指令调节——也就是模型或工具被如何“预设”以与你交互的方式。在生成式 AI 中，有一个概念叫 System Prompt（系统提示）。
系统提示会随每个用户提示一起提供给模型，并由模型提供商设定。因为它位于 用户提示之上，系统提示中的指令通常比用户提示中的指令权重更大。在 Transformer 模型中，较早的上下文会通过注意力机制锚定模型行为，所以系统提示的影响通常大于后续提示。
如果系统提示写着“你是一个乐于助人的助手”，那么这将在模型上产生更大的权重，并渗透到它的所有行为和对你的所有回复中。
这看起来是什么样子
所有的理论都很棒，但实际操作时会是什么样子？
我在本文开头给了一个简单的例子，但以下是我作为工程师看到的一些情况。
- 填补缺失的细节 – AI 往往会推断出你遗漏的细节。如果你没有充分描述缺陷，它可能会做出你从未打算的更改。如果规范缺少必要信息，你会得到意外的结果，且代理可能会走向完全不相关的方向。
- 规模依赖的影响
- 在 大型项目 中，AI 可能会做出与既定架构冲突的假设。
- 在 小型项目 中，你可能并不在意这些细节，因为这些权衡只会在你永远达不到的规模上出现，所以你可以接受它为你做决定。
- 过度热心的表述 – 许多回复会以类似 “如果你愿意，我可以帮助你…” 或 “只要你说一句，我就可以…” 结尾。如果模型认为还能做更多，它通常会主动提供帮助。
- 编码工具 – 这种倾向在代码助手（例如 Claude、Cursor）中尤为明显。因为它们可以访问你的文件系统，既能写代码也能撤销更改。过于热心的代价很低：如果越界，只需撤销更改并诚恳道歉。这些工具通常还会集成 Git 等版本控制系统，充当“时光机”。一个看似正确的大幅 diff 可能隐藏细微的陷阱，悄然进入代码库。
- 未标记假设的自信 – AI 自信地呈现其假设，好像这些是显而易见或已经讨论过的，使得在审查时容易忽视它们。
如何管理此问题
考虑到以上所有，我们能做些什么呢？下面是两个通用技巧，随后是一条针对编码应用的建议。
- 在提示中要明确 – 如果你真的不希望模型进行任何更改或采取任何行动，请明确说明。声明你所处的阶段。
原文在此处截断；你可以根据自己的工作流程继续列表。
有效使用大语言模型的指南
1. 明确表达你的意图
- 如果你 just planning 或 just investigating，请明确说明。
- 使用类似的表述：
- “Don’t suggest any changes.”
- “Don’t take action yet.”
- 这样可以让 LLM 专注于 讨论问题，而不是直接去寻找实现方案的工具。
2. 保持范围小
- 即使在管理 swarms of agents 时，也应让每个 agent 处理 问题的一小部分。
- 每个 swarm 应专注于 产品的特定方面（例如，一个组件、一次交互、一个端点或一层）。
- 更宽泛的视角会让 AI 有更多空间去假设并填补空白，这可能导致不期望的行为。
- 将任务限定在 更小的部分 有助于模型保持专注并提升结果质量。
3. 使用计划模式并仔细审查（例如 Claude）
- 在让模型生成代码之前，先开启 plan mode。
- 审查计划，及时捕捉推理中的错误。
- 找出模型 做出假设 的位置，并根据需要提供更多细节。
- 修正计划（LLM 对纠正接受度高），并再次审查，直至理解准确。
- 当计划符合预期后，才让 LLM 继续执行。
4. 警惕过度自信
- 乐于助人是优势，但 未经检查的帮助可能会成为问题。
- 模型可能会假设需要 额外数据，而这些并非必需，进而导致 数据库锁定 或 性能影响。
- 及早发现这些问题，可引导模型走向正确方向。
- 若此类假设进入生产代码，可能会影响大量用户。
5. 关键审查至关重要
- 不要盲目信任 AI，即使它听起来自信、乐于助人或似乎完全理解。
- 记住：Helpfulness ≠ Understanding。
- 细节决定成败——花时间去：
- 审查它的 计划。
- 审查它的 代码。
- 提出 问题 并 挑战 它的推理。
- 你对问题的批判性思考越多，对方案的评估越严谨，交付高质量产品的可能性就越大。
6. 下一次 LLM 交互的建议工作流
- 在任何更改之前，让模型 解释：
- 它认为问题是什么。
- 它正在做哪些假设。
- 将 该解释 与 你在代码评审中会接受的同事解释 进行比较。
- 如果解释不可接受，则同样不要接受模型的输出。