惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Microsoft Security Blog
Microsoft Security Blog
J
Java Code Geeks
GbyAI
GbyAI
aimingoo的专栏
aimingoo的专栏
L
LangChain Blog
I
InfoQ
D
Docker
F
Fortinet All Blogs
Y
Y Combinator Blog
Martin Fowler
Martin Fowler
月光博客
月光博客
B
Blog
Engineering at Meta
Engineering at Meta
T
Tailwind CSS Blog
罗磊的独立博客
博客园_首页
G
Google Developers Blog
Stack Overflow Blog
Stack Overflow Blog
Recent Announcements
Recent Announcements
D
DataBreaches.Net
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
B
Blog RSS Feed
IT之家
IT之家
V
V2EX

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
B端产品经理如何在AI时代不掉队:我从迷茫到数字分身的两年复盘
Vvictor.ON · 2026-03-10 · via 人人都是产品经理

AI时代下,B端产品经理如何从零开始构建专属AI工作流?本文作者亲身经历从“AI新手”到“数字分身”的完整进化路径,揭秘如何将AI工具真正嵌入需求理解、原型设计、PRD撰写等核心工作环节,并分享90天实战框架,助你摆脱碎片化应用,实现能力模块的可持续沉淀。

2025 年刚开始深度接触 AI 时,我其实很慌。

不是担心“会不会被替代”这种大话题,而是一个更现实的问题:

我每天的工作里,AI到底该放在哪一步?

我当时也走了很多弯路。

看了很多教程,收藏了很多提示词,结果真正做需求、画原型、写 PRD 的时候,还是用回老方法。

后来我才慢慢走出来。

今天这篇不讲概念,我只复盘一件事:

一个 B 端产品经理,怎么从“偶尔用 AI”走到“有自己的 AI 工作流”,再走到“开始做数字分身”。

如果你现在也在“会一点,但没形成体系”的阶段,应该会有共鸣。

一、我最开始的误区:把 AI 当搜索框,而不是工作流节点

我刚开始用 AI 的方式很典型:

  • 问定义
  • 问方案
  • 让它润色一段话

看起来每天都在用,但价值不大。

因为这些动作都在“边角料”上,没进入核心产出链路。

对 B 端产品经理来说,核心产出不是一句话,而是一整条链路:

  • 需求理解
  • 方案表达
  • 原型呈现
  • 文档对齐
  • 评审推进

如果 AI 只帮你写几句好看的描述,最后你会觉得“有用,但不关键”。

我后来真正开始起变化,是做了一个很小但很关键的动作:

不再先问 AI 能干嘛,而是先拆我每天重复做的任务。

二、第一个转折:从“玩工具”到“拿真实任务喂工具”

我最早的工具组合是 VSCode + Cursor。

一开始也是在试功能,写点 demo,看看能不能生成代码。

真正让我打开局面的,是我把一个非常具体的任务交给它:

用静态 H5 画一个可交互的原型页面。

这件事听起来不大,但它直接改变了我的工作方式。

过去做 B 端原型,我要在设计稿、流程说明、评审口头表达之间来回切换。

现在我先让 AI 出一个能点、能看、能演示的 H5 原型。

这有三个好处:

  1. 讨论焦点从“你想表达什么”变成“页面行为是不是对的”。
  2. 评审效率明显变高,很多误会当场就能消掉。
  3. 我自己梳理需求的速度也更快,因为页面会逼着你把细节补完整。

这时候我第一次意识到:

AI 的价值不是替你做完工作,而是帮你把抽象问题更快变成可讨论对象。

三、第二个转折:把单点提效,串成稳定工作流

只有原型还不够。

你在 B 端项目里会很快发现,原型只是起点,后面还有一整串动作要跟上。

我后来把流程固定成了下面这条链路:

  1. 用 AI 快速搭静态 H5 原型(先把方案“看得见”)
  2. 基于原型回写 PRD(把规则、边界、异常写清楚)
  3. 用 AI 生成并优化流程图(补齐跨角色和状态流转)
  4. 评审后再反向更新原型和文档(保持版本一致)

这个工作流最关键的一点是:

每一步都能吃到上一步的产物。

不是今天让 AI 写一段文案,明天又从零开始。

