Hao的游戏PM笔记 - 节目列表

📝 本期摘要 一个在前司把Scrum跑得很顺的游戏PM，跳到新团队后同一套方法推了两个月就翻车了。这个故事引出一个根本问题：大部分PM积累的经验是「做过什么」，而不是「什么条件下该怎么判断」。前者换个项目就失效，后者到哪都能用。本期从「能搬家的经验」和「搬不走的经验」这个区分出发，用版本规划中的真实决策场景拆解了怎么沿着因果链条做判断，列举了大厂流程搬到小团队、照搬故事点估算、跟风爆款立项等游戏行业高频翻车场景，最后给出三个把经历转化为判断力的日常习惯。 ❓ 本期讨论了这些问题 * 游戏PM换了项目或团队，为什么验证过的管理方法突然就不灵了？ * 怎么区分「能搬家的经验」和「搬不走的经验」？ * 看到别人成功的管理方法，怎么判断自己的团队能不能用？ * 版本规划中，怎么识别关键路径上未验证的技术风险并做出取舍？ * 游戏PM怎么通过日常复盘真正积累可复用的判断力？ 🔥 本期核心内容 1. 经验分两种：能搬家的，和搬不走的 做过几个项目、管过多大团队、跑过什么流程——这些是有条件的经验，条件变了就失效。真正拉开PM差距的，是从经验中提取出「在什么条件下该怎么判断」的逻辑，这才是换个项目、换个团队依然管用的东西。 1. 别人的路只是参考，你要抓的是因果关系 经验可以过时，方法论可以失效，但「在什么条件下，什么原因会导致什么结果」这个链条是可以复用的。看到别人用某个工具效果好，第一反应不应该是「我们也用」，而是去追问他们的团队规模、协作模式和技术栈是什么，这个工具解决了什么问题，我们有没有同样的问题。要警惕把相关性当因果——「XX项目用了Scrum按时交付了」是结果描述，不是因果关系。 1. 版本规划的条件拆解：目的、要素、关系 版本规划的真正目的是在有限的时间和资源约束下交付一个能验证核心体验的版本，不是做得多。围绕这个目的，需要盘清团队实际产能、核心玩法验证状态、技术方案成熟度、里程碑硬约束等关键要素，再看它们之间怎么互相影响。一个未验证的技术方案放到关键路径上，一旦卡住，下游所有模块联调时间全部被压缩——沿着这个因果链条，才能做出「拆成流程版和完整版」这样的决策。 1. 照搬翻车在游戏行业太常见了 大厂200人团队的评审流程搬到30人工作室，一半时间花在开会填表上；故事点估算没经过校准就推行，速率数据乱成一团；跟风做开放世界，连核心玩法都没想清楚就写进PPT。这些场景的共同点是：看到了「果」，没去追问「因」，更没有盘自己的条件能不能支撑这个「因」。 1. 让每次经历都变成判断力材料的三个习惯 复盘时多问一层——不只记录做了什么、结果怎样，还要追问哪些条件促成了这个结果，某个条件变了结果会不会不同。看别人分享时先问条件——他的条件是什么，我有没有。接受判断会出错——关键是踩完坑之后拆开看，到底是哪个条件没看到、哪个因果判断错了。吃一堑，长十智，前提是你真的把那个堑拆开看过。 🏷️ 本期提到的人物与概念 概念：Scrum、Sprint / 迭代、Sprint Review / 迭代评审、故事点估算 / Story Point Estimation、关键路径 / Critical Path、版本规划 / Release Planning、目的·要素·关系（条件拆解框架）、开放世界 / Open World 📌 关于我 我是 Hao，游戏行业项目管理从业者，10年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai

