当大家谈论AI颠覆游戏行业时，一线从业者这样用Deepseek

我在想，到底对游戏行业的影响有多大。

你看，这款工具在年前火得一塌糊涂，被《黑神话：悟空》制作人称为“国运级科技成果”。

一段时间内，Deepseek本身就成了流量密码、泼天富贵。大到概念股暴涨，各领域大厂下场接入Deepseek、小到零基础用Deepseek做游戏……沿着这个趋势，说不定蔡浩宇说的“99%的开发者”真的要被迫提前转行了。

《逆水寒》《和平精英》接入Deepseek

可事实真的是这样吗？跟多位不同岗位的游戏从业者聊过后，葡萄君却得出了不太一样的结论。

我身边有关卡同事做Demo的时候，会利用自己的需求内容，先让Deepseek写一份代码，然后给技术同事进行效果演示，这种操作方式会让技术同学更好地理解策划需求。

图片素材来源葡萄君模拟，仅供演示

另外就是把Deepseek当搜索引擎，比如问它某种玩法机制哪些游戏用过。

最近我也在想怎么扩展Deepseek的应用，因为这款工具特别大的好处是会给参考文献和推理过程，这样它给的结果准确与否其实没有关系——我自己能看出来，并基于这些中间结果进行二次搜索。

这种特性特别适合个人跨行学习和发展：

再比如帮我梳理策划文档的逻辑，查漏补缺，这对我个人发展来说很有意义。

——某单机游戏文案策划

Deepseek上次对工作有帮助的时候，应该还是辅助我找资料。

在联网和深度思考模式下，让它给出某一时代适合作为英雄进行二度包装的历史人物的姓名、资料、选取原因、包装方案、包装逻辑说明，人工再对其二次筛选修改，作为供上级选择的材料。

图片素材来源葡萄君模拟，仅供演示

但我认为Deepseek暂时没办法真正加入研发核心工作流，它的确在灵感和包装层面会提供一定帮助，但成品转化的效率并没有想象中那么高。一个是胡编乱造的原因，你需要花精力交叉验证；另一个是它自己的模型语料风格鲜明（比如科幻味），很难掰成你想要的风格，顶多给到一些prompt，但这就会导致产出结果很一般。

——某独立游戏制作人

我们在策划过程中，会对一些碰到的问题跟Deepseek交流，它会给出一些建议和方向，尤其是推理问题的过程，能够帮我们查漏补缺，或者提供一些新的思考方向：

——某上海四小龙游戏玩法策划

我也经常将Deepseek等工具作为搜索引擎，或者自我审查的工具。

比如在写好策划案后，跟它说“你现在扮演一个测试工程师来检查一下，看有哪些边缘条件我没有想到，来质疑一下我。”

然后它就开始被我忽悠着“打工”了。

图片素材来源葡萄君模拟，游戏为虚构，仅供演示

我觉得AI查漏补缺对个人的好处大于对项目，因为这个环节在你跟其他同事对接协作时，也都会对出来，只不过用了这些AI工具后，你在大家眼里就会更“细心、靠谱”起来。

除此之外，我个人对AI工具和应用主要是两方面：制作业务工具、搭建玩法原型。

对于前者来说，虽然我们公司有专门的技术中台帮策划研发各种工具，但从提需求、排期、沟通、执行到落地，中间可能会耗费大量的成本，用Deepseek、GPT等AI工具研发，会节省大量时间精力。

比如上次我花了1个小时写了个相对复杂的业务工具，可以实现数据可视化和验证。在没有这个工具前，我审查这些编辑器导出的表格数据可能需要一两天，现在基本只要5分钟。

数据验证工具

搭建玩法原型的情况类似，因为不少厂商的立项自下至上，我们需要给老板审查我们做的东西好不好，过去做这些东西可能需要一个方案、一个PPT，但这样哪怕你说得天花乱坠，没法验证，大家还是不知道好不好玩。

因此我们策划需要简单出个玩法原型，可能不需要很完善、不用打包，能看起来像回事、达到演示效果就行。

这时如果你按原来的模式和开发周期，可能需要一两周的时间和人力成本，还需要担心做出来之后没过评审，来回拉扯修改；但随着GPT等AI工具的迭代进化，我们只需要拆分这个玩法原型需要什么功能，然后逐一跟AI工具对话、优化、组合……最终可能只需要一天就能做出玩法原型。

做这些东西的时候我也在想：这算不算“偷工资”？因为我周围的人确实很少有意识地用AI工具提效。

但回头想想，哪怕真是手打代码，那其实也会有类似Copilot这类预测输入工具进行20%-30%的提效，我这应该算是另一种“技术红利”了。

Copilot根据注释进行预测，图源知乎@Jayden

——某大厂叙事策划（技术向）

我目前的编程工作中不太用DeepSeek，因为它太发散了，喜欢提醒我注意一些我不需要注意的问题。

首先，我的工作分两个部分，一是找到解决方案，二是落实解决方案。

在前者上我会问：有什么方法，能实现怎样的一个功能？这个时候得到的基本都是启发性回答，还是有用的；但当我说，我认为其中一个方案不错后，它会一直围着这个方案转，出不去了。

比如我先问：在虚幻引擎的GAS中，通常如何判断一个Gameplay Ability是否可以触发（比如血量低于 90%时可触发）？它会给我一些有价值的参考；

图片素材来源葡萄君模拟，仅供演示

我的第二个问题是：假设现在有一个源对象和一个目标对象，我需要同时依赖源对象和目标对象的状态作为Ability可用条件（比如需要双方血量均低于90%），我是否可以利用Gameplay Ability System做到这个判断？

DeepSeek给了我一个完整的方案：结合属性监听、条件检查逻辑和网络验证来实现。

图片素材来源葡萄君模拟，仅供演示

但你知道我第二个问题最需要的答案是什么吗？

是“不能”。Ability在激活前没有办法得到Target的信息，只要知道这个，我就可以放弃这个方向，去寻找别的方法了。

也就是说，针对一个具体问题，有时我问“能不能”，它会想着办法给我“能”的答案。但如果事实上确实不能，它想的办法可能就会变成胡编乱造，或者至少也会浪费时间。所以DeepSeek基本只能在方案选型上用，进入一个方案后就跳不出来了。