一旦串起来,你会发现自己的产出稳定性变高了。

以前我经常在 PRD 阶段才发现流程断点,现在在原型阶段就能暴露出来。

以前评审主要靠嘴说,现在更多靠“页面 + 文档 + 流程图”三件套同步验证。

四、第三个转折:从 Cursor 转到 Codex / Claude Code,我学到的不是“更强”,而是“更可持续”

后来我从 Cursor 逐步转到 Codex 和 Claude Code,不是因为谁绝对更好,而是因为我开始追求另一件事:

可持续协作。

我希望 AI 不只是一次性帮我产出,而是能在一个项目上下文里持续推进:

  • 读现有目录
  • 识别改动
  • 基于已有结构生成新稿
  • 按平台再改写
  • 归档到固定目录

当这些动作能连起来,我的角色就变了。

从“我写,AI偶尔帮忙”,变成“我定目标,AI和我一起跑流程”。

这也是我后来开始做 skill 的原因。

五、我理解的“数字分身”,不是玄学,是可复用的能力封装

很多人听到“数字分身”,会以为是做一个很聪明的聊天机器人。

我自己的理解更朴素:

把你高频、可标准化的能力,沉淀成可复用流程。

比如我现在会沉淀这些东西:

  • 常用文章结构模板(不同平台不同语气)
  • PRD 写作检查清单(字段完整性、边界条件、状态流)
  • 评审前自测清单(是否可演示、是否可追踪、是否可回滚)
  • 归档规范(平台稿、投稿包、图片、说明)

这就是数字分身的雏形。

它不神奇,但非常实用。

因为它把“靠经验临场发挥”变成“有方法可复制”。

六、我最想强调的一句话:别因为一件小事自己做得快,就放弃让 AI 参与

这是我这两年最大的体会。

很多同学会说:

“这个我自己 10 分钟就做完了,不用 AI 更快。”

短期看没问题,长期看这是在放弃训练机会。

AI 能不能真的帮上你,取决于你给了它多少真实场景、多少反馈闭环。

你总在“大任务”才用它,它就很难理解你的工作习惯。

反而是那些小任务、日常任务、重复任务,最适合用来训练协作默契。

我自己的做法是:

  • 小到改标题、改一段结构,也先让 AI 参与
  • 让 AI 给出版本 A/B,我负责判断和取舍
  • 每次都把“为什么改”讲清楚,作为下一轮输入

这样跑一段时间后,它给你的内容会越来越像“你自己”。

这才是数字分身真正开始形成的信号。

七、给 B 端产品经理的 90 天行动框架(可直接照做)

如果你现在也想从“会用一点 AI”走向“形成自己的工作流”,可以先跑一个 90 天版本。

第 1-30 天:固定一个高频场景

不要贪多,先选一个你每周都在做的任务。

我建议从下面二选一开始:

  1. 原型初稿(页面结构 + 关键交互)
  2. PRD 初稿(目标、流程、边界、验收)

目标只有一个:

让 AI 进入你的主流程,而不是边角流程。

第 31-60 天:把上下游串起来

把单点动作升级成链路动作。

比如你可以定一个最小闭环:

原型 -> PRD -> 流程图 -> 评审问题清单

这个阶段重点不是“写得多漂亮”,而是“版本能对齐”。

第 61-90 天:开始沉淀自己的 skill

把前 60 天反复出现的动作,整理成模板:

  • 提示词模板
  • 输入字段模板
  • 产出检查清单
  • 归档命名规范

当你手上有 3-5 个稳定模板时,你已经不在“学工具”阶段了。

你在搭自己的能力系统。

八、最后说个更现实的结论

AI 时代,B 端产品经理真正的竞争力,不是“你会不会某个工具”。

而是这三件事:

  1. 你能不能把复杂业务快速结构化。
  2. 你能不能把产出链路稳定跑起来。
  3. 你能不能把自己的方法沉淀成可复用资产。

我也是从迷茫一路走过来的。

所以我现在不太焦虑“会不会掉队”。

我更关注的是:

今天我有没有再多沉淀一个可复用的能力模块。

你每多沉淀一个模块,你的数字分身就更完整一点。

这就是我理解的,不掉队。

本文由 @Vvictor.ON 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议