作为资深LLM用户，我其实不常使用生成式大语言模型

最近一直在制定关于生成式AI态度的个人伦理声明。虽然对现代生成式AI的某些方面持批判态度，但我仍参与其中。在构思声明时，我反思了作为某机构高级数据科学家，如何将大语言模型应用于专业工作和个人开源项目。

近十年来，从char-rnns到微调GPT-2，再到GPT-3实验，以及ChatGPT等LLM API的测试，我一直在研究和开发文本生成工具。虽然不敢自称最优秀的现代LLM用户，但我在应对下一代token预测模型的缺陷方面积累了丰富经验，并擅长发掘其优势。

出乎意料的是，我使用LLM的频率远低于人们对工程师的想象，但这并不意味着LLM对我无用。这是一个需要具体案例具体分析的话题。

与LLM的交互方式

多年来我运用了所有技巧来优化LLM输出效果。最著名的技巧是提示工程——通过特定方式组织提示词来引导模型生成受限输出。在提示中添加经济激励或直接要求LLM改进输出，确实能量化提升提示遵循度和文本质量。当同事抱怨LLM输出不符预期时，我建议加强提示工程，这通常能解决问题。

AI领域没人喜欢提示工程，尤其是我自己。试图通过更强大的RLHF范式消除提示工程需求，反而因为能实现更好的提示遵循而使其更有价值。确实，“提示工程师”这个职位成了梗，但这主要是因为提示工程已成为LLM严肃用户的必备技能。提示工程确实有效，而专业素养就在于使用有效的方法哪怕它显得可笑。

因此，我从不使用ChatGPT.com等面向普通用户的前端界面，因为它们难以精确控制。我通常直接使用各LLM服务提供的后端UI，这些界面作为API功能的轻量封装，也便于需要时移植到代码中。直接调用ChatGPT等LLM API允许设置系统提示，精细控制生成规则。在系统提示中指定“不超过30个单词”或“禁止使用delve一词”等约束，比在用户提示中声明更有效。任何不允许显式设置系统提示的现代LLM界面，很可能使用了不可控的自定义系统提示。

通过API还能控制生成“温度”——高层面上控制创造力的参数。LLM默认不会选择概率最高的下一个token以保证输出多样性，但我偏好将温度设为0.0实现确定性输出，或0.2-0.3允许轻微变化。现代LLM默认温度为1.0，我认为较高温度会加剧幻觉问题，导致文本内部一致但事实错误。

专业问题解决中的LLM应用

基于上述前提，现在可以讨论过去几年在某机构使用生成式LLM的案例：

分层分类系统
站点策展人开发了新的分层分类法，需要将数千篇文章归类到特定类别和子类别。由于缺乏带标签数据训练传统多分类模型，我编写脚本调用Claude Sonnet API，系统提示声明“以下是一个分类法：返回与用户提供文章最匹配的类别和子类别”，并附上JSON格式的分类体系，用户提示包含文章元数据，温度设为0.0保证精度。循环处理所有文章后获得准确标签。

语义聚类标注
通过数据科学方法识别数百个文章语义聚类后，难以手动为每个聚类生成唯一标签。我编写另一个脚本调用Claude Sonnet API，系统提示要求“返回适用于用户提供所有文章的JSON格式标题和描述”，用户提示包含聚类的五篇文章。循环执行后获得优质标签。

语法检查工具
有作者询问能否用LLM根据风格指南检查语法问题（如“这里该用长破折号吗？”）。再次调用Claude Sonnet API，将完整风格指南粘贴进系统提示，并附加命令“参考提供的风格指南回答用户问题，并引用具体规则”。测试显示引用准确且推理一致。

这些项目都是站会或Slack消息中随手提出的想法，但每个项目仅需1-2小时完成概念验证（含测试）并交付相关方评估。对于分层标注等项目，没有LLM就需要更复杂的研发流程，包括人工标注构建训练数据集，耗时数天且缺乏智力挑战性。LLM确实遵循了二八定律，提供了80%的解决方案基础，但剩余20%的迭代测试和反馈收集耗时更长。即使输出可靠性提升，幻觉问题仍需警惕，因此我建议同事对异常输出保持谨慎并人工复核。

