游戏策划与研发的边界：一位十年资深策划的自白

从业十年，我常被问到一个看似简单的问题：游戏策划到底算不算研发？在知乎上，这个提问下聚集了上百条争论。有人坚持策划只是“写文档的”，有人则认为策划是产品灵魂的构建者。边界在哪？其实取决于团队规模、项目阶段和公司文化。本文不试图给出标准答案，而是结合行业现状，拆解这一争议背后的逻辑。

近期趋势：策划角色被重新定义

近两年，国内游戏行业进入存量竞争阶段，项目立项更谨慎，“精品化”成为主流。与此同时，技术门槛降低（如Unity、Unreal引擎的普及）让策划有机会直接参与原型制作和逻辑配置。一个明显趋势是：许多中小团队要求策划具备基础脚本编写能力，甚至使用蓝图系统搭建关卡逻辑。策划与程序之间的灰色地带正在扩大。

• 纯文档型策划的生存空间收窄，尤其在快节奏的移动端项目里。
• 技术策划（Technical Designer）岗位出现，填补了设计与工程之间的鸿沟。
• 用低代码工具（如游戏内编辑器）进行“可玩文档”验证成为常态。

行业背景：研发的定义随公司规模浮动

在大型企业（如拥有成熟中台的厂商），研发通常指程序、TA（技术美术）、QA等直接产出代码、资源或测试服务的角色。策划被归类为产品部门，负责需求定义与验收。但在独立工作室或初创团队中，策划往往需要自己写脚本、调数值甚至做简单的场景编辑，此时“研发”边界变得模糊。

判断策划是否属于研发的一个经验标准：你写的东西是否会直接编译进游戏包体，或者直接影响最终用户的体验逻辑？如果答案是肯定的，你就在参与研发。

这并非绝对。例如，一个设计文档驱动的数值策划，其产出通过程序实现后进入包体，但策划本人并不直接编写代码。行业共识中，这种间接贡献仍被视为研发环节的一部分，但具体归口取决于公司组织架构。

用户关注点：策划在知乎上争论的焦点

知乎上该问题的高赞回答集中在三个核心矛盾：

• 话语权差距：很多策划抱怨自己的设计被程序以“实现不了”为由驳回，而程序则吐槽策划不懂技术限制。这导致策划被看作“提需求的”，而非“做产品的”。
• 技能交叉：能写出清晰伪代码的策划更容易获得程序尊重，但很多从业者缺乏编程基础，推进工作受阻后产生“策划不是研发”的挫败感。
• 职业晋升路径：在薪酬职级体系中，策划通常不与程序、美术并列为“技术序列”，而是“产品序列”或“设计序列”。这种岗位划分强化了“非研发”的认知。

用户关注点本质是：策划是否应该具备技术能力才能被称为研发？以及，如果策划不写代码，其贡献是否被低估？

可能影响：边界模糊带来的行业变化

边界争论并非纸上谈兵，它直接影响招聘标准、薪资结构和项目协作模式。

• 招聘要求趋同：越来越多JD要求策划掌握一种脚本语言（如Lua、Python）或熟悉引擎编辑器，纯文案策划的岗位减少。
• 学科教育滞后：高校游戏设计专业仍侧重理论，而行业对“可执行设计”的需求迫使策划在职自学，加速了“策划向研发侧靠拢”的趋势。
• 团队协作模型重塑：部分团队尝试将策划纳入“研发小组”，与程序使用同一套任务管理流程和版本控制工具，模糊了传统分工。

需要警惕的是，过度强调策划的研发属性可能导致另一种极端：要求所有策划都具备编程能力，从而忽视游戏性、叙事、关卡节奏等不可量化的设计价值。

后续观察：边界是否会消失？

从短期看，策划与研发的边界会持续存在，因为组织分工需要明确的权责划分。但趋势是：随着开发工具民主化和岗位细化，“全栈策划”或将成为一个独立分支，而传统“需求型策划”则更偏向产品经理角色。后续需关注以下信号：

• 技术策划岗位是否从大厂向中小团队扩散。
• 策划的绩效考核是否从“设计文档通过率”转向“最终上线效果”。
• 游戏制作人岗位是否统一由具有程序背景的策划担任。

作为一名十年策划，我的自白是：不必纠结头衔，重要的是你能否用自己的专业能力让游戏变得更好。边界存在，但值得去打破它——前提是你清楚自己想要成为哪种策划。