纯编程岗位已完，能做可验证奖励强化学习的都会完

标签： | 发表时间：2026-05-20 16:09 | 作者：

出处：https://x.com

为什么 AI 会先吃掉程序员，而不是产品经理

如果你还在用职业名判断 AI 风险，先停一下。

姚顺宇在访谈里给过一个反直觉判断：AI 最先高速改变的，不一定是人类觉得简单的工作，而是反馈最清楚的工作。

这个判断落到职业上，最扎眼的例子就是程序员。

过去很多人以为，AI 会先替代那些重复、低门槛、标准化的工作。客服、简单文案、资料整理，听起来都比程序员更容易被自动化。

程序员是高门槛脑力劳动，写的是复杂系统，按这个直觉，它不该这么早站到第一排。

结果最早被 AI 工具改写工作方式的，偏偏是代码世界。Cursor、Claude Code、Copilot 和各种代码智能体（coding agent），让很多人第一次感觉到，AI 不只是会聊天，它真的开始接一段工作了。

但姚顺宇恰恰把 AI 编程（AI coding）拿出来当第一批爆发的 AI 原生场景。原因不在写代码低端，也不在产品经理更高级；关键是代码世界有测试、编译、运行结果、日志和版本记录。

模型做完以后，环境会告诉它哪里错了。

AI 不按职业声望排队，它先进入那些能被清楚定义、快速验收、低成本纠错的任务。

程序员只是第一排。AI 盯上的，是所有职业里能被拆成输入、输出、标准和反馈的可验收执行层。

职业替代榜单太粗了

这几年，关于“AI 会先替代谁”的讨论很容易变成一张职业榜单。

程序员排第几，产品经理排第几，设计师、运营、咨询、律师、会计又排第几。这个游戏好玩，因为它简单，像看 K 线图。每个人都想知道自己的职业是不是已经破位，隔壁职业是不是先跌。

但职业名太粗了。

同样叫程序员，有人每天接明确需求，改一个局部函数，跑一下测试，然后提代码；也有人要理解业务目标，拆系统边界，决定哪些依赖不能动，最后对整个系统结果负责。

同样叫产品经理，有人按模板写产品需求文档（PRD）、整理会议纪要和竞品截图；也有人要判断用户到底卡在哪里，定义指标，协调资源，承担版本取舍。

这两组人被同一个职业名盖住了。你说“程序员会不会被替代”，或者“产品经理会不会被替代”，其实像是在问“车会不会坏”。卡车、赛车、出租车、自行车都被塞进一个词里，答案当然会很混。

姚顺宇那条判断有用的地方，就在这里。它把问题从职业名换成了任务结构：

一个任务做完以后，环境能不能告诉模型做对了没有；
这个信号能不能被重复收集、训练和纠错；
失败以后，能不能低成本再试一次。

这件事有没有成败信号，可以叫任务可评价性。成败信号越清楚，AI 越容易练；反馈越脏、越晚、越主观，模型就越难稳定进步。

所以 AI 不认识你的岗位头衔。它不关心你在公司系统里叫工程师、产品经理、运营，还是策略分析师。

它只看这件事能不能被定义，能不能被执行，能不能被验收，失败以后能不能继续修。

代码世界像一座提前铺好的练习场

写代码对人很难，但对训练系统很友好。

这句话听起来有点别扭。因为我们习惯把“人觉得难”直接等同于“机器也应该觉得难”。但模型学习一件事，和人类职业声望不是同一套坐标。

对模型来说，难点不只在任务本身有多复杂，还在于环境能不能把错误及时推回来。

代码世界恰好在这件事上非常慷慨。你写完一段代码，能不能编译，测试能不能过，类型检查有没有报错，运行结果对不对，日志里有没有异常，性能有没有下降，版本记录里改了哪些文件，这些信号都会露出来。

很多时候，它们不是人类主观评价，而是工具链直接给出的反馈。

一个代码智能体修改了某个函数，测试失败了，它至少知道失败在哪里；命令跑不通，它能看到报错；依赖不对，它能读依赖配置文件；改坏了别的模块，版本控制和测试能把影响暴露出来。

这个过程当然还需要人审查，但它已经比很多知识工作更接近“做一步，看反馈，再修一步”的闭环。

