系列说明
这是我复盘 2015 年开始游戏创业失败过程的第二篇。第一篇写的是出发时的错觉：我把在腾讯、搜狐畅游做游戏和游戏社区的工程经验，误认为足以支撑自己从零做一家公司。本文更具体，写第一款产品是怎样从热血、兴奋、快速推进，慢慢变成失控、犹豫和消耗的。
我不想把这段经历写成“如果当时某个功能做对就好了”。很多失败不是某个功能的问题，而是立项方式、验证路径、团队节奏和心理状态共同造成的。第一款产品失败，表面上看是数据不好、完成度不够、上线节奏拖延；更深一层，是我们从立项第一天起就没有把核心问题问清楚。
立项时的兴奋
创业初期最危险的一种感觉，是大家都很兴奋。
刚离开稳定环境，几个有经验的人坐在一起讨论一款自己的游戏，每个人都能贡献点子。有人讲核心玩法，有人讲世界观，有人讲战斗节奏，有人讲数值成长，有人讲社交关系，有人讲后续活动，有人讲商业化。白板上写满功能，文档里堆满设想，聊天记录里都是“这个可以”“那个也不错”。那种氛围很容易让人误以为项目已经成形。
现在回想，我们当时缺的不是点子，而是减法。
一个团队真正成熟的立项，不是看能想到多少东西，而是看能不能排除多少东西。什么不做，什么以后再做，什么只是备选，什么是核心验证，什么是上线前必须证明的关键假设。我们当时没有这种纪律。因为每个想法都来自真实经验，看起来都有道理：客户端需要更顺滑，服务端需要更稳，社交要有传播，成长要有长期目标，战斗要有策略，付费要有梯度，活动要能持续运营。
这些话单独看都没错。错在它们一起出现时，小团队承担不起。
当时我有客户端和服务端经验，所以很自然地会从系统完整性理解产品。比如角色系统不能太简单，否则后期扩展麻烦；背包和道具要抽象好，否则活动做不动；战斗协议要预留空间，否则以后改起来痛苦；资源加载要考虑热更新，否则上线后版本迭代慢；数据埋点要提前设计，否则运营看不到问题。这些判断在成熟项目里正确，但在第一款创业产品里，我们还没证明玩家愿意玩，就已经在替一个想象中的长期运营项目做基础设施。
兴奋让我们向未来借了太多复杂度。
核心玩法没有被真正压实
游戏项目最核心的问题永远绕不开：它到底好玩在哪里？
我们当时也讨论过这个问题，但讨论方式很浅。我们会说“战斗要爽”“成长要有反馈”“社交要有关系链”“关卡要有挑战”“数值要有追求”。这些都是正确废话，因为几乎每款游戏都想要这些。真正有用的问题应该更窄：玩家在前三分钟做什么？第一次觉得有趣的瞬间在哪里？失败之后为什么愿意再来一次？重复十次后还有什么变化？如果去掉成长和奖励，核心操作还是否成立？如果没有美术包装，玩法本身是否有张力？
这些问题我们没有用足够严苛的方式验证。
原因之一是技术团队容易把玩法理解成系统组合。战斗系统、技能系统、关卡系统、掉落系统、成长系统、任务系统，这些拼起来像游戏，但不等于有乐趣。乐趣不是模块相加，而是玩家在一连串选择、反馈、压力和奖励中的感受。服务端的数据结构再漂亮，也不能替代玩家手指按下去那一瞬间的判断；客户端动画再完整，也不能掩盖核心循环的空洞。
原因之二是我们太早进入“正式项目”状态。真正的玩法验证应该便宜、粗糙、快速，甚至可以用纸面、表格、简陋 demo、单机关卡来做。但我们很快开始搭工程框架，做账号、资源、协议、后台、配置和版本流程。工程一旦启动，团队心理就会变化：大家会觉得已经在做产品，而不是在验证假设。之后再质疑核心玩法，就像质疑已经投入的时间，心理成本越来越高。
这就是沉没成本最早出现的地方。不是钱花完才有沉没成本，第一周写下的代码、第一版画出的角色、第一份完整系统设计，都会变成让你不愿回头的理由。
功能膨胀不是贪心，而是恐惧
外人看功能膨胀，常以为是团队贪心，什么都想要。经历过之后我更愿意说，很多功能膨胀来自恐惧。
我们害怕游戏太单薄，所以加成长线；害怕留存不够，所以加日常任务；害怕社交弱，所以加好友和聊天；害怕商业化不足，所以加商城和礼包；害怕上线后运营困难，所以加活动配置；害怕玩家觉得内容少，所以加关卡、装备、技能和成就。每个新增功能背后都有一个担忧，而不是单纯的野心。
问题在于，用功能覆盖恐惧，通常会让恐惧变得更大。
功能越多，完成时间越长；时间越长，外部环境越变化；环境越变化，团队越焦虑；越焦虑，就越想增加更多功能来提高成功概率。于是产品不是被核心乐趣牵引，而是被不安全感牵引。每个模块都像保险，可最后整个项目背上了太多保险，走不动。
我当时作为技术负责人之一，对这种膨胀有责任。因为从技术角度，我经常会说“这个可以做”“这个不难”“这个后面会用到”。这三句话很危险。
“可以做”不等于应该做。
“不难”不等于没有成本。
“后面会用到”不等于现在要做。
小团队里，技术可行性很容易被误解为产品必要性。尤其是当创始人本身懂技术时，别人提出想法，我会本能判断实现路径，而不是先问它是否服务核心验证。结果就是很多功能在会议上通过得太轻松。没有人恶意浪费时间，但每个人都在用自己的专业视角给项目加重量。
项目计划看起来越来越专业
随着开发推进，我们的项目管理越来越像样：需求文档、任务拆分、版本计划、接口协议、资源规范、配置表、测试清单、问题列表。看起来，团队在变专业。
可专业也会制造幻觉。
如果方向没有被验证，越专业的推进，越可能只是更高效地走向错误。任务按时完成，会给人一种“项目健康”的感觉；版本能跑，会让人觉得“离上线近了”；bug 数下降，会让人觉得“质量在提高”。这些都是局部真实，但它们无法回答整体问题：这个游戏是否值得继续？
我记得当时最常见的会议状态，是大家围绕进度和问题讨论，很少围绕玩家体验和市场反馈讨论。因为进度和问题具体，容易处理；玩家体验抽象，市场反馈缺失，讨论起来容易争执。于是团队自然选择更容易管理的对象。我们管理了开发，却没有管理不确定性。
这句话现在看很关键：创业早期最需要管理的不是任务，而是不确定性。
任务管理告诉你今天做什么，明天谁负责；不确定性管理告诉你这个项目最大的未知是什么，下一步如何用最小代价减少未知。我们把大量精力放在前者，后者却没有形成机制。
第一次内部试玩
第一次内部试玩通常会很激动。终于可以看到角色动起来，看到战斗发生，看到界面跳转，看到服务端数据保存，看到关卡结束后的奖励。对开发团队来说，这一刻像是项目活了。
但内部试玩也最容易骗人。
开发者知道每个按钮是什么意思，知道系统背后设计了什么，知道还没完成的地方未来会补上。你会自动替产品脑补完成态。一个外部玩家不会这样。他只看到当前屏幕，只根据当前反馈判断是否继续。他不会因为你未来会加功能而留下，也不会因为你服务端架构优秀而多给一次机会。
我们第一次内部试玩后，大家提出了很多问题，但大多是可修复问题：打击感不够，UI 不顺，关卡节奏偏慢，数值奖励不明显，加载有点长。这些当然要改。可是更深的问题是，核心体验并没有强到让人想反复玩。只是当时没人愿意把话说得那么重。
这也是创业团队常见的人情困境。大家都很辛苦，谁都不想在早期直接否定项目。尤其团队规模不大，很多人既是同事也是朋友，批评产品很容易被感受成批评个人。于是反馈会变得温和，问题会被翻译成“再优化一下”。但有些问题不是优化能解决的，它们需要重做，甚至需要停掉。
当时我们缺少一个残酷但必要的机制：让真实外部用户尽早、频繁、无情地测试。
没有种子用户，只有想象用户
我们当时经常说“玩家会喜欢”“玩家会觉得”“玩家应该”。但这些玩家大多存在于想象里。
真正的种子用户不是一个抽象人群标签，而是一群可以被找到、被观察、被反复沟通的人。你知道他们在哪些群里，玩过什么游戏，为什么弃坑，愿意为什么内容付费，对什么美术风格敏感，能接受多长新手流程，讨厌什么商业化方式。你可以把 demo 给他们，看他们在哪里卡住，在哪里笑，在哪里无聊，在哪里退出。
我们没有建立这样的用户池。我们更多依赖自己的经验和少量熟人反馈。熟人反馈的问题是太客气，而且样本太窄。同行会从专业角度提建议，朋友会鼓励你，身边人会因为关系多试一会儿。真正市场里的玩家不会这样。他不喜欢就退出，不理解就卸载，没被吸引就连下载都不会发生。
没有种子用户，产品决策就会在团队内部循环。内部循环久了，会形成一种自洽语言。大家越来越熟悉自己的系统，也越来越难模拟新玩家。每一次讨论都基于团队共同知道的上下文，而真实玩家没有这些上下文。于是新手引导、目标表达、节奏设计、奖励反馈，都可能在团队看来清楚，在外部玩家看来混乱。
这件事对我打击很大。因为我原本以为做过游戏社区，就等于知道如何接近用户。后来才明白，社区经验如果不转化成持续的用户研究机制，只是一段履历。真正理解用户，要把用户放进项目节奏里，而不是上线前才想起来找人看看。
技术债和产品债同时出现
随着项目继续推进，技术债和产品债一起出现。
技术债很好理解：为了赶进度，一些模块写得不够干净；为了适配临时需求，协议和配置变复杂；为了快速实现效果，客户端代码开始有重复逻辑；为了支持活动，服务端加了不少条件分支。这些问题我能看见，也知道怎么修。
更难的是产品债。
产品债是那些没有被回答却继续堆叠的问题。核心玩法弱，但我们继续加成长；新手目标不清楚，但我们继续加系统；美术方向不稳定，但我们继续做资源；商业化逻辑没有验证，但我们继续设计付费点；目标用户不明确，但我们继续写宣传文案。每往前推进一步，过去没解决的问题就跟着一起往前滚。
技术债通常会让开发变慢，产品债会让判断变钝。到后面，团队已经分不清问题的优先级。每个模块都有 bug，每个人都有任务，每个方向都能再优化。你感觉自己被很多小问题包围，却很难抬头问：这个项目还值得继续吗？
创业里最痛苦的不是明确失败，而是不知道应该坚持还是放弃。
如果数据已经清楚证明不行，反而容易决策。最消耗人的是半成品状态：你总能看到希望，也总能看到问题；总觉得再给两周会好一点，再补一个功能会完整一点，再优化一轮会顺一点。于是时间被一段段切走，现金也被一段段烧掉。
上线前的焦虑
产品接近上线时，团队的情绪会发生明显变化。
早期是兴奋，中期是疲惫，后期是焦虑。因为上线意味着想象要接受现实检验。只要没上线，就还能说“等做好之后”；一旦上线，下载、留存、付费、评论、渠道反馈都会变成具体数字。数字没有情面，也不会因为团队努力而改变口径。
我们上线前开始补很多东西：教程要再顺一点，首日奖励要再明显一点，商城展示要再调整，服务器要压测，崩溃要修，埋点要加，活动要配，公告要写。每一项都合理，但整体状态很狼狈。因为很多本该更早验证的东西，被推迟到了上线前集中处理。
这时技术团队会很忙，却也很无力。忙是因为问题很多，无力是因为真正决定产品命运的东西，已经不完全在代码里了。你可以把崩溃率降下来，可以让登录更稳定，可以修 UI 适配，可以优化加载时间，但如果核心体验不成立，这些只能减少扣分，不能创造加分。
我记得自己那段时间经常加班到很晚，看着服务端日志和客户端崩溃信息，心里其实有一种说不出的空。不是累，而是不确定。以前在公司里，修完一个严重 bug，项目就会往好的方向走一点；创业项目里，修完所有 bug，也可能没有人来。
这个感受很真实，也很残酷。
数据回来之后
当第一批真实数据回来，很多幻想就结束了。
不是完全没人玩，也不是完全没有好评，但数据没有强到支撑继续投入。留存不够，转化弱，玩家反馈分散，流量获取困难。最麻烦的是，我们不知道该优先归因到哪里：玩法？美术？节奏？新手？渠道？题材？完成度？投放素材？每个原因都可能成立，每个原因都需要成本去验证。
这时之前缺失的验证机制开始反噬我们。因为没有早期用户研究，没有小步测试，没有清晰假设，所以正式上线后的数据变成一团难以解释的结果。我们知道不好，却不知道哪一个改动最可能让它变好。
团队很容易进入两种极端。一种是继续加功能，觉得内容不够；另一种是全面推倒，觉得方向错了。前者可能继续消耗，后者可能过早否定。成熟的做法应该是基于数据和用户行为拆解问题，但我们当时的数据体系和分析能力都不足，更多靠感觉争论。
这让我第一次真正理解，数据不是上线后才需要的工具，而是立项第一天就要想清楚的验证语言。你要知道自己关心什么指标，为什么关心，达到什么程度继续，低于什么程度停止，哪个指标代表核心乐趣，哪个指标只是表面热闹。没有这些，数据回来也只是增加焦虑。
第一款产品真正失败在哪里
如果只看结果，第一款产品失败于表现不好。但如果看过程，它失败于三个更早的地方。
第一，立项没有足够窄。
我们没有把产品压缩到一个最小但锋利的核心。我们想做一款完整游戏，而不是先证明一个明确的乐趣点。结果就是功能很多，焦点不够。小团队最怕做“什么都有一点”的产品，因为它既消耗资源，又缺少传播记忆点。
第二，验证太晚。
我们把大量验证推迟到产品接近成型之后，导致每次发现问题都很贵。越晚验证，越难承认错误。越多投入，越容易自我保护。创业早期应该反过来：越不确定的东西越早验证，越关键的假设越便宜验证。
第三，技术推进替代了产品判断。
我作为技术人，对这点感受最深。我们太擅长把模糊想法变成可执行任务，却不擅长在任务开始前判断想法是否值得执行。工程能力让项目跑起来，也让我们更晚面对根本问题。技术是推进器，但方向盘不在技术里。
这次失败给我的第一份清单
第一款产品之后，我给自己写过一份很粗糙的清单。后来反复修改，但核心意思没有变。
立项时，只能有一个最关键的玩家理由。说不清这个理由，不开工。
第一版只验证最大风险。不是最容易做什么，而是最怕什么不成立。
内部喜欢不算数，熟人鼓励不算数，真实玩家反复回来才算数。
功能越多，越要问它服务哪个指标。如果说不清，就先不做。
技术方案要匹配阶段。未验证产品不要提前背长期运营的重量。
数据埋点不是为了好看报表，而是为了支持继续或停止的决策。
上线不是胜利，只是第一次公开考试。考试前应该已经做过很多小测。
这些道理现在看简单，当时却是用钱、时间和信心换来的。
第二篇的结论
第一款产品让我明白，一个游戏项目最容易失败的地方，不是做不出来，而是做出来之后没人足够在乎。
我们有技术能力，有热情，有行业经验，也有认真工作的态度。但这些都没有自动形成一个强产品。产品不是功能集合，游戏也不是系统堆叠。玩家要的是明确、即时、持续的体验价值，而不是开发者努力的证明。
那次失败之后，我开始意识到，创业真正困难的不是从 0 写到 1，而是判断哪个 1 值得写。下一篇会写更现实的一层：当产品不够顺利，团队、外包、现金流和自研之间如何互相拉扯，创业者又如何在压力下做出越来越短视的选择。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。