AI时代的工作要靠自己创造！斯坦福AI经济学家：下一代开发者，要学会给一群Agent找事做，更大的机会是复制高手的工作方法

一名即将毕业的斯坦福学生问Erik：“我和身边很多同学都找不到工作，我们这一代是不是完了？”

Erik承认，AI正在代替一部分工作。随后，他提醒这名学生：以后，工作不会总被别人拆分好，再变成一张张任务单送到你面前。

你得自己先发现问题，再想办法解决。

备注：Erik是斯坦福数字经济实验室主任，也是研究AI、生产力与就业市场最有影响力的经济学家之一。

放到开发团队里，这句话很好理解。

修Bug、补测试、升级依赖，Agent已经能做不少。开发者接下来要干的，是看出系统哪里出了问题、用户为什么不满意，以及这件事究竟应该改成什么样。

在最近的一场访谈中，斯坦福数字经济实验室主任Erik Brynjolfsson把AI换了一个说法：Amplifying Intention，意为放大意图。

模型会把一个人的行动能力放大。但方向是哪里，仍然取决于使用它的人。

以下为访谈内容，我们进行了翻译与整理。

Erik Brynjolfsson谈AI时代的主动性

Agent能接工单，却不会替团队决定做什么

“Amplifying intention.”

Erik Brynjolfsson：AI可以理解为“放大意图”。

“意图”听起来有些抽象。换成开发现场的话，就是团队究竟想解决什么问题。

假设监控里出现一条告警：支付接口的P95延迟升到了1.2秒。把“优化支付接口”交给Agent，它可以搜索调用链、调整连接池、增加缓存，甚至直接提交一份能通过测试的改动。

接下来还有几件事需要人来决定。

延迟来自数据库锁等待，还是第三方通道变慢？目标是把P95压到300毫秒，还是先保证支付成功率？缓存会不会让订单状态过期？增加重试以后，会不会把一次超时放大成重复扣款？

这些问题没有现成答案。它们需要日志、业务规则和历史事故一起参与判断。

开发者把问题定义清楚，Agent才能沿着正确方向执行。目标模糊时，它也能快速产出，只是产出的可能是更多代码、更大的diff，以及一次看似完成的错误优化。

Erik Brynjolfsson重新解释AI的含义

资深开发者已经开始带着一群Agent工作

Erik在访谈中专门谈到了编程。

例行任务正在被Agent代替。资深开发者获得的则是一种放大效果，他们开始同时调度一群Agent。

“Fleets of agents.”

Erik Brynjolfsson：他们使用的是一群Agent。

在真实项目里，一个人可以让不同Agent并行查问题：一个读取日志和链路追踪，一个复现Bug并补测试，一个检查接口变更会影响哪些服务。等结果回来，人再判断哪条线索值得继续、哪些改动可以合并。

这与过去多开几个聊天窗口不一样。并行任务越多，开发者越需要提前写清依赖关系和停止条件。否则，三个Agent可能同时修改同一组文件，也可能各自修好局部问题，却把系统推向三种不同的设计。

Agent数量增加以后，编码速度只占整个工作的一个部分。任务怎样拆分，结果怎样汇总，冲突由谁处理，错误改动如何撤回，都会直接影响交付质量。

资深开发者的优势也因此变得清晰。他们见过系统在什么地方出事故，知道一项改动会牵动哪些服务，也能识别一份“测试全绿”的结果是否遗漏了生产环境里的真实约束。

Erik Brynjolfsson谈资深开发者调度多个Agent

一句“帮我做完”，还算不上清楚的意图

主动定义工作，并不是自己写一份长PRD，再把每个步骤手动指定给Agent。

一个能够执行的任务，至少要让Agent知道四件事：现在的问题是什么，完成以后哪个指标会变化，哪些边界不能碰，以及怎样证明结果可用。

仍以支付接口为例。比起“优化一下性能”，下面这组条件更接近真实任务：

•复现晚高峰时出现的延迟；

