0
0📝 本期摘要
Hao的游戏PM笔记《游戏PM的AI实战手册》第13章，讲风险找到以后怎么处理到位。判断标准只有一条：下次同样的情况会被某个机制拦住，靠人记住“以后注意”的不算。处理先核实证据，“测过了”“改好了”对人和对agent一样要看到记录；AI出错先定位出在材料、交代、计划、工具还是最后一步，一次只改一处。5Why每一层都附依据，问到能用机制改变的原因为止，方案分人、机制、结构三层。最后讲检查点放在哪、规则和闸门怎么分，以及每个agent都要有owner，谁放行谁担责。
❓ 本期讨论了这些问题
风险处理怎样才算处理到位？
同事或agent说“测过了”“改好了”，要看到什么证据？
用AI做5Why，为什么每一层都要附依据？
改进措施落在人、机制、结构哪一层，差别在哪？
agent出了问题，谁来负责？
🔥 本期核心内容
先核实证据，对人和对agent一样
测过了要看测试清单或报告，改好了要看提交记录和按原复现步骤再走一遍的结果，执行成功要看复查结果。拿不出证据的，在处理记录里写“未核实”，不能当成已完成。5Why每层附依据，“沟通不畅”不算根因
以外包角色模型进度落后15%为例：返工率40%，依据是外包周报；修改意见和最初要求不一致，依据是反馈记录；需求只有简单描述，依据是需求文档；根因是外包启动前没有“需求文档完整”这道前置条件。找不到依据的层标推测。方案分人、机制、结构三层
提醒、培训、以后注意落在人这一层，下次会不会被拦住取决于当事人记不记得，只能当临时措施；检查点、必填项、自动检查落在机制层；调整职责、改流程顺序落在结构层。确定的规则交给脚本和工具，需要理解内容的，让AI先列疑点、负责人判断。不可逆的动作用闸门，谁放行谁担责
规则写在项目规则或Skill里，agent可能误解或忽略；闸门是权限不给或必须审批，一定拦得住。对外发布、删除、批量修改、改线上内容用闸门。每个agent都有owner和授权卡，放行的人对放行负责，出了问题先改机制。
🏷️ 本期提到的人物与概念
概念：根因分析 / Root Cause Analysis；5Why / 5 Whys；检查点 / Checkpoint；闸门 / Gate；授权卡 / Agent Authorization Card；责任表 / Responsibility Matrix
🔗 延伸话题
Q：项目复盘的根因写“沟通不畅”有什么问题？
A：它描述的是现象，改不了任何机制；要继续问为什么，问到一个能通过改流程、加检查或改职责解决的原因。
Q：agent的产出有问题，直接让它重做可以吗？
A：常常会换一种方式再错一次，先判断问题出在材料、交代、计划、工具还是最后一步，一次只改一处再让它重做。
Q：给AI开权限之前要想清楚什么？
A：先问三个问题：它会不会在你不知道的情况下改变任务，会不会替你做不可逆的决定，你监督它的方式靠不靠得住，再把答案写成授权卡。
🌐 About This Episode
Chapter 13 of Hao's Game PM Notes course defines risk handling as done only when a mechanism would catch the same problem next time. Hao walks game project managers through evidence checks, an evidence-backed 5 Whys, solutions at the people, mechanism and structure levels, gates for irreversible actions, and clear ownership for every AI agent.
📖 本期延伸阅读
关于 Hao 的游戏 PM 笔记
我持续分享游戏项目管理、求职准备和 AI 实践，也把相关内容整理在了 PMNote 这本游戏 PM 百科全书里。微信内也可以直接搜索「Hao的游戏PM笔记」，使用小程序版。
查资料、找岗位：游戏 PM 岗位信息、面试练习、文章、工具和模板。
一对一咨询：简历修改和模拟面试。围绕目标岗位梳理经历，检查简历表达，或通过模拟面试和逐题复盘发现准备中的问题。
系统课程：游戏 PM 课程与 AI 课程，分别介绍游戏项目管理，以及 AI 在游戏行业和日常工作中的用法。
课程内容、服务说明和预约方式：PMNote · 课程与咨询。
