知乎热榜今天挂着一个问题：为什么不能由产品经理操作AI开发，把程序员全淘汰掉？提问的逻辑很顺——既然AI能写代码，那最懂需求的人直接对AI下指令不就行了，中间为什么还要隔一层程序员？
我把这个问题最近一周的相关报道和行业报告翻了一遍，发现答案有点反直觉：这个设想的一半已经在发生，而另一半，恰恰连AI最强的公司自己都不信。
对的一半：不写代码的人，确实已经在用AI开发了
10月8日发布的《State of AI Report 2026》里提到一组数据：OpenAI今年6月公布的研究显示，Codex的非开发类使用者增长快于开发类，个人和组织人群都是如此。也就是说，产品经理、运营、设计师这些人拿起AI编程工具的速度，比程序员还快。
这不难理解。做一个原型、搭一个内部小工具、写一段自动化脚本，需求方自己用AI完成，比写需求文档→排期→等开发→来回改，快得多。36氪本周一篇讲AI产品经理的文章也提到，现在对产品经理的要求不是会不会训练模型，而是能不能判断模型边界、API权限、评估成本这些真正影响产品决策的技术问题——技术判断力在往产品侧迁移，这是事实。
所以"产品经理操作AI开发"这半句，不是幻想，是现状。
错的一半：淘汰的前提是"开发=把需求翻译成代码"，但这个等式已经不成立了
问题出在后半句"把程序员全淘汰掉"。它默认程序员的工作就是敲代码，而敲代码这件事AI已经包了。可开发真正交付的从来不只是代码。
还是36氪那篇文章举的例子：业务方说"接入大模型，让客服自动回答退款问题"，这一句话里其实混着三个任务——解释规则（退款政策能不能直接答）、查询事实（用户的订单到哪了，模型凭什么知道）、执行动作（用户说帮我退款，系统能不能替他调用接口）。三个任务用到的数据、权限、风险和验收方式完全不同。AI答错了谁接住？重复点击怎么处理？接口超时怎么兜底？这些不是"下指令"能解决的，是工程判断。
腾讯新闻本周刊的一篇文章把这种新角色叫Builder：他的主要工作不再是亲自写代码，而是给AI设定目标、拆解任务、搭建测试验收标准，再安排多个AI角色怎么配合——有点像从程序员变成CTO，只不过指挥的不是人，是一支AI团队。你看，代码确实可以不亲手写了，但"定义什么叫做对了"这件事，反而更值钱了。
最有说服力的证据来自模型公司自己。《State of AI Report 2026》注意到，OpenAI和Anthropic今年5月都组建了企业部署服务公司，派前线工程师进客户现场，接入业务系统，把模型变成实际可用的流程，再持续维护。报告用苹果Genius Bar作比：AI需要自己的"天才吧"，帮人们选工具、完成设置。全球最有能力提供AI的两家公司，没有一家认为"客户自己对着AI说说需求就够了"——它们反而在加重工程师的分量。
真正的答案：不是谁淘汰谁，是岗位在合并
所以这个问题从一开始就问岔了。它预设了"产品经理"和"程序员"是两个固定的筐，AI来了之后往哪个筐里倒。而实际发生的是筐本身在消失：开发、测试、发布、运维的角色在合并，产品思维强、沟通能力好的开发者可以把产品经理的活一起承担；反过来，不懂验收和边界的"纯需求翻译者"，才是真正被AI挤掉的那个人。
被AI淘汰的从来不是程序员，是"只会把需求原样转述给下游"的工作方式——无论这个下游是人还是AI。
这对不写代码的普通人同样成立。你让AI做海报、写方案、处理表格时，本质上就是在扮演那个"操作AI开发的产品经理"。想让产出靠谱，秘诀和工程师转型Builder是同一件事：动手之前，先把验收标准写下来——做成什么样算对、哪些情况必须人工确认。标准清楚了，AI是高效的施工队；标准模糊，AI就是一台高速生产返工品的机器。
我在 spark1.cn 的工具链页面（/toolchains）整理过一批"先定验收、再让AI执行"的工作流模板，写作、数据处理这些非编程场景都能直接套用，有兴趣可以去翻翻。
工具的门槛会越来越低，判断的价值会越来越高。这一点，对产品经理和程序员是公平的。
评论