2026年我作为高级工程师如何使用LLM

https://seangoedecke.com/how-i-use-llms-in-2026…

2026年AI工作流最大的变化：将代理视为编码、调试、测试和代码库研究的得力协作者——同时仍由人类负责判断、沟通和审查。

2026年我作为高级工程师如何使用LLM

来源：https://www.seangoedecke.com/how-i-use-llms-in-2026/ 一年多以前，我写了《我作为高级工程师如何使用LLM》(https://www.seangoedecke.com/how-i-use-llms/)。以下是我去年使用AI的简要总结：

• 使用Copilot做智能自动补全
• 在不熟悉的领域做出短期战术性改动（总是由领域专家审查）
• 编写大量一次性使用的探索性代码
• 提出大量问题以学习新主题（例如Unity游戏引擎）
• 作为最后手段的bug修复，以防它能立即解决
• 对长篇英文沟通进行宏观校对

以下是我去年明确没有使用AI完成的任务：

• 在我熟悉的领域为我编写整个PR
• 编写ADR或其他技术文档
• 在大型代码库中进行研究并找出问题所在

2025年2月已经是很久以前的事了。当时最好的模型是第一个推理模型——OpenAI的o1。代理勉强能用，但经常卡住或被复杂性打乱。从那以后发生了什么变化？

代理现在很好用

最大的变化是：现在我在熟悉的领域使用LLM生成完整的PR。一年前，我偶尔会让代理修改单个文件，前提是改动简单且我不愿手动输入。有时我会把自己写的函数复制到LLM聊天窗口寻求反馈。但现在，每次改动我都会先让代理解决问题，通常只需一次编辑审查就能推送PR。

