游戏策划能力模型：30项核心条件与自测补短板路线

聊游戏策划这个岗位我这些年被问得最多的一句话就是什么样的人能干这行什么样的人能把这行干到顶尖。市面上讲“策划能力模型”的内容不少但大多停在“要有逻辑、要懂玩家、要会沟通”这种正确却没法落地的层面。我自己带过人也被人带过面试过上百份简历慢慢攒出了一套相对粗暴但好用的判断标准——30项核心条件。这篇就把它掰开揉碎讲清楚这30项条件分别是什么、为什么是这30项、怎么用它做自我诊断、怎么按优先级补齐短板以及哪些坑是新人最容易踩而我当年也踩过的。不管你是刚入行想搞清楚方向的新人还是做了几年开始遇到瓶颈的老策划或者只是对“游戏策划圣体”这个说法好奇的路人都能从里面拿到能直接用的东西。1. 先把30项条件这件事说透它到底解决什么问题很多人一提“能力模型”就头大觉得是HR搞出来考核人的表格。我一开始也这么想直到自己开始带项目才发现问题不在模型本身而在于大部分模型是“描述型的”——它告诉你优秀的人长什么样却不告诉你从现在的自己走到那个样子要经过哪几步。30项核心条件我想做成“诊断型的”它的目标不是评优而是定位让你知道自己的短板在哪个格子里而不是笼统地觉得“我还不够强”。1.1 策划岗的真实分工决定了条件必须分三层先说说现实。策划这个title下面藏着完全不同的活有人天天写表做数值有人趴在地上摆白盒关卡有人写系统规则文档写到凌晨有人跟美术对着一版UI稿吵一下午有人负责整个项目的世界观和台词。你让一个擅长写剧情的人去做经济系统平衡他会痛苦你让一个数值敏感的人去写对白他能写出说明书。所以30项条件我按三层来排底层素质、专业技能、高阶判断。底层素质决定你能不能入行并且活下来专业技能决定你能不能独立干活高阶判断决定你能不能带项目、做决策、成为那个“方案拍板的人”。这三层不是并列关系是叠加关系——底层不过关专业技能再花哨也走不远专业技能不扎实高阶判断就是空中楼阁。这里要强调一个常被忽略的点这三层的比例不是平均的。底层素质大概占8项专业技能12项高阶10项。为什么底层反而少因为底层素质的单项权重极高一项不合格基本就是一票否决。比如“能接受自己的方案被推翻”这一条做不到的人在这行待不过两年不管他多有才华。1.2 为什么是30项而不是10项或者100项有人会问30这个数字是怎么来的。说实话它不是精确计算的结果是我在实际带人过程中反复增删收敛出来的。10项太粗粗到“有逻辑”这种描述根本无法指导行动100项太细细到你会陷入工具焦虑光打勾就花一周。30项刚好落在一个舒服的区间每一项都能对应到一个具体的行为或产出物你能拿它去回看自己过去半年的工作记录判断“我到底做到了没有”。比如“会做数值基础建模”对应的行为就是“能不能独立搭出一个产出消耗闭环的表格并用它跑通一轮模拟”比如“能用一句话讲清核心体验”对应的行为就是“你向一个非本行业的朋友介绍你的项目他能不能在30秒内说出这游戏好玩在哪”。注意这套条件不是招聘JD不要拿它逐条去卡候选人。真实招聘看的是“有没有至少两项明显长板其余项不拖后腿”全项达标的人基本不存在真有也不会来面你这个岗位。1.3 这套条件最适合谁用我把它推荐给三类人。第一类是入行1-3年的新人用来做年度自评找出最该补的两三个短板避免东一榔头西一棒子。第二类是准备转岗的人比如从运营、测试、文案转策划用它对照一下缺口在哪心里有底。第三类是带人的主策或者制作人把它改成团队内的能力对照表比空泛地说“你要多思考”有效得多。不适合什么人不适合用它来给自己打鸡血。这套东西的用法是“找差距”不是“刷成就”。我见过有人拿它当清单一条条打勾全打完了发现自己还是不会做项目——因为打勾是自我评价做项目是外部验证两者中间隔着一整个真实世界的复杂度。2. 底层素质的8项条件决定你能不能在这行活下来底层素质这一层我的判断标准很朴素这些能力如果在入职前就不具备入职后也很难通过培训补上。它们更像性格和习惯的延伸而不是知识点。所以面试的时候我会重点看这几项专业技能反而可以放一放——技能能教习惯很难改。2.1 前三项把话说清楚、把问题拆小、把需求听明白第1项能把话说清楚。这一项看着像废话但我可以负责任地说它淘汰掉的人比任何专业技能都多。策划的核心产出物是“让别人按你的想法行动”而让别人行动的前提是别人能看懂你写的东西。一份策划案如果程序看完要来回问五遍“这里到底是什么意思”那这份案子的价值就是负的因为它消耗了别人的时间。什么叫“说清楚”不是文采好是信息完整、无歧义、有优先级。我自己写文档有个笨办法写完先放两小时回来以“我完全不知道这个项目”的视角重读一遍凡是需要脑补的地方全部补上。这个习惯让我少挨了很多骂。第2项能把问题拆小。策划每天面对的都是模糊需求“这个玩法不好玩你优化一下”“留存掉了你分析一下”。这类需求没法直接执行必须拆。拆解的关键不是拆得细而是拆完之后每一块都能独立验证。举个真实场景某项目组发现新手期流失严重讨论半天都在说“新手引导太长”。后来有人把它拆成三段——注册到第一次战斗、第一次战斗到第一次获得奖励、第一次奖励到第一次自主选择——一测数据问题出在第二段奖励发放的反馈太弱玩家不知道自己获得了什么。拆解的价值就在这它把一个没法下手的大问题变成了一个改一个动效就能验证的小问题。第3项能听懂别人在说什么。这一项比前两项更隐蔽。很多人以为自己听懂了其实只听到了字面意思。程序说“这个做不了”可能意思是“这个做不了但换个做法可以”美术说“这个风格我不太擅长”可能意思是“给我更明确的参考”主策说“再想想”可能意思是“这个方向不对但我不想打击你”。听懂的诀窍是追问一层。对方说完你复述一遍“你的意思是不是……”或者直接问“如果一定要做卡点具体在哪”。这个动作看着笨但能省掉大量返工。2.2 中间三项扛得住推翻、找得到信息、耐得住长周期第4项能接受自己的方案被推翻。我把这一项单独拎出来因为它是最容易劝退新人的一关。你花三天写的方案评审会上十分钟被否掉而且否得有理有据。这时候有两种反应一种是觉得被针对开始防御性辩论另一种是把否决理由记下来回去改。这行做久了你会发现方案被推翻是常态不是失败。一个方案能活到上线中间大概要经历五到八轮大改。真正的失败是“因为怕被推翻所以只提最保守的方案”——这种人三年后还在原地因为他从来没试过边界在哪。第5项能主动找信息。策划是信息的枢纽上游接需求下游对接程序美术外面还有玩家和竞品。指望别人把信息喂到你嘴边是不现实的。我见过做得好的同事都有个共同习惯自己建信息库。具体怎么做比如做竞品拆解不是看一遍就算而是截图存档、按模块归类、记录版本变化。比如做用户反馈不是等运营给报表而是自己去社区翻帖子、看评论区。这些动作没人要求但半年后差距就出来了——讨论同一个问题别人靠印象你靠记录。第6项耐得住长周期没有正反馈。游戏开发的反馈周期极长。你改了一个数值可能要两个月后才能在上线数据里看到效果你写的一段剧情可能因为版本排期被砍掉永远不会有人看到。这跟很多人的预期是反的——他们以为做游戏是天天玩、天天有灵感实际上是天天对表格、天天改文档。能扛住这一项的往往是那种能从过程本身获得满足感的人。改一版表格看到曲线变平滑了他能开心一下午。这种特质很难伪装也很难培养。2.3 后两项跨职能协作与足够的游戏阅历第7项能跟程序美术把事掰扯清楚又不结仇。这一项本质上是“在坚持目标和维护关系之间找平衡”。太软你的设计会被一路砍到面目全非太硬下次没人愿意配合你。我的经验是对目标强硬对方案柔软。目标层面不含糊——“这个功能必须让玩家在3秒内知道自己赢了”方案层面开放——“用动效还是用音效还是用文字你们定我配合”。这样对方感受到的是“这个人有主见但不难搞”协作成本大幅下降。第8项有足够的游戏阅历广度。注意是广度不一定是深度。只玩一个品类的人设计思路会被死死框住。我自己有个习惯每年强制自己玩三款“我平时绝对不会碰”的游戏哪怕只玩五小时。这五小时的价值不在于玩懂而在于知道“原来这个问题还有这种解法”。这一项还有个隐藏价值帮你建立横向参照系。讨论一个成长曲线的问题你能想到三个不同品类的处理方式讨论的质量立刻不一样。3. 专业技能的12项条件决定你能不能独立干活如果说底层素质是“人”的问题专业技能就是“活”的问题。这一层的12项每一项都对应一个能拿出来的产出物。我建议自评的时候不要凭感觉直接翻自己过去一年的工作记录看有没有对应的东西。3.1 文档、表格与数值建模最枯燥也最见功底的三项第9项掌握至少一种能落地的文档规范。策划案不是写作文它的读者是程序、美术、测试、运营每个人关心的部分不一样。所以好的策划案要有清晰的分区这一段是给程序看的功能逻辑这一段是给美术看的视觉描述这一段是给测试看的验收标准。我自己的模板大概包含几块需求背景为什么做、玩家体验目标玩家应该感受到什么、功能流程分步骤描述、边界情况异常怎么处理、验收标准怎么算做完。其中边界情况是最容易被漏掉也最容易出事的部分——正常流程谁都想得到出问题的永远是“玩家断线了怎么办”“道具满了怎么办”“重复点击怎么办”。第10项会做数值基础建模。这一项不是要求你会高深数学而是要求你能用表格把“产出—消耗—成长”这条链跑通。很多新人一听到数值就躲觉得那是专人干的活。但只要你要独立负责一个系统数值能力就是绕不过去的。入门路径我建议这样走先做一个最简单的成长曲线设定“玩家从1级到10级每级需要的经验值”然后用表格画出曲线看它是不是前期快后期慢。再往后加变量每日可获得经验、玩家留存分布、卡点设计。做完这一轮你对数值的感觉就有了。第11项懂经济系统的产出与消耗平衡。这一项和第10项是连着的但视角不同。数值看的是成长曲线经济看的是资源的进出总量。核心问题只有一个玩家每天产出多少资源系统每天消耗多少资源两者的差额会不会导致通胀或者卡死。这里有个特别好用的自查方法把所有资源列成一张表横轴是时间第1天、第7天、第30天纵轴是存量。如果曲线一路往上冲不回头说明消耗端不足中期会通胀如果曲线在第3天就贴地说明产出不足玩家会被卡走。这个方法粗糙但极有效我现在做任何带资源的系统都会先跑一遍。提示经济系统的坑往往不在数值本身而在“玩家会找到你没预想到的路径”。所以任何经济设计都要问一句“有没有可能被套利”这个问法能挡掉大部分事故。第12项会设计战斗节奏与手感反馈。这一项偏感官但它是有方法论的。战斗节奏的核心是“张弛”——连续高压会让玩家疲劳连续低压会让玩家无聊。我通常把它拆成三段来看进入战斗的引导期给玩家熟悉敌人、战斗中段的变化期加入新机制或压力提升、收尾的释放期给一个明确的胜利爽点。手感反馈则是另一套逻辑它更依赖多通道叠加视觉打击特效、受击抖动、听觉音效层次、操作输入延迟、镜头反馈、数值伤害数字跳动。任何一个通道缺失手感都会“轻”。这也是为什么很多小团队做出来的战斗总感觉差一口气——不是设计不对是反馈通道只做了两个。3.2 关卡、交互与规则描述把想法变成可执行的东西第13项会做关卡白盒与节奏铺排。白盒就是用最简单的几何体把关卡搭出来先不追求好看只验证“走位舒不舒服、视野够不够、难度曲线顺不顺”。这一项的价值在于它能把争论变成验证——两个人对着文档吵半天不如搭个白盒一起跑一遍五分钟就分出对错。白盒阶段我建议只关注三件事路径是否清晰玩家知不知道自己该往哪走、威胁是否可读玩家能不能提前判断危险、节奏是否有起伏有没有喘息的空间。这三件事定下来美术进场才有意义。第14项懂交互流程与信息层级。交互设计的核心不是好看是减少玩家的认知负担。玩家打开一个界面第一眼应该看到最重要的信息第二眼看到能做的操作第三眼才看到次要说明。层级乱了的界面玩家的第一反应是“我不知道该干嘛”然后关掉。判断层级有没有做对有个土办法把界面截图给别人看三秒然后问他“这个界面是干什么的、我该点哪”。答不上来就是层级有问题。这个方法我用过无数次比任何理论都好使。第15项会写无歧义的规则描述。这一项是第9项的加强版。功能流程能写清楚只是及格规则描述无歧义才是本事。区别在哪功能流程描述的是“玩家点了按钮会发生什么”规则描述的是“在所有可能的情况下系统应该怎么响应”。比如“使用道具”这个动作规则描述要覆盖道具不存在怎么办、数量不足怎么办、使用中被打断怎么办、使用后触发连锁效果怎么办、并发操作怎么办。写全这些程序才能一次做对测试才能一次测全。第16项有基础的程序思维。不是要求你会写代码而是要求你理解几个基本概念状态机一个东西有几种状态、怎么切换、事件什么事发生了要通知谁、数据驱动哪些东西应该配表而不是写死。有了这层理解你跟程序沟通的效率会翻倍因为你提的需求是“可实现的形状”。我见过最典型的反例是需求里写“玩家情绪低落时给他一个惊喜”程序看完直接沉默。这需求没错但它没法翻译成可执行的逻辑。改成“玩家连续三次战斗失败后第四次进入战斗时触发特殊演出”立刻就能做了。差别就在于有没有程序思维。第17项会做原型验证。原型可以是纸面的、可以是表格模拟、可以是引擎里搭个粗糙版本。核心目的只有一个在投入正式资源之前先确认这个东西成不成立。很多团队跳过这一步直接开工做完才发现不好玩代价是几十人月。原型阶段最忌讳追求完整。我自己做原型的标准是“能回答一个具体问题就停”——比如我要验证“这个战斗循环有没有节奏感”那就只做战斗其他全砍掉。3.3 文案叙事、用户研究与数据指标容易被低估的三项第18项有文案与叙事的基本功。这一项不是只有剧情策划才需要。任何策划写的文档、写的提示语、写的活动说明都在跟玩家对话。文字啰嗦、语气不对玩家对游戏的印象就掉一档。基本功的最低要求是准确、简洁、有语气一致性。提示语不能有歧义“确定要退出吗”这种要写清退出了会怎样活动说明不能有歧义奖励发放时间、领取条件必须明确整体语气要跟游戏的世界观一致。第19项会做竞品拆解与用户研究。竞品拆解不是“玩一遍写个感想”而是有结构的观察它的核心循环是什么、它靠什么留住人、它的付费点在哪、它的版本迭代节奏是什么。用户研究也不是“看评论区”而是能区分“玩家的表达”和“玩家的真实需求”——玩家说“太难了”可能真实需求是“我需要更清晰的反馈”而不是“把难度调低”。第20项掌握数据埋点与指标定义。这一项是很多新人的盲区。你不定义指标就没法验证自己的设计。最基础的一组指标是进入率有多少人到了这个功能、完成率有多少人走完了、留存贡献用过这个功能的人留存是不是更高。埋点设计的关键是先想清楚要回答什么问题再决定埋什么。反过来做的话埋了一堆点最后发现回答不了任何一个具体问题白费功夫。4. 高阶判断的10项条件决定你能不能成为顶尖前面两层加起来20项做到的人已经能独当一面。但“能干活”和“顶尖”之间隔着一段很长的路。这10项条件我自己也是在带项目之后才慢慢有感觉的。4.1 核心体验、创新判断与取舍能力第21项能用一句话讲清核心体验。这一项是分水岭。能讲清楚的人做设计时知道什么该保什么该砍讲不清楚的人只能靠堆功能。判断方法是你说完这句话听的人能立刻想象出玩家在干什么、感受是什么。比如“这是一款让玩家在有限资源下做艰难取舍的游戏”——听完你就知道重点在决策压力而不是战斗爽感。反过来“这是一款融合了多种玩法的开放世界冒险游戏”这种话等于什么都没说。第22项能判断一个玩法到底新不新。这行的“创新”大部分是重组真正的新东西很少。所以判断的重点不是“有没有人做过”而是“这个组合有没有产生新的体验”。我自己的判断方法是问三个问题它改变了玩家的什么决策它带来了什么新的约束它让玩家产生了什么以前没有的情绪三个问题都答不上来那大概率是换皮。第23项能做取舍与优先级排序。项目永远资源不足所以策划的核心工作之一就是排序。排序的原则不是“哪个最重要”而是**“哪个不做会死哪个不做只是少赚”**。前者是底线后者是加分项。资源不够的时候先保底线。这一项还有一个更难的部分砍自己最喜欢的设计。我砍过好几个自己写得很爽的方案砍的时候确实难受但回头看那些方案如果不砍会拖垮整个版本的节奏。第24项有商业模型与付费设计意识。这一项跟“良心”不冲突。理解商业模型是为了知道项目的钱从哪来、成本结构是什么、哪些设计会影响收入。有了这层意识你在做设计时会自然考虑“这个功能对留存有什么用、对转化有什么用”而不是只考虑好不好玩。第25项能带领团队对齐愿景。这一项是从“做好自己的活”到“让别人也做好”的跨越。对齐愿景不是开会喊口号而是让团队每个人在遇到具体取舍时能做出和你一致的决定。方法很朴素反复讲、用案例讲、在每次决策时把理由讲出来。4.2 审美、决策、复盘、迁移与长期主义第26项有审美与品味判断力。品味这东西看着虚但它是所有“差一点”的来源。同样的功能有人做出来就是顺手有人做出来就是别扭差别往往在那些说不清的地方——间距、动效时长、文字节奏、反馈的轻重。培养品味的办法只有一个大量接触好的东西并且试着说出它好在哪。说不出来就还没有真正理解。第27项能在不确定性中做决策。游戏开发本质上是高不确定性的工作你永远不可能有完整信息。这一项要求的是在信息不足时能给出一个“当前最优解”并且保留调整空间。我的做法是决策时明确标注“这个判断基于什么假设”假设被推翻时立刻重估。这样既不会因为怕错而不决策也不会因为决策了就死不回头。第28项能复盘失败并提炼方法论。复盘最怕变成追责会或者变成“下次注意”的空话。有效的复盘要落到可复用的规则上。比如“这次活动参与率低原因是我们把入口放在了三级界面”提炼出来的规则就是“重要活动的入口层级不超过二级”。这种规则攒多了就是个人的方法论。第29项有跨品类迁移与创新能力。这一项是第22项的延伸。真正的创新往往来自跨领域的类比把某个品类的机制搬到另一个品类产生新的化学反应。这要求你不仅有广度还要有“抽象的中间层”——能把具体机制抽象成通用结构再套到新场景里。第30项长期主义与持续输出。这一项听着像鸡汤但它是最实在的一条。这行的知识更新极快三年前的方法今天可能完全失效。能走远的人都有持续学习和持续输出的习惯——写复盘、做拆解、跟同行交流。5. 把30项条件用起来自测表与补短板路线条件列完了但列完不等于有用。我自己用下来的经验是这套东西的价值全在“怎么用”上。用得不对它会变成焦虑制造机用对了它是一张地图。5.1 自测表的打分方式与判读标准打分不要用1到10分太主观人会本能地往中间靠。我建议用三档能做到有产出物为证、勉强能做到需要别人帮忙、做不到。三档的好处是逼你去翻证据而不是凭感觉。层级条件数量判读标准常见状态底层素质8项出现2项以上“做不到”先别急着补技能新人普遍在这一层有1到3项缺口专业技能12项出现4项以上“勉强”说明还不到独立负责系统的阶段1到3年的人普遍在这一层卡住高阶判断10项大部分“勉强”是正常的这一层靠项目历练通常需要有主导项目的经历才会明显提升判读的关键不是总分而是分布。如果底层有硬伤专业技能再高也会在某个节点崩掉如果专业技能很整齐但高阶全是“勉强”那说明你缺的是主导项目的机会而不是能力本身。5.2 按阶段补短板的具体路线入行0到1年重点只放在三项把话说清楚、把问题拆小、掌握一种文档规范。其他全部先放一放。这三项扎实了你在团队里的口碑就立住了后面才有机会接触更核心的活。1到3年重点补数值建模、规则描述、原型验证、数据指标这四项。这四项是“独立负责一个系统”的门槛。补法不是看书而是主动申请一个小系统从头做到尾做完一遍比看十本书管用。3到5年重点转向核心体验表达、取舍排序、商业意识、复盘方法论。这一阶段最有效的方式是跟着一个完整项目走一遍从立项到上线的全流程中间每一个决策点都问自己“如果是我我会怎么定”。5年以上重点在愿景对齐、不确定性决策、跨品类迁移。这一层没什么标准路径基本靠带团队和跨项目经验堆出来。注意不要试图同时补五项以上。人的精力有限同时推进多项的结果通常是每项都停在“知道”层面没到“会用”层面。我自己的习惯是一年只定两个重点年底回看。6. 常见问题与踩坑实录这一节是我这些年被问得最多的问题以及我自己踩过的坑。有些坑现在想起来还挺丢人但确实有用。6.1 高频疑问与对应解法常见疑问背后的真实问题我的处理方式我玩的游戏不够多是不是做不了策划把阅历等同于数量广度比数量重要一年认真玩三款不同品类比无脑刷三十款有用我不会数值能不能只做系统把数值当成单独的工种只要独立负责系统数值就绕不开先从最简单的成长曲线开始我的方案总被否定是不是不适合这行把否定等同于能力否定记录每次否定的理由三个月后回看如果理由开始重复说明你在同一个点上没进步想法很多但落不了地缺拆解和验证习惯每个想法强制写一句“怎么用最小成本验证它”跟程序沟通总是不顺需求描述不可执行提需求前先自问“这个需求能不能翻译成状态和事件”做了两年感觉没成长一直在做执行没碰过决策主动申请参与一次立项讨论哪怕只是旁听6.2 几个我踩过的坑以及从中提炼的规则坑一把文档写得越厚越有安全感。刚入行时我写策划案动辄三四十页觉得写得越全越显得专业。结果程序根本不看直接来找我口头问。后来我才明白文档的价值不在于长度而在于程序能不能照着它一次做对。现在我写文档先写一页纸的核心逻辑确认对方看懂了再补细节。坑二用“玩家会喜欢”来支撑设计。这句话是万能挡箭牌但它什么也没说明。我现在要求自己每次想说这句话时替换成具体的推测“玩家在这个节点会因为缺少正反馈而流失所以加一个即时奖励”。推测可以被验证口号不能。坑三原型阶段追求完整。有次做一个小玩法我在原型阶段就把美术资源、音效、UI全配齐了花了三周。结果一测核心循环不好玩全废。从那以后我给自己定了条规矩原型阶段只做能回答一个问题的最小版本问题答完立刻停手。坑四复盘的结论写成“下次注意”。这种复盘等于没做。现在我的复盘必须落到一句可以检查的规则上比如“所有涉及资源产出的改动必须同时给出消耗端的调整方案”这种规则写进团队文档下次直接查。坑五把“不被否定”当成目标。有一段时间我提的方案总是最保守的那种因为保守的方案不容易被挑毛病。短期看很安全长期看毫无成长。后来我想明白一件事方案被否定的成本远低于不提方案的成本。前者只是浪费几天后者浪费的是整个人的成长曲线。6.3 从用人视角补一句我最看重哪几项如果让我只保留五项来挑人我会选把话说清楚、把问题拆小、能接受方案被推翻、会做原型验证、能用一句话讲清核心体验。这五项覆盖了“能不能沟通”“能不能落地”“能不能扛”“有没有判断力”四个维度基本能判断一个人是能干活还是有潜力。反过来说我最怕遇到的是那种“什么都能聊两句但拿不出一个完整产出物”的人。聊设计谁都会聊把东西做出来并且做成才是这行的分水岭。