AI时代的工作需要自己创造！斯坦福经济学家：下一代开发者的核心能力是调度Agent，真正的机会在于复制顶尖高手的方法论
“It's that you have to be the creator.”
Erik Brynjolfsson：你必须成为那个主动创造岗位的人。
一位即将从斯坦福毕业的学生向Erik提问：“我和身边不少同学都找不到工作，我们这一代人是不是没希望了？”
Erik坦率地表示，AI确实在替代一部分工作岗位。接着他告诫这位学生：未来，工作不会再由别人拆解好，然后以任务清单的形式派发给你。
你需要自己先去发现问题，再思考解决方案。
备注：Erik是斯坦福数字经济实验室的负责人，也是研究AI、生产力与就业市场最具影响力的经济学家之一。
把这一观点放到开发团队中，很容易理解。
修Bug、补测试、升级依赖等任务，Agent已经能够胜任很多。开发者接下来需要做的是，洞察系统存在的隐患、理解用户不满的原因，以及明确产品究竟该如何改进。
在近期的一次访谈中，斯坦福数字经济实验室主任Erik Brynjolfsson给AI赋予了一个新的解读：Amplifying Intention，即放大意图。
模型能够将一个人的行动能力成倍放大。但前进的方向，依然由使用它的人来决定。
以下是访谈内容的翻译与整理。
Erik Brynjolfsson解读AI时代的主观能动性
“Amplifying intention.”
Erik Brynjolfsson：AI的本质是“放大意图”。
“意图”这个词听起来有些抽象。放在开发场景中，它代表团队真正想要攻克的核心问题。
假设监控系统中出现一条告警：支付接口的P95延迟飙升至1.2秒。把“优化支付接口”这一任务交给Agent，它能够检索调用链路、调整连接池、添加缓存，甚至直接提交一份通过测试的代码变更。
但还有一些关键决策需要人来完成。
延迟究竟源于数据库锁竞争，还是第三方通道响应变慢？目标是P95降至300毫秒，还是优先保障支付成功率？缓存机制是否会导致订单状态过期？引入重试机制后，单次超时会否演变为重复扣款？
这些问题没有标准答案。它们需要结合日志数据、业务规则和历史故障案例进行综合研判。
开发者只有把问题界定清晰，Agent才能沿正确方向推进。若目标模糊，它虽然能快速产出，但产出的可能只是更多代码、更大的差异包，以及一次看似完成实则错误的优化。
Erik Brynjolfsson重新定义AI的内涵
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执行任务时的上下文支撑。
记录高手经验，不能简单理解为复制几段提示词。需要保存的是判断逻辑：遇到何种信号优先排查何处，捕捉到哪些证据后才继续推进，出现哪些风险必须移交人工处理。
当这套方法可被Agent调用，一位资深工程师解决的便不再仅是当前故障。他的判断将延伸至后续任务，助力整个团队规避重复的弯路。
Erik Brynjolfsson阐述如何复制高绩效员工的工作方法
Erik还谈及近年频繁出现的“一人独角兽”现象。他认为，一家公司仅凭一人实现10亿美元估值或许略显夸张，但小团队借助AI获得显著杠杆效应，已不再是遥不可及的目标。
“One-person unicorn.”
Erik Brynjolfsson：一人独角兽。
过去，小型开发团队常在研发、测试、文档和用户支持之间艰难取舍。人手不足时，自动化建设往往让位于紧迫的业务需求。
Agent能够同步补充测试、整理变更记录、排查依赖风险，也能在开发者专注核心逻辑时生成文档和验证脚本。
团队规模小，更凸显方向把控的重要性。大团队走错方向，可能有其他小组及时纠偏。而三人团队若将Agent全部投入错误目标，一天内就会产出大量无人需要的功能。
小团队获得的并非免费劳动力，而是一组需要精细管理的执行能力。优先级的确定、输出的审核、上线结果的责任归属，仍需在团队内部明确界定。
Erik Brynjolfsson分析AI为小团队赋予的杠杆效应
Agent将持续替代边界清晰的工单任务。修复单文件Bug、升级依赖、补充测试和整理文档，都将愈发接近全自动执行。
剩余的工作不会凭空消失，而是向前端迁移。
开发者需要从日志和用户反馈中定位问题，将业务目标转化为工程指标，为Agent设定权限和修改边界，再借助测试、监控和真实数据回收结果。代码仅是这条链路中的一个环节。
Erik将AI定义为“放大意图”。模型能将既定方向快速推进，却无法替团队抉择哪个方向值得投入。
未来依然会有工单。但只会等待工单的人，能够胜任的工作范围将持续收窄。唯有主动发现问题、组织Agent并对结果负责的开发者，才有机会将工具赋予的速度转化为稳定可靠的软件产品。
https://www.youtube.com/watch?v=u76xdhpF474
——好文链接——
程序员远没到“完了”的时候！Sam Altman：OpenAI不包办一切，模型只是底座，开发者仍是AI生态的主角
AI时代，最强开发者更像CEO！Claude Code创始人：“一人军队”时代将要到来，好想法成为新的稀缺资源
AI时代，最强开发者更像CEO！Claude Code创始人：“一人军队”时代将要到来，好想法成为新的稀缺资源