大语言模型（LLM）可以被用来做什么？

日复一日地，帮我们写文章、编码、甚至给予陪伴……

实际上，在具有丰富 LLM 使用经验的资深用户 Max Woolf 看来，我们可能根本不需要那么频繁地使用 LLM。Max Woolf 是全球性媒体和科技公司 BuzzFeed 的高级数据科学家，从事人工智能/机器学习工具和开源项目研究，对现代生成式 AI 的多个方面持批评态度。

在他看来，agent 和 MCP 本质上就是 2022 年 ReAct 论文提出的“工具范式”的新包装；至于使用 Claude Code 或 Cursor 等编码 agent 进行氛围编码，他甚至连尝试的欲望都没有。

图｜Max Woolf

他认为，人们应该在适当时使用正确的工具，而 LLM 只是工具箱中的一种工具。根据使用时间和地点的不同，LLM 可能会产生效果，也可能产生反效果。

在一篇近期发表的个人博客中，他详细论述了为什么他作为一名经验丰富的 LLM 用户，其实并不经常使用 LLM。原文如下：

最近，我一直在撰写一份个人声明，阐述我对生成式 AI 的立场，因为我对生成式 AI 的多个方面持批评态度，尽管我也参与其中。在撰写这份声明的过程中，我一直在反省自己是如何在担任高级数据科学家的专业工作中，以及在撰写博客和编写开源软件的个人工作中利用 LLM 的。大约 10 年来，我一直在研究和开发有关文本生成的工具，从 char-rnns，到微调 GPT-2 的能力，再到基于 GPT-3 的实验，甚至更多的基于 ChatGPT 和其他 LLM API 的实验。虽然我不敢声称自己是现代 LLM 的最资深用户，但在克服下一个 token 预测模型的缺点方面，我已经积累了丰富的经验，且非常善于发现其优点。

结果出乎我的意料，我并不像人们认为的工程师那样经常使用 LLM，但这并不意味着 LLM 对我毫无用处。这是一个需要具体情况具体分析的问题。

我与 LLM 是这样互动的

多年来，我尝试了各种方法来从大语言模型（LLM）中获得最佳效果。其中最知名的技巧是“提示工程”（prompt engineering），也就是通过特定方式撰写提示词，引导模型生成符合特定约束的输出。这类技巧包括：在提示中加入“给予模型经济奖励”之类的内容，或者简单地告诉模型“请优化你的输出”等，确实在提升模型对提示的遵循程度和输出文本的质量方面，有显著的积极效果。每当同事问我为什么他们得到的 LLM 输出不如预期时，我都会建议他们加强提示工程，而这几乎总能解决问题。

在 AI 领域，没有人真正喜欢提示工程，我尤其如此。尽管人们尝试通过更鲁棒的 RLHF 方法来减少对提示工程的依赖，但反而令其变得更加重要——因为这让 LLM 更容易对提示做出精准响应。虽然“提示工程师”作为一个职位已经成为了一个网络模因，但如今它几乎已经成为所有认真使用 LLM 的人必须掌握的一项基本技能。提示工程确实有效，作为专业人士，就该用有效的工具，哪怕它看起来有点“愚蠢”。

因此，我从不使用网页版 ChatGPT 或其他面向大众的 LLM 前端界面，因为它们更难控制。我更倾向于使用每个 LLM 服务提供的后端界面，它们本质上是对 API 的轻量封装，同时也便于将提示逻辑迁移到代码中。通过直接访问 LLM API（如 ChatGPT API），你可以设置系统提示，从而控制可能非常微妙的生成“规则”。在系统提示中指定生成文本的具体约束条件，如“不超过 30 个字”或“绝不使用'delve'一词”，往往比在网页版 ChatGPT 的用户提示中更有效。如果某个 LLM 界面不允许你显式设置系统提示，那它多半是在背后使用了你无法控制的默认提示。举个例子，当网页版 ChatGPT 出现过对用户过度奉承的问题时，OpenAI 修改了系统提示，要求 ChatGPT“避免毫无根据或过度谄媚的奉承”。我个人更偏爱使用 Anthropic 的 Claude API，尤其是 Claude Sonnet，因为从经验上来看，Claude 的回答显得“机器人腔”更少，处理编程问题也更准确。

此外，使用 API 还可以控制“temperature”参数，它决定了模型生成的“创造性”。默认情况下，LLM 并不会每次都选择概率最高的下一个 token，这样可以让生成结果具有一定的多样性。我更喜欢将 temperature 设置为 0.0，以获得尽可能确定性的输出；如果希望输出有一些变化，则会设为 0.2 至 0.3。如今很多 LLM 的默认 temperature 是 1.0，而我推测这种较高的 temperature，会加剧“幻觉”问题——即模型生成的内容在逻辑上连贯，但在事实层面却是错误的。