📝 本期摘要 Hao的游戏PM笔记本期分享《游戏PM的AI实战手册》的第十篇加餐，聊了一个大部分AI深度用户都会遇到的问题——用着用着不知道让AI做什么了。Hao结合自己大半年的AI Agent开发和使用经验，从四个时间节点的工作记录中提炼出一个判断：问题出在"人提需求→AI执行"这个模式本身的结构性瓶颈。在此基础上提出了"自进化飞轮"的构想——让AI从被动执行者变成能自主发现问题、优化自身的协作伙伴。这套思路对游戏PM日常的Sprint回顾和工作流迭代同样适用，并给出了三个不需要技术能力就能落地的起步方法。 ❓ 本期讨论了这些问题 * 为什么用AI一段时间后，会出现"不知道让AI做什么"的空窗期？ * 当前"人提需求→AI执行"的协作模式，瓶颈到底在哪一端？ * 怎么把AI从"初级员工"升级为能自主发现问题的"资深员工"？ * 什么是"自进化飞轮"，它和普通的自动化有什么区别？ * 不写代码的游戏PM，怎么用现有工具构建AI的自进化体系？ * 游戏项目管理中的敏捷实践，能从自进化飞轮中借鉴什么？ 🔥 本期核心内容 1. 需求中断是结构性问题，不是个人能力问题 工具开发是阶段性的，痛点解决后需求就断了。人的需求发现能力有上限，而AI的执行带宽远超人的决策带宽，产能严重不匹配。BCG 2025年数据显示超过85%的员工仍停留在AI辅助执行阶段，McKinsey同期调查也发现从试点到规模化之间存在显著断层。 1. AI目前被当"初级员工"用，但它能胜任"中高级"角色 大多数人和AI的协作模式是单向链条：人发现问题→人提需求→AI执行→人验收。"发现问题"和"提需求"完全依赖人，这是瓶颈所在。改变不是技术问题，是管理思维的转变——和游戏团队中对不同职级成员的授权逻辑一样。 1. 自进化飞轮：感知→诊断→行动→反馈的闭环 不同于固定流程的自动化，自进化飞轮让AI在执行过程中发现可优化的环节，提出改进方案并实施迭代。学术界已有Self-Evolving Agents综述，IBM的MAPE-K框架也提供了工程参考。对不写代码的从业者来说，行为级自进化（优化Prompt和工作流）是最具现实意义的方向。 1. 落地三步：从"被动响应"到"主动体检" 第一步设定周期性AI自检，第二步给AI方向而非具体任务，第三步建立正反馈闭环。不需要技术能力，只需改变一个习惯——让AI也想想该做什么。这套方法可以直接迁移到游戏开发的Sprint回顾和敏捷实践中，让AI参与迭代复盘而非仅仅执行任务。 🏷️ 本期提到的人物与概念 概念：自进化飞轮 / Self-Evolving Flywheel、自进化Agent / Self-Evolving Agent、MAPE-K框架 / MAPE-K Framework、数据飞轮 / Data Flywheel、行为级自进化 / Behavioral Self-Evolution、敏捷实践 / Agile Practice、Sprint回顾 / Sprint Retrospective、Scrum、游戏美术管线 / Art Pipeline Management 公司/产品：BCG、McKinsey、IBM、NVIDIA、Notion AI、Claude 来源：《A Survey of Self-Evolving Agents》（arxiv）、《A Comprehensive Survey of Self-Evolving AI Agents》、NVIDIA Data Flywheel Blueprint 🔗 延伸话题 Q：游戏项目管理中，AI能自动化哪些Sprint环节？ A：AI可以自动化Sprint中的日报汇总、Bug分类优先级排序、跨职能依赖追踪等重复性环节。自进化飞轮的思路是让AI不仅执行这些任务，还能在每轮Sprint回顾中主动发现流程可优化的地方。 Q：零经验转行做游戏项目经理，需要先学AI工具吗？ A：建议先建立项目管理基础认知（流程、沟通、风险管理），再学习AI工具提效。AI是放大器，放大的前提是你有扎实的管理基本功。《游戏项目管理14讲》覆盖了从零开始的完整体系。 Q：游戏美术项目管理中，AI能做哪些自动化？ A：在美术管线中，AI可以辅助资产命名规范检查、外包交付物自动比对、进度看板更新等环节。自进化的思路同样适用——让AI在执行过程中发现美术管线的效率瓶颈，而不是等PM手动排查。 Q：游戏PM和互联网PM在AI应用上有什么区别？ A：游戏研发的迭代周期更长、跨职能协作更复杂（策划、程序、美术、音频多线并行），AI的应用重点在于版本节奏管理和跨团队信息同步，而互联网PM侧重数据驱动的快速迭代决策。 🌐 About This Episode In this episode of Hao's Game PM Notes, Hao explores a common challenge for AI power users in game project management: running out of ideas for what to delegate to AI. Drawing from months of hands-on experience building AI Agents for game development workflows, Hao introduces the "Self-Evolving Flywheel" — a framework that shifts AI from passive task execution to proactive problem discovery and self-improvement. This episode offers practical steps any game PM or game producer can implement without coding, bridging agile project management practices with AI-driven workflow optimization. 📌 关于 Hao的游戏PM笔记 「Hao的游戏PM笔记」是一个专注游戏项目管理的垂直内容品牌，覆盖游戏PM知识体系、转行路径、AI提效与行业观察。 主理人 Hao，10年游戏行业经验，策划转项目经理，持有 PMP / PMI-ACP / PSM / PSPO 认证。 📚 系列课程： * 《游戏项目管理14讲》——从零基础到游戏PM体系搭建 * 《从执行者到架构师》——进阶项目管理方法论 * 《游戏美术项目管理基础》——美术管线、外包管理与验收标准 * 《游戏PM的AI效率课》——AI工具在游戏项目管理中的实战应用 📡 全平台：小宇宙播客 · B站 · 小红书 · 公众号 · 知乎 课程 · 一对一咨询 · PM成长社区 → pmnote.ai

