沃顿教授：程序员的新工作是“经理”，监督AI比派任务更困难，别把Agent当“一键完成”
51CTO技术栈 · 软件开发
原创 姜篇 2026-11-06 18:00 北京 莫利克：以前总有人说商学院毕业生得找技术人员帮忙。现在轮到更多人学习怎么管理工作了。 编辑 | 姜篇 莫利克：现在，人人都得学着当经理了。 莫利克：把工作交给Agent之后，盯着它有没有做对，同样要花不少时间。 莫利克：那些决定，我不想全让AI替我做。 莫利克：以前总有人说商学院毕业生得找技术人员帮忙。现在轮到更多人学习怎么管理工作了。 在访谈中，伊桑·莫利克把这几件事连在了一起。 他说的“当经理”，不是让程序员转去管人，而是当Agent开始替你执行任务，你得负责讲清目标，约定它什么时候来汇报，并从它拿出的方案里作选择。 备注：伊桑·莫利克，沃顿商学院管理学副教授、生成式AI实验室联合主任，长期研究人如何与AI共同工作。 这事并不省心。莫利克算过另一笔账：把任务交出去，除了花 Token，还要花时间盯进度、看方案、发现跑偏后把它拉回来。 他担心开发者们 太早相信 Agent 。工具 “按一下就能完成”，开发者们容易错过那些本来该自己做的选择。 他讲了自己的经历。Agent替他找约5000个故事、整理材料、写分析工具，但它提出的第一套研究办法，他没有直接照办。而是先让Agent列出几种方案，比较结果，再把不同方案里有用的部分拼起来。费时间的活可以交出去； 研究什么、采用哪条路，仍由他选。 还有一次，他明明不想发邮件， AI却给院长发了出去。莫利克因此强调： 对Agent的信任要从低风险任务慢慢建立，不能因为它过去完成过几项任务，就默认它可以替你做所有决定。 放进开发者的日常，问题就很具体了： Agent可以修Bug、补测试、准备PR；谁来告诉它改动不能碰什么，什么时候必须停下来请人看，以及“测试过了”之外还要验收什么？ 莫利克谈 AI工作给人带来的管理任务 以下根据 访谈 翻译整理。 派完活还得注意： Agent有一笔看不见的成本 主持人问莫利克，该怎样管理 Agent。他说了一个很容易被忽略的地方：安排十项任务很快，但是逐项看它们做到了哪一步、有没有走错方向，很费时间和精力。 莫利克：使用AI系统的成本，不只是Token。把大量工作派出去之后，监督这些工作的时间和精力也很贵。你要想清楚的是，怎样管理整个过程。 莫利克指出监督 Agent同样要花时间 他的做法是在派任务时就说清楚：做到哪一步回来汇报，在哪一步给出几种不同方案供他挑选，什么样的结果算好、什么样的结果不行。尤其任务刚开始时，他会早一点检查，免得 Agent理解错了方向，还一路认真地做下去。 莫利克：我会指定它在哪些节点回来和我核对，也会要求它拿出几种不同的例子，让我来选。关键是由我决定，自己要在哪一步参与，而不是把Agent放出去就等成品。 莫利克描述自己的检查点设置 对一个开发任务来说：让 Agent升级支付接口，可以先要求它列出会改哪些调用点、旧接口在哪些服务里还在用；确认范围后再改代码；最后提交测试结果和未覆盖的风险。这里的“管理”就是把决定留在合适的位置，不是坐在旁边看它敲每一行代码。 他让 Agent找5000个故事，却没让它选研究方法 访谈中最能说明这套分工的，是莫利克自己的研究。 他想弄清不同故事有没有可比较的结构，于是让 Agent先提出研究思路。Agent能给出办法，但他没有让它挑一个自己最喜欢的就直接执行。 莫利克：我先让它提出多种研究路径，再给反馈，让它分别做出初稿。我看过结果后，可能会说：“第三种有意思，但第二种有个好地方，能不能把两者结合？” 莫利克没有让 Agent直接执行它推荐的第一种研究方法 在这个过程中， Agent替他找约5000个故事、建立分析文本的工具；莫利克自己则是比较方案，追问哪里可能错了，再决定下一步。 这不是一个“万能提示词”的故事。 他说自己像带研究团队那样工作：先看几个方向，再根据看到的东西调整，而不是事先写死每一步。 莫利克：繁琐的检索和整理工作可以让AI做。我希望把有意思的部分留给自己，包括挑选、组合方案，以及决定哪些结果值得继续研究。 莫利克谈自己的研究分工 开发者也会遇到这样的选择。让 Agent先给某个慢接口提出三种优化方案，再决定改索引、改缓存，还是先查上游请求；它可以跑压测、整理日志，但不能因为它给出的第一条建议看起来完整，就跳过对业务代价的判断。 越像 “一键完成”，越容易把选择权一起交出去 莫利克并不反对自动化。 他很愿意把事实核查、填表等费时间的工作交给 AI。在自己的新书里，AI查出过他写错的地方，甚至指出他引用的资料也有错误。不过， “省事”不等于把过程里所有选择都交给AI。 莫利克：最常见的错误，是过于相信Agent。现在有些界面把它的工作过程藏起来，让结果显得像魔法；人想在中途参与，反而更难了。 莫利克谈使用 Agent时常见的过度信任