我用 LLM 解决专业问题

现在，我可以谈谈过去几年我在 BuzzFeed 使用生成式 LLM 的一些案例。以下是我使用 LLM 快速解决问题的若干项目概览（这只是众多项目中的一部分）：

BuzzFeed 网站引入了一种新的分层分类法，将数千篇文章归入指定的“类别”和“子类别”中。由于我们手头没有带标签的数据，无法训练传统的多类分类模型来预测这些新标签，因此我编写了一个脚本，向 Claude Sonnet API 发送系统提示：“以下是分类法：返回与用户提供的文章最匹配的类别和子类别。”我也使用了以 JSON 格式呈现的完整分类体系，并将文章元数据作为用户提示，把所有 temperature 设置为 0，以获得最精确的结果。对所有文章循环运行这个脚本，最终成功地为它们打上了合适的标签。

在使用数据科学方法识别出 BuzzFeed 文章的数百个不同语义集群后，我发现没有一种简单的方法可以给每篇文章都贴上独一无二的标签。我又写了一个脚本，向 Claude Sonnet API 发送系统提示：“返回适用于用户提供的所有文章的 JSON 格式的标题和描述”，用户提示部分则提供该聚类中的 5 篇文章：同样，对所有聚类循环运行脚本，结果非常好。

一位 BuzzFeed 作者曾问我是否有办法使用 LLM 来检查语法问题，比如“我是否应该在这里使用破折号？”是否符合 BuzzFeed 的风格指南。我又一次使用了 Claude Sonnet API，这次我在系统提示中复制/粘贴了完整的风格指南，并加上了一条命令：“参考所提供的风格指南来回答用户的问题，并引用回答问题时所使用的具体规则。”在测试中，源输入中的引文准确无误，推理也前后一致。

这些项目大多是在晨会或 Slack DM 上随口提出的想法，但每一个都只用了一两个小时就完成了概念验证（包括测试），并交给相关负责人进行评估。对于分层标注这样的项目，如果没有 LLM，我就需要进行更复杂的研发，很可能要花费数天时间，包括通过手动标注来建立训练数据集。而 LLM 确实可以遵循帕累托原则，让我完成 80% 的工作，找到可行的解决方案，其余 20% 则是花在反复测试、迭代优化与收集反馈上。即使在模型输出变得更加可靠之后，LLM 的幻觉仍然是一个令人担忧的问题，这就是为什么我也提倡我的同事们在 LLM 输出出现异常时要小心谨慎，并与人工反复确认。

另外还有一种 LLM 的用法虽然不涉及文本生成，但在我的工作中同样具有价值：文本嵌入。从技术上讲，现代文本嵌入模型也是 LLM，只不过它的 head 不是输出下一个 token 的对数，而是输出一个数字向量，在一个更高的维度空间中唯一地识别输入文本。ChatGPT 革命对 LLM 的所有改进，如更长的上下文窗口和更高质量的训练方法，也同样适用于这些文本嵌入模型，并使它们得到了大幅改进，如 nomic-embed-text 和 gte-modernbert-base。我们用文本嵌入来识别相似文章、构建推荐系统等。

用 LLM 写文章？不

不，我没有使用 LLM 撰写这篇博客。我怀疑这已经是人们在阅读由资深 LLM 用户撰写的文章时的默认假设。我的博客风格太奇怪了，LLM 根本无法模仿。我的写作风格直率、不恭敬，偶尔还会让人感到难堪：即便我使用提示工程，给它几篇我过往的文章作为 few-shot 样本，并要求模型精确模仿同样的写作风格，最终输出的内容也更像是漫威电影里的台词。不过，即使 LLM 可以用我的口吻写文章，我还是不会使用它们，因为大部分作品都不是我自己的文字，这有违作者的道德规范。此外，我倾向于写科技/编码界的最新事件，而这些事件在 LLM 的训练数据中即使有，也不会有很强的代表性，这就增加了产生幻觉的可能性。

不过，我发现了一种愚蠢的技巧，可以让 LLM 在不参与我写作的情况下改进我的写作：把我基本完成的博文文本提供给 LLM，让 LLM 假装成一个愤世嫉俗的 Hacker News 评论者，根据博文写出五条不同的评论。这种方式不仅能暴露我文章中较弱的论点，便于我提前思考如何回应负面评价，而且它并不会直接告诉我该怎么改内容，我得自己动脑去解决问题。在通过 Claude API 运行这篇博文的粗略草稿和 Hacker News 系统提示时，它指出我在 BuzzFeed 使用 LLM 的例子过于简单，与传统自然语言处理技术相比没有任何创新，因此我进行了编辑，详细阐述了 NLP 如何无法达到同样的效率或效果。

