2026年，我作为职员工程师如何使用LLM

大约一年前，我写了《我作为职员工程师如何用LLM》。以下是去年我使用AI的简要总结：

- 用Copilot智能自动补全 - 在不熟悉的领域做短期战术性改动（总是由领域专家审查） - 编写大量一次性使用的科研代码 - 通过提问学习新话题（例如Unity游戏引擎） - 最后的bug修复，万一它能立刻解决 - 对长篇英文沟通进行全局润色

以下是去年我明确不使用AI的任务：

- 在我熟悉的领域为我编写完整的PR - 编写ADR或其他技术沟通文档 - 在大型代码库中调研并理清事情如何运作

2025年2月已经是遥远的过去。当时最好的模型是首个推理模型——OpenAI的o1。代理虽然能用，但常常卡住或被压缩干扰。自那以后发生了什么变化？

代理现在很好用了

最大的变化是，我现在让LLM在我熟悉的领域生成完整的PR。一年前，我偶尔会让代理修改单个文件，如果那是简单改动且我不想手动输入的话。有时我会把写好的函数复制到LLM聊天窗口获取反馈。但现在，每一项变更我都会先让代理去解决问题，通常只需一次编辑审核就能推送PR。

2025年底，我打开了很多VSCode窗口。到2026年初，这变成了终端标签页加上Copilot CLI，尤其是当需要同时修改多个仓库时。现在我大量使用GitHub Copilot应用（每天几十次会话）。

这反映了从需要伴随代理逐行编辑，变成只在最后做一次编辑审核的转变。早期的代理经常出错且无法恢复，所以有必要盯着它们的思考过程，并介入暂停和纠正。根据我的经验，当前代理运行太快，无法这样介入，而且它们大多数情况下能自行恢复错误。

有时我甚至不需要做任何编辑，可以直接推送原样变更，不过这很少见：至少我会通读一遍，去掉过度注释和其他LLM腔调。

我大量浏览并评估代理的变更。大多数情况下我会直接拒绝，仅仅因为“嗯，这跟我想的不一样”。通常大约30秒就能做出初步判断。如果变更看起来没问题，我会深入进行正式审查，确保理解它且它在做正确的事情。对于困难的任务，我常常拒绝五六次（或更多！）代理尝试，才接受一个足够好的版本，或者放弃并手动修改。

调试bug

对于调试bug，我比做变更更依赖LLM。2025年，我偶尔会把bug抛给LLM，指望它能迅速给出解释。现在我把每个bug都抛给LLM（通常通过打开一个新的代理会话并粘贴bug报告），因为它能独立正确诊断80%的问题。当前的代理非常擅长追查bug，尤其是当给它们跨多个仓库的视角时。

但我仍然比它强。就在上周，有一个棘手的bug，大概花了14次代理会话才最终解决。在这些会话之间和期间我在做什么？

- 挖掘关于bug的额外上下文（日志、Slack等）并报告给代理 - 当然，构建自己对这个问题的心理模型 - 并行建立自己的bug复现 - 回应代理会话：“不，你的理论不可能是对的，因为X”（或者直接终止并重启会话，加上这个额外提示）

最终是代理抓到了这个bug。但我仍然认为这是我自己发现的，因为到那时我已经把搜索范围缩小得足够紧，使得第14次会话要解决的问题比第1次轻松得多。换句话说，调试bug仍然非常依赖人类专家的经验。

写作

我几乎总是自己写PR描述，因为LLM会过度沟通，不擅长表达变更背后的“核心思想”。手动写PR描述也向审阅者表明我已经审查过变更，而不是请他们成为第一个阅读diff的人。只有变更是琐碎的且代理生成的描述只有一句话时，我才不自己写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命令来诊断和修复问题。

总结

过去十五个月的主要变化是代理现在真的很棒。它们从我偶尔怀疑地使用变成了时刻轻监督地使用。

我工作的核心仍然相同：交付项目、运用判断力、影响技术公司政治。但我现在愿意承担的小任务范围大大增加了，基本上任何可以交给代理且预期它能大致正确完成的事情都包括在内。

过去我花很多时间推脱工作，要么委托给别人，要么说“抱歉，我现在没时间做”。现在我更多时候能说“好”（至少对于低风险的小改动是如此）¹。

总体而言，我现在用AI做以下事情：

- 编写（或起草，取决于复杂度）我做的每一项代码变更 - 调研并修复bug，对于大多数bug自主进行，对于更棘手的bug则紧密参与 - 在大型代码库中调研，因为当前代理已经足够好，几乎总能给出正确答案（当它们出错时，从解释中能明显看出遗漏了什么） - 手动测试以及本地机器设置或故障排除 - 我仍然用AI来提问学习新话题，以及润色

以下是我仍然不用AI做的事情：

- 为我编写任何形式的公开沟通内容（PR描述、ADR、消息），除了两行式的琐碎PR - 编写我不仔细审查的代码 - 测试任何形式的UI

在我看来，当前的核心AI技能是尽可能多地把工作转移给AI代理，但不要过度。许多人未能充分利用代理：不让它们调研bug或测试变更，或者不给它们足够多的简单任务。另一些人则过度使用：让它们写本应手写的消息，或者信任它们做需要仔细人工审查的大范围变更。自我上一篇文章以来，天平更多地倾向了代理，但找到平衡点仍然一如既往地棘手。

¹ 这次我总算能给出一个实际的例子，因为它在公开仓库中。有位内部人员希望能在actions/ai-inference这个GitHub Action中使用Copilot后端推理（出于各种原因），我没有说“抱歉，我没时间处理”，而是扔给了代理。如果是人类来做，输出质量可能会更好，但可能要拖几周（甚至更久）才能完成。