再往外看，GitHub 和开源生态又给了代码世界大量任务、上下文和修改历史。一个模型不只是看到最终答案，还能看到别人怎么提交议题（issue）、怎么改缺陷（bug）、怎么做代码审查（review）、怎么围绕一个仓库（repo）迭代。

仓库本身就像一台状态机，文件、提交、测试、讨论和文档把上下文记录下来。

好代码当然也有争议。架构是否优雅、命名是否合适、抽象是否过度，这些不可能完全自动判断。但相比很多产品判断，代码仍然更容易形成可重复的质量标准。

能不能运行，是否通过测试，是否引入明显回归，是否符合接口约束，这些东西足够让模型反复练。

所以程序员先站到第一排，并不是因为这份工作低端。恰恰相反，软件工程复杂到一定程度，才给了 AI 足够多的可学习信号。

代码世界像一座提前铺好的练习场：有题目，有上下文，有工具，有错误提示，有回滚，有复盘。

这也解释了为什么代码智能体的体感来得这么快。关键不只是模型“会写代码”，还在于它被放进了一个能持续纠错的环境。

写错了，能看到；看到了，能改；改完了，还能再跑。

产品经理不是安全，只是反馈更脏

那是不是产品经理就安全了？

不是。

这个误读很常见：程序员先危险，产品经理暂时没事。这个判断太便宜，也不符合姚顺宇的原意。

产品经理工作里有大量结构化子任务，都会被 AI 改造：

写产品需求文档；
整理用户访谈；
总结会议；
生成竞品分析；
做数据初筛；
拆需求列表；
写埋点方案；
生成原型说明。

这些事情本来就有模板、有输入、有输出、有交付格式。它们不可能长期停在纯人工状态。

这里有个很残酷的分界。

你是在写文档，还是在定义问题？你是在整理别人已经说清楚的东西，还是在把没人说清楚的东西变成判断标准？

前者会越来越像执行任务，后者才更接近产品经理的责任位置。

但姚顺宇说难的，是完整产品判断。他在访谈里反复指向一个问题：好产品的奖励信号（reward signal）不清楚。

翻译成人话，就是你做完一个产品决定以后，很难立刻知道它到底对不对。

一个功能上线以后，用户会不会用，为什么不用，是因为入口太深、文案不清楚、需求本身不成立，还是因为市场时机不对？

一个留存指标变了，是功能带来的，还是渠道、活动、季节、竞品、价格、品牌一起搅出来的？

一个产品方向看起来失败，是判断错了，还是资源没跟上，还是组织执行变形了？

产品反馈经常晚、脏、主观。晚，是因为它需要时间显现；脏，是因为混进了太多变量；主观，是因为用户心理、审美、组织目标和商业取舍都会进入判断。

做出来以后，大家才知道它好不好，而且经常不是一眼就知道。

所以产品经理的护城河不是写文档，也不是开会。文档会被生成，会议会被总结，竞品会被整理，数据会被初筛。

产品经理（PM）难被完整训练的部分，是把模糊目标变成可验证的问题、标准和取舍。

程序员和产品经理的差异，不是“谁会被替代，谁不会”。更准确的说法是：代码世界更早暴露了未来所有知识工作的重构方式；产品世界的核心判断更难训练，但它的外围执行层一样会被重构。

AI 提效以后，工作未必变少

很多人以为，AI 写代码以后，程序员会轻松一点。

这个期待很正常。过去写一个功能要两天，现在半天能做出来，剩下的时间似乎应该还给人。你可以早点下班，可以多想一会儿架构，可以把拖了很久的文档补上。

听起来挺好的。

但姚顺宇谈 AI 编程时，给出的体感更接近另一种结果：想法实现得更快以后，人会试更多方案，跑更多实验，做更多判断。

AI 提效先改变的，是尝试成本。尝试成本一降，高竞争环境通常不会把省出来的时间留给你，它会把更多尝试塞进同一天。

过去一个方案要两天，团队可能只试一个。现在一个下午能试三个，领导、同事、你自己都会自然地问：那为什么不多试几个？

过去一个 bug 修起来很费劲，大家可能先忍一下；现在模型能快速定位和修改，就会有更多边角问题被拉进待办。

过去没人敢开太多实验，因为每个实验都要人力；现在实验成本低了，判断成本就会上升。

工作没有少，只是从“手写实现”迁移到了“定义任务、组织上下文、审查结果、比较方案、承担验收”。

