Lazy Prompting 提示词进阶技巧

以下是 Deepseek 对原文 The Benefits of Lazy Prompting 翻译结果，做了少量调整。

注：Lazy Prompting 是属于进阶技巧，需要一定的使用经验作为前提。另它还有很多不适配的场景，需要谨慎使用。

---

亲爱的朋友们：

与常规建议相反（通常认为应该为 LLM 提供充分的上下文以确保成功），我发现有时偷懒反而更高效 —— 快速抛出一个不精确的提示词，先看看会发生什么。这种做法的关键在于能否快速评估输出质量，从而决定是否需要补充更多上下文。本文将分享我使用” 懒惰式提示” 的时机与方法。

调试代码时，许多开发者会直接把错误信息（有时甚至长达数页）粘贴到 LLM 中而不加任何指令。大多数 LLM 足够聪明，能自动理解你需要故障诊断与修复建议，因此无需明确说明。即便是” 编辑这段代码：…” 或 “dotenv 使用示例”（用来提醒使用 Python dotenv 包的写法）这类简短指令，LLM 通常也能给出不错的结果。若响应存在缺陷，你往往能立即发现问题并优化提示，比如调整文本编辑方向。

另一种极端情况是，有时我会花 30 分钟精心撰写两页长的提示，让 AI 系统协助解决原本需要更长时间才能完成的任务（例如编写多页代码）。

我不会采用 Lazy Prompting 的情形包括：(i) 确信缺乏额外上下文时 LLM 绝无可能给出好方案。例如面对不完整的程序需求时，即便是资深人类开发者都难以理解你的意图；又如当我坚持要使用特定 PDF 转文本工具（比如我们 LandingAI 团队的 Agentic Doc Extraction）时，就必须在提示中明确说明，否则 LLM 几乎不可能猜中我的偏好。(ii) 错误实现需要很长时间才能被发现的情况。例如若唯一验证方式是耗时地运行代码检查功能，那还不如提前花时间补充上下文，提高 LLM 生成理想结果的概率。

需要说明的是，Lazy Prompting 属于进阶技巧。我观察到更多人常犯的错误是给 LLM 的上下文不足而非过多。只有当你已掌握提供充分上下文的技巧后，才有资格尝试” 偷懒”—— 刻意减少上下文来测试最低需求边界。此外，该方法仅适用于能通过网页 / 应用界面快速迭代的场景，不适用于需要反复调用 API 的编程式提示（毕竟你不会检查每个输出并持续优化）。

感谢正在与我合作开发开源项目 aisuite 的 Rohit Prsad 提出 “Lazy Prompting” 这个术语。这让人联想到计算机科学中的” lazy evaluation”—— 只在真正需要特定结果时才调用函数。懒惰式提示同理，我们仅在必要时才向提示中添加细节。

持续创造吧！

Andrew