2026年我作为资深工程师如何使用LLMHow I use LLMs as a staff engineer in 2026
文章探讨了资深工程师在2026年如何利用大型语言模型（LLMs）提升工作效率。作者主要使用Copilot进行智能代码补全，在熟悉度低的领域实施经过专家审核的小型战术性修改，并大量编写一次性研究代码。此外，他频繁向LLM提问以快速学习新主题如Unity游戏引擎，并将LLM作为最后的调试工具。作者强调所有AI生成内容均需人工复核，尤其涉及关键系统时。其核心观点是：LLM应被视为增强人类能力的工具而非替代者，合理使用可显著加速开发流程。
大约一年前，我写了《作为高级工程师，我是如何使用大语言模型的》。以下是去年我为 AI 所做的事情的简要总结：
以下是我去年明确没有使用 AI 的任务：
2025 年 2 月仿佛已是遥远的过去。那时最好的模型还是 OpenAI 的首个推理模型 o1，智能体（agent）勉强能用，但经常陷入僵局或被上下文压缩干扰。自那以后，究竟发生了什么变化？
现在的智能体已经非常出色了
最大的变化在于，我现在会利用大语言模型生成整个 PR，尤其是在我熟悉的领域。一年前，我偶尔会让智能体修改单个文件中的简单变更，如果懒得手动输入的话。有时我会把写好的函数复制到 LLM 聊天窗口中寻求反馈。而现在，我每次改动都从让智能体解决问题开始，通常只需一次编辑就能直接推送 PR。
2025 年底，我频繁打开多个 VSCode 窗口；到了 2026 年初，则改用终端标签页配合 Copilot CLI，特别是在需要同时跨多个仓库进行修改时。如今，我大量使用 GitHub Copilot 应用（每天几十次会话）。
这反映出一种转变：不再需要在智能体运行过程中实时逐行编辑，而是只在最后进行一次整体编辑。早期的智能体容易出错且难以恢复，因此有必要密切关注其思考过程，及时干预、暂停或纠正。而据我的经验，现在的智能体速度太快，大多数错误都能自行修正，反而难以介入。
有时候我甚至不需要做任何修改，可以直接推送变更——虽然这种情况很少见：无论如何，我通常会顺手删掉那些过度注释和其他典型的“LLM 风格”的内容。
我经常快速浏览并评估智能体提出的修改。大多数时候，仅凭“嗯，这不是我想要的”就全盘拒绝。平均而言，初步判断只需三十秒左右。如果看起来还不错，我再深入审查，确保自己理解其逻辑，并确认它确实在做正确的事。对于复杂任务，我常常要拒绝五六次（甚至更多！）智能体的尝试，才会接受一个足够好的版本，或者干脆放弃，自己动手实现。
调查 bug
我在排查 bug 方面对大语言模型的依赖甚至超过了在代码修改上的依赖。2025 年时，我只是偶尔会把 bug 抛给 LLM，碰碰运气看能否快速解释清楚。现在，我会把所有 bug 都交给 LLM（通常是新建一个智能体会话，粘贴 bug 报告），因为它能独立诊断出约 80% 的问题。当前的智能体在追查 bug 方面表现尤为出色，尤其是当你能提供跨多个仓库的视角时。
我依然更擅长处理这类问题。就在上周，我遇到一个棘手的 bug，前前后后用了大约十四次智能体会话，才终于让它搞明白。在这期间和之间，我到底做了些什么？
最终是某个智能体发现了这个 bug。但我仍将其视为我的发现，因为到那时，我已经足够缩小了搜索范围，使得第 14 次智能体会话所面对的问题，远比第一次会话简单得多。换句话说，人类的专业知识在 bug 排查中依然至关重要
编写文档
我几乎总是自己撰写 PR 描述，因为 LLM 往往过度表达，难以准确传达改动背后的核心思想。手动撰写 PR 描述也能向评审者表明我已审阅过代码变更，而不是让他们成为第一个阅读 diff 的人类。只有在改动微不足道且智能体生成的描述仅一句话时，我才不会重写——这时我通常就保留原样
我仍然不用 LLM 来写 Slack 消息、ADR、issue 等。我认为自己对哪些内容重要有更好的判断力，而且我希望传达出这是经过人类思考的内容
尽管我会让每个草稿博客都经过 LLM 反馈，但我从不直接用 LLM 写博客文章。过去 OpenAI 的模型在这方面表现极差，直到最近 GPT-5.5 才达到可用水平。无论是 OpenAI 还是 Anthropic 的模型，仍倾向于弱化我的论点，但我已接受这属于 LLM 的“写作风格”，并选择忽略这部分反馈
测试与配置
现在我还尽量把尽可能多的测试和配置工作交给智能体完成。2025 年时，我有时会要求 LLM 生成一组 curl 命令脚本供我在开发服务器上运行；而到了 2026 年，我只需让智能体去测试我的变更，然后读取它执行过程中产生的日志即可
我不这样处理 UI 相关的测试，部分原因是这类任务更繁琐，另一部分原因是我不信任智能体能敏锐察觉改动带来的微妙视觉与交互体验变化
智能体会主动编写详尽的单元测试，无需我特别指示。但有时我也会请它们为某项变更搭建更广泛的集成测试。如今我认为测试代码成本很低：只要不确定是否有用，我就直接加上（前提是知道它不会不稳定）。当然，LLM 有时也会写出奇怪或不够理想的测试代码——我会阅读以捕捉明显错误，但对它们的审查比对生产代码更宽容
我还会让智能体处理那些令人厌烦的本地配置任务，比如在我机器上调整 nvm 导致 Node 版本切换失败时，我常会打开 Copilot CLI 智能体让它自己搞定。这基本上是对“上网搜索解决方案”的直接替代，而且更快，因为智能体能自行运行简单的 bash 命令来诊断并修复问题
总结
过去十五个月最大的变化在于：智能体现在真的很强了。它们已经从我曾偶尔怀疑使用的工具，变成了我现在频繁使用、仅需轻度监督就能高效工作的伙伴
我的工作核心依然没变：交付项目、做出判断、影响科技公司里的技术决策。但现在，我承接小型工作的范围更广了，只要我能放心交给 AI 代理处理并期望它大致做对，基本上什么活儿我都接。
过去我经常把事情推掉，要么是转手给别人，要么就是干脆说“抱歉，我现在没时间做这个”。现在，我更多时候会说“行”（至少对于风险低的小改动是这样）。
总体来看，我现在使用 AI 的用途如下：
以下是我目前仍不使用 AI 的场景：
在我看来，当前 AI 的核心能力正朝着尽可能多地将工作交给 AI 代理的方向发展，但又不至于越界。很多人其实没有充分利用代理：不让它们去查 bug 或验证修改，或者没有给它们分配足够多的简单任务。另一些人则过度依赖：让他们写本应由人撰写的消息，或信任他们做出需要细致人工审核的大规模改动。自从我上次发文以来，这种平衡更偏向于代理一方，但找到合适的平衡点依然像以往一样棘手。
如果你喜欢这篇文章，欢迎订阅邮件更新以获取我的新帖通知，或在 Hacker News 上分享它。
这里有一篇相关帖子，标签与此文部分重叠。
我是如何用大语言模型学习新领域的 如果你想在 2025 年学习一个新领域，最好的方法之一就是向一个强大的语言模型提问。 这种方法之所以有效，并不是因为大语言模型比普通谷歌搜索结果更聪明，而是因为你能够提出无限个后续问题。我通常先问一个宽泛的问题（比如“Kafka 是怎么工作的？”），然后围绕它提出大量后续问题：既有具体问题，比如“如果 broker 崩溃了会怎样？”，也有确认性问题，比如“听起来 Kafka 依赖客户端来跟踪哪些事件已被处理，对吗？”。我认为这是一种相当直观的学习方式，因为它本质上是在把 LLM 当作一个知识渊博的朋友来对待。继续阅读……
需要完整排版与评论请前往来源站点阅读。