手从键盘上少敲了一些，脑子里的窗口反而开得更多。像系统里同时跑了很多线程，每个线程都很快，但你要负责调度、抢占、回滚和判断优先级。

这件事不会只发生在程序员身上。任何职业一旦能把执行切成小闭环，节奏都会被同一股力量推快。

运营可以更快生成活动方案，研究员可以更快整理文献，产品经理可以更快写需求和原型说明，创作者可以更快生成多个标题和版本。

每个环节都快一点，最后不一定换来轻松，可能换来更高的工作密度。

AI 未必先让人失业。它可能先让同一份工作变得更密。

这才是很多人已经感受到、但还没说清楚的变化。

AI 工具越好用，工作越不像消失，而像被压缩。原来一天里只能跑一个版本，现在一天里要看三个版本。原来一个人只要交付结果，现在还要解释为什么选这个结果、为什么不用另外两个结果、哪里可以继续迭代。

真正危险的是可验收执行层

问题不是程序员会不会消失。这个问题太大，也太容易吵。

有人会拿顶级工程师反驳：他们当然不会被替代；有人会拿初级岗位反驳：很多局部实现已经被模型接走了。

两边都能找到例子，然后继续争职业名。

更有用的问题是：一个职业里，哪些部分只是在明确标准下完成局部执行？

只接局部任务、写局部实现、无法定义需求、无法审查跨文件影响、无法承担系统验收的人，价值会被压缩。

这未必是因为他们不努力，更因为他们那部分工作越来越像可切分、可派发、可回收的任务。

模型只要能拿到足够上下文，再通过测试、编译、日志和代码审查得到反馈，就会不断逼近这部分执行层。

对应到产品岗位，风险也一样存在。

只按模板写 PRD、整理材料、做浅层竞品分析、把别人说过的话包装成页面的人，也会被压缩。因为这些任务可以被拆成输入、输出和格式要求，可以快速验收，也可以低成本重做。

姚顺宇那条判断在这里完成了职业转译：AI 优先进入的，不是某个职业名，而是职业内部可验收、可拆解、可低成本纠错的执行层。

再压一层，可以变成三个指标：

第一，验收速度：做完以后多久知道对错。
第二，纠错成本：错了以后能不能快速重来。
第三，责任位置：你是在执行标准，还是在制定标准。

前两个越高，第三个越低，风险就越近。

如果你的工作能被拆成输入、输出、标准和反馈，它就会开始变得像代码。

它比“程序员危险”更准确，也更难躲。因为它把所有职业都拉进来了。

运营里有像代码的部分，研究里有像代码的部分，咨询里有像代码的部分，设计里有像代码的部分，产品里也有像代码的部分。

所谓“像代码”，重点不在产出物是不是代码，而在任务结构：输入清楚，输出清楚，验收清楚，失败可以重跑，迭代成本很低。

只要这个结构出现，AI 就有了练习场。

职业名会给人一种安全错觉。你以为自己站在某个行业、某个岗位、某个头衔后面。

结果 AI 看见的是另一张图：哪些地方有清楚任务，哪些地方有反馈信号，哪些地方失败了能改，哪些地方上下文已经结构化。

人的价值会往反馈责任迁移

被压缩的是纯执行，不是所有人的价值。

问题在于，你有没有从执行层往反馈层迁移。

人的价值会往上游和下游迁移。上游是定义任务、组织上下文、设定边界。下游是审查结果、设计验收、承担取舍。

中间那段纯执行，会被越来越多的 AI 工作者接走。

这里说的 AI 工作者（AI worker），就是你能调度来做具体任务的 AI 工作者。它可能是一个代码智能体，也可能是一个能整理资料的助手，一个能跑分析的工具，一个能生成方案的模型。

它不是传统意义上的员工，但它会占据越来越多的执行位置。

程序员的迁移路径很清楚。过去的价值可能更多体现在手写实现上：理解需求、查上下文、设计方案、写代码、调试、交付。

AI 进入以后，这条链会重排。人要更擅长定义任务边界，给模型足够上下文，知道哪些文件不能动，知道结果如何验收，知道一个局部修改会不会影响系统其他部分。

这不是说写代码不重要。你看不懂代码，就很难审查模型写出来的东西；你不理解系统，就不知道模型哪里在胡来。

只是写代码不再是唯一中心。更稀缺的是你能不能组织一批 AI 工作者去做事，然后对结果负责。

