一个Staff Engineer的2026年AI工作流

🤖 AI摘要 一位一线Staff Engineer复盘了自己15个月来使用AI编程助手的真实变化：从偶尔试水到每天开启几十个Agent会话，从逐行盯防到只需最终审核。文章没有吹嘘，全是实战细节——怎么写代码、怎么查Bug、怎么把握"信任但不放任"的度。

🔑 核心要点 1、Agent已从"偶尔用用"变成"每次都先用" 2、80%的Bug能被Agent独立诊断 3、核心技术技能是"尽可能多地把活儿交给Agent，但别交过头" 4、沟通和判断仍然是人类的领地

原文作者 Sean Goedecke 是一线 Staff Engineer，本文写于2026年5月，是他一年多前那篇《How I use LLMs as a staff engineer》的续篇。

一年多前我写了《一个Staff Engineer如何使用LLM》。当时我的AI使用方式大概是这样：

• 用 Copilot 做智能补全
• 在不熟悉的领域做短小精准的改动（改完一定让领域专家审）
• 写大量用完即弃的研究性代码
• 问很多问题来学习新领域（比如 Unity 游戏引擎）
• 修 Bug 时偶尔死马当活马医，碰碰运气
• 给长篇英文文字做整体润色

而以下这些事，我当时明确不用AI：

• 在我熟悉的领域让 AI 写整个 PR
• 写 ADR（架构决策记录）或其他技术文档
• 在大型代码库中做研究、搞清楚事情是怎么运作的

2025年2月，离现在很久了。那时候最强的模型是 OpenAI 的第一个推理模型 o1。Agent 勉强能跑，但经常卡住，或者因为上下文压缩（compaction）而跑偏。

从那以后，什么变了？

Agent 真的好用了

最大的变化是：我现在让 LLM 在我熟悉的领域直接写整个 PR 了。

一年前，我偶尔会让 Agent 改单个文件——那种我懒得手打的简单改动。有时我会把写好的函数复制到 LLM 对话窗口里求反馈。但现在，我的每一次改动，都是先让 Agent 来解决问题，通常一轮编辑审核后就直接推 PR。

2025年底，我开着很多 VSCode 窗口。2026年初，变成了 Copilot CLI 的终端标签页——尤其是需要跨多个仓库改代码的时候。现在我用 GitHub Copilot App 非常多（每天几十个会话）。

这背后反映的是一个根本性的转变：以前我得跟着 Agent 逐行盯着改，现在只需要在最后做一轮审核。早期的 Agent 经常出错且无法自行恢复，所以盯着它的思考过程、及时踩刹车纠偏是有价值的。但现在 Agent 跑得太快了，跟不上也没必要跟——而且大多数时候它们自己就能恢复错误。

有时候我甚至不需要编辑，直接推就行。不过这很少见：至少，我通常会过一遍把过度注释和其他"LLM 味"的东西清掉。

我花了大量时间在快速浏览和评估 Agent 的改动上。 大多数时候我会直接否掉，原因就是"嗯，这不是我想的"。平均来说，这个初步判断大约花三十秒。如果改动看起来还行，我才会深入做一次正式的 code review，确保我理解了改动并且它在做正确的事。

遇到困难的任务，我经常要否掉五六次（甚至更多！）Agent 的尝试，才能接受一次"够用了"的结果，或者干脆放弃自己上手。

查 Bug

在查 Bug 这件事上，我对 LLM 的依赖甚至超过了写代码。

2025年，我偶尔会把 Bug 丢给 LLM，碰碰运气看它能不能快速给出解释。现在我把每一个 Bug 都丢给 LLM——通常的做法是开一个新的 Agent 会话，把 Bug 报告贴进去——因为它能独立正确诊断 80% 的问题。

现在的 Agent 非常擅长追查 Bug，尤其是当你给它跨越多个代码库的视角时。

不过我查 Bug 还是比它强。就在上周我遇到一个棘手的 Bug，前后开了约十四个 Agent 会话，最后一个才找到原因。在这十四次之间我在干什么？

• 从日志、Slack 等渠道挖更多上下文，喂给 Agent
• 当然，自己也在建立对问题的心理模型
• 自己搭 Bug 复现环境（和 Agent 并行）
• 回复 Agent 会话：“不对，你的理论不成立，因为 X”（或者直接杀掉会话、带着新线索重开）