•将P95控制在300毫秒以内，支付成功率不能下降；

•暂时不修改数据库表结构，也不接触生产密钥；

•补齐压力测试，给出修改前后的日志，并保留一键回滚路径。

这时，Agent可以自己搜索代码、提出方案和运行测试。它在一个可检查的范围里行动，人也知道什么时候应该叫停。

问题定义仍可能出错。团队以为瓶颈在接口，查完才发现拖慢流程的是下游风控。好的任务不会朝着错误方向前进，它会要求Agent先拿证据，再开始大范围改动。

开发者从“接工单”走向“定义任务”，练的就是这套能力：把模糊抱怨变成可以验证的问题，再把问题交给Agent推进。

高手解决一次问题，团队应该得到一套方法

访谈中Erik说，几乎每家公司都有少数能做到10倍、20倍产出的人。如果能记录这些人怎样工作，把方法整理出来，再复制给团队，其他人的能力也会被带起来。

“10x,20x.”

Erik Brynjolfsson：少数人的工作表现可以达到10倍、20倍。

开发团队里最有价值的经验，经常没有写在代码里。

某位工程师看到连接数异常，就会先查最近一次配置变更；遇到消息重复消费，他会先看幂等键和补偿任务；上线前，他知道哪几个监控指标必须放在同一张面板里。这些判断来自一次次故障，往往只存在于人的脑子里。

Agent进入团队后，这些经验需要留下来。

故障Runbook、架构决策记录、代码审查清单、回滚步骤和失败样例，都可以成为它执行任务时的上下文。

记录高手经验，也不能把它理解成复制几段提示词。需要保存的是判断顺序：遇到什么信号先查哪里，看到什么证据才继续，哪些风险出现后必须转交给人。

当这套方法能够被Agent调用，一位资深工程师解决的不再只是眼前这次故障。他的判断会进入后续任务，让整个团队少走同样的弯路。

Erik Brynjolfsson谈如何复制高绩效员工的工作方法

小团队先拿到过去买不起的能力

Erik也谈到近两年频繁出现的“一人独角兽”。他觉得，一家公司只靠一个人做到10亿美元估值可能有些夸张，小团队借助AI获得巨大杠杆，却已经离现实不远。

“One-person unicorn.”

Erik Brynjolfsson：一人独角兽。

过去，一个小型开发团队常常要在研发、测试、文档和用户支持之间做取舍。人手不够，自动化建设很容易排到业务需求后面。

Agent可以同时补测试、整理变更记录、检查依赖风险，也能在开发者处理核心逻辑时准备文档和验证脚本。

人数少，也意味着方向更重要。大团队走错一条路，可能还有另一个小组纠偏。三个人的团队把Agent全部派往错误目标，一天就能生成一大堆没人需要的功能。

小团队得到的并非免费劳动力，而是一组需要被管理的执行能力。谁来决定优先级，谁来检查输出，谁对上线结果负责，仍然要在团队内部说清楚。

Erik Brynjolfsson谈AI给小团队带来的杠杆

写在最后：别把主动权也交给Agent

Agent会继续代替边界清楚的工单。修复单文件Bug、升级依赖、补测试和整理文档，都可能越来越接近自动执行。

剩下的工作不会凭空消失，它会向前移动。

开发者要从日志和用户反馈里找到问题，把业务目标写成工程指标，给Agent划出权限和修改范围，再用测试、监控和真实数据收回结果。代码只是这条链路中的一段。

Erik把AI叫作“放大意图”。模型能把一个方向推进得很快，却不会替团队决定哪个方向值得投入。

以后仍然会有工单。只会等工单的人，能够掌握的工作范围会越来越窄。能主动找到问题、组织Agent并对结果负责的开发者，才有机会把工具带来的速度变成稳定可用的软件。

参考链接：

https://www.youtube.com/watch?v=u76xdhpF474

文章来自于微信公众号 “51CTO技术栈”，作者 “51CTO技术栈”