2025年底，我经常打开许多VSCode窗口。到2026年初，这变成了终端标签页配合Copilot CLI，尤其当需要同时修改多个仓库时。现在我非常频繁地使用GitHub Copilot应用(https://github.blog/changelog/2026-05-14-github-copilot-app-is-now-available-in-technical-preview/)（每天数十次会话）。

这反映了一个转变：从需要基本上边做边对代理进行逐行编辑，变为只在最后做一次编辑审查。早期的代理经常出错且无法恢复，因此密切关注它们的思考过程并适时介入暂停和纠错很有价值。根据我的经验，当前的代理速度太快，无法做到这一点，而且大多数时候它们自己能纠正错误。

有时我甚至不需要做任何编辑，可以直接推送改动，不过这种情况很少见：至少我会浏览一遍，删除一些过度注释和其他LLM风格的习惯。

我会大量浏览并评估代理的改动。 大多数时候我会直接拒绝，仅仅因为“嗯，这和我设想的不一样”。平均而言，我做初步评估只需大约30秒。如果改动看起来还行，我会深入进行正式审查，确保我理解它并且做了正确的事情。对于困难的任务，我通常会拒绝五到六次（甚至更多！）代理的尝试，直到接受一个足够好的版本，或者放弃并手动修改。

调查bug

我在bug追踪方面对LLM的依赖甚至超过修改代码。2025年，我偶尔会向LLM报告一个bug，以防它能快速给出解释。现在，我每一个bug都会提交给LLM（通常通过打开新的代理会话并粘贴bug报告），因为它能正确诊断80%的问题。当前的代理在追踪bug方面非常擅长，尤其是当你给它们跨多个仓库的视角时。

我仍然更擅长这件事。就在上周，有一个棘手的bug，大约用了十四个代理会话才最终解决。在这些会话之间和周围我在做什么？

• 挖掘关于bug的额外上下文（来自日志、Slack等）并报告给代理
• 当然，建立自己对问题的心理模型
• 并行进行自己的bug复现工作
• 对代理会话回应“不，你的理论不可能是正确的，因为X”，或者直接结束会话并重启，带上那个额外的提示

最终是某个代理找到了bug。但我仍然认为这是自己的发现，因为那时我已经将搜索空间缩小到足够小，使得第14个代理会话需要解决的问题比第1个会话容易得多。换句话说，人类专业知识在调查bug时仍然非常重要。

写作

我几乎总是自己编写PR描述，因为LLM沟通过度且不擅长表达改动背后的“核心思想”。手动编写PR描述也向审查者表明我已经自己审查过改动，而不是要求他们成为第一个阅读代码差异的人。唯一不写PR描述的情况是改动微不足道，且代理生成的描述只有一句话。那时我就直接不管了。

我仍然不使用LLM编写Slack消息、ADR、问题等。我相信自己更清楚什么重要、需要沟通，并且我想传达出有一个人类在思考内容。

我仍然从不用LLM写博客文章，不过我会把每篇草稿发给LLM寻求反馈。OpenAI的模型以前非常糟糕，直到最近GPT-5.5才勉强可接受。OpenAI和Anthropic的模型仍然试图淡化我的论点，但我已经接受这是LLM的“风格”，忽略那部分反馈。

测试和环境设置

我现在做的另一件事是尽可能将测试和环境设置工作推给代理。2025年，我有时会让LLM生成一个curl命令的测试脚本，以便在开发服务器上运行。2026年，我直接让代理去测试我的改动，然后阅读它的操作日志。

我不会像这样测试UI工作，部分因为更繁琐，部分因为我不信任代理能敏感地捕捉到改动中微妙的视觉和交互细节。

代理会自动编写大量的单元测试，但我有时会要求它们为改动组合更广泛的集成测试。总的来说，我现在认为测试代码是廉价的：如果我在想某个测试是否有用，我就会添加它（只要我知道它不会不稳定）。当然，LLM有时会产生奇怪且不令人满意的测试代码——我会阅读以发现明显的错误——但我审查它的眼光比实际的生产代码更宽容。

我还会让代理处理烦人的本地环境设置任务，比如涉及机器上配置调整的任务。例如，如果我的nvm安装没有正确切换Node版本，我通常会打开一个Copilot CLI代理，让它来解决问题。这基本上直接替代了Google搜索问题，而且快得多，因为代理可以运行简单的bash命令来诊断和自行修复问题。

总结

过去十五个月的主要变化是：代理现在真的很好用。它们从我不时怀疑地使用的东西，变成了我持续使用并轻度监督的东西。

我工作的核心仍然是：交付项目(https://www.seangoedecke.com/how-to-ship)、运用判断力、影响科技公司政治(https://www.seangoedecke.com/how-to-influence-politics/)。但我现在有了一张更广阔的小活儿网，愿意接手，基本上包括任何我可以交给代理并期望它大体上正确完成的事情。

过去我花了很多时间推脱工作，要么委托给别人，要么说“抱歉，我现在没时间做”。现在我可以更多地说“好的”（至少对于低风险的小修小补）。1(https://www.seangoedecke.com/how-i-use-llms-in-2026/#fn-1)

总的来说，以下是我现在使用AI的方面：

• 编写（或根据复杂度起草）我所做的每一个代码改动
• 调查和修复bug，对于大多数bug自主完成，对于更棘手的则与我的紧密参与结合
• 在大型代码库中进行研究，因为当前代理已经足够好，几乎总能给出正确答案（而当它们出错时，从解释中也能清楚地看出遗漏了什么）
• 手动测试和本地机器环境设置或故障排除
• 我仍然使用AI提出大量问题来学习主题，以及进行校对

以下是我仍然不使用AI的方面：

• 为我编写任何形式的公开沟通（PR描述、ADR、消息），除了微不足道的两行PR
• 编写未经仔细审查的代码
• 测试任何类型的UI

在我看来，当前核心的AI技能是在不让AI过度介入的情况下，尽可能多地将工作转移到AI代理上。许多人没有充分利用代理：不让它们调查bug或测试改动，或者没有向它们提交足够多的简单任务。另一些人则过度利用：让它们编写本应手写的消息，或者信任它们做出需要仔细人工审查的大规模改动。自从我上一篇文章以来，天平更多地倾向了代理，但找到平衡点仍然一如既往地棘手。

如果你喜欢这篇文章，请考虑订阅(https://buttondown.com/seangoedecke)以获取新文章的邮件更新，或在Hacker News上分享(https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fwww.seangoedecke.com%2Fhow-i-use-llms-in-2026%2F&t=How+I+use+LLMs+as+a+staff+engineer+in+2026)。

以下是与此文章标签相关的预览：

我如何使用LLM学习新主题 如果你想在2025年学习一个新主题，最好的方法之一就是向一个强大的语言模型提问。这个方法之所以如此好，不是因为LLM比普通的谷歌搜索结果更聪明，而是因为你可以提出无限后续问题。我通常从提出一个笼统的问题开始（比如“Kafka是如何工作的”），然后用许多、许多后续问题进行深入挖掘：既包括具体问题（如“如果某个代理崩溃会发生什么”），也包括确认性问题（如“听起来Kafka依赖客户端来追踪哪些事件已处理，对吗？”）。我认为这是一种相当直观的通过LLM学习的方法，因为它本质上就是把LLM当作一个消息灵通的朋友。继续阅读…(https://www.seangoedecke.com/learning-from-llms/)