📝 本期摘要 2026年，游戏行业AI工具采纳率已超过90%，但超过半数从业者认为生成式AI对行业产生了负面影响。本期从一线游戏PM的视角出发，探讨了AI效率提升背后的四个真实困境：省下来的时间被组织填满、从业者角色从执行者退化为质检员、团队协作因不同环节的AI采纳差距而失速、以及60分到100分之间的能力鸿沟反而变得更有价值。同时分享了那些在AI时代真正获益的游戏人的共同特征——他们不追工具，追工作流。 ❓ 本期讨论了这些问题 * AI提升了73%开发者的效率，为什么行业焦虑反而在上升？ * 当从业者的角色从执行者变成AI的质检员，下一步会变成什么？ * 为什么AI在个人层面落地顺利，到了跨团队协作就全部撞墙？ * AI能快速拿到60分，从60分到100分的路为什么AI走不了？ * 当AI能做80%的执行工作时，游戏从业者靠什么留在牌桌上？ 🔥 本期核心内容 1. 效率陷阱：AI提了产能天花板，没有帮人省时间 Unity报告显示73%开发者认为AI提升效率，Google Cloud调研90%已在使用AI。但GDC 2026调研中52%从业者认为生成式AI产生负面影响，较去年上升22个百分点。省下来的时间被填进了更多的任务里，产能提升没有配套节奏管理，变成新一轮内卷——以前卷加班时长，现在卷产出密度。 1. 角色反转：从「我指挥AI」到「AI指挥我」 越来越多从业者的工作变成给AI提供上下文、抽检产出。部分团队已搭建「AI验证AI」流程，人的角色从质检员进一步退到流程设计者。PM的信息枢纽和判断中心优势正在被AI Agent压缩。大部分人的焦虑根源不是AI太强，而是没想清楚自己工作中哪些环节AI真正替不了。 1. 协作失速：AI加速了个人，但没有加速对齐 沃顿商学院研究发现，20家游戏工作室在个人层面引入AI顺利，但跨团队工作流几乎全部撞墙。瓶颈在于「隐性知识」——写不进文档的默契和上下文。不同部门AI采纳差距导致接口处摩擦成倍增加。AI写出的战略文档可能「文字全对，但无法产生承诺感」。 1. 60分到100分：AI帮不了的那段路价值最高 AI可以快速拿到60分的起点，但业务理解、行业体感、审美判断和经验直觉是AI无法替代的。真正获益的人把AI嵌进工作流而非当搜索引擎用、清楚人和AI的边界、追工作流设计思路而非追具体工具。 🏷️ 本期提到的人物与概念 人物：Craig Robinson / Games and AI 作者，前游戏公司高管 机构：Unity、Google Cloud、Skillsearch、GDC / Game Developers Conference、沃顿商学院 / Wharton School Generative AI Labs、游戏葡萄、脉脉、Aftermath 概念：效率陷阱 / Efficiency Trap、AI Agent、隐性知识 / Tacit Knowledge、渗透岗、产能天花板 📌 关于我 我是 Hao，游戏行业项目管理从业者，10年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai

📝 本期摘要 当一个大型互联网团队超过90%的代码由AI生成后，他们发现系统复杂度的增长远超维护能力——根源不在代码质量，而在需求端的失控。 AI压缩了交付周期，也降低了提需门槛，"先做做看"成为默认心态。 这个问题在游戏项目中尤为严重，因为系统间的高耦合度让一个需求的返工代价远高于互联网产品。 本期从需求失控的根因、游戏项目的特殊性、以及PM可落地的三个应对策略三个层面展开讨论。 ❓ 本期讨论了这些问题 * AI Coding为什么导致需求端失控而非代码端出问题？ * 为什么游戏项目的技术债比互联网产品积累得更快？ * 组织的激励结构如何推动"做更多"而非"做更对"？ * PM如何在自己的影响范围内守住需求入口？ * AI应该被用来生成需求文档还是审查需求文档？ 🔥 本期核心内容 1. AI Coding的最大风险在需求端，不在代码端 AI压缩了交付周期，需求方的心理门槛随之降低。"先做做看"成为默认选项，模糊需求和试探性需求大量涌入系统。单个需求看似合理，总量却在悄然失控，最终导致系统臃肿到无法快速迭代。 2. 游戏项目的"爆炸半径"远大于互联网产品 互联网产品模块相对独立，一个功能做砸了回滚即可。游戏项目中改一个战斗技能的判定方式，可能同时牵动动画、数值、碰撞、联机同步四个组。同样一个没想清楚的需求，在游戏项目里的返工成本是数倍级别的。 3. 重构治不了需求端的失控 代码审查、技术债清理、研发规范完善——这些都是下游筑坝。当每个人的KPI都在催"多做、快做"，没有人的考核指标是"这个需求不该做"。激励结构推着每个人做出局部最优、全局恶化的选择。 4. PM的三个可落地策略：换问题、锁需求、审而非写 需求评审从"能不能做"升级为"值不值得做"；用Feature Freeze在明确时间点后锁住新增需求；让AI辅助审查需求文档的边界条件和耦合点，而非只用来生成文档。这三个动作是PM在自己影响范围内能守住的阵地。 🏷️ 本期提到的人物与概念 概念：AI Coding、技术债 / Technical Debt、Feature Freeze、需求评审 / Requirements Review、系统耦合 / System Coupling、需求入口管理 / Requirements Gate 📌 关于我 我是 Hao，游戏行业项目管理从业者，10年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai

