AI时代代码确实变得更便宜了但产品经理的核心壁垒不是因为代码贬值而消失而是换了一种更明确的形态能不能把模糊问题定义成可执行、可验证、可取舍的产品判断。这个标题最近在不少产品群里被反复讨论我也一直在跟踪 AI 编程工具在实际项目里的落地边界今天想从产品经理视角把这件事拆透。先给一个不那么讨巧的结论代码本身没有被彻底“去价值化”被削弱的只是“从无到有生成一段能跑的脚本”的难度。真正值钱的从来不是代码字符串而是代码背后的问题定义、业务约束、用户场景、验收标准和维护责任。产品经理如果只把“我会不会写代码”当成衡量自身价值的标尺那确实容易被 AI 冲击但如果把核心竞争力放在“我能不能说清楚做什么、为什么做、怎么做才算成功”AI 时代反而是话语权更强的时期。下面按我实际带团队、评审需求、和研发协作时验证过的顺序把这套判断标准拆开讲。1. “代码不值钱”是一句被误解的判断1.1 AI 降低的是生成成本不是维护成本很多人看到 AI 编程工具几秒钟生成一段示例代码就得出“代码不值钱”的结论。这个判断只对了一半。AI 确实把“写代码”的边际成本压低了。以前一个页面原型可能要写一个下午现在让大模型生成一版初稿只要几分钟。过去要查半天文档的常见函数现在直接问 AI 就能得到可运行版本。这个变化是真实的也是为什么“示例代码讲解”“AI 编程”“Cursor AI 编程”这类词在开发者社区里热度一直很高。但软件生产从来不是“把代码写出来”就结束。代码写出来之后还要处理异常、边界条件、权限控制、日志记录、数据一致性、上线后的问题定位和持续迭代。这些成本不会因为 AI 生成速度快而消失有些甚至因为代码来源不可控而变高。我见过一个团队让 AI 快速生成了核心交易模块的初版代码单看第一次运行确实很顺畅结果一接入真实支付回调立刻暴露出签名校验缺失、重复通知处理不到位、日志不足以定位问题三个坑。这三类问题没有一个是大模型能替团队提前决定的它们需要在产品设计阶段就把规则想清楚谁允许调用、失败怎么办、重复请求怎么处理、对外展示什么信息。所以更准确的说法是AI 降低了“从 0 到 1 生成代码”的成本但没有降低“从 1 到 100 维护系统”的成本。产品经理如果只盯着生成速度就会误判技术团队的真实工作量。1.2 判断代码还值不值钱先看出错后的损失我在评估一个需求是用 AI 生成代码还是让工程师精雕细琢时会用最简单的一条标准这段代码出错后的损失有多大如果是一个内部工具、一次性脚本、活动页原型、Demo 演示出错后刷新重来就行那它确实可以用 AI 快速生成代码本身的“单向价值”不高。产品经理不需要在这里纠结代码贵不贵重点是验证想法有没有人用。如果是登录鉴权、支付流程、数据导出、用户隐私处理、核心算法策略出错后直接影响用户信任甚至引发合规风险那代码就非常值钱AI 生成的内容只能作为参考必须经过严格评审、测试和回归。产品经理要在需求文档里明确这些边界不能让研发拿“AI 都能写出来”作为降低质量控制要求的理由。这就是“代码不值钱”成立与不成立的边界写错成本低代码就不值钱写错成本高代码依然非常值钱。产品经理真正的能力是能提前判断哪些地方允许低成本试错哪些地方必须高标准交付。2. 产品经理真正的壁垒在不确定性里定义问题2.1 AI 能生成 PRD但不能替你定义“真正的问题”市面上已经有不少工具可以基于一句话需求生成完整的产品需求文档功能列表、用户故事、验收标准都能写出来。乍一看产品经理好像要被替代了。但实际用几次就会发现AI 生成 PRD 的前提是有人已经把问题背景、目标用户、典型场景、约束条件、判断标准说得足够清楚。换句话说AI 是优秀的文档整理器不是合格的问题定义器。它能把你的半成品思路变成结构化的文档但不会替你想清楚“这个功能为什么存在”。我接触过不少需求评审会最常见的失败场景不是文档格式不行而是会议开完研发问“这个需求到底要解决什么问题”产品经理回答“就是用户想要一个 XX 功能”。这句话等于没有定义问题。真正的定义问题至少要包含五个要素目标用户是谁是全部用户还是某类细分人群使用场景是什么用户当时在做什么、遇到了什么阻碍当前没有这个功能时用户是怎么凑合解决的做完之后怎么判断成功是使用率、留存、客单还是时长哪些场景明确不做哪些边界必须排除AI 可以帮你把这段话整理得更通顺但它不会自动知道你的用户是谁。这个信息的来源只有两种一种是产品经理自己做的用户研究另一种是产品经理和业务方反复对齐后的判断。后者恰恰是没法外包给大模型的部分。2.2 用一张小表代替冗长的需求模板我团队里现在不强制要求产品经理写大而全的 PRD反而要求每个人在需求评审前先填一张小表不超过六行问题用户在什么场景下遇到了什么具体问题用户主要影响哪类人次要影响哪类人现状没有这个功能之前用户如何应对目标功能上线后可观察到的用户行为变化是什么验证用哪个指标判断成功边界哪些诉求这次明确不解决这张表填得出来需求评审大概率能顺利推进。填不出来问题往往不是“文档没写好”而是产品经理自己没想清楚。这时候强行让 AI 生成一份漂亮的 PRD只会把不确定问题包装成确定问题最后在开发阶段又被打回原形。产品经理的核心壁垒不是会写文档而是能在充满噪音的需求里找到真正值得解决的问题。这个能力在 AI 时代不会贬值反而会因为“生成文档太容易”而变得更加值钱。3. 用户洞察问卷调查替代不了行为证据3.1 用户说的不一定是他真正做的AI 时代有一个隐蔽的陷阱产品经理很容易拿到大模型生成的大量用户画像、需求分析、竞品报告看起来很有道理但往往经不起真实行为验证。用户访谈里经常出现一种情况用户为了礼貌或者为了显得自己很理性会告诉你“我觉得这个功能很好如果上线我一定会用”。结果功能上线后数据一动不动。原因很简单用户在被问到“你会不会用”的时候回答的是想象当中的自己而不是真实场景里的自己。所以我在做需求验证时更相信行为证据而不是口头承诺。行为证据包括用户当前是不是已经在用某种替代方案用户是不是愿意为这个能力付出时间或金钱用户在使用流程里有没有明显的卡点有多少人因为某个问题流失。产品经理的壁垒在于能发现别人看不到的细节。比如用户反复提到“这个操作太麻烦”但真正的麻烦也许不是按钮位置而是用户不知道什么样的输入会得到什么样的结果。如果没有真实现场观察很容易被表层话术带偏。3.2 用最小验证问题代替功能清单每当我听到“我们要做一个新功能”时第一反应是先问一句这个问题值不值得解决怎么验证它值不值得最简单的方式是把这个需求变成一个行为假设“如果我们在某个页面增加一个入口那么会有多少比例的用户在第一次访问后七天内再次使用”一个可以验证的假设比一个洋洋洒洒的功能清单更有价值。我还建议产品经理养成一个习惯定期看客服记录、用户差评、竞品论坛和产品内搜索词。这些东西比内部讨论群更早暴露真实需求。AI 可以帮你总结这些内容但总结的前提是你知道要去哪里找以及哪些信号代表机会哪些信号只是噪音。4. 决策力和取舍AI 给不了的东西4.1 信息不全的时候也必须拍板作为产品经理很多决策是在信息不完整的情况下做出的。AI 可以帮你列出三个方案各自的优缺点但它不会替你承担选择后的结果。举个例子一个功能可以做深也可以做浅。做深意味着投入更多研发资源做浅则可以快速上线验证。AI 大概率会告诉你“快速验证更稳妥”但真实决策要复杂得多团队当前节奏、下个月有没有重要发布、这个功能对老用户的影响、营销团队有没有配套计划这些上下文 AI 没有也无法自动收敛成一个决定性结论。产品经理的核心壁垒之一就是“在模糊中给出能执行的答案”。这里的答案不只是“做或者不做”还包括做多少、做到什么程度、哪些部分可以延后、哪些部分必须一次到位。这个决策过程需要产品经理对成本有感知对风险有预判对团队状态有了解。4.2 用价值、成本、风险三个维度做取舍我自己的需求优先级排序不会只看“用户价值”而是把价值和成本、风险放在一起看。价值这个功能让用户获得什么让产品获得什么成本开发工作量、设计成本、测试成本、上线后的运营成本风险数据安全、合规、用户信任、技术可行性、对现有功能的影响价值高、成本低、风险小的需求优先做。价值高、成本高、风险可控制的需求拆成小版本分步做。价值一般、成本高、风险大的需求除非战略需要否则坚决砍掉。这套方法看起来简单但执行起来非常依赖产品经理的领域知识。比如一个金融类产品和一个内容社区产品对“成本”和“风险”的定义完全不一样。AI 能给你一个通用分析框架但具体业务里的关键约束只能靠产品经理自己积累。这就是 AI 时代产品经理壁垒里很隐形的一块别人看不出来你究竟懂不懂业务但每一个决策都会暴露。5. 与技术团队协作懂技术但不是为了自己写代码5.1 懂技术的正确姿势是理解边界不是比拼语法很多产品经理会纠结要不要学编程。我的建议是不一定非要写到能独立交付的程度但一定要理解技术分工、数据流转和系统边界。你需要知道什么是 API、什么是数据库、什么是模型上下文、什么是 Token、什么是延迟和并发不是因为你必须自己写接口而是因为你要和研发团队在同一个语境里沟通。当研发说“这个功能要处理大量并发成本会很高”的时候你要能判断这是技术借口还是真实瓶颈。我自己在评审需求时经常让产品经理描述一遍用户操作路径。比如用户点击一个按钮后系统需要哪些数据调用什么能力等待多久失败后展示什么。如果产品经理能把这条链路说清楚研发不仅会觉得沟通顺畅还能提前发现很多设计漏洞。懂技术的另一层价值是能对 AI 生成的内容形成判断力。现在很多内部工具都接入了大模型会输出各种各样的生成结果。产品经理如果不知道模型有“幻觉”问题不理解为什么有时候答案不稳定就会拿一个充满不确定性的结果去给用户承诺最终变成事故。5.2 用验收标准代替“你看着做”和技术团队协作时我最强调的一件事是写清楚验收标准。不要写“AI 能回答用户问题”这种描述等于没有标准。要写成“当用户输入一个包含具体产品名的问题时系统返回的结果必须包含产品相关介绍并且不能给出与产品无关的推荐”。这样研发才能测试测试才能判断是否通过产品经理后续做验证也有依据。一个可执行的验收标准通常包括输入条件、处理逻辑、输出格式、边界情况、性能要求、失败提示。产品经理不需要写出具体代码但要把这些约束描述到研发可以直接落地的程度。这就是产品经理的技术素养它比“会写几段示例代码”重要得多。我经常用一个简单公式回答产品经理要不要学代码你能用一段自然语言把用户操作、系统判断、异常兜底讲清楚说明你已经具备基本的技术沟通能力。如果你还能把这段描述里的变量、条件分支、返回结果对齐那你在 AI 时代的技术协作能力就已经超过大多数只背概念的产品经理。6. 排查清单AI 时代产品经理最容易踩的坑6.1 五个真实常见的坑先列出我在实际项目里见过最多的五个问题每一个都值得产品经理拿来自查。第一个坑把“我不会写代码”当成一种不需要改变的状态。过去这可能是合理分工但现在 AI 工具把技术门槛降低后产品经理至少应该会描述逻辑、会看数据、会提初步的技术方案方向。依然完全不懂不代表安全反而意味着你和团队之间会多一层认知损耗。第二个坑用 AI 生成的 PRD 替代思考。文档越来越漂亮问题定义越来越模糊。评审时每个人都觉得文档写得不错但没人能说清楚为什么要做。这个坑尤其隐蔽因为表面上看流程很顺。第三个坑让 AI 写原型、写代码结果需求本身没验证。AI 能快速生成“看起来能用的东西”但生成物的背后没有真实用户反馈没有数据验证。急于展示 Demo 会带来一种“我们已经做完了”的错觉实际上距离解决问题还很远。第四个坑功能上线后只看“有没有 bug”不看“有没有人用”。产品经理的核心责任是结果不是交付。交付只是第一步用户是否有行为变化、是否愿意持续使用才是更关键的回传信号。如果上线两周后没有任何行为数据变化这个功能大概率没有解决真实问题而不是“用户还没习惯”。第五个坑缺少领域知识被 AI 的错误输出带偏。AI 生成市场分析、用户需求、竞品信息时经常会一本正经地给出错误数据。产品经理如果没有领域常识很难发现这些错误最后把错误结论带到产品设计里。6.2 问题排查的推荐顺序当产品出现问题不管是新功能没起色、用户反馈差还是研发说需求不清晰我建议按这个顺序查先看问题定义再看用户行为然后看验收标准接着看数据指标最后才看技术实现。很多团队一上来就怀疑技术方案有问题急着让研发优化模型、加服务器、调参数。但实际排查下来大多数问题的根源都在更前面需求定义时就没想清楚给谁用或者上线后没有埋点导致完全不知道用户是怎么使用这个功能的。举个通用案例假设产品做了一个 AI 智能问答助手上线后使用率很低。正确排查顺序是用户入口够不够明显知不知道这个功能存在第一次打开后的引导是否清楚用户会不会用提出的问题能否得到有效回答回答质量是不是太差回答质量足够的情况下用户是否觉得这个功能解决了真实问题都排除之后再看系统延迟、错误率、成本消耗只盯着“模型效果不行”去优化很可能忽略了前两步的入口和引导问题。产品经理的价值就是能把这个排查链路拆出来而不是被问题表面带走。6.3 一个可持续使用的闭环清单最后留一个我自己长期使用的闭环清单每次负责一个从 0 到 1 或者重要迭代时都会按它过一遍问题定义能不能一句话说明用户困境、发生场景和希望获得的变化目标指标上线后哪个数字变好才能说明价值成立最小版本砍到哪些功能不做也能完成基本验证验收标准研发完成后谁来测、怎么测、通过标准是什么数据埋点需要记录哪些行为是否覆盖完整路径上线节奏小范围放量还是全量发布什么时候看数据迭代判断保留、优化还是下线依据是什么这套清单很朴素但它恰好对应了 AI 时代产品经理最稀缺的能力把想法变成可验证的路径而不是停留在“我觉得用户需要”。代码可以由 AI 来写但“为什么做、做什么、怎么算好”这组问题永远需要有人负责。这就是核心壁垒而且短期内不会消失。