最终，是 Agent 抓到了这个 Bug。但我仍然认为这是我的功劳——因为到那个时候，我已经把搜索空间压缩得足够窄了，第14号 Agent 面对的问题比第1号 Agent 容易得多。

换句话说，人类的专业能力在查 Bug 这件事上仍然非常重要。

写作

我几乎总是自己写 PR 描述，因为 LLM 总是过度沟通，不擅长表达一个改动的"核心意图"。手写 PR 描述也能向审阅者传递一个信号：我自己审过了，不是让你们当第一个读 diff 的人。

唯一例外是改动非常简单，Agent 生成的描述只有一句话，那我就不管了。

我依然不用 LLM 写 Slack 消息、ADR、Issue 等。我相信自己对"什么信息重要"有更好的判断，而且我想传递一个信号：有一个人在认真思考这些内容。

博客文章也一样，我从来不让 LLM 代笔，不过每篇草稿都会跑一遍 LLM 求反馈。OpenAI 的模型以前在这方面糟透了，直到 GPT-5.5 才勉强可以接受。OpenAI 和 Anthropic 的模型现在还是会试图淡化我的论点，但我已经把这当作 LLM 的"出厂风格"了，直接忽略那部分反馈就好。

测试和环境配置

另一个变化是：我现在尽可能把测试和配置工作推给 Agent。

2025年，我偶尔会让 LLM 生成一组 curl 命令的测试脚本，我自己跑。2026年，我直接让 Agent 去测试我的改动，然后看它的执行日志。

UI 测试我不这么做——一方面更麻烦，另一方面我不信任 Agent 对界面细微手感的判断。

Agent 会自动写大量的单元测试，不需要你要求。但有时我会让它们组装更广泛的集成测试。总的来说，我现在把测试代码视为"廉价的"：如果我在犹豫某个测试值不值得加，加了就是了（只要我知道它不会变成 flaky test）。

当然 LLM 有时会写出奇怪得让人无语的测试代码——我会读一遍，抓明显的低级错误——但审核测试代码时，我的标准比审生产代码宽容得多。

我也会把烦人的本地环境配置任务丢给 Agent。比如 nvm 没法正确切换 Node 版本，我会开一个 Copilot CLI Agent 让它自己搞定。这基本上替代了以前 Google 搜索问题的流程，而且快得多——因为 Agent 可以直接跑那些无聊的 bash 命令来诊断和修复问题。

总结

过去十五个月最大的变化就是：Agent 真的好用了。 从偶尔怀疑地使用，变成了持续地、轻度监督地使用。

我工作的核心没变：交付项目、行使判断力、影响公司的技术决策。但我现在愿意接手的小活儿的范围大了很多——基本上，只要是我能丢给 Agent 并且预期它八九不离十的事情，我都接。

以前我花很多时间推活儿——要么推给下属，要么直接说"抱歉，我现在没时间做"。现在我能说"好"的时候多多了（至少对那些低风险的小改动来说）。

以下是我现在用 AI 做的事：

• 写（或起草，看复杂度）我的每一次代码改动
• 调查和修复 Bug——简单 Bug 让它自主搞定，复杂 Bug 我深度参与
• 大型代码库中的研究，现在的 Agent 已经几乎总能给出正确答案（而且当它答错时，看解释就能看出来它漏了什么）
• 手动测试和本地机器的故障排查
• 问大量问题学习新领域，以及给文字做润色

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

• 替我写任何公开沟通内容（PR 描述、ADR、消息等），除了那种只有两行的无脑 PR
• 写我不仔细审阅的代码
• 测试 UI

在我看来，当前最核心的 AI 技能是：尽可能多地把工作推给 AI Agent，但不要推过头。

很多人对 Agent 利用不足：不让它查 Bug、不让它跑测试、不给它足够的简单任务。另一些人则过度利用：让它代写本该手写的沟通内容，或者信任它做需要人类仔细审阅的大范围改动。

自从上次写那篇文章以来，天平进一步向 Agent 倾斜了，但找到那个平衡点，依然和以前一样难。

本文翻译自 How I use LLMs as a staff engineer in 2026，作者 Sean Goedecke，发布于 2026年5月17日。