📝 本期摘要 游戏行业长期以来有一种"天才叙事"——好产品是个人灵感的产物。但十年项目管理经验告诉我，真正让项目从PPT走到上线的，不是那一两个决定性的大判断，而是上千个"谁都知道该做但不是谁都能做到位"的执行决策。本期从一个朋友招人时的感慨切入，拆解"靠谱"的三层含义——做事有闭环、对输出负责、眼里有整个项目，探讨在团队规模越来越大、个人英雄主义逐渐退场的行业趋势下，为什么可预测性正在成为比创造性更稀缺的竞争力，以及游戏PM如何系统性地训练"靠谱"这项能力。 --- ❓ 本期讨论了这些问题 • 为什么游戏行业招人时"靠谱"比"有想法"更难找到？ • "靠谱"这个看似模糊的词，拆开来到底包含哪三层能力？ • 当项目规模从十几人膨胀到上百人，个人英雄主义为什么逐渐失效了？ • 为什么大多数项目问题的根因不是"不知道怎么做"，而是"知道但没做到位"？ • 游戏PM如何通过日常习惯系统性地训练自己的可靠性？ --- 🔥 本期核心内容 1. 做对一千个小判断才能真的成功 一个项目从立项到上线需要做对几百上千个决策，其中方向性的大判断可能只有一两个，剩下绝大多数是排期、需求拆分、风险管控这类执行决策。单个不需要天才，但加在一起决定了项目能不能交付。 2. 靠谱的三层递进：闭环→负责→全局视角 第一层是主动给反馈不让人追着问，第二层是确保自己的产出下游能直接用，第三层是站在整个项目而非单个模块的角度做判断。三层递进，区分度逐层拉高。 3. 在复杂系统里，可预测性比创造性更稀缺 技术能力强但行为不可预测的人放在关键位置，不确定性会沿协作链条传导到所有下游。一个不那么耀眼但极其靠谱的人接手后，项目反而跑得更顺。 4. 对游戏PM的实操建议：闭环习惯、不追求高光、做串联者 不要追求高光时刻，真正定义靠谱的是每天处理的不起眼的事。建立当天同步进度的闭环习惯。关注模块之间的缝隙和信息差，做协作链条的串联者而非单点管理员。 --- 🏷️ 本期提到的人物与概念 概念：靠谱 / Reliability、闭环 / Closed-loop、可预测性 / Predictability、协作链条 / Collaboration Chain、信息黑洞 / Information Black Hole --- 📌 关于我 我是 Hao，游戏行业项目管理从业者，10年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai

📋 本期信息 * 原始来源：「Hao的游戏PM笔记」原创长文 📝 本期摘要 这期聊的是游戏团队在AI时代真正的护城河——不是技术，不是资金，而是组织形态。通过育碧、BioWare、米哈游、网易和Riot Games的案例，分析了组织结构如何决定一个团队能吸引什么样的人、做出什么样的决策、识别什么样的风险。对管理者来说，关键在于决策权跟着信息走、结构承诺和口头承诺一致、扩张前想清楚为什么需要更多人。对从业者来说，选择一个组织，本质上是在选择你会变成什么样的人。 ❓ 本期讨论了这些问题 * 为什么有些游戏团队技术不差、钱也够，产出却在缩水？ * 组织形态如何筛选和塑造团队中的人？ * 米哈游的「team of teams」模式在规模扩张后遇到了什么问题？ * 管理者搭建组织结构时最容易忽略的三个关键点是什么？ * 从业者选择团队时，怎么判断一个组织的形态适不适合自己？ 🔥 本期核心内容 1. 产品可以被模仿，组织形态极难复制 育碧巅峰期六年六部刺客信条，但资深员工流失、组织膨胀后产出反而缩水。BioWare做圣歌开发六年核心玩法最后两年才定。两个案例的共同点：技术、资金、人力都不缺，但组织结构决定了决策质量和人才发挥空间。 2. 扁平结构在规模膨胀后会失控 米哈游追求「team of teams」的扁平网状结构，但Project SH的教训表明，目标不明确时快速招人会让决策和执行同时变形。扁平结构在50人时靠默契运转，到500人时每个节点掌握全局信息的难度急剧上升。 3. 制作人集权是一种结构性风险 网易部分项目中制作人掌控从开发到宣发的所有环节，缺乏有效制衡。决策风险集中在单一节点上，一旦判断失误整条线跟着翻车。射雕和天启行动的结果证明了这种模式的脆弱性。 4. 组织形态决定你会变成什么样的人 对管理者：决策权跟着信息走而非职级走、结构承诺和口头承诺保持一致、扩张前想清楚为什么需要更多人。对从业者：区分一个团队是让你「觉得被选中」还是「被真正看到」——前者是情感驱动，后者是结构保障。Riot Games的案例说明，好的组织形态能批量培养出有独立判断力的人。 🏷️ 本期提到的人物与概念 人物：Alex Hutchinson / 蔡浩宇 公司/产品：育碧 / Ubisoft、BioWare、米哈游 / miHoYo、网易 / NetEase、Riot Games、EA 游戏：刺客信条 / Assassin's Creed、英灵殿 / Valhalla、圣歌 / Anthem、龙腾世纪审判 / Dragon Age Inquisition、射雕、天启行动 概念：Team of Teams、组织形态 / Organizational Structure、制作人集权、决策权下放 📌 关于我 我是 Hao，游戏行业项目管理从业者，9年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai

内容摘要 游戏行业9年PM从业者Hao，基于茹炳晟老师提出的AI Native产品经理成长框架，将游戏从业者与AI的关系拆解为四个阶段：工具提效、管线嵌入、工作流重构、判断力竞争。从策划用AI写文档到AI重写研发管线，从"用AI检查AI"的守门员模式到"越底层越确定、越顶层越灵活"的新三层架构，逐层剖析每个阶段的核心挑战与实操思路。最终结论是：当所有团队都用上了差不多的AI，拉开差距的不是技术，而是谁更懂自己的玩家、谁知道什么时候该克制。 本期讨论了这些问题 游戏从业者使用AI的四个阶段分别面临什么核心挑战？ 为什么AI嵌入工作流程比AI作为独立入口更有价值？ 怎么在需要确定性的游戏系统里用好不确定的AI工具？ 当策划能用AI独立验证玩法原型，研发协作模式会发生什么变化？ AI工具全面普及后，游戏团队之间比的到底是什么？ 本期核心内容 从消耗型到投资型：AI提效的真正门槛 策划花两小时跟AI打磨出的数值检查框架，保存下来反复用就是投资，每次从零开始就是消耗。AI工具人人能用，但你积累的判断标准和工作流模板是别人拿不走的竞争力。 AI嵌入流程比AI作为入口更有价值 在关卡编辑器里右键出现"自动生成过渡地形"，比让策划切出去打开聊天窗口输入需求，效率和体验都高一个量级。好的AI功能应该像输入法纠错——用户感觉不到它存在，但操作更顺畅了。 用AI检查AI：确定性系统里的守门员模式 游戏研发大量环节需要100%确定性，而AI天然是概率性的。解法是让专门的验证模型做守门员：检查NPC对话是否符合世界观、AI关卡是否可通关、装备推荐是否平衡。 新三层架构与PM角色的变化 工具链从"前端→后端→数据库"走向"意图理解→任务编排→确定性执行"，越底层越确定、越顶层越灵活。PM思考的问题不再是"做什么feature"，而是"哪些环节交给AI、哪些保持确定性、哪些需要人拍板"。 最后比的是判断力和克制 当所有团队都用差不多的AI技术，拉开差距的是谁更懂自己的玩家。养成系统做收集感还是成长感、付费底线在哪、什么feature会打断体验——这些取舍AI做不了。知道什么该AI化、什么该保持简单，本身就是核心能力。 本期提到的人物与概念 人物：茹炳晟 / Ru Bingsheng 概念：AI Native产品经理 / AI Native Product Manager、守门员模式 / Guardian Model、新三层架构 / New Three-Layer Architecture、Human-in-the-Loop、消耗型vs投资型AI使用 / Consumptive vs Investment AI Usage 关于我 我是 Hao，游戏行业项目管理从业者，9年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai

📝 本期摘要 《纽约时报》记者 Jasmine Sun 采访了五十多位技术研究者、经济学家和政策专家后发现，硅谷内部正在形成一个令人不安的共识：先进AI将在短期内大规模替代知识工作岗位，普通人的经济议价能力可能消失，财富和权力进一步向AI公司和资本所有者集中。"永久底层阶级"这个概念虽然极端，但它折射出的焦虑是真实的——从OpenAI的GDPVal测试方向、到企业提前裁员、到AI公司自身研究揭示的技能退化问题。本期从游戏行业项目管理的视角，拆解了这篇报道的3个层面，并讨论了AI对游戏研发团队的实际影响和从业者的应对方向。 ❓ 本期讨论了这些问题 * 为什么OpenAI的GDPVal测试方向本身就是在测"AI能否替代高薪专业人士"？ * 为什么AI公司嘴上说"增强人类"，实际研发方向却全部指向Agent？ * Anthropic的研究发现初级工程师依赖AI后技能下降17%，这对游戏行业意味着什么？ * 中国和美国对AI就业冲击的焦虑程度为什么差异巨大？ * 游戏行业的"AI使用深度分水岭"正在如何重塑团队之间的竞争格局？ 🔥 本期核心内容 1. AI评测基准的导向就是"替代" OpenAI的GDPVal测试覆盖44个高薪职业的1320个真实任务，从GPT-4o到GPT-5一年内得分提升三倍，模型对人类专业人士的胜率已超过80%。测试设计的目标不是"辅助"，而是直接对标人类专家的工作产出。 2. "增强还是自动化"跟技术无关，是商业环境决定的 同一个AI工具对资深从业者是杠杆、对初级从业者是替代品；在增长型公司是增强、在收缩型公司是自动化。AI公司无法控制客户如何使用产品，而所有研发激励都指向更自主的Agent。 3. AI公司的研究正在打自己的脸 Anthropic研究显示过度依赖AI编程的初级工程师技能下降17%，但公司自身靠Claude Code年化收入达300亿美元。OpenAI白皮书提出32小时工作周和公共财富基金等激进想法，但缺乏任何执行路径和游说承诺。 4. 中国视角提供了重要参照 中国劳动力成本低、就业竞争本已激烈、政策对裁员更谨慎，导致AI就业恐慌远低于美国。同样的技术在不同的经济土壤里产生完全不同的结果，说明"永久底层阶级"确实是政策选择而非技术宿命。 5. 游戏行业正在经历微缩版的"阶级分化" 团队内部AI使用深度的差距正在制造数量级的产能差异。对游戏PM来说，排期模型、资源分配、岗位价值定义都需要根本性重构——AI时代的项目管理不是做得更快，而是需要重新理解"人的价值"在哪里。 🏷️ 本期提到的人物与概念 人物：Jasmine Sun、Sam Altman、Dario Amodei、Tejal Patwardhan、Steven Adler、Yash Kadadi、Alex Karp / Alex Karp、Carl Benedikt Frey 公司/产品：OpenAI、Anthropic、Claude Code、GDPVal、Block、Palantir 概念：永久底层阶级 / Permanent Underclass、增强vs自动化 / Augmentation vs Automation、杰文斯悖论 / Jevons Paradox、公共财富基金 / Public Wealth Fund、技能退化 / Skill Degradation 📌 关于我 我是 Hao，游戏行业项目管理从业者，10年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai 参考资料 * Silicon Valley Is Bracing for a Permanent Underclass - The New York Times * Notes on AI, Labor, and China - Jasmine Sun Substack * GDPval: Measuring the performance of our models on real-world tasks - OpenAI * Industrial Policy for the Intelligence Age - OpenAI White Paper * How AI assistance impacts the formation of coding skills - Anthropic