还有一种不涉及文本生成的LLM应用同样重要：文本嵌入。现代文本嵌入模型技术上也属于LLM，但其输出不是下一个token的逻辑值，而是唯一标识文本的高维空间向量。ChatGPT革命带来的所有改进（如更长上下文窗口和更优训练方案）也适用于文本嵌入模型，推动其持续进化。文本嵌入在某机构广泛应用于相似文章识别和推荐模型构建，但本文聚焦生成式LLM故不展开。

写作辅助中的LLM？

不，我不使用LLM撰写博客正文——尽管这已成为读者对资深LLM用户的默认假设。我的博客风格过于独特难以被LLM模仿：行文直率、不拘礼节且偶尔令人尴尬。即使通过提示工程和少样本提示提供现有文章示例并要求精确模仿，LLM输出仍接近漫威电影对话风格。即便LLM能模仿我的声音，出于伦理考虑（大部分内容非本人创作涉嫌 authorship misrepresentation）也不会使用。此外，我常撰写技术/编码领域的最新动态，这些内容在LLM训练数据中占比极低，增加了幻觉风险。

但我发现一种改善写作的巧妙方法：将基本完成的博客内容输入LLM，要求其扮演愤世嫉俗的Hacker News评论员生成五条不同评论。这不仅能识别易受批评的薄弱论点，还不会直接告诉我如何修改内容应对负面反馈，迫使我自己有机解决问题。将本文草稿和Hacker News系统提示通过Claude API运行时，它指出某机构的使用案例过于简单，未超越传统NLP技术范畴，因此我增补了说明NLP效率不足的内容。

情感陪伴中的LLM？

不，我也不将LLM用作友好聊天机器人。Character.ai和Replika等LLM伴侣创业公司的爆发式增长足以证明其应用价值，哪怕只是娱乐/治疗而非实用功能。

我必须承认自己是异类，因为将LLM视为朋友是最常见用途。且不论我的内向性格，很难与一个被训练得极度友好但因幻觉习惯性撒谎的实体交朋友。虽然可以通过提示工程让LLM指出我的错误而非一味肯定，但无法解决撒谎问题。

编程辅助中的LLM？

是的，我在编码中使用LLM，但仅当确信能提升效率时。自ChatGPT诞生之初，我就用LLM编写正则表达式——仅此一项就节省数小时，尽管承认这点有些尴尬。如今LLM在编程中的角色已远不止于此，但如何最佳利用LLM辅助变得更具争议性。

和多数程序员一样，我曾通过谷歌搜索编码问题并点击首个相关Stack Overflow结果，直到开始向Claude Sonnet提出相同问题并获得更详细定制化的答案。对于需要特定功能约束和软件框架组合的问题，这种优势更明显——Stack Overflow往往没有现成解决方案。最近在撰写另一篇博客时，我曾要求Claude Sonnet“使用Pillow库编写Python代码将五张图像合成为单张图像：左半部分为一张图，右半部分为剩余四张图”。用Pillow合成多图并不困难，Stack Overflow也有相关解答，但特定合成方式需要精确定位，首次尝试容易出错。Claude Sonnet的代码基本正确且易于测试，节省了调试时间。

但对于复杂编码问题（尤其涉及冷门库时），我对LLM输出更加谨慎。实际遇到的一个需求是在模型训练时向数据库记录详细指标（使用Hugging Face transformers的Trainer类），便于后续可视化分析。我要求Claude Sonnet“为Hugging Face transformers库的Trainer类编写Python回调类，将每步训练元数据（如当前周期、步长时间、损失值等）记录到本地SQLite数据库”。由于关于自定义回调的代码示例稀少，我本不抱太大期望，但Claude生成的代码提出了我未曾想到的有用方案：限制阻塞I/O的缓冲区、SQLite配置优化、批量插入和连接处理。两次要求“改进代码”后（何乐而不为？），又出现了SQLite连接缓存和使用JSON列类型存储任意指标等意外方案，同时代码更符合Python风格。虽然这些代码需要在实际训练循环中测试，但即使存在缺陷，其创意本身极具价值——基于生成代码修改比从头编写SQLite记录器更高效且质量更高。

