前几天一个做产品经理的朋友跟我说他刚用 AI 把一个内部报表页面做完了。老板看了一眼半开玩笑地说“这玩意儿现在这么便宜了吗”朋友有点慌跑来问我代码是不是不值钱了产品经理以后还能干什么我的回答是代码字符串确实在贬值但“代码”这件事并没有。真正值钱的东西不是那几行能跑起来的文本而是你为什么要写这几行、你拿它解决谁的什么问题、什么程度算真的完成。AI 能生成语法但生成不了上下文。这一句话就是整篇文章的主判断。这个变化的冲击力比听起来要大。因为它不只是影响程序员也直接影响产品经理、运营、设计、测试甚至几乎所有和信息产品打交道的人。过去我们以为产品经理不写代码没关系因为有人能把需求翻译成代码现在 AI 已经能直接翻译了那产品经理的价值到底还在哪里这是今天真正值得想清楚的问题。1. 为什么“代码不值钱”这句话只说对了一半1.1 编程门槛确实在被快速拉平过去几年从 GPT 类模型到各种 AI 编程助手再到像 Cursor 这样的 AI 原生编辑器变化是肉眼可见的。以前一个普通的信息展示页面前端至少要写半天现在用自然语言描述清楚字段、布局、交互AI 能在一两分钟内给出一个可运行的初稿。这确实让“写代码”这个动作的边际成本大幅下降。很多团队已经开始尝试不同分工方式。比如运营或产品先用自然语言生成原型逻辑基础开发任务由 AI 辅助完成。这个变化带来的直接结果就是一线编程岗位里那些“照着需求搬砖”的部分正在被压缩。不是没有接口了而是接口变了。如果一个程序员把全部核心能力定义成“把 PRD 翻译成代码”那确实会在这个浪潮里感到焦虑。同样的道理也适用于产品经理。如果把核心能力定义成“画原型、写文档、跟开发传话”那 AI 确实能替代掉其中大部分。问题在于很多人把这句话理解成了“产品经理整个岗位都没用了”于是陷入了一种工具焦虑担心自己不会写代码是不是就要被淘汰。1.2 但代码的价值从来不只在代码字符串本身回到那个报表页面。如果只是让 AI 生成一个静态表格它确实几分钟就能给你。可这个页面上线后要面对什么哪些人看数据口径怎么定义访问权限怎么分周末没人值班时出了故障怎么办这些约束不会因为你用 AI 生成代码就自动消失。代码只是载体它承载的是业务规则、边界条件和异常处理逻辑。同样的一个列表页在学校课程设计里和银行对账系统里价值完全不是一个量级。前者跑起来就算成功后者要处理权限、并发、审计、失败重试、数据一致性。AI 可以把基本形态生成出来但行为的正确性、合理性、风险控制仍然需要人来定义和验收。所以我的判断是AI 确实让“施工”变便宜了但没有让“设计图纸”变便宜也没让“验收标准”变便宜。如果你只会“把需求变成代码”这个能力确实在贬值如果你能“定义清楚问题并判断结果对不对”这个能力不但没有贬值反而因为生成效率和试错成本降低而显得更贵。2. 真正被 AI 压缩的是产品经理的“表达层”不是决策层2.1 原型、文档和流程图正在变成 AI 的天然生成物以前产品经理的核心交付物经常被理解为需求文档、流程图和原型图。这些交付物的本质是什么是把一个复杂问题的解决方案用一种协作各方都能看懂的形式表达出来。AI 对文本、图表和结构化的理解能力非常强这些恰恰是最容易被自动生成的部分。现在你用 AI 工具把用户角色、目标、操作路径和异常状态描述清楚它可以很快给你出一版结构化需求和原型草图。这意味着那些“把脑子里的想法倒出来画成图”的技能价值在快速下降。一个只靠“文档写得好”“原型画得漂亮”吃饭的产品经理确实要紧张。但你需要同时看到另一面AI 生成原型和文档的前提是你先在脑子里把问题想清楚了。它需要你告诉它用户是谁、要解决什么痛点、为什么用这个方案不用另一个方案、成功标准是什么。这些信息如果 AI 不问你容易漏掉而恰好是这些信息才是产品经理真正的工作。2.2 决策层反而更贵了我见过很多类似场景产品经理拿着 AI 生成的代码方案去找开发说“AI 都能写出来你怎么还要两天”这句话听起来很合理实际上踩了一个大坑。AI 可能用两分钟写出来但没有人验证过它处理边界条件、异常输入和极端流量的表现。开发说的两天不是在打字而是在把一段“看起来能跑”的代码变成“确定能上线”的代码。这个从“看起来”到“确定”的过程不是打字成本而是判断成本。如果产品经理连这一点都不理解那他省下来的时间没有任何价值因为团队信任会被快速消耗。反过来如果产品经理能说清楚“这个页面的核心用户是早会期间的销售总监只看昨日达成率和异常 Top5宁可少展示也不能造成误解移动端打开时间要控制在 5 秒内。”AI 和开发都能更快地做出正确的东西。你提供的信息质量直接决定 AI 输出质量的上限。所以产品经理的核心动作不是“写需求”而是“定义需求和验收标准”。3. 产品经理真正的四个核心壁垒先说清楚哪种能力在变便宜、哪种能力在变贵。可以把下面这张表当成一个快速参照容易被 AI 压缩的能力难以被 AI 替代的能力常规代码实现问题定义和优先级判断需求文档初稿业务上下文理解流程图和原型草图验收标准和风险判断测试用例初稿跨角色协调推进信息检索和汇总对最终结果负责很容易被 AI 压缩的大多是信息处理和生成类工作很难被替代的则是判断、理解和责任。产品经理接下来要做的不是和 AI 比生成速度而是把精力集中到表格右边这一列。3.1 判断力在不确定里做取舍AI 可以给你十个方案但它不会替你做决定。做决定需要知道资源边界、公司阶段、用户质感、团队状态。同样两个功能先做哪个做到什么程度为什么不做第三个。这些取舍背后是价值观和现实约束的权衡。AI 可以分析利弊但最终“我选择什么”的担子仍然要人来扛。实际工作中不是每个需求都有完整数据。产品经理常常要在一个信息不完整、时间压力很大的局面里做出决定。这个能力没办法通过“多问几个 AI 提示词”获得只能通过大量真实决策和复盘积累。你需要清楚在资源有限时砍掉哪个需求比新增哪个功能更重要。3.2 业务语境知道系统为什么存在一个系统不是为了长得好看而是为了服务某个业务目标。产品经理如果理解不了商家为什么要用这个后台、用户为什么会在这里付费、销售为什么愿意录入线索那即便 AI 生成再漂亮的页面也只是空壳。举个例子。你让 AI 给一个后台系统加一个搜索结果排序功能AI 默认会按相关度或时间排序。但真正的业务场景里运营可能希望按“最近 7 天有活跃的客户”优先销售可能希望按“线索价值分级”优先客服可能希望按“紧急程度”优先。这个排序逻辑不在接口文档里而在业务现场。AI 不知道这些只有懂业务的人才知道。这种对真实业务语境的理解短期很难被 AI 替代。因为它需要长期泡在业务里理解各部门的利益点、用户的真实动机、组织的隐性规则。这个“在场感”是产品经理不容易被替代的壁垒。3.3 验收标准知道什么算好AI 时代验收能力会变成一个极其关键的岗位能力。因为生成内容变容易了我们不需要再去生产而是需要去筛选和判断。产品经理要能回答这个功能满足需求了吗边界情况处理了吗用户体验及格吗性能符合预期吗如果一个产品经理自己都说不清什么叫“好”那就只能被 AI 生成的结果牵着走AI 给什么就用什么最后做出来一个“看起来完整但不好用”的产品。真正的验收标准不是“有没有”而是“是否在真实场景下成立”。这个能力对开发者同样适用。代码能不能上线不只是看编译通不通还要看异常路径、安全、日志、可运维性。这些都需要人的判断。一个团队如果只有 AI 生成没有人验收那它本质上是在裸奔。3.4 协调推进让一群人一起往前走产品经理的另一个价值是推动协作。一个需求要落地往往涉及产品、研发、测试、数据分析、法务、客服等多个角色。AI 可以生成方案但不能代替产品经理召开评审、说服开发、安抚业务方、处理管理层预期。尤其是当方案不完美时产品经理需要让各方在信息不完整的情况下达成一致、继续推进。这种协调推进能力建立在对人的理解、对组织运转方式的理解上AI 短期很难替代。某种意义上产品经理承担的是“最终结果责任人”的角色。AI 可以帮忙生成一个方案但不能对方案上线后的用户投诉负责也不能对财务结算错误负责。责任仍然在具体的人身上。4. 开发者也不用慌“只会写代码”会被压缩“用代码解决问题”会更值钱4.1 对开发者的冲击是结构性的很多开发者听到“代码不值钱”会不舒服。但如果冷静看这不是“职业消失”而是“职业内涵在迁移”。就像以前打字员被个人电脑取代但电脑带来了一整条新的行业链条。现在 AI 把“实现”这个环节变便宜了真正值钱的是“实现之前的问题定义”和“实现之后的验证维护”。如果开发者每天的工作就是按需求文档实现接口没有参与需求讨论、没有理解业务、没有做架构设计那确实会越来越被动。因为你提供的打字能力AI 已经超过了大多数人。但如果开发者能借助 AI 更快地完成实现然后把时间花在更核心的事情上理解业务链路、设计扩展性好的架构、审查 AI 生成代码的正确性、完善监控与日志、处理性能和安全问题那他的价值不但没有降低反而会因为天花板变高而增长。4.2 AI 更像一个高水平的实习生而不是替代者我把 AI 理解成一个极其勤奋、知识面很广但缺乏业务判断力的实习生。它能把代码写得很快甚至写得像模像样但你不交代清楚它就会做错你让它优化它可能越改越复杂你问它隐患它能列出很多但不会主动为结果负责。这意味着团队里至少要有一个人能审查它的输出能看出哪里是在“一本正经地犯错”。这个审查者可以不是传统意义上的代码高手但必须懂业务逻辑、懂边界条件、懂正确性判断。这种新的技术素养比以前背 API 更值钱。从招聘角度观察现在更值钱的不只是“会写代码”而是“能不能让 AI 高质量地产出并确保它产出可靠”。这种能力的关键不是你背了多少快捷键而是你对问题的理解清晰到什么程度。4.3 给开发者的三条建议第一把 AI 当成结对搭档。不要因为它写得慢就全部手写也不要因为它写得快就全盘接受。让它出初稿你做审查、补充边界、加测试。第二加强系统层面的能力。代码不是终点部署、监控、日志、安全、数据一致性和可维护性才是。这些能力 AI 很难替你承担最终责任。第三尽量往前参与业务。如果你只被当成一个“接需求的人”确实容易被替代如果你能主动指出哪些需求在业务上不成立、哪些技术方案存在隐患那你就是在提供超越代码的价值。把 AI 当成一个高水平的实习生它可以写很多东西但最后签字确认的人必须是你。5. 不管你是产品经理还是开发都可以按这个框架练前面的分析如果落地到动作其实可以归纳成一套可复用的训练框架。我把它叫做“问题定义—方案生成—验收验证—沉淀复用”的四步法。这个框架看起来简单但真正执行起来会发现层层都是思考题。5.1 第一步把需求从功能清单改写成问题定义不要只说“我要一个报表页面”要说清楚谁会用、在什么场景用、解决什么决策问题、什么数据最重要、什么算成功。越清晰的上下文会让 AI 和协作者都更高效。这个环节不是写作题是思考题。如果你发现自己写不清楚说明你还没想清楚这不是 AI 能帮你省掉的。你可以把“功能清单”模式改成“问题卡片”用户是谁、场景是什么、当前痛点是什么、成功标准是什么、哪些边界不能碰。同一张卡片既给 AI也给人效率会高很多。5.2 第二步让 AI 完成初稿但不要让它直接面对最终交付无论写文档、写代码还是做原型第一步都可以先让 AI 出初稿。但初稿只是原材料。你要检查它是否覆盖了所有边界、是否符合业务语境、是否有明显错误。这个阶段的核心动作是“审查”不是“生成”。审查的时候可以问自己几个问题它理解我真正的目标了吗它假设了什么条件这些假设在我的场景里成立吗它漏掉了哪些异常情况如果这些问题答不上来就说明你对问题本身的理解还不够。一个有效的提醒不要让 AI 直接决定交付物。它可以做初稿但只有人才应该对最终质量负责。5.3 第三步用验收清单倒逼质量可以做一个简单的验收清单功能是否成立边界情况是否处理异常路径是否有提示性能是否可接受安全和权限是否考虑输出是否可解释、可维护不同项目权重不同但这份清单本身就是产品经理和开发者的共同语言。你越早建立验收思维越不容易被 AI 生成结果带着走。我见过一些团队开始建立“AI 生成物验收检查表”让产品经理在把 AI 生成的东西交给开发之前先过一遍。这个动作看似增加了流程实际上减少了后续返工。因为很多问题在 AI 生成阶段就已经存在了越早发现越便宜。5.4 第四步沉淀提示词和流程而不是沉淀一次性答案当你发现某类问题用 AI 解决得不错可以把有效的问题描述方式固化下来。比如你的业务里常见的权限规则、数据口径、页面规范整理成固定的提示词模板或校验清单下次直接复用。这样你能把 AI 变成团队工作流的一部分而不是每次从零开始沟通。这个沉淀过程本身也是在积累团队的知识资产。如果 AI 生成的结果不对不要先急着怪工具。按这个顺序排查先看你的问题描述是否清晰再看有没有把业务边界和约束条件交代清楚然后看输出格式和平台是否匹配最后才看是不是工具的能力边界。很多时候问题出在第一环。这套框架的适用边界也要说清楚。它适合信息展示、原型、文档、代码初稿、测试数据等生成工作但不适合直接承担高风险业务决策、复杂架构设计、安全责任和最终交付。AI 越快人的验收越重要这不是矛盾而是新分工。6. 剩下要做的不是学工具而是练判断现在可以回答开头的问题了。AI 时代代码字符串确实不值钱了因为生成成本趋近于零。但代码背后的“问题解决”依然值钱甚至更值钱。产品经理的核心壁垒不是比 AI 更会写文档、画原型而是能定义值得解决的问题、能在不确定中做取舍、能验收结果是否真的成立。很多人看到 AI 编程工具越来越强第一反应是去学各种提示词技巧、背工具用法。这个方向不是错但如果只停留在工具层很容易变成一种新的内卷。今天学会的提示词明天模型一更新可能就不生效这个编辑器还没吃透下个编辑器又来了。真正稳定的资产还是判断力和业务理解。我并不是说工具不重要。熟练使用工具当然能提高效率但它更像是一个运动员的体能训练不是比赛本身。比赛本身还是你如何定义问题、如何组织上下文、如何判断结果。6.1 给三类人的行动建议如果你是产品经理多逼自己把问题想清楚少把时间花在重复的描述性工作上。练习用一句话说出价值这个功能为谁解决了什么问题为什么是现在做。如果你的答案含糊AI 也帮不了你。如果你是开发者多去理解业务和系统少把 AI 当作躲避思考的工具。把 AI 生成的代码当成需要审查的代码而不是可以跳过测试的代码。如果你刚好