📝 本期摘要 游戏行业过去十年最稳定的人才传送带——实习、校招、基础执行、慢慢成长为骨干——正在从中间断裂。脉脉数据显示新发岗位七成以上要求3年经验，面向新人的岗位缩减20%。斯坦福研究发现AI渗透率最高的白领岗位中，22-25岁年轻人就业率下降6%-16%。Hao从游戏行业"师徒制"特性出发，分析AI为什么恰好切断了新人积累判断力的入口，并分别给新人和老团队提出了具体的应对动作——核心是把"判断"和"执行"压在同一个动作里练，把沉淀的对象从结果换成判断。 ❓ 本期讨论了这些问题 * 为什么AI替代的不是"工作"，而是"工作经验的入口"？ * 游戏行业的"师徒制"培养模式为什么比其他行业更容易被AI冲击？ * 当执行被压缩，新人怎么在更短时间里长出判断力？ * 老团队过去的经验沉淀方式为什么正在被AI贬值？ * 如何把AI从"替你想的工具"变成"逼问自己的工具"？ 🔥 本期核心内容 1. 人才断层的本质是能力形成机制在断裂 斯坦福研究显示AI渗透率最高的岗位中，22-25岁群体就业率下降6%-16%，35岁以上反而增长6%-9%。AI接管的恰好是新人赖以入场的基础执行工作——整理文档、debug代码、跑报表——这些曾是训练判断力的训练场。 1. 游戏行业的"师徒制"让断层更深 游戏行业的判断力高度依赖重复执行中的隐性积累：PM的版本节奏感、策划的数值手感、美术的风格把控。AI压缩了执行量，新人两三个月消化完过去一年的工作量，但"做完了"不等于"做明白了"——速度变快，判断力密度反而变稀。 1. 新人的出路：把判断和执行压在同一个动作里 三个具体动作：执行前先问"为什么是这个不是那个"；用AI做"逼问自己的工具"而非替你想的工具；把每次卡点单独存档作为判断力训练样本。主动找有反馈的执行工作（Game Jam、竞品分析）替代正在消失的公司内基础岗位。 1. 老团队需要从沉淀"结果"转向沉淀"判断" 文档化沉淀的是"做了什么"，人头化依赖单点——两种方式都在被AI贬值。出路是把复盘从看结果转到看判断、把AI审核变成新人训练场、让新人更早介入决策场景、让"判断质量"成为被考核认可的产出。 🏷️ 本期提到的人物与概念 人物：Marc Benioff / Salesforce CEO、Dario Amodei / Anthropic CEO 机构：斯坦福数字经济实验室 / Stanford Digital Economy Lab、世界经济论坛 / World Economic Forum、脉脉 概念：人才断层 / Talent Pipeline Gap、师徒制 / Apprenticeship Model、判断力密度 / Judgment Density、AI Agent、Game Jam 📌 关于我 我是 Hao，游戏行业项目管理从业者，9年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai

【本期简介】 最近跟不同公司的朋友聊AI,大家都觉得有什么"对不上"了——发行的立项标准筛出来的项目"看着对,做下去就觉得不对";独立团队的人天和成本估计在尺度上失灵;大厂花一年做的内部AI工具,上线那天就过时。 这些零散的现象指向同一件事——游戏行业过去三十年用来判断"什么是好的、什么是稀缺的、什么值得追"的旧标尺,正在悄悄失灵。 这期节目,我会先讲清楚上游AI行业最近半年到底发生了什么,再聊这种震荡怎么传导到游戏行业,具体让哪三把标尺失灵了——工时、简历、大厂。最后落到中小团队和个人,聊聊我们到底应该怎么换尺子。 适合PM、团队负责人、正在准备跳槽或者中小团队里推AI转型的朋友收听。 【本期金句】 我们手里那些用来判断"什么是好的、什么是稀缺的、什么值得追"的旧标尺,正在悄悄失灵。 公司没省钱,只是把"人的成本"换成了"token的成本"。 你今天对AI的认知,六个月之后大概率是不准的。 经验里那部分跟具体工具和具体流程绑定的"工艺型经验",正在快速贬值。 简历的核心要素正在从"你的过去有多厚"变成"你的认知更新有多快"。 船大难掉头是个老常识。但在AI这一轮里,"难掉头"不再以年为单位,而是以月为单位。 敏捷本身就是一种资源。在AI这一轮里,这种资源比技术储备更值钱。 当所有标尺都在失灵的时候,真正稀缺的不是经验、不是title、不是大厂背景——而是重新校准自己的能力。 【主播介绍】 Hao,游戏行业项目经理,从业近10年。在公众号、B站、小红书同名"Hao的游戏PM笔记"持续分享游戏项目管理的实战经验和AI时代的工作方法。 【相关资源】 * PM成长社区:每天更新工作思考与复盘,聚集游戏行业PM和想转行做PM的朋友 * 课程体系:游戏PM入行课、《从执行者到架构师》进阶课、游戏PM的AI提效课 * 一对一服务:游戏PM模拟面试、简历优化 详情可以访问 pmnote.ai,或者在小红书"Hao的游戏PM笔记"后台联系。 【欢迎】 如果这期内容对你有启发,欢迎在评论区聊聊你手里那把"正在失灵"的标尺是哪一把。 如果你身边有正在做PM、带团队、准备跳槽的朋友,也欢迎把这期节目分享给他们。