在日常工作的核心数据科学任务中，LLM代码生成用处有限。LLM无法可靠输出数学运算结果，部分API通过代码解释器实现数据ETL和分析来规避此问题，但鉴于我处理的数据规模，这种工作流成本效益不高。虽然pandas是Python中操作表格数据的标准库（2008年问世），但我专使用较新的polars库，注意到LLM常将polars函数幻觉为pandas函数，需要深入查阅文档确认，十分烦琐。在数据可视化方面（完全使用R和ggplot2而非Python），我从未想求助LLM，也怀疑LLM能否同时掌握这两个框架。自2017年以来我的可视化技术未变，最耗时的问题是调整数据点尺寸以确保人类可读性——这超出了LLM的能力范围。

提问编码问题只是LLM辅助的一方面。另一主要用途是GitHub Copilot等行内代码建议工具。尽管成功利用LLM解决一次性编码问题，我却因意外原因不喜欢编码助手：它分散注意力。每当Copilot弹出建议，我不得不从编写代码切换到审查代码再返回，破坏专注度。总体而言，它带来中性生产力提升但净成本为负，因为Copilot比通过Web界面临时提问昂贵得多。

现在可以讨论焦点话题——智能体、MCP和氛围编程——我的观点比较犀利。高层面上，智能体和MCP是2022年ReAct论文推广的工具范式的重新包装：LLM可判断是否需要工具来响应用户输入，提取相关元数据传递给工具执行后返回结果。此后上下文窗口大小和提示遵循度的快速进步提高了智能体工作流可靠性，MCP标准化相比普通工具是客观改进。但它们并未开启LangChain几年前问世时没有的新用例，如今简单的MCP工作流实现反而比当时更复杂难懂。我个人始终未找到智能体的新颖应用场景。

对于Claude Code或Cursor等编码智能体的氛围编程，我甚至缺乏实验欲望。理论上，编码智能体应能解决我对LLM生成代码可靠性的担忧，因其具备自检能力并能整合整个代码项目上下文。但我也听闻过有人意外花费数百美元却未解决编码问题的恐怖故事。实验代码生成与赌博代码生成只有一线之隔。氛围编程能完成80%的工作，我承认这对构建快速个人应用（无论是否公开发布）有价值。但以氛围编程为借口在严肃项目中交付明知不合格的代码是不专业的，我只支持自己完全确信实现正确的代码。

当然，编程环境始终在变，以上只是我当前使用LLM的方式。很可能某篇Hacker News帖子会彻底改变我对氛围编程或其他AI编程工作流的看法，但我对现有编码效率感到满意，能快速准确地完成所有编码任务。

LLM用户的未来展望

关于LLM及其社会角色的讨论已足够两极分化，以至于中性声明“LLM有些用处”都会招致谩骂。我强烈反对AI批评者Ed Zitron的观点，他认为LLM行业注定失败是因为某机构等提供商无法赚取足够收入抵消巨额成本，且LLM没有实际用途。两件事可同时成立：(a) LLM提供商成本经济性太差无法给投资者带来正回报；(b) LLM能有效解决有意义的高影响力问题，尽管未达到能证明(a)合理性的AGI炒作水平。这种组合创造了令人沮丧的灰色地带，需要意识形态分裂的社交媒体难以优雅支持的微妙平衡。假设某机构和其他LLM提供商突然崩溃，且不再训练发布更优模型，性能媲美ChatGPT的Qwen3和DeepSeek R1等开源许可模型将成为有效替代品，可由某机构等按查询收费的专用LLM托管服务商部署。某机构崩溃不会终结LLM，因为LLM确实有用，市场需求永远存在——这是无法收回的既定事实。

作为软件工程师（尤其是数据科学家），我学到的重要经验是始终选择合适工具，而LLM只是工具箱中的新成员。LLM可能提升也可能降低效率，取决于使用场景和时机，但绝非无用。LLM更像强行将方钉打入圆孔（可能损坏钉或孔），而无LLM辅助则如同精心打磨圆钉顺利通过圆孔。但对某些圆孔，快速迭代时先强行打入方钉再解决问题是合理的，而有时必须同时精确处理钉和孔以避免损坏，否则需额外耗时费钱修复二者。

……或许以后请LLM帮忙写比喻句也没关系。