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

2026 年 3 月，我所在团队（约 30 人，GTM + 产品 + 研发混合）的一位业务同事，用 Claude Code 花了约 4 个小时，做出了一个 Creator Intelligence 平台的管理后台 demo。 他带着这个 demo 来找我对需求。

那是我第一次意识到，产品表达能力正在扩散。

事件

demo 是一个完整的后台界面，深色侧边栏，包含 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 按钮。这些文案和字段不是随手填的，能看出来同事对行业术语很熟，知道这个平台该有哪些模块。

这个 demo 是用 Claude Code 生成的，用了 4 个小时，约 1200 行代码。放在以前，等产品经理出 Axure 原型、UI 出稿、研发出 demo，4 周都不一定够。

我的第一反应是，产品经理这个岗位是不是可以不再需要了？

因为这本来很像产品经理会做的事，理解业务需求，拆成页面和流程，再拿一个交互原型和业务讨论需求。但现在业务同事自己就做出来了这个"原型"，带着交互、带着内容，可以点开看，也能直接拿来评审。

背景

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

业务沟通（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 的位置，处境会变得尴尬。别人不一定需要一个"需求转述者"。

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

Demo 的边界

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

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

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

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

后续

在那之后几个月（2026 年 4 月到 6 月），我做了一些具体的事。

1. spec-analyze（GitHub），把需求分析流程标准化，输出带三层研发注释的规范文档，让 AI 和人都在同一页面上
2. spec-sdd（GitHub），定义 AI 辅助开发的三阶段工作流规约，需求→设计→实施，每阶段有明确产出物和质量门禁
3. project-knowledge（GitHub），自动生成项目知识库，让 AI 进入项目时几分钟内理解上下文
4. MatchInfluence，搭了一个 Multi-Agent 系统，4 个 agent（Strategy / Sourcing / Tracking / Orchestrator），做 influencer marketing 全流程自动化（系列第 5 篇）
5. ai123.com，完全靠 vibe coding 上线的一个产品，从想法到上线用了两个月

工作方式整个换了。以前是帮了点忙，现在是整个工作流都换了。

这些项目不是各自独立的尝试。spec-analyze 的第一步是问现状，有数据吗，流程在跑吗，谁在用，第二步才问要解决什么，跟现状的差距在哪，判断标准是什么。每步都有输出，拆完是一份 proposal，背景、目标、范围、风险、验收标准都在里面。

spec-analyze 的第一版是 2026 年 5 月 26 日提交的，一个 566 行的 SKILL.md 单文件。我把接需求的过程写成 12 步流程，中间挂了 4 道质量门禁，G1 上下文完备，G2 收敛完成，G3 输出准备，G4 自检完成。路径分三条，Lightweight、Standard、Full，Full 路径输出 proposal、design、tasks 三份文档，组件注释分 L1、L2、L3 三层，L1 管简单交互，L3 留给全局复用的组件。我还在开头写了一条硬规则，用户设计确认之前不许写代码。当天我就发现 566 行太长，先压到 254 行，再拆成 references/ 里的 8 个文件。后来的结构都是从这一版长出来的。

MatchInfluence 把四条边界分开，Strategy 定 KPI 和预算，Sourcing 找人，Tracking 看效果，Orchestrator 调度，Agent 之间用结构化数据通信，不让自由文本在传递里累积偏差。project-knowledge 做的是把项目背景整理成 AI 能读的文档，进项目几分钟就能接上上下文。这几件事有一个共同点，把产品经理的判断拆成可执行的规则。

反思

回到 3 月那个下午，业务同事推开门、电脑屏幕上是一个 AI 生成的 demo。

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

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

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

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

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