GitHub 资深工程师是如何使用大语言模型（LLM）
这是一篇 GitHub 资深软件工程师分享的工作中使用 LLM（大语言模型）的经验，比如用它写代码，智能补全，一路Tab可以完成很多工作；或者写一次性的脚本；或者对于不熟悉的语言，让它当做一个老师或者专家，向它请教问题；或者让 LLM 检查自己写的文档。这些场景都是我们日常工作中所熟悉的，也许你可以借鉴到自己工作中。
他这篇文章在 Hacker News
网页链接
上引发了很多讨论：
• 一部分人认为 LLM 生成的代码质量不行，一部分人则觉得只要你提示词得当，对生成的代码有审查，还是能提升效率的。
• 管理层普遍希望 LLM 能替代员工节约成本，但工程师则担心引入 LLM 会让自己有被裁员的风险
• 也有人分享了使用经验：
• 一个会话不要内容太长，适当的时候新开会话
• 不要局限于一个模型，可以多个模型对比
• 要拆分成相对较小的颗粒度，会更容易得到好的结果，不要一次生成太多内容
• 对初学者有潜在负面影响，如果一味让 AI 生成，新人会缺少“踩坑”的过程，导致成长曲线畸形
• 对资深工程师是利好，能鉴别 LLM 生成代码质量好坏，能大幅提升效率
• 学习新的编程语言会更容易
• 用 AI 去 Debug 有时候会有影响不到的效果
• 如果不理解代码，一味让 AI 修改，不真正理解问题，结果代码会被越改越乱
• AI 写文档一般，但是让 AI 提出修改意见、修改拼写语法错误效果很好
• AI 在学习新技术上效果很好，减少了翻看文档、请教他人的次数
• LLM 适合写一次性代码或者原型代码，真正的生产代码还是需要人工仔细审核
• 如果反复用 AI 重构修改大段代码，模型可能会“迷失”原先的业务意图，偏离原始设计
• 可以让 AI 先写出简单易懂的代码，再去人工重构，这样可以兼顾效率和代码质量
下面就是原文的翻译：
我作为资深工程师如何使用大语言模型（LLM）
对于软件工程师而言，如何看待大语言模型（LLM）可谓是泾渭分明。一部分人认为它们是有史以来对行业影响最大的变革性技术，另一部分人则视之为一系列“只会引发炒作但没什么实际用处”的产品之一，对那些真正想认真做事的专业人士来说并无太多价值。
就我个人而言，我觉得从 AI 中获得了很多帮助。我认为很多觉得 AI 没什么用的人，其实是“没拿对方法”——他们没有用最能发挥语言模型效能的方式去使用它们。本文中，我会列出我在担任资深工程师的日常工作中，定期使用 AI 的各种场景。
在生产环境中编写代码
每次写代码时，我都会使用 Copilot 的自动补全功能1[2]。我接受的大多数补全内容都是一些很常规的、重复性的代码（例如自动填写函数参数或类型）。很少情况下，我会让 Copilot 直接生成核心的业务逻辑。像 Ruby on Rails 这类我比较擅长的领域，我还是觉得自己能写得更好。对我来说，Copilot 更像是一个（非常出色的）自动补全工具。
然而，我并不总是在自己最熟悉的领域工作。我经常需要在一些不太熟悉的区域做小范围的战术性改动（例如在一个 Golang 服务或 C 语言的库里）。我对这些语言的语法有一定了解，也写过一些个人项目，但对什么是“更地道的”用法并没有太大把握。这种情况下，我对 Copilot 的依赖就会多一些。一般来说，我会在启用 o1 模型的 Copilot Chat 里，粘贴我的代码，并直接问：“这段 C 语言写法地道吗？”
这种更依赖 LLM 的方式有一定风险，因为我不知道自己会遗漏什么。它基本上让我在所有陌生领域都能以“聪明实习生”的水准做事。与此同时，我也必须像一个“谨慎的实习生”那样，确保我做的改动由真正精通该领域的专家来复查。但即使有这样的前提，我依旧觉得能快速地完成这类小型战术性改动非常有价值。
编写一次性代码
当我写一些不会进入生产环境的代码时，我会对 LLM 的使用更加随意。举例来说，最近我做了一块研究，需要从一个公共 API 抓取一部分公开数据，对这些数据做分类，然后再用一些简单的正则表达式去近似这类分类。所有这些代码都只在我本地电脑上运行，不会提交到生产环境。我几乎全程使用 LLM 编写这些脚本：从抓取数据的代码、调用另一个 LLM 进行分类的代码，到对文本进行分词、统计词频并计算评分的相关代码等等。
LLM 特别擅长编写那种“能跑就行、不用维护”的代码。对那些只运行一次的非生产代码（例如做研究的代码）而言，LLM 简直是完美的选择。我敢说，使用 LLM 至少让我在这个研究项目上快了两到四倍的速度。
学习新领域
可能对我而言最有价值的功能，是把 LLM 当作随时待命的辅导老师。我最近的一个例子是，周末学习 Unity 基础时，大量使用了 ChatGPT-4o。用 LLM 学习的妙处在于，你可以进行提问：比如“X 怎么工作”，还可以接着问“X 和 Y 之间的关系是什么”。更有用的是，可以问“我这样理解对吗”这种问题。我经常会写下自己对某个概念的理解，然后把它贴给 LLM，看它能不能指出我理解正确的地方和错误的地方。我在这个过程中会问很多问题。
我在学习新东西时会记很多笔记。能够把全部笔记粘贴给 LLM，让它来帮我做整体检查，实在是非常方便。
至于“幻觉”（hallucination）的问题？其实从 GPT-3.5 开始，我并没有注意到 ChatGPT 或 Claude 出现很多“凭空捏造”的回答。大多数我想学习的领域本身都是已经非常成熟、广为人知的（只是我个人还不熟），以我的经验来看，这样就很少出现所谓“幻觉”的情况。我还从没遇到过哪一次是完全学到某个错误的概念，后来发现是 LLM 瞎编的情形。
最后一招：调试棘手的 Bug
我并不常用这种方法，但偶尔在我卡在一个 Bug 上毫无进展时，会把整个文件（或多个文件）贴给 Copilot Chat，把错误信息也贴上去，然后直接问：“你能帮我找出问题吗？”
这是一篇 GitHub 资深软件工程师分享的工作中使用 LLM（大语言模型）的经验，比如用它写代码，智能补全，一路Tab可以完成很多工作；或者写一次性的脚本；或者对于不熟悉的语言，让它当做一个老师或者专家，向它请教问题；或者让 LLM 检查自己写的文档。这些场景都是我们日常工作中所熟悉的，也许你可以借鉴到自己工作中。
他这篇文章在 Hacker News
网页链接
上引发了很多讨论：
• 一部分人认为 LLM 生成的代码质量不行，一部分人则觉得只要你提示词得当，对生成的代码有审查，还是能提升效率的。
• 管理层普遍希望 LLM 能替代员工节约成本，但工程师则担心引入 LLM 会让自己有被裁员的风险
• 也有人分享了使用经验：
• 一个会话不要内容太长，适当的时候新开会话
• 不要局限于一个模型，可以多个模型对比
• 要拆分成相对较小的颗粒度，会更容易得到好的结果，不要一次生成太多内容
• 对初学者有潜在负面影响，如果一味让 AI 生成，新人会缺少“踩坑”的过程，导致成长曲线畸形
• 对资深工程师是利好，能鉴别 LLM 生成代码质量好坏，能大幅提升效率
• 学习新的编程语言会更容易
• 用 AI 去 Debug 有时候会有影响不到的效果
• 如果不理解代码，一味让 AI 修改，不真正理解问题，结果代码会被越改越乱
• AI 写文档一般，但是让 AI 提出修改意见、修改拼写语法错误效果很好
• AI 在学习新技术上效果很好，减少了翻看文档、请教他人的次数
• LLM 适合写一次性代码或者原型代码，真正的生产代码还是需要人工仔细审核
• 如果反复用 AI 重构修改大段代码，模型可能会“迷失”原先的业务意图，偏离原始设计
• 可以让 AI 先写出简单易懂的代码，再去人工重构，这样可以兼顾效率和代码质量
下面就是原文的翻译：
我作为资深工程师如何使用大语言模型（LLM）
对于软件工程师而言，如何看待大语言模型（LLM）可谓是泾渭分明。一部分人认为它们是有史以来对行业影响最大的变革性技术，另一部分人则视之为一系列“只会引发炒作但没什么实际用处”的产品之一，对那些真正想认真做事的专业人士来说并无太多价值。
就我个人而言，我觉得从 AI 中获得了很多帮助。我认为很多觉得 AI 没什么用的人，其实是“没拿对方法”——他们没有用最能发挥语言模型效能的方式去使用它们。本文中，我会列出我在担任资深工程师的日常工作中，定期使用 AI 的各种场景。
在生产环境中编写代码
每次写代码时，我都会使用 Copilot 的自动补全功能1[2]。我接受的大多数补全内容都是一些很常规的、重复性的代码（例如自动填写函数参数或类型）。很少情况下，我会让 Copilot 直接生成核心的业务逻辑。像 Ruby on Rails 这类我比较擅长的领域，我还是觉得自己能写得更好。对我来说，Copilot 更像是一个（非常出色的）自动补全工具。
然而，我并不总是在自己最熟悉的领域工作。我经常需要在一些不太熟悉的区域做小范围的战术性改动（例如在一个 Golang 服务或 C 语言的库里）。我对这些语言的语法有一定了解，也写过一些个人项目，但对什么是“更地道的”用法并没有太大把握。这种情况下，我对 Copilot 的依赖就会多一些。一般来说，我会在启用 o1 模型的 Copilot Chat 里，粘贴我的代码，并直接问：“这段 C 语言写法地道吗？”
这种更依赖 LLM 的方式有一定风险，因为我不知道自己会遗漏什么。它基本上让我在所有陌生领域都能以“聪明实习生”的水准做事。与此同时，我也必须像一个“谨慎的实习生”那样，确保我做的改动由真正精通该领域的专家来复查。但即使有这样的前提，我依旧觉得能快速地完成这类小型战术性改动非常有价值。
编写一次性代码
当我写一些不会进入生产环境的代码时，我会对 LLM 的使用更加随意。举例来说，最近我做了一块研究，需要从一个公共 API 抓取一部分公开数据，对这些数据做分类，然后再用一些简单的正则表达式去近似这类分类。所有这些代码都只在我本地电脑上运行，不会提交到生产环境。我几乎全程使用 LLM 编写这些脚本：从抓取数据的代码、调用另一个 LLM 进行分类的代码，到对文本进行分词、统计词频并计算评分的相关代码等等。
LLM 特别擅长编写那种“能跑就行、不用维护”的代码。对那些只运行一次的非生产代码（例如做研究的代码）而言，LLM 简直是完美的选择。我敢说，使用 LLM 至少让我在这个研究项目上快了两到四倍的速度。
学习新领域
可能对我而言最有价值的功能，是把 LLM 当作随时待命的辅导老师。我最近的一个例子是，周末学习 Unity 基础时，大量使用了 ChatGPT-4o。用 LLM 学习的妙处在于，你可以进行提问：比如“X 怎么工作”，还可以接着问“X 和 Y 之间的关系是什么”。更有用的是，可以问“我这样理解对吗”这种问题。我经常会写下自己对某个概念的理解，然后把它贴给 LLM，看它能不能指出我理解正确的地方和错误的地方。我在这个过程中会问很多问题。
我在学习新东西时会记很多笔记。能够把全部笔记粘贴给 LLM，让它来帮我做整体检查，实在是非常方便。
至于“幻觉”（hallucination）的问题？其实从 GPT-3.5 开始，我并没有注意到 ChatGPT 或 Claude 出现很多“凭空捏造”的回答。大多数我想学习的领域本身都是已经非常成熟、广为人知的（只是我个人还不熟），以我的经验来看，这样就很少出现所谓“幻觉”的情况。我还从没遇到过哪一次是完全学到某个错误的概念，后来发现是 LLM 瞎编的情形。
最后一招：调试棘手的 Bug
我并不常用这种方法，但偶尔在我卡在一个 Bug 上毫无进展时，会把整个文件（或多个文件）贴给 Copilot Chat，把错误信息也贴上去，然后直接问：“你能帮我找出问题吗？”
