当业务也能手搓 Demo 时，产品经理该走向何处？

3 月的某个下午，我和业务同事约了一个需求沟通会。

正常流程是他说需求、我问问题，然后我去整理成方案。但这次会开到一半，他打开笔记本说："我自己通过 Claude，针对需求设计了一个产品方案，我觉得这个方案很符合我的预期，你看看。"

屏幕上是一个完整的管理后台。深色侧边栏，包含 Dashboard、Discover Creators、Creator Profiles、Campaigns，搜索框、数据卡片、Campaign performance、Top performing creators、Live campaigns 等模块。页面里写着 "Search 24M+ verified profiles across Instagram, TikTok & YouTube"，表格里有 creator 名字、audience 数据、engagement 率、invite to campaign 按钮。这些文案和字段不是随手填的，能看出来他对行业术语很熟，知道这个平台该有哪些模块。

4 个小时做的。让我有点意外的不是速度，是结构——Discover Creators、Campaigns、Performance Tracking 三段串下来，覆盖了 influencer marketing 的完整主流程，不是几个孤立页面拼在一起。

那一刻有两个念头，几乎同时：

AI 真的在拓宽人的边界——这件事以前只有产品经理能做，现在业务自己做出来了。

产品经理这个岗位，以后还需要吗？

背景

在这件事之前，我接一个新需求的工作流是这样的。

业务沟通（0.5-1 天）→ XMind 梳理（0.5 天）→ Axure 原型（1-2 天）
→ UI 评审（0.5 天）→ UI 出稿（1-2 天）→ 研发评审（0.5 天）
→ 开发（N 天）→ 验收 → 上线

这条流程很标准。业务说的是目标、场景、痛点；研发关心的是结构、字段、状态、边界。产品经理站在中间，翻译两次。这套流程里最慢的是等，等 UI 排期，等评审，等研发把原型做出来，中间任何一个人没空，需求就停在文档里。

我以前觉得，这是产品经理很重要的专业性。

但现在，这个中间层变薄了。

一个足够懂业务的人，只要能把背景、目标、角色和限制条件说清楚，就可以和 AI 反复对话，让 AI 帮他补流程、补页面、补信息结构，再用 Claude Code 直接生成 demo。难点从工具操作，转移到了能不能把事情说清楚。

这个 demo 未必严谨。它可能没有考虑权限，可能没有考虑数据来源，也可能对异常状态想得很浅。可是它足够让需求讨论提前进入"产品形态"，这在过去是 PM 才能做到的事。

为什么这次不一样

如果只是一个研发同学用 AI 写了点代码，我可能不会这么敏感。研发本来就离代码近。

但这次是业务同学。GTM、业务、增长、销售这些角色，本来就更靠近客户和市场。他们知道客户为什么买单，知道哪个场景最痛，也知道内部推进卡在哪里。

过去，他们就算很懂业务，也缺一道工序，把需求快速变成一个可以看的东西。他们需要产品经理来中转。

现在这个门槛被 AI 拉低了。

AI 不一定直接替代产品经理。但它会让很多人越过产品经理原来的边界。懂业务、也懂 AI 的 GTM，会越来越有能力直接定义产品形态。如果产品经理还停在等业务抛需求、再输出原型或 PRD 的位置，处境会变得尴尬。别人不一定需要一个"需求转述者"。

这是我在这个团队里观察到的一次。那位同事刚好是业务理解深、又愿意动手试 AI 的人——这类组合目前还不普遍，但门槛在降，只是快慢的问题。

产品经理的价值不会消失，但定义它的东西变了，不再是会不会画原型。

Demo 的边界

有一件事我必须说清楚，不然这篇会被理解成"又一个人鼓吹 demo 万能"。

Demo 能验证的，是用户路径是否合理、信息是否完整、业务方看到的东西是不是他想要的。但 demo 验证不了数据来源、权限控制、异常状态怎么兜底、这个方案和已有系统能不能兼容。

当方案涉及复杂系统联动时，跳过抽象设计直接上 demo，反而可能把关键设计问题藏起来，大家看着"好像没问题"，就开始讨论排期了。权限、数据来源、异常状态这类问题，在 demo 里看不出来，等开发到一半才暴露，返工成本比设计阶段高得多。

所以 demo 和文档是互补关系。但它确实改变了一件事，讨论终于可以落在屏幕上了，而不只是在文档里想象。

后续

那个下午之后几个月（2026 年 4 月到 6 月），我开始做几件具体的事。

第一个是 spec-analyze（GitHub）——把接需求的分析过程写下来：12 步流程、4 道质量门禁，输出 proposal、design、tasks 三份文档，带三层研发注释。第一版提交于 5 月 26 日，566 行单文件，G1 上下文完备，G2 收敛完成，G3 输出准备，G4 自检完成，路径分 Lightweight、Standard、Full 三条。当天就发现太长，先压到 254 行，再拆成 8 个文件。后来的结构都从这一版长出来的。

spec-sdd（GitHub）和 project-knowledge（GitHub）跟在后面——前者管 AI 辅助开发的三阶段工作流规约，后者让 AI 进项目几分钟就能接上上下文。

MatchInfluence 是另一个方向：4 个 agent 做 influencer marketing 全流程自动化，Strategy 定 KPI 和预算，Sourcing 找人，Tracking 看效果，Orchestrator 调度，agent 之间用结构化数据通信，不让偏差在传递里累积（系列第 5 篇）。还有 ai123.com，完全靠 vibe coding，两个月从 0 到 1。

这几件事有一个共同点：把产品经理的判断拆成可执行的规则。

反思

回到那次需求沟通会。

那个 demo 给我的刺激就在这里。它不完美，但已经足够说明问题，产品表达能力正在扩散，产品经理原来的边界正在变松。

我后来想，这个担心来自一个具体的变化。把想法变成可以看的东西，这一步的门槛被 AI 降到了几乎为零。

Axure 和传统产品流程在很多时候仍然有价值。严谨的 PRD、清晰的流程图、低保真原型依然有用。但我确实很难回到过去那种状态，很难再把"画完原型"当成方案输出的终点，因为我知道这可能是效率最低的一步。更难的是假装 AI 不会持续降低"把想法变成体验"的门槛，业务同学越来越熟练只是时间问题。

从那次会后，我做的第一件事是写 spec-analyze，把需求分析流程拆成可执行的规则。变化已经来了，我想先接住它。

最难的是明明看到了变化，却什么也不做。