【本期话题】 开了很多AI工具会员之后,我发现一个残酷真相——不是AI不够强,是我跟不上了。这期聊一个很少有人正面讨论、但每个深度使用AI的人迟早会撞上的问题:决策带宽的上限。 【内容提要】 * 个人AI使用反思:开了所有工具,钱浪费了,更关键的是我成了瓶颈 * 为什么AI产出必须人来验收:验收比想象中累得多 * 放手让AI做的代价:决策质量下降,反而得不偿失 * 核心矛盾:执行带宽可以无限扩展,决策带宽不能 * PM真正有价值的能力:高质量验收和决策AI产出 * 对不同阶段的人的具体启示:年轻人、有积累的、管理者 【金句摘录】 * AI可以无限扩展执行带宽,但人的决策带宽不可能同比例扩展 * AI放大的是你已有的能力,不是凭空给你能力 * PM真正有价值的能力,不是"能调用多少AI资源",而是"能高质量验收和决策多少AI产出" * AI的进化不会停,你的决策带宽是接下来拉开差距的关键变量 【相关内容】 * AI提效课:围绕游戏PM真实工作场景讲怎么用AI * 游戏PM进阶课《从执行者到架构师》 * PM成长社区:每天分享工作中的思考和复盘

本期信息 * 原始来源：《Agentic Design Patterns》Part Three & Part Four * 系列：智能体设计模式拆书 第4期（完结） 📝 本期摘要 这是智能体设计模式拆书系列的最后一期，聚焦把智能体从实验环境搬到生产环境时必须解决的问题。内容覆盖异常处理与恢复、人在回路中（Human-in-the-Loop）、安全护栏（Guardrails）、四种推理技术（链式思维 / 自我一致性 / 思维树 / 反事实推理）、评估与监控体系，以及多智能体通信架构（A2A）。最后从游戏项目管理的视角做全局收束：这 21 个智能体设计模式几乎都能在游戏研发管理中找到对应物，有效组织复杂工作的道理是相通的——PM 的核心能力和智能体系统设计高度重合，未来的 PM 角色正在从「执行者」向「架构师」进化。 ❓ 本期讨论了这些问题 * 智能体在生产环境中卡住或出错时，应该怎么决定是重试、回退还是求助人类？ * Human-in-the-Loop 有哪几种集成方式，怎么根据决策风险选择介入程度？ * 安全护栏应该在哪几个层面设计，为什么不能等出了问题再补？ * 链式思维、自我一致性、思维树、反事实推理这四种推理技术分别解决什么问题？ * 怎么系统化地评估智能体表现，为什么只看任务完成率远远不够？ * 21 个智能体设计模式和游戏研发管理之间有什么结构性的对应关系？ 🔥 本期核心内容 1. 异常处理的核心挑战是「知道自己不行了」 生产环境里的智能体需要超时机制、回退策略和降级服务组合使用。最难的设计不是让它持续尝试，而是让它学会在合适的时候停下来——对一个被设计来解决问题的系统来说，「放弃」反而是最难学会的事。 1. Human-in-the-Loop 的选择取决于「错了的代价有多大」 从「审批后才继续」到「只有异常才上报」，书里讨论了多种人机协作模式。核心判断逻辑和项目管理中的授权完全一致——不是所有事都需要审批，但关键决策该走流程就得走。 1. 安全护栏是架构决策，不是事后补丁 输入验证、输出过滤、行为边界、审计追踪四层防护需要在系统设计阶段就内建进去。和软件工程里「安全设计」的原则一脉相承——不要假设智能体永远按预期行事。 1. 四种推理技术针对不同复杂度的问题 链式思维让模型「做功课」再给结论；自我一致性通过多次推理比对结果可靠性；思维树在分支点探索多条路径；反事实推理问「如果条件不同，结论还成立吗」。简单任务可能用不到，但复杂多步任务的质量差异非常大。 1. 评估不只看结果，过程指标同样关键 步数、工具调用次数、耗时、自我纠正频率——这些过程指标对优化至关重要。「漂移检测」监控智能体行为是否逐渐偏离预期，因为有些变化是在变聪明，有些是在偏离目标。 1. 21 个设计模式和游戏研发管理的对应关系 提示链对应标准化流程，路由对应需求分级，反思对应评审机制，记忆管理对应知识沉淀，护栏对应质量门禁。这给 PM 带来双重启示：已有的管理思维可以直接理解智能体系统，而智能体设计模式也能反哺项目管理实践——信息策展、分层记忆、内建约束。 🏷️ 本期提到的人物与概念 概念：异常处理与恢复 / Exception Handling and Recovery，人在回路中 / Human-in-the-Loop，安全护栏 / Guardrails，链式思维 / Chain of Thought，自我一致性 / Self-Consistency，思维树 / Tree of Thought，反事实推理 / Counterfactual Reasoning，漂移检测 / Drift Detection，智能体间通信 / Agent-to-Agent (A2A)，资源感知优化 / Resource-Aware Optimization 书籍：《Agentic Design Patterns》 📌 关于我 我是 Hao，游戏行业项目管理从业者，9年经验。 课程 · 咨询 · PM成长社区 → pmnote.ai