向 LLM 寻求陪伴？不

不，我也不会把 LLM 视为友好的聊天机器人。character.ai 和 Replika 等 LLM 个人伴侣初创公司取得的成功足以证明 LLM 的用途，即使这种用途只是娱乐/治疗，而不是更功利的。

我承认我和他们不同，因为把 LLM 当作朋友是最常见的使用案例。撇开我自己是个内向的人不谈，要和一个被训练得尽可能友好，但又因为幻觉而习惯性撒谎的实体做朋友也很难。我可以让一个 LLM 来指出我的错误，而不仅仅是给我积极的肯定，但撒谎的问题是无法解决的。

将 LLM 用于编码？

是的，我确实会用 LLM 来写代码，但只在我确信它真的能提升效率时才会使用。从最初的 ChatGPT 开始，我就请 LLM 帮我写正则表达式，光是这一点就已经帮我省下了不少时间，说来有点惭愧。不过，如今 LLM 在编码中的作用已经远远超出了这一范畴，而如何高效使用 LLM 辅助编程，本身就是个更复杂、更具争议性的话题。

像大多数程序员一样，我在谷歌上搜索编码问题，然后点击第一个看起来相关的 Stack Overflow 结果，直到我决定开始向 Claude Sonnet 询问同样的编码问题，并得到更加详细和定制的结果。对于需要特定功能限制和软件框架的问题，这种情况更为明显，而这些问题的组合很可能不会出现在 Stack Overflow 的答案中。我在写另一篇博文时向 Claude Sonnet 提出了问题：用 Python 的 Pillow 库合成五张图像，左半边是一张图，右半边是另外四张图拼起来。用 Pillow 合成多张图片并不难，Stack Overflow 上也有很多相关的问题/解决方案，但合成的具体方式很独特，需要一些定位技巧，我第一次尝试时很可能会搞砸。但 Claude Sonnet 的代码基本正确，而且很容易测试，这就节省了我调试的时间。

不过，对于更复杂的问题，尤其是围绕从 Stack Overflow 和 GitHub 搜来的代码示例较少的不太流行的库，我对 LLM 的输出更为谨慎。举个真实例子：我需要在训练模型的过程中，把详细的指标记录进数据库，以便后续可视化分析——我用的是 Hugging Face transformers 提供的 Trainer 类。我问 Claude Sonnet：请为 Hugging Face 的 Trainer 写一个 Python 回调类，在每一步训练中将当前 epoch、耗时、损失值等元数据记录进本地 SQLite 数据库。

考虑到网上关于自定义回调的代码示例并不多，我原本并不抱太大希望，但 Claude 给出的代码倒是实现了一些我当时没想到的细节，比如设置缓冲区减少阻塞 I/O、优化 SQLite 配置、批量插入以及连接管理。我又对它说了两次“优化代码”，结果它提出了更多意料之外的建议，比如缓存 SQLite 连接、用 JSON 类型的单列来存储任意数量的指标数据等，还把代码风格改得更 Pythonic。虽然这段代码太长，几乎不可能在真正的训练循环中直接运行，但它提供的这些想法本身就非常有价值，相比我从零写一个 SQLite 日志器，这样“基于 AI 起草再修改”的方式更快，也更可能写出高质量代码。

不过，在我日常工作中最花时间的数据科学环节，LLM 的代码生成其实没那么好用。LLM 无法可靠地输出数学运算的文本结果，有些 API 可以通过允许代码解释器执行数据提取、转换、加载（ETL）和分析来解决这个问题，但考虑到我通常要处理的数据规模，这样的工作流程并不划算。虽然 pandas 是在 Python 中处理表格数据的标准，自 2008 年以来就一直存在，但我一直在专门使用相对较新的 polars 库，而且我注意到 LLM 往往会将 polars 函数当成 pandas 函数，这就需要深入文档进行确认，这变得很烦人。在数据可视化方面，我完全不使用 Python，而是使用 R 和 ggplot2，我真的从没想过求助 LLM，再加上我怀疑 LLM 是否真的掌握这两个工具。自 2017 年以来，我用于数据可视化的技术一直未变，制作图表时最耗时的问题是判断数据点是太大还是太小，而不便人眼阅读，这不是 LLM 能帮上忙的。

