一次提词器动画的失败，暴露了AI时代PM的能力鸿沟
一、开篇：一个真实的翻车现场
上周五下午，我盯着屏幕上Gemini生成的代码，陷入了沉思。
作为一个有4年经验的产品经理，我刚刚经历了一次"AI翻车"：我给Gemini发了一张精心设计的Landing Page设计图，附上一段需求描述：“请帮我实现这个提词器产品的首页，重点是中间那个提词器播放器的动画效果。”
5分钟后，Gemini交付了代码。我满怀期待地打开预览，然后愣住了。
屏幕上出现的不是我想要的"滚动时提词器逐渐展开"的流畅动画，而是三个静态图片并排放置：一个是"缩小状态"，一个是"展开状态"，一个是"收起状态"。就像小学数学题里的"找不同"配图一样。
“这不是动画，这是PPT啊！” 我苦笑着自言自语。
这不是我第一次遇到这种问题。过去几个月里，我尝试用AI辅助开发多个项目——从Chrome扩展AI Manga Translator，到SlitherLinks.com的游戏界面，再到现在的Teleprompter.Today。每次涉及复杂交互和动画效果时，AI总是会"理解错误"。
问题来了：为什么AI总是误解我的需求？
我一度怀疑是AI模型能力不够，直到我和Claude进行了一次深入的讨论。那次对话让我意识到，问题的根源不在AI，而在于我们这些产品经理还在用"传统需求描述方式"跟AI沟通。
这就像你用中文跟一个只懂编程语言的外国工程师交流——不是他能力不行，而是你们说的根本不是同一种语言。
更深层的问题是：这暴露了一个新时代的残酷现实——产品经理的传统技能包正在失效。
二、案例拆解：AI到底看到了什么？
让我详细拆解一下这个失败案例，看看人类和AI之间到底存在什么样的认知鸿沟。
2.1 设计图展示
这是我给AI的设计图：Teleprompter.Today的Landing Page。
核心区域是Hero Section，中间有一个提词器设备的mockup，里面显示着滚动的文字内容。我想要的效果是：
当用户向下滚动页面时，这个提词器mockup会经历一个"故事"：
- 最开始看不见（缩小、透明）
- 随着滚动逐渐放大、清晰
- 到达中间位置时完整展示，内部文字开始滚动
- 继续滚动时再次收起、消失
这是一个典型的"滚动驱动动画"（Scroll-driven Animation），也叫"滚动叙事"（Scrollytelling）——动画的进度完全由用户的滚动位置控制，而不是时间控制。
这种效果在Apple、Tesla等品牌的产品页面上随处可见，已经成为现代Web设计的标配。
2.2 人类的理解 vs AI的理解
当我把这张设计图发给Gemini时，我脑海里的mental model是这样的：
人类看到的（时间轴思维）：
📷 静态设计图（T0时刻）
↓
💭 自动脑补：
"这是滚动动画的某一帧"
↓
🎬 完整故事：
T0: 不可见
T1: 逐渐出现（滚动0-30%）
T2: 完全展示（滚动30-60%）
T3: 逐渐消失（滚动60-90%）
↓
✅ 形成完整的动态mental model
作为人类，我们有强大的"时间推理"能力。看到一张静态图时，我们会基于经验自动补全"这个状态前后发生了什么"。就像看到一张足球运动员起脚射门的照片，我们会自动脑补出"助跑-射门-球进网"的完整动作序列。
但AI看到的完全不同：
AI看到的（纯空间思维）：
📷 静态设计图
↓
🤖 视觉识别：
- 黑色背景
- 中间有个矩形设备mockup
- 里面有文字内容
- 按钮、导航栏、文字描述
↓
❓ 疑问：
"这是静态的还是动态的？"
"如果是动态的，动什么？怎么动？"
"触发条件是什么？"
↓
🎲 基于概率猜测一个实现
关键差异：人类会基于经验自动补全时间维度，AI不会。
2.3 AI的"字面理解陷阱"
让我们看看当我说"实现提词器的动画效果"时，Gemini是怎么理解的：
我说的话 | 我的意思 | Gemini可能的理解
---|---|---
“滚动时展开” | 滚动位置直接控制展开进度，连续变化 | 滚动到某个位置触发一个3秒的展开动画
“提词器演示” | 模拟真实提词器的文字滚动效果 | 放一张提词器的截图
“动画效果” | 复杂的滚动驱动、多阶段过渡动画 | 用CSS transition做个淡入效果
“展示播放状态” | 动态演示从静止到播放的过渡 | 并排显示"播放前"和"播放中"两张静态图
看出问题了吗？Gemini把每一个需要"动态理解"的描述，都理解成了"静态实现"。
这就是我开头看到的结果：三张静态图片并排放置。在Gemini的理解中，“展示动画效果"等同于"展示动画的不同阶段的快照”。
这不是Gemini特有的问题。我用GPT-4、Claude，甚至专门的代码生成工具测试过，只要我不明确说清楚技术实现细节，它们都会犯类似的错误。
根本原因：AI缺少"设计直觉"和"行业常识"。
对于一个有经验的前端工程师来说，看到"滚动时展开的提词器"这个描述，他会立即想到：
- 需要监听scroll事件
- 根据scrollY计算动画进度
- 用transform和opacity做连续过渡
- 可能需要用到Intersection Observer
- 缓动函数选择ease-out会比较自然
但AI没有这些"设计直觉"。它只能基于你给的文字描述，在概率空间里搜索一个"最可能"的实现。而"展示三张静态图"在语义上确实符合"展示动画效果"这个描述。
这就是问题所在：我们用"人类语言"描述需求，AI用"字面意思"理解指令。
三、深层矛盾：传统需求文档为什么失效了？
这次翻车让我开始反思：为什么我写了这么多年的需求文档，在AI时代突然不好使了？
3.1 传统PM的需求描述方式
让我们看看一个传统的产品需求文档是怎么写的：
【产品需求文档 - Hero区域动画】
需求背景：
为了提升首页的视觉冲击力和产品展示效果，需要在Hero区域
设计一个引人注目的动画交互。
需求描述：
Hero区域需要展示产品的核心价值——提词器功能。用户滚动
页面时，提词器mockup应该有一个"呈现感"，让用户感受到
产品的专业性和现代感。
验收标准：
- 动画流畅，保持60fps
- 符合品牌调性（现代、科技感、专业）
- 用户体验良好，不干扰内容阅读
- 移动端也要有良好表现
参考案例：
类似Apple iPhone产品页的滚动展示效果
类似Tesla Model S页面的3D交互
设计资源：
见附件 - hero_section_design.fig
这是一份"合格"的传统PRD。它包含了：
- ✅ 需求背景（为什么做）
- ✅ 核心目标（要达成什么效果）
- ✅ 验收标准（怎么算成功）
- ✅ 参考案例（辅助理解）
这种需求文档的核心特点是：
- 目标导向 ：告诉团队"要什么"，而不是"怎么做"
- 留白空间 ：把"如何实现"交给专业团队自主决策
- 依赖判断 ：假设接收者有专业能力和经验积累
这在传统团队协作中非常有效。设计师会基于这个需求提供3个设计方案，前端会选择最合适的技术栈，大家在迭代中不断优化。
但是，这份需求对AI来说完全无效。
3.2 AI需要的需求描述方式
当我把上面那份PRD发给AI时，AI能理解的只有：
- “Hero区域” → 知道位置
- “提词器mockup” → 知道元素
- “动画” → 知道需要运动
但关键问题AI无法回答：
- 动画的触发条件是什么？（滚动？点击？自动？）
- 动画的时长是多少？（3秒？5秒？跟着滚动走？）
- 具体的运动轨迹是什么？（放大？位移？旋转？）
- 缓动函数用什么？（线性？ease-in？ease-out？）
- 初始状态和结束状态的具体数值是什么？
经过这次教训，我重新写了一份"AI能理解的需求"：
【Hero区域滚动驱动动画 - 技术实现规格】
动画类型：
Scroll-driven Animation（滚动驱动动画）
动画进度由页面滚动位置控制，不是时间控制
核心技术栈（2025标准）：
- 优先使用 CSS animation-timeline: scroll()
- 仅在浏览器不支持时回退到 JS 监听方案
触发方式：
- 监听页面滚动位置
- 不是时间触发，是滚动位置触发
动画分阶段实现：
【阶段1：出现过程 - 滚动0%到30%】
初始状态（滚动0%）：
- transform: scale(0.5) translateY(100px)
- opacity: 0
- 元素位置：视口下方，用户看不见
目标状态（滚动30%）：
- transform: scale(1) translateY(0)
- opacity: 1
- 元素位置：视口中心
过渡方式：
- 所有属性线性插值（lerp）
- 公式：currentValue = startValue + (endValue - startValue) * progress
- progress = (scrollPercent - 0) / (30 - 0)
【阶段2：展示阶段 - 滚动30%到60%】
状态保持：
- transform: scale(1) translateY(0)
- opacity: 1
内部文字滚动：
- 使用 transform: translateY 实现文字向上滚动
- 滚动速度：每50ms向上移动2px
- 循环逻辑：当文字滚出视口，重置到底部
【阶段3：消失过程 - 滚动60%到90%】
初始状态（滚动60%）：
- transform: scale(1) translateY(0)
- opacity: 1
目标状态（滚动90%）：
- transform: scale(0.5) translateY(-100px)
- opacity: 0
- 元素位置：视口上方，用户看不见
过渡方式：
- 同阶段1，线性插值
- progress = (scrollPercent - 60) / (90 - 60)
技术要求：
- 必须使用 requestAnimationFrame 优化性能
- 动画是双向的：用户向上滚动时完全反向执行
- 移动端使用 touch events 替代 scroll events
- 禁止使用 setTimeout 或基于时间的 CSS animations
性能优化：
- 使用 transform 和 opacity（硬件加速）
- 避免触发 layout reflow
- 使用 will-change: transform, opacity 提示浏览器
- 节流处理：最多每16ms（60fps）更新一次
禁止的实现方式：
❌ 不要做成"滚动到某个点就触发CSS animation"
❌ 不要展示多个静态状态（普通、展开）的对比图
❌ 不要用 setTimeout 或固定时长的动画
✅ 必须是滚动位置直接控制动画进度的连续变化
这里有一个关键的细节：为什么我要写这么详细的JS逻辑？
其实，这正暴露了不懂技术的PM容易踩的坑。之前我让Claude Code直接写，它用了大量JS代码来“造轮子”。
在2025年的今天，浏览器早已原生支持 CSS Scroll-driven Animations （滚动驱动动画标准）。本来只需要几行CSS代码就能实现的高性能效果，因为我（或者AI）默认选择了“旧思路”，结果写出了几十行复杂的JS代码。
这就是“技术理解力”的价值：
- 不懂技术的PM ：接受AI生成的复杂JS代码，虽然能跑，但性能差、维护难。
- 懂技术的PM ：会在指令中加一句“请优先使用CSS animation-timeline实现”，瞬间节省90%的代码量，性能提升10倍。
但无论用哪种技术实现，核心逻辑（分阶段、状态变化）是不变的。
看到区别了吗？
传统需求的颗粒度：
战略层：为什么做（商业价值）
↓
产品层：做什么（功能需求）
↓
设计层：长什么样（视觉/交互）
↓
开发层：怎么做（技术实现）← 留给专业团队决策
AI需求的颗粒度：
战略层：为什么做
↓
产品层：做什么
↓
设计层：长什么样
↓
实现层：具体怎么做 ← PM必须明确
↓
代码层：每个参数的具体数值 ← PM也要明确
3.3 对比分析：两种需求范式的差异
让我用一个表格来总结这两种需求描述方式的本质差异：
维度 | 传统人类团队 | AI工具 | 差异本质
---|---|---|---
理解能力 | 可以理解模糊意图和隐含假设 | 只能理解明确的字面描述 | AI缺少"常识推理"
决策能力 | 可以基于经验自主提供多个方案 | 只能按给定指令执行 | AI缺少"专业判断"
沟通方式 | 会主动询问不明确的地方 | Agent模式会反问，但效率低 | 依靠反问的"沟通成本高"
迭代方式 | 基于反馈进行专业优化 | 基于新指令重新生成 | AI缺少"学习优化"
创造力 | 可以创造性地解决问题 | 只能组合已知模式 | AI缺少"真正创新"
上下文 | 记得项目历史和团队习惯 | 每次都是新的上下文 | AI缺少"记忆积累"
这张表暴露了一个残酷的现实：AI不是"初级开发"，而是"高级编译器"。
你可能会反驳：“现在是2025年底，Gemini和Claude都已经具备Agentic（代理）能力，它们发现需求不明确时会主动提问啊？”
没错，现在的AI确实会问：“你是想要A还是B？”。但这就陷入了低效的“猜谜游戏”。
依靠AI的反问来澄清需求，是PM的失职。 你的核心价值应该是在第一轮指令中就提供清晰的规格 ，避免多轮拉扯。
初级开发虽然经验不足，但仍然具备：
- 主动询问的能力（“这里有两种实现方式，你倾向哪种？”）
- 专业判断的能力（“方案A性能更好，我建议用A”）
- 学习优化的能力（“上次你说速度太慢了，这次我优化了算法”）
而AI更像一个编译器：
- 给它精确的代码，它能完美执行
- 给它模糊的描述，它只能猜测
- 它不会问你"是不是这个意思"
- 它不会说"我有更好的方案"
3.4 角色倒置的困境
这导致了一个尴尬的局面：角色倒置。
传统的产品开发流程：
PM：定义方向和目标
↓ 需求文档（What & Why）
设计师：设计视觉和交互方案
↓ 设计稿（How - 视觉层面）
前端：选择技术方案并实现
↓ 代码（How - 技术层面）
每个角色都在自己的专业领域做决策：
- PM决策：做不做，先做哪个
- 设计决策：用什么风格，什么交互模式
- 前端决策：用什么技术栈，怎么优化性能
AI辅助的产品开发流程：
PM：定义方向 + 目标 + 方案 + 技术细节
↓ 超详细指令文档
AI：执行
↓ 代码
😰 PM被迫成为"全栈决策者"
所有的决策都回到了PM身上：
- 用什么动画方式？（原本设计师决定）
- 用什么缓动函数？（原本前端决定）
- 具体参数是多少？（原本设计和前端协商）
这就好比：
- 传统模式：你是将军，手下有参谋、军师、将领，你只需要下达战略指令
- AI模式：你是将军，但手下只有一群严格执行命令的机器人，连"怎么排兵布阵"都要你亲自规划
PM从"战略决策者"被迫成为"战术执行设计师"。
这合理吗？可持续吗？
四、更深一层：这暴露了什么本质问题？
这次提词器动画的失败，让我开始思考更深层的问题：专业分工这个现代工作方式的基础，正在被AI重构。
4.1 专业分工正在被重构
传统的专业分工建立在两个基础上：
基础1：信息不对称
- PM了解用户需求和商业目标（设计/开发不知道）
- 设计师了解视觉规律和用户体验（PM/开发不知道）
- 开发了解技术可行性和实现成本（PM/设计不知道）
基础2：技能壁垒
- PM不会写代码
- 设计师不懂技术实现
- 开发不懂商业战略
所以大家各司其职，通过"需求文档 → 设计稿 → 代码"的流程协作。
但AI打破了什么？
AI打破的：执行层的技能壁垒
- 写代码不再难（AI几秒钟就能生成）
- 实现设计稿不再难（AI能直接转代码）
- 基础的技术实现不再需要专业开发
AI没打破的：
- 判断力（什么方案更好？）
- 创造力（能不能想到全新的解决方案？）
- 审美力（这个设计好看吗？）
- 商业sense（这个功能值得做吗？）
- 复杂权衡（性能vs体验，成本vs收益）
所以新的分工线出现了：
传统分工线：
能想（战略层）vs 能做（执行层）
新的分工线：
能判断+创造（人类）vs 能执行（AI）
这意味着：
- ✅ 如果你的价值在"执行"层（严格按规则做事），你很危险
- ✅ 如果你的价值在"判断"层（复杂权衡和决策），你很安全
- ⚠️ 如果你是"协调者"（把需求传递给执行者），你的价值在被压缩
对PM来说，如果你的核心价值是"写PRD + 开会 + 推进度"，那你确实应该感到危机。因为：
- 写PRD：AI也能写（甚至写得更规范）
- 开会：很多会是为了解释需求和协调（AI减少了这个需求）
- 推进度：如果开发环节被AI替代，进度问题也减少了
那PM还剩什么？
4.2 "需求"的定义正在改变
我经历的这次翻车，本质上反映了"需求"这个概念正在发生变化。
传统需求的定义：
需求 = "是什么" + "为什么"
例子：
"需要一个用户登录功能，因为我们要识别用户身份"
这种需求描述的假设是：接收者知道"怎么做"。
前端工程师看到这个需求，会自动：
- 想到要有用户名、密码输入框
- 想到要有"忘记密码"链接
- 想到要做表单验证
- 想到要调用后端API
- 想到要处理登录失败的情况
但AI看到这个需求，只会生成一个最基本的登录表单，其他的"常识"它都不具备。
AI需求的定义：
需求 = "是什么" + "为什么" + "怎么做" + "做到什么程度"
例子：
"需要一个用户登录功能（是什么），
因为我们要识别用户身份（为什么），
包含用户名输入框、密码输入框、登录按钮、忘记密码链接（怎么做），
用户名长度3-20字符，密码需8位以上且包含数字字母，
登录失败3次后锁定账户10分钟（做到什么程度）"
看到了吗？传统需求是"目标描述"，AI需求是"执行规格"。
类比一下：
- 传统需求：像给人类发布任务
- “把这个房间打扫干净”
- 对方知道"打扫"包括扫地、拖地、整理物品、擦桌子
- AI需求：像给机器人编程
- “第一步：用扫帚清扫地面，从左上角开始，每次移动10cm”
- “第二步：用拖把擦地，拖把保持45度角，前后移动…”
- 如果你不说"擦桌子"，它就不会擦
需求文档从"沟通工具"变成了"控制指令"。
这对PM意味着什么？你需要懂得：
- 前端动画的基本实现方式
- 什么能做到，什么做不到
- 不同实现方式的优劣
- 如何用技术语言描述效果
不是让你成为开发，而是让你能"说开发的语言"。
4.3 PM的价值主张在漂移
说到这里，可能有PM会焦虑：如果我要懂这么多技术细节，那我和开发有什么区别？我的价值到底在哪里？
这是一个好问题。让我们理性分析一下：
传统PM的核心价值：
- 📊 理解用户需求和商业目标
- 🤝 协调多方资源（设计、开发、运营）
- 📋 制定产品规划和优先级
- 🚀 推动项目落地和上线
- 📈 监控数据并迭代优化
这些价值在AI时代会如何变化？
变化1：执行协调的价值下降
- 如果AI能直接实现，"协调开发资源"的价值就下降了
- 如果需求能自动生成代码，"编写PRD"的价值也下降了
- 项目管理工具越来越自动化，"推动进度"的价值也在被压缩
变化2：判断决策的价值上升
- 什么值得做？（战略判断）
- 用户真正需要什么？（洞察能力）
- 这个方案是最优解吗？（方案评估）
- 如何平衡各方利益？（复杂权衡）
变化3：新增能力要求
- AI工具链的整合能力（会用AI协作）
- 技术可行性的判断（知道什么能实现）
- Prompt工程能力（能把需求翻译成AI能懂的语言）
所以未来PM可能会分化成三个方向：
路径1：战略型PM
- 更上层，专注商业和战略
- 核心能力：商业判断 + 用户洞察 + 战略规划
- AI是执行工具，PM是指挥官
- 类比：将军（不需要亲自扛枪）
路径2：技术型PM
- 深入技术，成为"AI工具链专家"
- 核心能力：技术理解 + 工具整合 + 执行把控
- 知道如何组合AI达成目标
- 类比：首席工程师（懂技术但不一定写代码）
路径3：创意型PM
- 专注创新，提供AI无法产生的想法
- 核心能力：创造力 + 设计思维 + 用户同理心
- 设计全新的产品和交互范式
- 类比：首席产品官（定义未来）
但无论哪条路，有一点是共同的：不能再停留在"传话筒"的角色。
你必须在某个维度有不可替代的价值：
- 战略判断？
- 技术深度？
- 创新能力？
- 还是用户洞察？
如果你的工作只是"把需求从A传递给B"，那这个环节确实可以被压缩甚至消除。
五、解决方案：新时代PM的能力模型
说了这么多问题，现在来说说解决方案。作为一个正在经历这个转型的PM，我总结了5个新时代PM的必备能力。
5.1 必备能力1：技术理解力（不是写代码能力）
澄清一个误区： 技术理解力 ≠ 会写代码
很多PM听到"要懂技术"就恐慌：“我又不是开发，要我学编程？”
不是的。你需要的是**“能够用技术语言描述需求”** 的能力，而不是"能够实现需求"的能力。
什么是技术理解力？
举个例子，当你说"我要一个动画效果"时，你需要知道：
- 动画的类型有哪些？
- CSS Transitions（简单的状态过渡）
- CSS Animations（关键帧动画）
- JavaScript动画（复杂的交互动画）
- Canvas/WebGL（高性能图形动画）
- 滚动驱动动画（我这次的需求）
- 每种类型适合什么场景？
- CSS Transitions：按钮hover效果，简单的淡入淡出
- CSS Animations：loading动画，简单的循环动画
- JavaScript：复杂的用户交互，游戏逻辑
- 滚动驱动：产品展示页，storytelling效果
- 它们的局限性是什么？
- CSS Transitions：不能做复杂的序列动画
- CSS Animations：难以和用户交互联动
- JavaScript：性能开销大，需要优化
- 滚动驱动：移动端兼容性需要考虑
你不需要会写这些代码，但你需要知道：
- 当你想要一个"跟随鼠标的粒子效果"时，这大概率需要Canvas
- 当你想要一个"滚动时产品逐渐展开"时，这需要滚动驱动动画
- 当你想要一个"流畅的60fps动画"时，要避免频繁的DOM操作
实战案例：如何描述"滚动驱动动画"
❌ 错误描述： “用户滚动页面时，提词器要有一个炫酷的出现效果。”
✅ 正确描述：
技术要求：滚动驱动动画（Scroll-driven Animation）
核心技术栈（2025标准）：
- 优先使用 CSS animation-timeline: scroll()
- 仅在浏览器不支持时回退到 JS 监听方案
触发方式：
- 监听页面滚动位置
- 不是时间触发，是滚动位置触发
动画逻辑：
- 滚动进度 = 当前滚动位置 / 总滚动高度
- 动画进度 = 滚动进度的映射
- 所有视觉变化由动画进度控制
具体实现：
- 滚动0-30%：元素从不可见到可见
- 滚动30-60%：元素保持可见，内部内容动画
- 滚动60-90%：元素从可见到不可见
技术要点：
- 使用 transform 和 opacity（GPU加速）
- 避免使用主线程 JS 计算（除非必要）
- 移动端需要适配touch事件
学习路径建议：
第1周：了解基础概念
- 花3小时看：前端动画基础（CSS Transitions, Animations）
- 重点学习：CSS Scroll-driven Animations（这是2025年的主流）
- 花2小时看：JavaScript动画原理（requestAnimationFrame）
- 花1小时看：性能优化基础（重排、重绘、GPU加速）
第2周：实践理解
- 找3个喜欢的网站，用开发者工具分析它们的动画实现
- 试着用文字描述出来：“这个动画用了什么技术”
- 不需要会写，但要能说出个大概
第3周：建立词汇库
- 整理一个"技术术语 - 白话翻译"对照表
- transform → 元素的移动、缩放、旋转
- opacity → 透明度
- transition → 状态变化时的过渡动画
- animation → 自动循环的动画
- scroll-driven → 跟着滚动条走的动画
目标： 不要求你能实现，但要求你能：
- 看懂开发说的"这个用CSS做不了，需要Canvas"
- 描述需求时能说清楚"我要的是滚动驱动，不是时间触发"
- 判断一个参考案例的技术复杂度：“这个可能需要WebGL”
5.2 必备能力2：Prompt工程能力
如果说技术理解力是"知道有什么技术"，那Prompt工程能力就是"知道如何用语言控制AI"。
什么是Prompt工程？
简单说，就是让AI理解你意图的艺术。
这不是"写得更详细"那么简单，而是要理解：
- AI的理解边界在哪里
- AI容易误解什么
- 如何结构化地表达需求
我的Prompt模板：
经过这次提词器动画的教训，我总结了一个Prompt模板，屡试不爽：
## 【核心需求】（明确这是什么类型的交互）
描述动画的类型和核心特征
## 【动画主体】（明确哪个元素要动）
具体到DOM元素或组件
## 【动画行为 - 分阶段描述】（最重要的部分）
### 阶段1：[阶段名称]
触发条件： 什么情况下进入这个阶段
初始状态： 具体的CSS属性值
目标状态： 具体的CSS属性值
过渡方式： 线性/缓动函数/自定义曲线
时长： 如果是时间驱动，明确时长；如果是滚动驱动，明确进度区间
### 阶段2：[阶段名称]
...
## 【技术要求】（约束AI的实现方式）
- 必须使用的技术：xxx
- 性能要求：60fps, GPU加速
- 兼容性要求：移动端、浏览器版本
- 交互要求：双向、可中断、可暂停
## 【禁止的实现方式】（用反例强化理解）
❌ 不要：[错误理解]
❌ 不要：[常见误区]
✅ 必须：[正确方式]
## 【参考示例】（可选）
[提供参考链接或代码片段]
实战案例：用模板重写提词器需求
## 【核心需求】
实现一个滚动驱动的交互动画（Scroll-driven Animation）
不是时间触发的动画，而是滚动位置直接控制动画进度
## 【动画主体】
Hero区域的提词器mockup（.teleprompter-device 元素）
## 【动画行为 - 分阶段描述】
### 阶段1：出现过程
触发条件： 页面滚动进度 0% → 30%
初始状态：
- transform: scale(0.5) translateY(100px)
- opacity: 0
- 位置：视口下方，完全不可见
目标状态：
- transform: scale(1) translateY(0)
- opacity: 1
- 位置：视口中心
过渡方式：
- 线性插值（lerp）
- progress = (scrollPercent - 0) / 30
- 每个属性独立计算：currentValue = start + (end - start) * progress
### 阶段2：展示阶段
触发条件： 页面滚动进度 30% → 60%
状态： 保持阶段1的目标状态不变
额外动画：
- 内部文字开始向上滚动
- 使用 transform: translateY 实现
- 每50ms向上移动2px
- 当文字滚出视口时，重置到底部实现无限循环
### 阶段3：消失过程
触发条件： 页面滚动进度 60% → 90%
初始状态： 阶段2的状态
目标状态：
- transform: scale(0.5) translateY(-100px)
- opacity: 0
- 位置：视口上方，完全不可见
过渡方式：
- 同阶段1，线性插值
- progress = (scrollPercent - 60) / 30
## 【技术要求】
- 必须使用 Intersection Observer API 或 scroll event 监听滚动
- 或使用 CSS scroll-driven animations (animation-timeline: scroll())
- 动画必须是双向的：用户向上滚动时完全反向执行
- 使用 requestAnimationFrame 优化性能
- 所有视觉变化用 transform 和 opacity 实现（GPU加速）
- 响应式：移动端也要流畅
## 【禁止的实现方式】
❌ 不要做成"滚动到某个点就触发一个3秒的CSS animation"
（这是时间驱动，不是滚动驱动）
❌ 不要展示多个静态状态（普通状态、展开状态）的对比图
（这不是动画，是静态图片）
❌ 不要用 setTimeout 或固定时长的动画
（无法响应用户的滚动速度）
✅ 必须是滚动位置直接控制动画进度的连续变化
（滚动50%，动画就执行到50%）
## 【参考示例】
类似效果参考：
- Apple iPhone 15 Pro 产品页的滚动展示
- Tesla Model S 页面的3D旋转效果
关键技巧总结：
- 用"阶段"拆解复杂动画
- 不要试图一句话说清楚
- 分成若干个清晰的阶段
- 每个阶段独立描述
- 给出具体数值
- 不说"放大一点"，说"scale(1.2)"
- 不说"移动一些"，说"translateY(50px)"
- 不说"慢慢淡入"，说"opacity 0到1，持续300ms"
- 用反例强化理解
- AI最容易理解"这个不对"
- 明确告诉AI “不要做成XXX”
- 比正面描述更有效
- 提供计算公式
- 如果涉及数学计算，给出公式
- progress = (current - start) / (end - start)
- AI擅长执行公式，不擅长猜测公式
5.3 必备能力3：AI能力边界的判断
这个能力容易被忽视，但非常重要：知道什么时候该用AI，什么时候不该用。
AI适合的场景：
✅ 重复性工作
- 批量生成相似的代码
- 实现标准的CRUD功能
- 转换数据格式
✅ 标准化实现
- 实现已知的设计模式
- 遵循现有的代码规范
- 复刻参考案例
✅ 辅助性任务
- 代码审查和优化建议
- 文档生成
- 测试用例编写
AI不适合的场景：
❌ 需要创新的设计 “设计一个革命性的交互方式” → AI只能组合已知模式
❌ 复杂的商业决策 “我们应该做功能A还是功能B？” → AI无法理解业务上下文
❌ 需要审美判断的工作 “这个设计好看吗？” → AI没有真正的审美
❌ 需要深度上下文的工作 “根据我们团队的技术栈，这个方案可行吗？” → AI不知道你的团队情况
实战案例对比：
案例1：登录表单
- 需求：实现一个标准的用户登录表单
- AI能做：✅ 完全可以
- 原因：标准功能，有无数参考实现
案例2：创新交互
- 需求：设计一个从未见过的、革命性的文件上传交互方式
- AI能做：❌ 无法做好
- 原因：需要真正的创造力和对用户心理的深刻理解
案例3：动画实现
- 需求（模糊版）：实现一个炫酷的滚动动画
- AI能做：⚠️ 会做错
- 原因：需求太模糊，AI会按字面意思理解
案例3：动画实现
- 需求（明确版）：实现滚动驱动动画，具体参数见技术文档
- AI能做：✅ 可以做对
- 原因：需求明确，有清晰的执行规格
混合策略：人机协作
最好的工作方式不是"全部AI"或"完全不用AI"，而是：
人类：定义方向和方案
↓
AI：生成初始实现
↓
人类：审查和优化
↓
AI：根据反馈迭代
↓
人类：最终把关和上线
我的实践经验：
在开发AI Manga Translator时，我的工作流程是：
- 战略层（纯人类）
- 决定做图片翻译功能
- 调研用户需求和市场空间
- 规划产品roadmap
- 方案层（人类主导）
- 设计交互流程：点击图片 → 识别文字 → 翻译 → 覆盖显示
- 选择技术方案：用Chrome Extension API
- 评估多个实现方案的优劣
- 实现层（AI主导，人类把关）
- 让AI实现具体的代码
- 我审查代码质量和性能
- 发现问题后让AI修复
- 优化层（人机协作）
- 我提出性能优化需求（“翻译速度太慢”）
- AI提供优化方案（“用Web Worker”）
- 我评估方案可行性并决定是否采纳
判断标准：
问自己三个问题：
- 这个任务需要"判断"还是"执行"？（执行用AI）
- 这个任务有没有标准答案？（有标准答案用AI）
- 这个任务的要求我能说清楚吗？（能说清楚用AI）
5.4 必备能力4：商业sense（比以前更重要）
这可能让人意外：为什么在AI时代，商业能力反而更重要了？
原因很简单：执行变容易了，战略方向更关键了。
传统时代的约束：
好想法
↓
能否实现？（技术约束）
↓
需要多久？（资源约束）
↓
能否上线？（执行力约束）
很多好想法死在执行环节。PM需要大量精力在推动执行上。
AI时代的约束：
好想法
↓
是否值得做？（战略约束）← 核心问题前移
↓
AI快速实现（执行不再是瓶颈）
↓
市场验证
当执行不再是瓶颈，选择做什么 比如何做好 更重要。
PM必须能回答的商业问题：
- 为什么要做这个功能？
- 用户痛点是什么？
- 解决这个痛点的商业价值是多少？
- 不做的机会成本是什么？
- 这个功能对关键指标的影响？
- 对留存的影响？
- 对收入的影响？
- 对获客成本的影响？
- 对竞争力的影响？
- 优先级如何排序？
- 为什么先做A后做B？
- 投入产出比如何计算？
- 风险和收益如何权衡？
实战案例：我的Chrome扩展决策
当我开发AI Manga Translator时，面临一个决策：
功能选项：
- 选项A：支持更多语言（增加到30种）
- 选项B：优化翻译速度（从3秒降到1秒）
- 选项C：增加批量翻译功能
传统PM可能的思路： “都做！让开发评估工作量，按工作量排期。”
AI时代PM的思路：
- 数据分析：
- 查看用户反馈：80%的抱怨是"速度慢"
- 查看使用数据：95%的用户只用中日英3种语言
- 查看竞品：批量翻译是竞品的差异化功能
- 商业判断：
- 选项A：边际收益低（大部分语言用户少）
- 选项B：影响核心体验，可能大幅提升留存
- 选项C：可能成为付费功能，增加收入
- 决策：
- 先做B（优化速度），因为影响最大
- 再做C（批量翻译），因为有商业价值
- 暂不做A（更多语言），因为投入产出比低
- 执行：
- AI在2小时内实现了选项B（优化速度）
- 我上线后监控数据：留存率提升12%
- 验证了判断正确，继续推进选项C
关键点： 因为AI让执行变快了，我可以快速验证商业判断。这时候，判断的质量比执行的速度更重要。
如何提升商业sense：
- 建立数据驱动的习惯
- 每个决策都要有数据支撑
- 不是"我觉得用户需要"，而是"数据显示用户需要"
- 学习商业分析框架
- AARRR海盗模型（获客-激活-留存-收入-推荐）
- 北极星指标（什么是最重要的指标？）
- 单位经济模型（一个用户的LTV vs CAC）
- 关注业务目标
- 公司今年的目标是什么？
- 你的产品如何支撑这个目标？
- 每个功能如何服务业务目标？
- 培养战略思维
- 不只看当下，也看未来
- 不只看功能，也看生态
- 不只看用户，也看竞争
5.5 必备能力5：模型思维（新增能力）
这是一个全新的能力要求：理解不同AI模型的能力差异，并知道如何组合它们。
为什么需要模型思维？
AI不是一个统一的工具，而是一系列能力各异的模型。就像：
- 你不会用锤子拧螺丝
- 你不会用扳手钉钉子
- 不同的工具适合不同的任务
主流AI模型的能力对比：
模型 | 擅长 | 不擅长 | 适合场景
---|---|---|---
Claude | 复杂逻辑推理、代码质量、长文本理解 | 视觉生成、实时信息 | 代码开发、文档写作、复杂分析
GPT-4 | 创意写作、对话流畅度、知识广度 | 代码调试、复杂逻辑 | 文案创作、头脑风暴、通用对话
Gemini | 多模态理解、视频分析、实时信息 | 代码生成质量 | 图像分析、视频理解、搜索增强
Midjourney | 高质量图像生成、艺术风格 | 精确控制、文字渲染 | 概念图、宣传图、创意视觉
Stable Diffusion | 可控性、本地部署、自定义训练 | 开箱即用质量 | 定制化图像、批量生成
实战案例：我的工具链组合
在开发Teleprompter.Today时，我是这样组合AI工具的：
阶段1：视觉设计
- 工具：Midjourney
- 任务：生成Landing Page的概念图
- 原因：Midjourney的视觉质量最好
阶段2：代码实现
- 工具：Claude + Cursor
- 任务：根据设计图实现前端代码
- 原因：Claude的代码质量高，Cursor集成开发环境友好
阶段3：动画调试
- 工具：Claude（在claude.ai对话）
- 任务：解释复杂的滚动动画逻辑，优化性能
- 原因：需要深度的逻辑推理和代码优化
阶段4：文案创作
- 工具：GPT-4
- 任务：生成产品介绍文案
- 原因：GPT-4的文案创意更好
阶段5：SEO优化
- 工具：Claude
- 任务：生成结构化的SEO元数据
- 原因：需要严格遵循技术规范
工具链图示：
Midjourney (视觉)
↓ 设计稿
Claude (代码)
↓ 初始实现
Cursor (开发)
↓ 集成和调试
GPT-4 (文案)
↓ 内容填充
Claude (优化)
↓ 性能和SEO
↓
最终产品
如何建立模型思维：
- 体验主流模型
- 花1周时间试用 Claude、GPT-4、Gemini
- 给同一个任务，看不同模型的表现
- 记录：哪个做得好，哪个做得不好
- 建立能力矩阵
- 制作一个表格：任务类型 × AI模型
- 标注：每个任务最适合哪个模型
- 不断更新（AI能力快速迭代）
- 关注模型更新
- Claude Sonnet 4.5 vs Claude Opus 4
- GPT-4 vs GPT-4 Turbo
- 新模型发布时快速测试
- 学习组合技巧
- 如何把多个模型串联起来？
- 如何在不同阶段切换模型？
- 如何管理不同模型的输出格式？
高级技巧：模型级联
复杂任务
↓
GPT-4 生成创意方案（3个选项）
↓
Claude 分析每个方案的技术可行性
↓
人类选择最优方案
↓
Claude 实现具体代码
↓
Gemini 生成配套的视觉素材
↓
Claude 整合所有内容
↓
最终交付
模型思维的核心： 不是"AI能做什么"，而是"哪个AI最适合做这个"。
六、实践指南：如何立即升级你的工作流
说了这么多理论，现在给你一套可以立即执行的行动计划。
6.1 短期策略（本周就能做）
行动1：建立双轨需求文档
不要放弃传统的PRD，而是增加一份"AI指令文档"。
传统PRD（给人类的）：
# 产品需求文档
## 需求背景
为了提升产品首页的转化率，需要增加一个引人注目的Hero动画。
## 目标用户
B端用户，专业内容创作者
## 核心目标
- 展示产品核心功能
- 提升页面停留时长
- 增强品牌专业感
## 验收标准
- 动画流畅（60fps）
- 移动端适配良好
- 不影响页面加载速度
AI指令文档（给AI的）：
# AI实现指令 - Hero区域滚动动画
## 技术类型
Scroll-driven Animation
## 实现规格
[详细的技术参数，参考前面的模板]
## 代码要求
- 使用React + Tailwind CSS
- 兼容Chrome 90+, Safari 14+
- 移动端使用touch events
## 性能要求
- 使用GPU加速
- Lighthouse性能分数 > 90
两份文档各司其职：
- PRD给团队看，保持战略高度
- AI指令给AI看，提供执行细节
行动2：学习3小时的基础技术
不需要成为开发，但要建立"技术感觉"。
Day 1（1小时）：CSS动画基础
- 看一个YouTube教程：“CSS Transitions and Animations in 20 Minutes”
- 重点理解：transition、animation、transform、opacity
- 不需要会写，但要知道这些词是什么意思
Day 2（1小时）：JavaScript动画原理
- 看一个教程：“requestAnimationFrame Explained”
- 理解：为什么不用setInterval，什么是帧率
- 知道：60fps是什么意思，性能瓶颈在哪里
Day 3（1小时）：实战分析
- 打开3个你喜欢的网站（推荐Apple、Tesla、Stripe）
- 打开开发者工具，查看它们的动画是怎么实现的
- 试着用文字描述：“这个动画用了transform scale…”
行动3：建立参考案例库
不要说"类似Apple官网"，而是提供具体链接。
创建一个文档：
# 动画效果参考库
## 滚动驱动动画
- Apple iPhone 15 Pro: https://www.apple.com/iphone-15-pro/
技术：Scroll-driven, Canvas 3D, Video
- Tesla Model S: https://www.tesla.com/models
技术：Scroll-driven, 3D Transform
## 粒子效果
- Stripe Home: https://stripe.com
技术：Canvas, WebGL
## 交互动画
- Linear: https://linear.app
技术：Framer Motion, React Spring
当你需要实现类似效果时，直接给AI链接： “请分析这个网站的动画实现方式，然后用相同的技术栈实现我的需求。”
6.2 中期策略（这个月要做）
策略1：建立Prompt模板库
把前面讲的Prompt模板保存下来，建立自己的模板库。
模板1：动画效果描述
## 【核心需求】
[动画类型]
## 【动画主体】
[具体元素]
## 【动画行为】
### 阶段1：
- 触发：[条件]
- 初始：[状态]
- 目标：[状态]
- 过渡：[方式]
## 【技术要求】
[约束]
## 【禁止方式】
❌ [错误理解]
✅ [正确方式]
模板2：功能实现描述
## 【功能描述】
[功能是什么]
## 【用户流程】
1. 用户点击/输入/滚动...
2. 系统响应...
3. 显示结果...
## 【边界情况】
- 如果用户输入为空？
- 如果网络请求失败？
- 如果数据格式错误？
## 【技术约束】
- API: [使用哪个API]
- 数据格式: [JSON/XML/...]
- 错误处理: [如何处理]
每次使用时，复制模板填空即可。
策略2：培养AI能力直觉
建立一个"AI使用日志"：
# AI使用日志
## 2024-12-08
任务： 实现滚动动画
模型： Gemini
提示词： "实现一个提词器的滚动展开动画"
结果： ❌ 理解成静态图片
改进： 增加"滚动驱动"关键词，给出技术规格
二次结果： ✅ 实现正确
学习： Gemini容易把动画理解成静态状态，需要明确"scroll-driven"
## 2024-12-09
任务： 优化代码性能
模型： Claude
提示词： "这段代码性能不好，请优化"
结果： ✅ 提供了3个优化方案
学习： Claude擅长代码优化，给出的建议质量高
## 2024-12-10
...
一个月后回顾，你会发现：
- 哪些类型的任务AI容易理解
- 哪些描述方式更有效
- 不同模型的能力边界
策略3：优化工作流程
重新设计你的产品开发流程：
传统流程：
需求分析 → PRD → 评审会 → 设计 → 开发 → 测试 → 上线
（2-4周）
AI辅助流程：
需求分析 → PRD + AI指令 → AI生成初版 → 人工审查优化 → 上线
（3-5天）
混合流程（推荐）：
战略决策（人类）
↓
需求文档（双轨）
↓
核心逻辑（人类设计）
↓
具体实现（AI生成）
↓
审查优化（人类把关）
↓
上线监控（数据驱动）
关键是：人类负责判断和决策，AI负责执行和迭代。
6.3 长期策略（未来半年）
策略1：重新定义自己的价值
花时间思考三个问题：
问题1：我的不可替代性在哪里？
- 是战略判断能力？
- 是用户洞察能力？
- 是技术整合能力？
- 是团队协作能力？
问题2：AI强化了我的什么优势？
- 如果你擅长快速验证想法，AI让你更快
- 如果你擅长数据分析，AI能处理更多数据
- 如果你擅长创意，AI能快速实现你的创意
问题3：AI暴露了我的什么弱点？
- 如果你依赖"协调执行"，这个价值在被压缩
- 如果你不懂技术，你会越来越难以驾驭AI
- 如果你缺少商业判断，你会失去方向感
基于答案，制定转型计划：
路径A：成为战略型PM
- 学习商业分析和战略规划
- 提升行业洞察和竞争分析能力
- 把执行层完全交给AI和团队
路径B：成为技术型PM
- 深入学习技术栈和工具链
- 成为AI工具整合专家
- 建立技术判断力
路径C：成为创意型PM
- 培养设计思维和创新能力
- 关注用户体验和交互设计
- 提供AI无法产生的创意
策略2：建立新的技能组合
传统PM技能树：
产品设计 ─┐
需求分析 ─┼─ 传统PM
项目管理 ─┘
新时代PM技能树：
商业分析 ─┐
用户洞察 ─┤
战略规划 ─┤
技术理解 ─┼─ 新时代PM
AI工程 ───┤
数据分析 ─┤
Prompt工程┘
6个月学习计划：
第1-2月：技术基础
- 学习前端基础（HTML/CSS/JS概念）
- 理解常见技术栈（React/Vue/…)
- 体验各种AI工具
第3-4月：AI工程
- 深入使用Claude、GPT、Gemini
- 学习Prompt工程技巧
- 建立工具链整合能力
第5-6月：商业分析
- 学习数据分析（SQL基础、数据可视化）
- 学习商业模型（单位经济学、增长模型）
- 实践：用数据驱动产品决策
策略3：建立个人品牌
在AI时代，个人的知识和能力更容易外化和变现。
输出内容：
- 写技术博客（如何用AI做产品）
- 做案例分享（你的成功经验）
- 录制教程（Prompt工程实战）
建立影响力：
- 在社区分享经验（Product Hunt、V2EX）
- 回答别人的问题（帮助他人也是学习）
- 开源你的工具和模板
为什么重要？
- 个人品牌是AI无法复制的
- 影响力带来机会
- 教学是最好的学习方式
七、未来展望：5年后的产品经理是什么样？
当我写完这篇文章的时候，我也在思考：5年后，产品经理这个职业还会存在吗？如果存在，会是什么样子？
7.1 三种可能的演化方向
基于我的观察和思考，我认为PM会分化成三个方向：
方向1：战略型PM（Product Strategist）
角色定位：
- 专注于商业决策和战略规划
- AI是执行团队，PM是指挥官
- 不需要懂具体的技术实现细节
核心能力：
- 商业判断：什么值得做，什么不值得做
- 用户洞察：用户真正需要什么
- 市场分析：竞争格局和机会点
- 资源协调：如何整合资源达成目标
日常工作：
- 制定产品战略和roadmap
- 分析市场和竞争对手
- 做商业决策和优先级排序
- 向AI或团队下达高层次指令
类比：
- 就像军队的将军：不需要亲自扛枪，但需要制定战略
- 或者企业的CEO：不需要懂每个细节，但需要把握大方向
收入水平：
- 高（30-50万美元/年）
- 因为决策的影响力大
方向2：技术型PM（Product Engineer）
角色定位：
- 深入技术，成为"AI工具链专家"
- 知道如何用各种AI工具组合达成目标
- 在战略和执行之间架起桥梁
核心能力：
- 技术理解：深入理解技术栈
- 工具整合：会组合不同的AI工具
- Prompt工程：能精确控制AI输出
- 质量把控：能审查AI的输出质量
日常工作：
- 将产品需求翻译成技术规格
- 使用AI工具快速原型和实现
- 审查和优化AI生成的代码
- 建立工具链和工作流程
类比：
- 就像建筑师：不需要亲自砌砖，但需要懂建筑结构
- 或者电影导演：不需要亲自拍摄，但需要懂镜头语言
收入水平：
- 中高（20-35万美元/年）
- 因为技术能力有溢价
方向3：创意型PM（Product Innovator）
角色定位：
- 专注创新，提供AI无法产生的想法
- 设计全新的产品和交互范式
- 引领行业的变革和创新
核心能力：
- 创造力：想出全新的解决方案
- 设计思维：从用户角度重新思考问题
- 用户同理心：深刻理解用户心理
- 审美能力：判断设计的好坏
日常工作：
- 探索未被满足的用户需求
- 设计创新的产品概念
- 创造全新的交互模式
- 引领设计趋势
类比：
- 就像艺术家：创造前所未有的作品
- 或者发明家：解决别人没想到的问题
收入水平：
- 差异大（15-50万美元/年）
- 取决于创新的价值
7.2 不变的核心
虽然PM的角色在变化，但有些能力永远重要：
1. 商业sense
- AI可以分析数据，但无法做商业决策
- "做不做"比"怎么做"更重要
- 理解商业模式和价值创造
2. 用户同理心
- AI可以总结用户反馈，但无法真正理解用户
- 面对面的用户访谈无法替代
- 理解用户的情感和动机
3. 复杂权衡能力
- 产品决策常常没有完美答案
- 需要在多个目标之间平衡
- 这需要经验和判断力
4. 跨角色协作
- 产品开发仍然需要多方协作
- PM是粘合剂和推动者
- 沟通和协调能力永远重要
5. 责任心
- 产品的成败最终由PM负责
- AI可以辅助，但不能替代责任
- 这是人的价值，不是工具的价值
7.3 新增的必备能力
除了传统能力，新时代PM还需要：
1. 技术理解力
- 不需要会写代码，但要懂技术可能性
- 知道什么能实现，什么实现不了
- 能和开发/AI有效沟通
2. AI工程能力
- 会使用各种AI工具
- 知道如何组合AI达成目标
- 理解AI的能力边界
3. 快速学习能力
- AI工具变化太快
- 每3-6个月就有新的工具和模型
- 必须保持学习和适应
4. 数据驱动思维
- 用数据验证假设
- 基于数据做决策
- 建立数据分析能力
5. 系统性思维
- 不是单点优化，而是系统优化
- 理解产品、技术、商业的整体关系
- 长期主义和战略眼光
7.4 个人选择：你想成为哪种PM？
如果你是一个PM，现在需要做一个选择：你想往哪个方向发展？
如何选择？
问自己三个问题：
问题1：你喜欢什么？
- 喜欢宏观战略？ → 战略型PM
- 喜欢技术和工具？ → 技术型PM
- 喜欢创意和设计？ → 创意型PM
问题2：你擅长什么？
- 擅长商业分析？ → 战略型PM
- 擅长技术理解？ → 技术型PM
- 擅长用户洞察？ → 创意型PM
问题3：你的公司需要什么？
- 早期创业公司：更需要技术型PM（快速执行）
- 成熟公司：更需要战略型PM（方向决策）
- 创新驱动公司：更需要创意型PM（差异化）
我的建议：
- 不要试图什么都会，而是在一个方向上做到极致
- 但也要保持基本的全栈能力
- 根据职业阶段调整：初期可以偏技术，后期可以偏战略
八、结尾：从提词器动画说起
让我们回到开头的那个失败案例。
一个简单的提词器滚动动画，暴露了整个行业正在经历的深刻变革。
当AI把我的"滚动展开动画"理解成"三张静态图片"时，我意识到：传统的产品需求描述方式已经不够用了。
这不是AI的问题，而是我作为PM，还在用"人类语言"跟"机器"沟通。
这次教训让我开始重新思考：
- 我的技能树是否需要更新？
- 我的工作方式是否需要改变？
- 我的价值主张是否仍然有效？
经过深入的学习和实践，我发现：AI不是威胁，而是放大器。
如果你的价值在"执行"层，AI确实会替代你。但如果你的价值在"判断"层，AI会让你更强大。
新时代的产品经理，需要：
- ✅ 懂技术（不是写代码，而是理解可能性）
- ✅ 懂商业（比以前更重要，因为执行不再是瓶颈）
- ✅ 懂AI（知道如何驾驭这些工具）
- ✅ 懂自己（找到不可替代的价值）
不是要成为全栈工程师，而是要成为全栈产品思维者。
就像这篇文章开头的那个提词器动画，如果我只是模糊地说"实现一个动画效果"，AI会按字面意思理解。但如果我明确地描述"滚动驱动、分阶段过渡、具体数值"，AI就能完美执行。
关键不是AI有多强，而是你能否清晰地表达需求。
更深层的，关键是你能否清晰地定义价值。
这个时代，画原型、写PRD、开会、推进度，这些传统PM技能的价值都在被压缩。但是：
- 判断什么值得做（商业sense）
- 理解用户真正需要什么（洞察力）
- 设计创新的解决方案（创造力）
- 在复杂约束下做权衡（决策力）
这些永远无法被AI替代。
最后，送给所有PM一句话：
新时代的产品经理，不是要成为工程师， 而是要成为能够指挥AI军团的将军。 而将军必须懂战术，才能制定战略。
行动起来：
如果这篇文章对你有启发，不要只是点赞收藏，而是：
- 本周： 花3小时学习一个技术基础概念
- 本月： 建立你的Prompt模板库
- 本季度： 重新定义你的价值主张
AI时代的大门已经打开，机会属于那些主动拥抱变化的人。
不要抗拒学习技术，不要害怕AI工具，但也不要迷信AI能解决一切。
找到你的不可替代性，然后用AI放大它。
关于作者：
我是Sagasu，一个正在AI时代探索的产品经理。
如果你也在经历类似的转型困惑，欢迎交流。我们都在摸索，没有标准答案，但可以互相学习。
延伸阅读：
参考资料：
- Apple Product Pages: https://www.apple.com
- Scroll-driven Animations: https://developer.chrome.com/articles/scroll-driven-animations/
- Anthropic Claude Documentation: https://docs.anthropic.com