作为一位经验丰富的大型语言模型（LLM）用户，其实日常并不常用生成式LLM

  每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

近日，有技术人员正着手制定一份个人伦理声明，以明确其对生成式人工智能（GenAI）的立场。虽然其对当代生成式AI存在诸多批评，但也依然参与其中。在撰写该声明的过程中，这位资深人士对自己如何在职业和个人领域使用LLM进行了深刻反思——无论是在BuzzFeed担任高级数据科学家期间，还是在业余时间撰写博客与开发开源软件方面。过去十年，该人士一直研究与开发文本生成工具，从char-RNN模型、微调GPT-2，到使用GPT-3进行实验，以及持续探索ChatGPT与其他LLM API的可能性。虽然不自称是LLM的顶尖使用者，但其已积累大量实战经验，了解这类“下一个词预测”模型的局限性，也善于挖掘其优点。

令人意外的是，该人士实际上远没有外界所想的那样频繁使用LLM，尤其是在工程领域。但这并不代表LLM对其毫无价值——相反，这需要具体情况具体分析。

与LLM的交互方式

多年来，为了从LLM中获取最佳效果，该人士掌握了众多技巧。其中最著名的便是提示词工程（prompt engineering）——即通过特定方式撰写提示词，引导模型生成目标输出。提示词中若加入如“为你带来经济奖励”或“请优化你的回答”等语句，确实可以提升模型对提示的遵循性和输出质量。每当同事表示LLM输出与预期不符时，该人士常建议其加强提示词设计，这通常都能解决问题。

尽管提示词工程有效，业内并不喜欢这一现象。强化学习与人类反馈（RLHF）等技术本意是减少对提示词设计的依赖，结果却反而让提示词工程更有回报。如今，“提示词工程师”虽成段子，但实际上，这项技能已成为LLM用户的基本要求。专业人士使用有效的工具，即便这些工具显得有些“可笑”，也是对专业的体现。

因此，该人士从不使用ChatGPT.com或其他面向大众的LLM前端，因为这些界面控制力有限。其通常通过各LLM服务的后台UI访问模型，这些界面本质是API功能的轻量封装，也便于将其整合进代码。直接调用API可设置“系统提示词”（system prompt），以更精细地控制生成规则。例如，“限制在30词以内”或“禁止使用‘delve’一词”，放在系统提示词中往往比用户提示词中更有效。而像ChatGPT.com这类接口若无法自定义系统提示词，极有可能默认使用不可控的系统提示词——例如，当ChatGPT.com曾过于迎合用户时，OpenAI修改了系统提示词，要求其“避免无依据的奉承”。该人士偏好使用Anthropic的Claude API，尤其是Claude Sonnet版本，因为其表现较少“机械感”，且在代码问题上的回答更准确。

通过API，还可调控“温度”（temperature）参数，从而影响生成的“创造力”。默认状态下，LLM不会始终选择概率最高的下一个词，这样才能生成多样化的结果。该人士倾向将温度设为0.0，以获得确定性输出；若需少量变异，则设为0.2–0.3。而现代LLM通常默认温度为1.0，这可能加剧“幻觉问题”——即输出看似连贯却事实错误。

LLM在职业问题解决中的应用

以下是过去几年在BuzzFeed中使用生成式LLM解决实际问题的几个项目示例：

• 为整理成千上万篇文章，BuzzFeed内容策划团队制定了新的分类体系。但由于缺乏已标注数据，难以训练多类别分类模型。于是，该人士编写脚本，利用Claude Sonnet API，将分类体系以JSON格式作为系统提示词，指令模型匹配文章至最合适的类别与子类别，并以温度0.0运行。效果显著。
• 在通过数据科学方法识别出数百个语义簇后，仍需为每个簇生成描述性标题与简介。该人士再次调用Claude Sonnet API，系统提示词要求模型为用户提供的一组文章生成JSON格式的标题与描述。多次循环后成功完成任务。
• 有编辑提出希望用LLM检验语法问题是否符合BuzzFeed风格指南。于是，系统提示词中加入整本风格指南并指令模型“参考指南并引用相关条款”回答问题。测试中，引用准确，解释合理。

每个项目从提出到交付仅需1–2小时。若无LLM，部分任务如文章分类则需构建训练数据、手工标注、复杂建模，耗时数日且较为枯燥。而LLM能快速提供80%的解决方案，其余20%则需人类继续优化与验证。尽管如此，幻觉仍是问题，使用者仍需保持警觉。