当然，问代码问题只是 LLM 编程辅助的一个方面。另一个主流用法是使用带有内联代码建议的编码助手，如 GitHub Copilot。尽管我成功地使用 LLM 解决了一次性的编码问题，但实际上我并不喜欢使用编码助手，一点都不夸张地说：它会分散我的注意力。每当我看到 Copilot 弹出代码建议时，我就不得不从编写代码切换到审查代码，然后再切换回来，这让我无法集中注意力。总的来说，它带来的生产力提升非常有限，而且价格还贵，不如直接在网页界面上问问 LLM 划算。

现在，我们可以谈谈 agent、MCP 和氛围编码。agent 和 MCP 本质上就是 2022 年 ReAct 论文提出的“工具范式”的新包装。在这一范式中，LLM 判断是否有必要使用工具来回答用户输入，提取相关元数据并运行工具，然后返回结果。由于上下文窗口大小的提高和提示遵循能力的提升，agent 工作流确实变得更可靠了，MCP 的标准化也比原始的“工具调用”更好。但问题在于，它们并没有解锁任何新的用例——这些功能早在 LangChain 出现时就已经能实现了。甚至现在 MCP 的实现比当年还更复杂、更容易令人困惑。到目前为止，我还没找到任何让我觉得“必须用 agent”的实际场景，过去没有，现在也没有。

至于使用 Claude Code 或 Cursor 等编码 agent 进行氛围编码，我甚至连尝试的欲望都没有。从纸面上看，编码 agent 应该可以解决我对 LLM 生成的代码可靠性的担忧，它们能自检并处理整个项目的上下文。不过，我也听说过一些“踩坑”经历，有人不小心花了几百美元，结果没解决任何问题。氛围编码确实可以帮我完成 80% 的目标，我同意它在构建快速个人应用程序方面的价值，这些应用程序要么不会公开发布，要么会在发布时注明“按现状发布”的免责声明。但是，在严肃的项目中，以“氛围编码”为借口，在明知代码不达标的情况下发布代码是不专业的。我只会为那些我亲手验证过、完全理解其实现方式的代码负责。

当然，编码领域一直在变化，我上面说的都是我目前使用 LLM 的情况。我完全有可能在 Hacker News 上看到一篇文章，彻底改变我对氛围编码或其他人工智能编码工作流程的看法。但就目前而言，我自己的编程效率挺高，基本都能又快又准地完成任务，我也乐在其中。

下一步是什么？

关于 LLM 及其在社会中角色的讨论，已经严重分裂到了只要你说出“LLM 有一些用处”这样极为中立的表述，都可能招来一顿网络骚扰的地步。我非常不同意 Ed Zitron 的观点，他认为 LLM 行业之所以注定要灭亡，是因为 OpenAI 和其他 LLM 提供商无法获得足够的收入来抵消其巨额成本，因为 LLM 在现实世界中没有任何用途。

我认为有两个看似矛盾的说法其实可以同时成立：(a) LLM 提供商的成本经济学过于消极，无法为投资者带来正向的投资回报率；(b) LLM 对于解决有意义和高影响的问题非常有用，尽管并不像 AGI hype 那样能够证明 (a) 的正确性。这种特殊的组合产生了一个令人沮丧的灰色地带，而当今被意识形态撕裂的社交媒体，已经无法优雅地处理这种复杂的讨论了。

假设一下，如果 OpenAI 和其他所有 LLM 提供商突然倒闭，再也没有更好的 LLM 模型被训练和发布，那么与 ChatGPT 相当的开源和宽松许可模型就是有效的替代品，它们可以托管在像 Cerebras 和 Groq 这样的专门 LLM 托管提供商上，而这些提供商实际上可以从每个用户的推理查询中赚钱。OpenAI 的倒闭不会导致 LLM 的终结，因为 LLM 在今天仍然有用，而且市场对它们的需求永远不会为零。

作为一名软件工程师，尤其是一名数据科学家，我这些年学到的最重要一点是：在合适的时候使用合适的工具。而 LLM，只不过是工具箱里的又一个工具。根据你使用的时间和场景不同，LLM 既可能提高生产力，也可能适得其反——但它绝不是“没用”的东西。

LLM 更像是你试图把一个方钉子硬塞进一个圆孔里——可能会损坏钉子或洞口；而不用 LLM，自己解决问题就像是先精心打磨出一个圆钉，然后顺利通过圆孔。但在某些情况下，强行把方钉塞进圆孔、出了问题再补救，反而是更快的迭代方式；而另一些时候，你就必须谨慎对待钉子和孔的形状，确保两者都不被损坏，否则你还得花额外的时间和金钱去修补。

……也许我以后该请 LLM 帮我写比喻。

原文链接：https://minimaxir.com/2025/05/llm-use/