产品经理的迁移路径也类似。PM 的价值不在于把一句需求扩写成三页文档，而在于把模糊目标变成可验证的问题、指标、实验和复盘。

你能不能判断“用户说想要”背后到底是什么需求；能不能把一个方向拆成几次低成本验证；能不能定义成功标准；能不能在数据不好看时判断是方向错了、执行错了，还是反馈还不够。

无法验收，就是 AI 协作里的最高优先级问题（P0）。

一个任务如果没有成败标准，就很难交给 AI 稳定执行。你让模型“做得好一点”，它只能猜。

你让模型“把这段接口改到测试通过，并且不改变现有调用方”，它就有了边界。

你让模型“写一个更好的产品方案”，它只能拼常识。

你让它“针对新用户首日留存下降，提出三个可在两周内验证的假设，每个假设要有指标、实验和失败判据”，它才有可能进入真正的协作。

下一阶段稀缺的，已经不只是会写代码或懂产品的人，而是能管理 AI 工作者的人。

这里的管理，和开会、发号施令、传统管理岗都不是一回事。

管理的意思是：能定义目标，分配任务，提供上下文，识别失败，更新标准，最后承担结果。

你不是因为站在 AI 上面而安全，而是因为你负责 AI 还不能稳定负责的那部分：目标、标准、取舍和验收。

不要先问学 AI 编程还是学产品

所以以后不要先问，学 AI 编程更安全，还是学产品更安全。

这个问题仍然停在职业名上。

它像问“我应该买科技股还是消费股”，但完全不看公司现金流、估值、行业周期和管理层质量。职业名只是股票代码，决定风险的是底层资产。

你可以先问五个问题。

第一个问题：你的结果能否自动验收？代码能跑测试，表格能对账，数据能校验，格式能检查，交付物能被明确打分，这类任务更容易被 AI 练习。

第二个问题：任务能否拆成小闭环？一个大目标如果能被拆成很多小任务，每个任务都有输入、输出和完成标准，就更容易被分配给 AI 工作者并行执行。

第三个问题：上下文是否结构化？文档、代码、数据、历史记录、接口、约束都清楚，AI 就更容易接手。

如果上下文全在某个人脑子里，模型很难稳定工作，但这不代表安全，只代表组织还没把上下文整理出来。

第四个问题：失败能否低成本纠错？失败以后能重跑、回滚、复盘、再试，AI 就会进步得更快。

如果失败一次成本很高，反馈很慢，风险就会晚一点暴露。

第五个问题：你是否拥有标准设定和取舍责任？

前四个答案越是“是”，而最后一个答案越是“否”，你手里的那部分工作就越容易站在第一排。

反过来，如果你能定义问题、组织上下文、设定验收、承担取舍，AI 进入以后，你反而会被放大。

你能让一个模型变成十个执行线程，让模糊问题变成可验证任务，让失败变成下一轮反馈。

这种人不会因为 AI 能写代码或写文档就消失，至少不会在同一条线上被简单压缩。

职业榜单还是会继续流行。原因也简单：它把复杂的任务风险压成身份命运，方便转发，方便站队，也方便让人暂时松一口气。

但真实的 AI 改造不按这个逻辑走。它不先问你是什么职业，而先问你的工作能不能被评价、复盘和重来。

姚顺宇的判断给这篇文章留下的，不是一张职业排名，而是一套更冷静的看法：

不要把职业名当护身符，也不要把某个工具当灾难本身。

AI 改造工作的顺序，更像是在寻找反馈最清楚的地方。

哪里能定义任务，哪里能观察过程，哪里能验收结果，哪里能低成本纠错，哪里就会先被推快。

程序员只是第一排。问题是：你的工作有没有正在被改造成 AI 喜欢的形状？

参考与引用来源

感谢张小珺完成这场对姚顺宇的长访谈。本文关于 AI 编程、产品判断、反馈信号和工作重构的理解，主要来自这场公开访谈；我在文中负责把这些判断转译为职业风险和个人工作方法框架。

张小珺 / Yao Shunyu 访谈：《Let Me Go a Little Crazy! Training Models at Anthropic & Gemini》
Cursor 官方文档：Cursor Docs
Anthropic 官方文档：Claude Code Docs
GitHub 官方文档：GitHub Copilot；GitHub Docs 中关于 repositories、issues、pull requests、reviewing proposed changes 的说明
Productboard：Product Requirements Document glossary
Atlassian：Understanding incident severity levels