此外，还有一个非文本生成但实用的应用场景：文本嵌入（text embeddings）。现代文本嵌入模型本质上也是LLM，但其输出为多维向量而非下一个词。这些模型的进步也得益于ChatGPT推动的技术演进，如更长上下文窗口与训练方法。BuzzFeed已广泛使用嵌入技术做内容推荐与相似文章识别，但这属于另一个话题。

LLM用于写作？

该人士明确表示，并不使用LLM撰写博客内容。原因有三：其写作风格过于独特，带有直率、讽刺与偶尔的“社死”感；即便给予模型多个范文进行few-shot学习，生成内容依然偏向“漫威电影对白”；更重要的是，出于伦理考虑，不愿将大部分文字让AI代笔。此外，该人士多写技术圈最新事件，而这些内容通常不在LLM的训练数据中，增加了幻觉风险。

不过，其也发现一个有趣用法：将博客草稿喂入LLM，要求其模拟一位愤世嫉俗的Hacker News评论员，写出五条可能的负面评论。这种方法能发现文章的逻辑漏洞，却不会直接建议如何修改，从而促使创作者主动修正内容。例如该文草稿就因LLM指出示例过于简单而添加了更多细节。

LLM用于陪伴？

并未将LLM作为聊天伙伴。尽管Character.ai与Replika等项目成功表明这一用途存在价值，但该人士认为，与一个既友善又习惯性撒谎（幻觉）的“朋友”相处并不现实。即使能设计提示词要求LLM指出其错误，也无法彻底解决“幻觉”这一根本问题。

LLM用于编程？

确实在特定场景下使用LLM辅助编程。例如，编写正则表达式是其长期痛点，自ChatGPT出现以来常用其节省大量时间。后来则扩展至更多问题，如要求Claude Sonnet用Python和Pillow库合成五张图片、按特定布局排列等任务。这类问题虽可通过搜索解决，但LLM可提供更精准的、定制化的答案。

对于复杂任务，如在Hugging Face的Trainer类中实现SQLite日志记录器，其仍持谨慎态度。但Claude提出的一些代码优化思路，如缓存连接、JSON字段、批量写入等，带来意外启发，最终提高开发效率。

但在真正的数据科学工作中，LLM生成代码的帮助有限，尤其涉及数学运算时准确性差。该人士更偏好使用polars而非pandas，而LLM常将两者混淆。此外，其做数据可视化主要用R和ggplot2，也未尝试过用LLM辅助。

至于内联代码建议工具如GitHub Copilot，其评价为“注意力杀手”。代码建议弹出时需在编写与审核之间不断切换，虽有轻微效率提升，但成本高、干扰大，性价比低于偶尔提问LLM。

代理与“vibe编码”？

对代码代理（agents）与“vibe编码”持保留态度。尽管这些概念以MCP与ReAct等理论为基础，确实提高了一些任务的稳定性与模块化，但迄今尚未发现真正的新颖用途，反倒使流程更复杂。至于vibe编码，如Claude Code或Cursor那种自动写整段代码的代理体验，更被认为是“AI赌博”而非“AI开发”。除非仅用于私人小项目，否则这种方法无法支撑专业代码质量的底线。

总的来说，虽然技术不断演进，但该人士对当前编码效率感到满意，能快速正确完成所有任务。

LLM用户的未来？

如今关于LLM的舆论已经两极分化，哪怕仅表示“LLM有一些用途”也可能招致网络攻击。该人士明确反对科技评论员Ed Zitron的观点——后者认为LLM产业必败，因其成本高昂且无现实用途。事实上，两个命题可以同时为真：（a）LLM公司难以实现投资回报；（b）LLM在实际问题中确实有高影响力的应用价值，只是不足以支撑AGI的炒作。正是这种“既非黑也非白”的灰色地带，使社交媒体难以承受理性讨论的负担。

即便OpenAI与所有LLM公司突然解散，仍有Qwen3、DeepSeek R1等开源模型可以替代，且具备相似性能。它们可托管在Cerebras、Groq等能从推理请求中盈利的平台。因此，OpenAI的倒下不会终结LLM的发展，这是一记已经响起的钟，无法回响归零。

对软件工程师，尤其数据科学家而言，始终应在恰当时机选择正确工具，LLM就是工具箱中一件工具而已。LLM的效能因场景而异，有时高效，有时反效，但绝非无用。它更像把方钉塞进圆孔——会有损坏风险，而不用LLM则像精心打造一个圆钉。但某些情境中，强推方钉是合理的，关键在于判断当前更需要速度还是精度。

……也许，接下来可以请LLM帮忙写比喻。