// 末尾没培训广告，真干货分享，可放心食用 
软件工程师对大语言模型（LLM）的看法太割裂了。
许多人认为它是行业有史以来最具变革性的技术，另一些人则觉得这不过是又一个仅靠炒作的产品：听起来激动人心，但对试图完成严肃工作的专业人士来说最终并无实际用处。
就个人而言，我从 AI 中获益良多。我认为许多持不同看法的人可能“使用方式不对”，也就是说，他们没有以最有效的方式使用 AI。
在这篇文章中，我将分享作为一名资深工程师（staff engineer），在日常工作中定期使用 AI 的几种主要场景。
英文作者 Sean Goedecke 目前在 GitHub 就职的程序员。
一、编写生产环境代码
我每次写代码时都会用 Copilot 自动补全功能。几乎所有我接受的补全内容都是完全模板化的代码（比如填充函数参数或类型）。
我很少让 Copilot 生成业务逻辑，但偶尔也会这么做。在我熟悉的领域（比如 Ruby on Rails），我确信自己能比大语言模型做得更好，它只是一个（非常优秀的）自动补全工具。
但我并非始终在熟悉的领域工作。当需要在较陌生的领域（如 Golang 服务或 C 语言库）进行小规模策略性修改时，我虽然了解语法，也用这些语言做过个人项目，但对“惯用写法”缺乏信心。这种情况下，我会更依赖 Copilot。通常我会启用 o1 模型的 Copilot 聊天功能，粘贴代码后直接询问：“这是地道的 C 语言写法吗？”
不过，过度依赖大语言模型存在风险，因为我可能意识不到自己忽略了什么。这相当于让我在不熟悉的领域达到“聪明实习生”的基准水平，我必须像一个小心翼翼的实习生那样，让该领域的专家同事审核我的修改内容。但即便有这个前提，能快速完成这类策略性修改，依然是高性价比的选择。
二、编写一次性代码
在编写不会进入生产环境的代码时，我对大语言模型的使用更加自由。
例如，最近我做了一项研究，需要从 API 提取公开数据块、进行分类，并通过一系列快速正则表达式对分类进行近似处理。所有代码仅在我的笔记本电脑上运行，而我几乎全程用大语言模型生成了这些代码：包括拉取数据的代码、运行独立大语言模型进行分类的代码、对数据进行分词并统计词频和评分的代码等等。
大语言模型擅长编写“能用但无需维护”的代码，而仅运行一次的非生产代码（如研究用途）正是完美适配场景。可以说，相比独自完成，使用大语言模型让我的效率提升了 2-4 倍。
三、学习新领域知识
大语言模型对我最有用的场景，或许是作为“随叫随到的导师”帮助我学习新知识。
比如上周末，我主要借助 ChatGPT-4o 掌握了 Unity 的基础知识。用大语言模型学习的魔力在于可以连续追问：不仅能问“X 如何工作”，还能接着问“X 和 Y 有什么关联”。
更有用的是，可以问“这样理解对吗”——我经常把自认为学到的内容整理成文字反馈给大语言模型，它会指出哪些正确、哪些仍存在误解。我会向它抛出大量问题。
学习新东西时我习惯记很多笔记，而能直接将笔记复制粘贴给大语言模型进行审核的体验非常棒。
至于“幻觉”问题，老实说，从 GPT-3.5 之后，我很少发现 ChatGPT 或 Claude 出现严重的虚构内容。我试图学习的领域通常已有成熟体系（只是我不了解），而在我的经验中，这意味着“幻觉”概率很低。我从未遇到过从大语言模型学到根本性错误知识的情况。
四、修 Bug 的最后手段
这种情况我不常使用，但有时遇到棘手 bug 时，我会把整个文件或相关文件附到 Copilot 聊天窗口，粘贴错误信息后直接问：“能帮忙看看吗？”
之所以不常用，是因为我认为自己目前比现有的 AI 模型更擅长调试。大多数时候，Copilot（或用于个人项目的 Claude）只会陷入混乱。但如果真的卡住了，尝试一下依然值得——毕竟成本极低。我记得有两三次，模型捕捉到了我忽略的微妙细节，帮我省了大量时间。
由于大语言模型目前在这方面还不够强，我不会花太多时间反复调试，通常只试一次，看它能否直接解决问题。
五、文档校对（拼写和逻辑错误）
我会撰写大量文档，如架构决策记录、技术总结、内部报告等，但我从不允许大语言模型代笔。一方面是因为我认为自己能写得比现有模型更清晰，另一方面是我不太喜欢 ChatGPT 的“AI 文风”。
不过，我偶尔会把草稿输入大语言模型请求反馈。它们很擅长捕捉拼写错误，有时还会提出有趣的观点，促使我修改草稿。
和调试一样，我不会反复迭代。通常只请求一轮反馈。模型往往会给出一些风格化建议，而我一般会忽略这些。
总结
我使用大语言模型的场景：
- 在不熟悉的领域进行小规模策略性修改（需经领域专家审核）
目前不会使用大语言模型的场景：
网友评论
Sean 小哥的这篇文章，写于 2 月份，在 Hacker News 上也是引发了热议。摘录几个：
jppope
我的体验类似：大语言模型很适合生成模板代码、实现自动补全，但在复杂任务上开始失灵，在业务逻辑层面几乎起不到作用（它又怎么能理解业务呢？）——总体而言非常有用，但短期内绝不可能取代合格的从业者。
大语言模型确实也能超快速产出一些企业文档……不过或许我们需要重新评估这种"效率"的真实价值了。
n144q
我同意文中的许多观点，尤其是关于一次性非生产代码的部分。我曾让 ChatGPT 编写工具代码，体验非常好。有一次，它为一个临时任务生成了 Go 代码，第一次运行就完全符合预期，而如果我自己写的话，至少要花 30 分钟——大部分时间都浪费在查阅不熟悉的 API 上。还有一次，它生成了一个 HTTP 服务器，只需稍作调整就能使用。我简直不敢想象没有大语言模型的日子会怎样。
文中未提及的一点是代码审查。大语言模型在这方面表现不算出色，常常指出琐碎或不存在的问题。但即使它在 10 条建议里只有 1 条真正能改进代码，这依然值得一试——毕竟大多数人类代码审查者也无法注意到代码中的所有问题。
pgm8705
我曾经认为大语言模型只是出色的自动补全工具或 Stack Overflow 替代品，直到我从 VSCode 切换到 Cursor。Cursor 中集成 Sonnet 的代理模式（agent mode）仅凭提示就能生成相当出色的内容。在我看来，这比 VSCode 提供的任何 AI 工具体验都要好得多。我认为，这类工具若能搭配有经验的开发者进行引导并监督输出，可大幅提升生产力。
我同意文中观点，即大语言模型在处理复杂任务或理解独特业务逻辑时会力有不逮，但它确实能做的远不止生成模板代码。
toprerules
作为一名同行资深工程师（staff engineer），大语言模型在编写或教授"地道代码写法"方面表现糟糕。事实上，由于初级到高级工程师们纷纷试图混入大语言模型生成的垃圾代码，我现在需要花费比以往更多的时间进行代码审核。
在我看来，使用 LLM 来写代码，你会学到糟糕的开发习惯，依赖代码数量、模板化内容和不确定的输出结果，而这些全都是拙劣软件工程的标志。除非机器学习能够真正实现从需求到产品的端到端自动化并取代我们所有人，否则放弃亲自读写代码，就无法培养作为人类工程师的核心直觉。
我并非完全否定大语言模型的价值：它们在激发创意或探索不可信的信息知识库时确实有用。但直接使用大语言模型生成的代码纯粹是疯狂之举——除非你正在构建的东西真的会被彻底抛弃并从头重写。同理，将其作为代码检查、调试工具或事实来源同样不可靠。
- EOF -
