205
今天花了点时间都投在了自己的 AI 体系上。用了几个月之后，记忆和规则越加越多，开始出现规则打架：同一件事在不同地方写了两份，改了一处漏了另一处；还有不少几乎不会被唤醒的规则一直躺在那里，占着上下文空间。今天跑了一次完整的体检、修复、复检，把积累的十几项问题全部处理掉了。
最大的体会有两个。一是 AI 的记忆体系和代码库一样会腐化，需要定期治理，而不是等它坏了再修——重复的规则、过期的规则、放错位置的规则，都会让系统越来越难维护，治理本身应该是个固定节奏的动作。二是修复本身也会引入新问题：复检抓出来的新问题里，有两个正是我这一轮整改自己造成的。
写进去的东西必须重新读出来验证，工具返回成功不等于真的改对了。 这跟做项目管理时验收交付物是一个道理，执行方说做完了，和真的做完了，中间隔着一次独立检查。
206
今天梳理了下半年的美术产能，过程中暴露出来的最大信息是：各环节的产能表面上都能算出来，但真正决定交付上限的是最下游的瓶颈环节，其他环节排期排得再满，瓶颈不动，整体产出就不动。这次会上把这一点明确成了共识：后续所有产能评估都以瓶颈环节为准。
这对资源申请来说，要人之前先回答三个问题：瓶颈在哪、加人是不是加在瓶颈上、瓶颈解开之后下一个瓶颈是什么。如果加的人不在瓶颈上，那不是产能提升，是库存堆积。需求侧同样有责任：当某类需求的实际成本远超预估时，先砍需求再谈加人，把最高光的部分做出来，比把清单做完更重要。
最近我也在思考项目管理这个岗位接下来的定位。我的判断是，下一阶段的核心竞争力，是把「花这么多钱做这些事合不合理」这个问题，从拍脑袋变成可以被测算回答。具体来说是一套量化机制：做一件事需要哪些岗位、各岗位的单价、按周期折算的人力成本、真实的预算规模。当团队提出资源诉求时，能快速把诉求绑定到具体规划上，用自有机制核算出一个可以被质疑、也经得起质疑的答案。
这套东西必须是工具和流程，不是文档和理念。写一份方法论谁都会，难的是把它嵌进评估过程里，让每一次资源决策都自然经过它。AI 在这里的位置也想清楚了：AI 引入之后，度量口径本身要重建，传统的人天估算没有覆盖「人机协作」这种新的生产方式，谁在用、用在哪、产出归因到哪，这些数据结构需要从头设计。这块做成了，价值不只在一个团队：机制固化之后可以被其他团队直接参考，输出是指数级的。
另一个判断是关于 AI 支出的：放开使用换来的是速度，收拢口径换来的是可持续。任何组织在 AI 上的投入放开一段时间后，财务侧一定会要求可归因：人均用量、人均成本、横向对比。提前把归因体系建好的团队，在这一轮收口中是加分项；拿不出数据的，会被解读为管理不透明。这件事不能等被要求了再补。
207
借着白天的执行会，把纪要格式固化了下来。核心结构原则是按读者分层：开头部分服务没参会的人，会议信息、关联链接、职能拆分表、需求范围，让人一眼看清这个需求要哪些职能参与、归谁开发；末尾的附录服务未来查证，完整保留会上讨论与决策的推导过程，平时不必细看，等后续实现与结论对不上、需要追溯「当时为什么这么定」时再查。职能拆分表只固定职能行，负责人与预估工时留空，由各职能会后自行填写。文本整理这类活交给 AI 处理，人只做结构与口径的裁决。
团队下一阶段的资源申请，最终要经受高层的审视，这个问题会层层传导到项目管理这里。我对这件事的判断框架拆成三块。
- 第一块是历史产能：团队过去做一类资产实际花了多长时间，这是既成事实，其中美术是成本大头，又恰好是标准化程度最高的工种，参考工时与外包单价都透明，所以从美术开始盘。
- 第二块是下阶段目标清单：哪些类型是做过的，可以用历史数据直接覆盖；哪些是没做过的新类型，只能采信团队预估，但要标注误差范围，等里程碑结束后回填实际值，让各组的报价可信度开始积累。
- 第三块是项目管理自己的判断：清单里的每一项，是否真的属于这个阶段该做的事，这一块无法量化，只能靠绑定里程碑来约束，产出物在阶段评审上用不上的，建议放到评审之后再批。
推演过程中被修正掉的一个方向：我一度想去测算「AI 帮团队提效了多少」，后来发现这是个伪命题。对照组不存在，没有人会用传统方式把同一件事重做一遍供你对比，而团队自报的提效比例也很难判断是否合理。真正可用的口径是实测产出速度，团队实际做出了多少东西是既成事实，人机协作的效果已经自动包含在里面，不需要单独拆分 AI 的贡献。
另一个阶段性结论是对「合理」这个词本身的重新定义。合理不等于回报为正，公司里绝大多数支出从来不靠测算回报来证明自己，差旅费就是例子。合理的实际标准是三条：钱花在哪说得清、横向对比不出格、发现不对随时停得下。还有一条判断是关于花钱顺序的：在没人知道对错的阶段，钱要优先花在能反悔的地方。人员编制是重押注，收缩的代价很大；外包与订阅类支出下个周期就能停。给决策者的东西，最好是一组可以分批下注的选项，单靠一份论证接不住这种不确定性。
208
今天把各职能把接下来要做的事逐模块过了一遍，信息量很大。对完之后我反复在想一个更根本的问题：项目进入新阶段之后，「该不该做这么多、该不该花这么多钱、要不要这么多人」，这类问题我拿什么来判断。昨天从算账的角度推演过一轮，今天从范围判断的角度接着往前走了一步。
这次其实只看最高优先级的需求，以及这个阶段的最小验收标准是什么。**口径先行的好处是，后面各模块报需求时天然有了裁剪依据，不会开成愿望清单大赛。**人力的讨论顺序也是对的：先想清楚要做的事，再谈要多少人；顺序反过来，就会变成先把人要满、再找事把人填满。
新阶段随之而来的问题是，规划里的东西该不该做这么多。回答这类问题是 PM 这个职能的核心价值之一，今天想把判断的来源和落点梳理清楚。
判断的输入有两层。
- 对内，是对游戏本身的理解、对研发规律的理解、对项目现状的了解，包括各职能的产能、各模块的状态、可能的风险点；
- 对外，是市场在什么位置、竞品在做什么、做得怎么样。
这些输入最终汇成 PM 视角的一个判断：接下来一段时间做这些事，是否合理。但「合理」不能悬空，它必须锚定在阶段目标上。
项目能不能持续拿到资源，最终取决于玩家买不买账；玩家买不买账，要看真实玩家验证的结果。这样倒推回来，判断依据就清楚了：下一次验证之前什么最重要，取决于这次验证要给玩家什么样的核心体验；一项内容该不该做，取决于它是否服务于这次验证要回答的问题。
敏捷开发的十二条原则里有一条我以前体感不深、现在越来越认可：以简洁为本，极力减少不必要的工作量。它把「不做什么」当成一门需要主动经营的手艺。
有一条原则要单独说清楚：**目的不是省钱，是不浪费钱。**让 PM 做这个判断，不是要团队用最抠的方式做事，是不希望产能花在对验证目标没有贡献的地方。而研发里最大的浪费从来都是返工，所以砍范围之前还要先给内容分类：有些内容后面可以增量补上，有些内容后补必然引发返工，比如底层架构、生产管线、工具链，这类反而要一次做对，不适用最小验证的逻辑。范围可以砍在内容上，不能砍在地基上。
209
前几天提到关于如何计算「AI 的效果」时我觉得提效百分比是伪命题，没有对照组，团队自报的数字通常站不住脚；真正可用的是团队实测的产出速度，它天然含着 AI 的贡献。今天我特意去翻了国外这两年的研究，想看看这个判断站不站得住，结果和我预期的差不多。
METR 去年做过一个随机对照实验，让资深开发者在真实代码仓库里做任务，用 AI 的一组事前预估自己能快百分之二十几，事后也觉得自己快了两成，实测反而慢了 19%。自我感知和真实数据连方向都是反的，连报数的人自己都不知道真相。
第二层印证来自 DORA 这两年的报告。他们的结论是 AI 是放大器，放大的是组织原有的工程体系，所以要衡量的对象是被放大的系统，而非 AI 活动本身；他们有句话我很喜欢：**衡量 AI 不看它写了多少代码，看它清掉了哪些瓶颈。**另一个数据：AI 让个人产出显著上涨，任务完成量和合并请求数接近翻倍，组织级的交付指标却基本没动，因为瓶颈转移到了评审和集成环节。这其实回答了「效果怎么算」的口径问题：口径要落在组织级交付上，个人产出只能当参考，不然会得出一堆好看但推不动决策的数字。
第三层对「资源给多少」也有增量。DORA 今年出了个 ROI 框架，里面提到一个 J 曲线：AI 投入的头几个月产出往往先降后升，因为省下来的时间被花在验证 AI 产出上了，他们管这个叫验证税。这对资源决策的含义是：观察窗口至少放到季度级，别拿头一两个月的数据下结论；同时也支持了分批下注的节奏，先小额投入，按季度实测再决定下一注。**核心是：衡量体系不是用来证明 AI 值钱的，是用来决定下一笔钱投在哪的。**这个定位想清楚，很多「算不清」的焦虑就消掉了。
最近工作方式上有个真实的痛点。AI 时代能做的事太多，我经常同时开好几个 agent 干不同的活，但在窗口之间切换的认知负担很大：每切一次都要重新回忆这条线的上下文、它做到哪了、我接下来要做什么决策、要派什么任务。可是一次只跑一条线也不现实，agent 干活说实话还是慢，串行等于把自己闲置。
去社区里翻了一圈，发现这已经是被反复讨论的问题，共识很一致：**多 agent 并行的瓶颈在人的协调成本。**有研究给过一个数字，每次任务切换要损失 15 到 20 分钟的恢复时间，一天切四次就是一个多小时。成熟的实践大致收敛成几条。工作区要物理隔离，每个 agent 一个独立目录和分支，改动互不污染，合并时由人来定顺序。状态要可视化，用一块看板挂住每条线：谁在跑、谁在等我审、谁可以合并，把「我现在该看哪个」从记忆里搬到屏幕上。每条线要有清晰的名字和一句话目标，agent 常驻自己的线程，不跨线乱窜。上下文按需给，规划的角色知道全局，干活的角色只拿自己那份。还有一条我觉得最聪明：agent 出错时别急着自己上手改结果，先改派给它的指令和上下文文件，再让它重跑，这样纠错就沉淀成了持久资产，下次不会再犯。
对我自己更重要的是一个视角转换：**并行度的上限由我的评审吞吐量决定，能开多少个 agent 反而是次要的。**写的环节被 AI 提速之后，瓶颈整体后移到了审的环节，盲目加并行只会让未审的产出堆积，所以真正该盯的指标是单位时间里通过质量线的任务数。打算先从克制的版本做起：并行两到三条、任务挑相互独立的、看板显式化，跑顺了再加。
韩国游戏《龙之剑：觉醒》前阵子上架 Steam。它的前身是一款服务型开放世界动作游戏，今年 1 月在韩国上线，撞档《明日方舟：终末地》，下载榜拿了第一，畅销榜只排到 75 名，营收很惨。更糟的是开发商和发行商随后闹翻，开发商以发行方未支付最低保证金为由解约，团队从 160 人裁到 50 人左右，走到破产边缘，中间还打赢了一场发行禁令官司。然后他们做了一件此前没人做过的事：用大约三个月把抽卡系统整个拆掉，全部角色改为免费获取，重新包装成买断制单机，国区定价 98 元上架 Steam。
结果比多数人预期的好：首周销量突破 20 万套，峰值同时在线约 2.3 万人，好评率九成上下，愿望单累计约 70 万，主机版本和后续内容更新也已经官宣。按定价粗算，首周流水在数千万人民币量级。这个数字要分两面看：对当初按服务型游戏立项的投资模型来说只是零头，但对一个研发成本已经沉没、公司濒临清算的团队来说，这是从零到有的回收，保住了团队、IP 和继续开发的资格。买断制救不回投资模型，但救得回团队。
我觉得这件事的行业意义大于产品本身。**新的商业模式往往由没有退路的人先验证，因为有退路的人不愿意做第一个担责的。**这家公司敢这么干，是因为不这么干公司就没了。而它一旦跑通，等于给所有商业化失败的服务型游戏多开了一条退出路径：内容资产重新包装成买断制再上架，止损方式从关服清算变成改造再发行。当然这条路有前提：得有 PC 版的底子，内容量得撑得起买断定价；纯手游改成单机上 App Store 大概率走不通，付费手游的市场天花板太低。往深一层想，如果这个案例被验证是可复制的，未来立项时「Steam 买断兜底」甚至可能被写进风险对冲方案里，商业化模式会从立项时锁死的属性，变成内容资产可切换的发行策略之一。接下来值得持续盯两个指标：长线销量能走到多少，承诺的持续更新能不能兑现。这两个答案决定它是孤例还是路径。
日更完整版在飞书：Hao 的工作思考