正文
直到我阅读到吴恩达老师最近的推文（见后面的正文），真的有共鸣，而且名字起的非常好。Lazy Prompting——懒提示。程序员们都知道懒加载，就是直到明确要用了才加载。
提示词也是，直到真的要用了再写。
正文
Contrary to standard prompting advice that you should give LLMs the context they need to succeed, I find it's sometimes faster to be lazy and dash off a quick, imprecise prompt and see what happens. The key to whether this is a good idea is whether you can quickly assess the output quality, so you can decide whether to provide more context. In this post, I'd like to share when and how I use "lazy prompting."
与标准提示建议相反，标准建议是应该给大语言模型（LLMs）提供成功所需的上下文，但我发现有时候偷懒一下，快速写一个不太精确的提示，看看会发生什么，这样做更快。这种做法是否合适的关键在于你能否快速评估输出质量，从而决定是否需要提供更多上下文。在这篇文章中，我想分享我何时以及如何使用"懒提示"。
When debugging code, many developers copy-paste error messages — sometimes pages of them — into an LLM without further instructions. Most LLMs are smart enough to figure out that you want them to help understand and propose fixes, so you don't need to explicitly tell them. With brief instructions like "Edit this: …" or "sample dotenv code" (to remind you how to write code to use Python's dotenv package), an LLM will often generate a good response. Further, if the response is flawed, hopefully you can spot any problems and refine the prompt, for example to steer how the LLM edits your text.
在调试代码时，许多开发人员会将错误信息——有时是好几页——复制粘贴到LLM中，而不提供进一步的指示。大多数LLM都足够聪明，能够理解你想要它们帮助理解并提出修复方案，所以你不需要明确告诉它们。使用简短的指令，如"编辑这个：..."或"sample dotenv code"（提醒你如何编写使用Python's dotenv包的代码），LLM通常会生成良好的响应。此外，如果响应有缺陷，希望你能发现任何问题并完善提示，例如引导LLM如何编辑你的文本。
