AI时代，产品经理和开发人员的职责区别

AI 出现以后，一个很有意思的现象是：产品经理越来越能“开发”，开发人员也越来越能“做产品”。

以前产品经理想验证一个想法，通常要先写需求、画原型，再找开发实现。现在借助 AI，一个不会写多少代码的产品经理，也可以自己写 Prompt、做 Skill、生成页面，甚至快速做出一个能运行的 Demo。

于是一个问题开始变得越来越模糊：

既然产品自己都能做出来了，还要开发干什么？

我们最近在做信息可视化，刚好就讨论到这个问题。

产品负责的，不是“提需求”，而是领域知识

在 AI 时代，产品经理最重要的价值，不应该只是写 PRD、画原型或者描述交互，真正重要的是：

理解业务，并把业务知识变成 AI 可以执行的规则。

比如我们要让 AI 自动完成财报解读，真正困难的并不是“调用哪个模型”，而是：

一份财报应该关注什么？
哪些数据最重要？
不同行业应该怎么看？
什么情况下应该展示图表？
哪些信息应该重点突出？
最终什么样的结果才算“有价值”？

这些东西本质上都是领域知识和业务方法论。

以前这些知识可能存在于产品经理的脑子里，最后会被翻译成 PRD。现在，它们越来越可能直接沉淀成：

Prompt
Skill
Rules
Workflow
Evaluation Criteria

换句话说：

产品经理正在从“需求描述者”，变成“领域知识的生产者”。

产品的核心产物，也开始从 PRD 逐渐变成一套能够被 AI 理解和执行的领域知识系统。

开发负责的，也不再只是“把需求写成代码”

如果产品经理已经可以借助 AI 做出 Demo，那么开发人员的价值在哪里？

答案恰恰不是：

“我比产品经理更会写代码。”

因为“写出一段代码”这件事本身，借助越来越强的AI Coding工具，对任何人来说，都已经不再是问题了。真正体现开发价值的，是把一个偶尔成功的 Demo，变成稳定运行的系统。

一个产品经理可能花半天，通过不断调整 Prompt，可以让 AI 得到一个非常漂亮的结果。

但是：

换 100 篇文章还能成功吗？
一天处理 10 万条数据还能运行吗？
模型偶尔输出错误怎么办？
格式突然发生变化怎么办？
怎么自动检测质量？
怎么重试和降级？
下一个业务接进来是不是还要重新做一遍？

这些才是开发真正需要解决的问题。

具体来说，开发要解决三个产品解决不了的问题：

1. 工程化 / 批量化

产品可以花一下午手工调出一个漂亮的Demo，但Demo无法批量运行。开发要做的，是让系统能够每天处理上百篇输入，自动输出完整的可视化页面，且无需人工干预。这不是简单的“调接口”，而是涉及任务调度、并发控制、资源管理、异常恢复等一系列工程问题。

2. 稳定性

LLM的输出天生具有不确定性。同样一份研报，今天跑和明天跑，输出的图表颜色、段落顺序可能完全不同。产品可以接受这种“随机的惊喜”，但业务不能。开发需要建立：

输入约束（什么格式必须满足）
输出校验（结果是否完整、是否符合Schema）
异常检测（模型是否“胡说八道”）
一致性控制（同类输入输出尽量稳定）这些不是靠“写更好的Prompt”能解决的，而是要靠程序逻辑、规则引擎、质量评估链路来兜底。

3. 泛化与快速扩展

当第一个业务场景跑通后，老板会问：“第二个业务什么时候能上？”如果每接入一个新业务都要从头搭一套链路，开发的价值就只是“重复劳动”。真正的系统能力在于：

新业务只需插入一个新的Skill，就能复用所有公共链路——内容解析、视觉生成、校验、输出。 这就是开发的终极目标：把业务知识从代码中剥离出来，让系统成为Skill的容器，而不是某个业务的特制工具。

一个很重要的分界线

所以可以用一句话定义两者的区别：

产品负责把业务变成知识，开发负责把知识变成能力。

或者更具体一点：

产品负责领域知识，开发负责系统能力。

产品回答的是：

这个业务到底应该怎么做？

开发回答的是：

怎样让它稳定、批量、低成本地一直做下去？

这比传统的：

产品负责“What”，开发负责“How”

又更进一步。

因为在 AI 时代，产品实际上已经可以参与很多“How”。

而开发也必须理解“What”，否则很容易设计出一个技术上非常漂亮、实际上却无法落地的抽象系统。

边界并不是一堵墙

这里还有一个很容易走向极端的地方。

既然产品负责领域知识，是不是开发就完全不需要懂业务？

恰恰相反。

特别是在一个新业务刚开始的时候，开发应该深入参与第一版 Skill 的建设。

因为如果没有真正做过业务，就很难知道：

哪些东西是业务特有的；
哪些东西可以抽象；
哪些异常一定会发生；
哪些规则应该留在 Skill；
哪些能力应该沉到底层系统。

如果一开始就急着“做平台”“做通用能力”，最后非常容易做出一个：

看起来高度抽象，实际上谁都不好用的系统。

所以更合理的路径应该是：

先深入一个业务，再从业务中抽象系统。

第一遍，产品和开发一起把业务真正跑通。

第二遍，开发开始寻找其中稳定的公共模式。

第三遍，再逐渐把新的业务交给产品通过 Skill 接入。

AI 越强，人越需要判断力

AI 时代还有一个容易被忽略的问题：

AI 可以帮我们生成东西，但不会自动告诉我们什么是好的。

比如让 AI 做一个页面。

发现不好看，就继续说：

再高级一点。

还不好看：

再优化一下。

继续不好：

再换一种风格。

这其实是一种非常危险的工作方式！

因为整个过程中，人没有自己的判断标准，只是在不断等待 AI “抽奖”。

真正成熟的系统应该建立自己的标准：

什么叫好？
为什么好？
哪些指标可以判断？
什么结果应该拒绝？
什么情况下应该重新生成？

所以 AI 越强以后，无论产品还是开发，有几种能力反而会越来越重要：

领域知识、品味、判断力和架构能力。

AI 可以快速产生答案，人的职责，是判断答案。

最后的变化

过去的软件开发流程，大致是：

产品定义需求 → 开发实现需求。

我认为 AI 时代会逐渐变成：

产品沉淀领域知识 → AI 执行 → 开发构建稳定的生产系统。

产品不应该停留在“告诉开发做什么”。

开发也不应该停留在“把产品需求写成代码”。

两者最终会形成一种新的协作关系：

产品把专家经验变成可执行的知识，开发把这些知识变成可以规模化运行的系统。

这可能才是 AI 时代产品经理和开发人员真正的职责边界。