从立项到上线，手把手用 AI 做一款《X 幸存者》

我是尖沙咀小霸王，熟悉我的朋友叫我八万仔。

如果你想用 AI 做游戏，第一步该输入什么？

今天我拿《X 幸存者》这种“幸存者玩法＋X 社交主题”的游戏，讲一遍从零立项的方法。

游戏入口：xs.wobu.si。

假设我们现在只有这个点子，项目文件夹还是空的，该怎么往下推进？

真实游戏开发通常会经历前期策划与原型、预制作、正式制作、测试打磨、发行和运营。

AI 可以参与其中的很多工作。关键是，你得知道现在进行到哪一步，以及这一轮究竟要验证什么。

这篇教程准备好 Codex 和浏览器就能开始。我们在 Codex 里讨论方案、读写项目文件、编写代码和生成美术，再到浏览器里试玩和检查。

下面从一个空文件夹开始。每一步先解决眼前的问题，让 Codex 帮忙推导，做出选择，再看《X 幸存者》中对应的实现。对话和试玩反馈是教学示例；游戏机制与配图来自真实项目。

第一步：立项。这个点子，究竟能让玩家做什么？

“把 X 做成幸存者游戏”，现在还只是一个题材。要往下做，我会先想：熟悉 X 的人为什么想玩？不熟悉那些梗的人能不能看懂？社交行为能否变成操作和决策？

先新建项目文件夹，在 Codex 中打开它。第一轮这样聊：

我有一个游戏点子：把 X 社交主题和幸存者玩法结合，
先做能在浏览器里玩的版本，由一个人或小团队完成。
目前没有确定角色、技能、关卡和成长规则。

帮我拆解可能的玩家需求，再提出 3 个玩法方向。
每个方向都用“一名玩家进入游戏后会做什么”来说明，
写出关键操作、反复发生的选择、吸引力和制作风险。

比较这些方向，指出哪个假设最需要先验证，
以及可以怎样用一个很小的原型验证。
涉及市场判断时，区分推测和有来源的事实。
这一轮先讨论。

读回答时，我会把“题材好玩”和“玩法成立”分开看。比如，我们可以把候选方向整理成三类：

• 把梗做成怪物和台词，玩家看得懂会笑，但操作可能还是普通的绕圈清怪。

• 把社交动作做成不同攻击，让玩家根据敌人的位置选择打法。

• 把发帖和传播变成地图目标，让玩家决定什么时候靠近、什么时候离开。

第一类适合提供内容，后两类才开始触及玩家行为。攻击可以支撑基础战斗，地图目标可能提供特色，但也可能让玩家被迫站着等。

所以，这个教学案例先选“基础生存战斗＋一种社交行为带来的地图决策”。此时只确定值得试的方向，规则和数值还没定。

接着把这个判断交回去：

我想先验证“基础生存战斗＋一种社交行为带来的地图决策”。
担心额外目标打断走位，让玩家觉得麻烦。

请提出最小实验范围，说明哪些功能缺了就测不出来，
哪些可以占位，哪些应该推迟。
把“玩家觉得有趣”改写成可以观察的行为：
我们要看到什么，才有理由继续投入？
出现什么情况，就应该修改或放弃当前方案？

整理为 docs/立项书.md，分别记录已确认方向、
待验证假设、实验范围和暂缓内容。

这轮的产物才是一页立项书。它要说清楚：想吸引谁，先验证哪件事，最多做到哪里，以及根据什么决定下一步。

我会先压到一名角色、一类敌人、一个地图目标。更多角色和长流程先留在候选清单。立项时最有价值的成果，是知道自己接下来要验证什么。

第二步：玩法原型。玩家为什么要移动，又为什么要冒险？

现在要让战斗动起来。但移动、攻击、成长之间怎样形成关系，还需要想清楚。

假如攻击和经验都自动完成，玩家可能只需要躲怪；假如还要瞄准、找经验、处理地图目标，操作又可能太忙。我们先比较操作负担与风险。

阅读立项书，帮我设计基础战斗原型。
希望玩家在短时间内理解操作，同时需要为了成长改变走位。

比较手动与自动攻击、经验直接到账与移动拾取，
分析这些组合怎样影响注意力、风险和成长节奏。
推荐一个最容易验证的组合，说明选择依据。

给出最少功能、实现方案和试玩观察项。
我确认后，用简单图形实现，提供本地启动方法。
让关键参数容易调整，能重玩同一段进行比较。

在这个案例里，我会先试“自动攻击＋移动拾取”。原因是地图目标已经需要注意力，把瞄准负担减下来，可以腾出空间；经验留在地上，又给了移动一个收益。

确认组合后，让 Codex 做出一小段能打怪、拾取、升级、死亡和重开的循环。先用方块和圆点，亲手玩。

接下来要把感受写成观察。比如，假设你看到玩家总在外圈绕，中央的经验越堆越多，就这样继续聊：

试玩观察：玩家一直沿外圈绕，中央的经验越堆越多。
他们说进去捡容易死，所以很少拾取，也很少升级。

请结合当前代码和参数分析可能原因，给出依据。
比较刷怪压力、经验分布和拾取距离的影响。
推荐先改一个因素，说明预期变化和对照试玩方法。
如果这次变化没有出现，下一步应该检查什么？

不要一口气把敌人、伤害和吸附距离全改了。如果怀疑经验附近没有安全路线，就先改这件事，再看玩家是否愿意进去、捡完是否能退出来。行为变了，才有依据继续；没变，就回头查假设。

沿这条路线，可以逐渐确定攻击、移动、拾取与升级的关系。《X 幸存者》的实际实现是 WASD 移动、空格位移、自动攻击，拾取经验后升级，选卡时暂停战斗。

到这里，应该得到一条能运行、能观察、能反复调整的基础循环。还没成立，就继续改这一层。

第三步：数值设计与调整。怎么判断该改哪一个数？

上一节说“调整一个因素”，具体该怎么调？这里单独展开。数值从原型就开始定，新增角色、武器和关卡后还要继续复查。

我会先写想要的体验：开局尽快理解成长，普通敌人有威胁但能处理，位移能救急，玩家仍然需要看预警和走位。

然后让 Codex 把这些描述变成可观察、可计算的东西：

读取原型，整理影响战斗与成长的参数、单位、公式和叠加来源。
我希望开局容易理解成长，普通敌人能处理但有压力，
位移能救急，同时仍需要玩家判断时机。

把这些目标转成观察指标，例如击破需要几次命中、
首次选卡时间、后续升级间隔、受击次数和位移使用时机。
提出一版初始参数与合理范围，说明推导依据和不确定之处。

检查伤害、攻击间隔、敌人生命、生成速度、经验收益之间的关系。
先做简化计算，再设计短试玩验证。
确认后把参数整理为方便调整的配置，保存当前值、单位、
影响范围与推导理由，避免同一个量在多处被重复修改。

这里最容易犯的错，是单独看一个数字。攻击力高了，体感一定明显吗？经验门槛不变，升级节奏一定不变吗？都得看它和其他量怎样配合。

先说攻击。用项目基础表做一个简化估算：回复弹基础伤害 16，“0 粉小号”基础生命 32，需要两次有效命中。伤害被动增加 5 后变成 21，仍需两次命中。这次提升对其他敌人可能有效，对这只小怪却未必立刻改变击破次数。

所以我会让 Codex 先算“生命÷有效伤害，向上取整”，再看攻击间隔、命中率、穿透和群体覆盖。计算时暂时忽略的暴击、时间与幕数修正、角色成长，要在实际战斗里补回来。

成长也一样。升级间隔同时取决于经验门槛、敌人数量、击破速度和拾取效率。看到升级慢，直接把经验需求砍半，可能把真正的问题藏起来。

试玩时先固定角色、局外成长、关卡和起始构筑。记录首次升级、几次后续升级、首次进化的时刻，受击和死亡原因也一起留。能固定随机种子就固定；还没有这个功能，就尽量统一条件、重复几局，别拿两次不同抽卡的结果直接比较。

假设记录里出现“中段选卡等待过长”，下一轮要带着材料追问：

我观察到中段选卡等待明显变长。
以下是同一角色与成长条件下的升级时刻、击破数、
经验拾取和选卡记录：[填入实际试玩材料]

请判断主要是经验需求增长、击破速度下降，还是拾取不足。
列出支持各解释的证据，说明还需要补什么记录。
比较调整经验曲线、敌人供给和攻击能力的影响。

推荐先验证一个假设，提出最小改动与预期结果。
保留原参数，重复同样的试玩路线，比较升级间隔与战斗压力。

如果记录表明杀怪、拾取都正常，主要是需求曲线上升过快，就先试曲线；如果经验堆在地上，先查路线和吸附。如果杀不动了，就查攻击成长与敌人生命的关系。

每轮围绕一个假设改，相关参数确实需要一起动时，把关系写清楚。保留基准版本，记下旧值、新值、改动理由和预期变化，复测后补上观察结果，再决定采用还是恢复。

还要查叠加后的结果。单件回血、护甲、无敌看着都不强，凑齐之后可能让玩家站着不动也能赢；只拿满成长角色测试，又可能看不见首局的问题。

请检查回血、护甲、位移安全时间与攻击成长的组合效果。
为无成长、少量成长和成熟成长安排对照试玩，
固定敌方条件，分别记录受击、生存时间和击破效率。

发现过强或过弱时，区分单项问题与叠加问题。
给出调整方案、可能伤到的打法，以及需要复查的角色和关卡。
纸面计算、自动模拟和真人试玩分别报告，不混用结论。

完成这种分析后，再看《X 幸存者》的实际数值。当前项目的首次升级需要 8 经验；之后，当前等级 L 的下一次升级需求是：

round(16 + 8 × L + 1.8 × L²)

线性项和平方项共同决定门槛，越到后面，平方项影响越大。假设确认中段等待偏长，可以把平方项系数 1.8 改成 1.5 做一版实验。先让 Codex 算出变化：

右列是教学实验方案，没有改动真实游戏。它说明门槛降低了多少；实际升级等待还要结合经验收入和拾取来测。减少约一成需求，不等于每位玩家都少等一成时间。

生存参数也有相同的推导空间。项目位移的基础无敌时间为 0.42 秒，相关强化叠加后上限 0.72 秒；“下线喝水”每阶恢复 0.35 HP/秒；“钝感力”增加 20 生命上限，并恢复 20 HP。

安全窗口变长，会降低对时机的要求；持续回血要结合一局中的受伤频率；生命上限和即时恢复量要分别计算。调整时要问：是在增加合理容错，还是让躲避与取舍失去意义？

这个步骤最终应留下数值表、公式、试玩记录和每次改动的理由。原型阶段先调基础循环；角色、配方和长流程加入后，再沿相同方法检查。

首领加入后，记录击破耗时、有效输出和受击原因，再决定调生命、伤害还是攻击窗口。资源系统加入后，比较收入、价格和消费时机，看看玩家能不能承担一次重抽，又是否值得留钱应对后面的风险。数值工作会贯穿后面的制作与打磨。

第四步：预制作。换角色，怎样才会换一种玩法？

基础循环能玩后，才开始讨论可扩展的制作规则。

我会先问一个很容易忽略的问题：如果只是换头像，玩家为什么要换角色？怎样让角色差异体现在每一局的行动里？

基础原型已经能移动、攻击、拾取和升级。
现在考虑增加角色，但希望换角色后，玩家的行动也会改变。

从攻击覆盖、距离、时机和风险出发，提出不同打法方向。
用具体战斗场景说明：同一群敌人面前，各自会怎样处理？
比较学习成本、弱点和实现成本，推荐先做哪两种。

给出比较两种打法的原型方法。
选定后，再细化技能规则、状态变化和界面反馈。
把已确认规则与待测参数分开写进 docs/游戏设计.md。

看回答时，我会要求它推演同一个场景：一群怪靠近，玩家会往哪里走，什么时候出手，哪里容易吃亏。

“伤害更高”和“攻击更快”可能仍是同一种绕圈打法。主动靠近、制造聚怪机会，与保持距离、利用追踪攻击，则比较容易在行为上分开。前者要承担靠近风险，后者要防止变成完全不用判断的自动清场。

先做这两类的小样，观察玩家的路径是否真的不同，再细化冷却、范围和效果。技能规则确认后，整理游戏设计文档；还没验证的数值继续标为待测。

美术也要顺着这些规则确定。角色会以多大尺寸出现？背景里能不能看清？玩家需要辨认哪些动作？先让 Codex 分析：

请根据已经确认的角色打法和战场显示尺寸，制定美术试制方案。
哪些轮廓、配色和动作能让玩家快速辨认角色与技能状态？
比较可行的视觉方向，说明小尺寸下的可读性和制作成本。

先试制一名角色，用原生生图能力生成候选立绘，
放进浏览器战场比较，再选定方向。
列出需要的动作状态、切帧要求和最少帧数，说明依据。

这里要把图缩到游戏中的实际大小看。一张放大的立绘很精致，缩小后手、脸、武器混成一块，仍然要回去调整。

确认像素方向、身份特征和动作状态以后，才确定图集规格。待机、步行、攻击、冲刺、绝活、受击需要分别可见；步行还需要交替动作。沿用《X 幸存者》的资源规范，可以把它整理为四列两行、八帧图集，再进入制作：

基于已确认的立绘和动作规范，生成同一角色的像素动作图集。
四列两行，依次为待机、三帧步行、攻击、冲刺、绝活、受击。
保持角色身份、比例、尺度和脚底基线一致。
全身完整，各格分离，步行有明确换腿与摆臂。
不添加文字、网格或场景，使用真实 Alpha 透明背景。

生成后让 Codex 检查透明通道、裁切和帧映射，在浏览器里播放。脚底抖动就查对齐，动作像滑行就查换腿与位移的关系。

实现结构也在这阶段检查：让 Codex 读取原型，比较继续扩展的成本，拿同屏敌人与特效做性能验证，约定素材目录并保存稳定版本。

经过这样的角色规则与制作标准讨论，我们再看真实项目的结果：小霸王的“表舅说”用话框聚怪标记，再打出破甲击退；Youzi 的“拼装双机”使用追踪模块，自动绝活会临时拼装认证机。

下面的角色页把攻击、被动、绝活和配方集中展示。它呈现的是规则已经落地之后的样子。

第五步：垂直切片。这个小样，能否代表一段完整体验？

现在各部分分别能工作，接到一起却可能出现断点：玩家不知道怎么开始，第一次升级看不懂，失败后也不知道发生了什么。

所以先做垂直切片。它是一小段接近成品的体验，用来检查玩法、界面、美术和音效能不能一起成立。

这一轮从玩家路径出发：

读取原型和设计文档，梳理新人从打开页面到结束一局的路径。
每一步需要知道什么、采取什么行动、得到什么反馈？
找出目前缺失或容易误解的环节。

建议一个能检验核心体验的切片范围，说明取舍。
哪些内容必须接齐，哪些只会扩大工作量？
范围确认后，按依赖关系安排任务并逐项实现。
记录实际耗时，用完整试玩检查每个环节。

我会保留一个开始、一次成长、一次特色玩法，以及能够结束并重开的结算。这样才能判断玩家有没有学会，并愿不愿意再来。

放到这个项目里，切片可以收敛为一名角色、评论区热身、一次升级、一次发帖，以及“邵·薄肌之王”首领战。更多角色和后续幕暂缓。

做完后，从首页亲手走到结算。攻击看得清吗？受伤有没有提示？第一次失败知道原因吗？在这条路径上补反馈，再拿实际耗时估算后续内容成本。

这一轮的成果是一份可完整试玩的小样、问题记录和有依据的排期。只有切片能稳定重复，才扩大制作范围。

第六步：正式制作。选卡怎样产生目标，发帖怎样产生行动？

先聊选卡。假如每次升级都只加一点伤害，玩家很可能随便点。我们要解决的是：短期选哪张卡，怎样影响后面想玩的打法？

当前升级主要增加数值，玩家很难形成跨多次升级的目标。
请提出几种让选择产生长期影响的方法。

用具体战斗过程比较：玩家选了什么，之后怎样改变行动，
怎样知道自己正在接近目标，以及随机性会带来什么问题？
推荐一条适合先验证的成长路线，说明制作成本和风险。

选定后再设计获得条件、反馈和短试玩，先实现一条路线。

我们可以比较三类：单纯升阶容易理解；能力之间联动会让组合重要；攻击形态进化会让成长更明显，但需要额外制作和配方说明。

在这个案例里，我会先试“有准备过程的攻击形态进化”。玩家能朝一个目标选卡，完成后又能看见差异。

再想形态怎么变：一次直线攻击，能否变成持续往返、覆盖一条路线的攻击？这样玩家就需要考虑敌人在哪里、自己怎样站位。结合引用传播的主题，这条路线可以落成“引用铁轨”到“无限引用列车”。

接下来才讨论配方。等级门槛让玩家投入前期升级，材料要求占用一次选择机会，获取入口影响进化时机。代价是玩家必须看懂这些条件，否则只会觉得迟迟抽不到。

所以，继续引导 Codex：

我们选择带材料条件的攻击进化路线。
请推演玩家从拿到普通武器到完成进化，需要经历哪些选择。

哪些条件必须提前告知，哪些进度应该一直可见？
怎样避免玩家拿错材料，或满足条件后不知道去哪里合成？
提出界面信息方案，并检查未满足、可合成、已合成三种状态。
实现后，让第一次接触配方的人尝试说明下一步该做什么。

看真实项目，这套规则被明确为：引用铁轨 Lv.5＋引用穿透，通过蓝 V 盲盒合成无限引用列车。选卡和合成界面展示能力、材料与条件，超武完成后替换普通攻击。

先理解这些条件为什么存在，再决定自己的原型需要怎样的门槛。Lv.5 是这款游戏的规则，仍要通过试玩检查等待长度与成长节奏。

跑通这条路线，再扩展折返、范围打击、聚怪控场等方向。每条都观察是否改变打法，以及是否存在不分场景都最强的选择。

接着聊立项时留下的地图目标。现在战斗已经能玩，才有条件检验额外目标会不会打断它。

这次先把“发帖”当一个待设计的行为，问清楚它需要玩家做什么：

我们希望把发帖变成战场上的地图决策。
它应当带来额外收益，也需要玩家承担风险。
目前还没有确定推进方式、成功条件和失败后果。

请提出不同方案，逐步推演玩家发帖后的行动。
比较它们对移动、攻击和节奏的影响。
找出可能出现的等待、重复操作或无解情况。
推荐一个最小实验，并说明要观察什么行为。

如果方案是站着等进度条，玩家可能只在等时间；如果要求处理附近的敌人，站位和攻击就能参与；如果还要引怪经过路线，移动的要求会更强，学习成本也会增加。

我会先验证较简单的守点战斗。把帖子放在场上，玩家需要决定是否回去保护，同时有机会失败。再考虑进度怎样计算：只认圈内敌人，会不会让远程攻击难以发挥？允许人在圈内时击破圈外敌人，能否让不同武器都有用？

这几种计数方式都能做小实验。要检查玩家是否理解计数，是否在选择站位，而不是靠运气等怪走近。

假设第一轮的现象是玩家能完成目标，却一直站在圈边，下一句应当写观察：

试玩观察：玩家主要停在目标圈边，等自动攻击清怪。
他们知道怎样推进，也能成功，但觉得过程单调。

请分析是目标规则、敌人压力还是奖励造成的。
提出一个小调整和一个需要更多制作的方案，
推演它们分别会怎样改变玩家路线，比较成本与学习负担。

推荐先试哪一个，给出对照方法。
沿同一段试玩，检查是否增加了有意义的选择。

提高敌人压力可以迫使玩家离开，但未必产生新的目标。增加第二个位置，并让两点之间的传播路线参与战斗，则更容易把“传播”做成操作；代价是需要讲清放置条件和保护规则。

这时才有理由选择引用接力，并继续确定放置距离、穿链目标和两端耐久。距离太近没有移动意义，太远又可能来不及保护。参数在试玩中调整，规则通过界面反馈验证。

再看《X 幸存者》的实际结果：帖子可以是“我家猫接管公司了”“转发抽一位替我上班”“郑重宣布退出互联网”，有耐久、倒计时、爆帖目标及不同后果。

守帖时，角色站在原帖金色圈内，击破任意位置敌人都能计入评论；引用接力允许角色在距原帖 240—510 个世界单位时按 F 放下引用帖，两端形成传播链，引怪穿链并保护两端。

先让一种帖子完整工作，再增加其他内容。新规则需要回到同一段复查，看看它有没有解决原本的问题。

第七步：扩充内容。下一段应该带来什么新挑战？

切片能玩，不代表内容越多越好。进入长流程前，我会先看试玩记录：什么时候紧张，什么时候重复，成长速度是否赶得上敌人压力？

先设计体验变化，再决定关卡数量：

读取切片的设计和试玩记录，梳理压力、成长与休息的节奏。
哪些体验值得保留，哪里需要新挑战，哪里只是重复？

提出后续流程方案，说明每一段希望玩家学会或改变什么。
再推导所需的敌人行为、事件和首领能力。
比较不同规模的制作成本，推荐当前首版的范围。

确认后先制作下一段，明确预警、动作、应对方式和验收路线。
验证新挑战成立后，再继续扩充。

从基础绕怪开始，后面可以考站位、区域判断、资源取舍和复合压力。相应的敌人要用行为制造挑战：会复制的敌人改变清理优先级，地面危险区改变可走路线，首领的阶段变化要求玩家重新判断。

玩家还必须看得懂。让 Codex 推演预警到落招之间能否反应，躲完之后有没有回击机会。如果一招只靠堆血硬吃，就继续查设计。

长流程接上后，再问资源与重开的目的，避免只为了丰富界面加货币：

希望玩家在本局的即时收益与后续风险之间取舍，
也希望一局结束后有理由尝试另一种打法。

请分析这些目的是否需要资源和局外成长。
比较共用与独立资源、数值成长与打法变化的影响。
推演获得、消耗和重开过程，指出容易囤积或必须刷的地方。

推荐最少的一套规则，并给出需要记录的试玩数据。
验证后再确定数值、存档字段及旧版本兼容方式。

判断资源有没有意义，可以看几局支出：玩家会不会为了重抽放弃之后的用途？一直攒着不用，是需求不明确、价格太高，还是失败惩罚太重？局外成长则要看它帮助玩家尝试新打法，还是变成重复劳动。

完成这些讨论后，再看真实项目如何组织内容。

《X 幸存者》最后形成五幕：评论区热身、暴论牌桌、社区注释夜、币圈狗窝、牢马接管时间线；对应 Boss 是邵·薄肌之王、梭哈哈、A➗、狗总、牢马。每幕基础推进时间为五分钟，热搜事件能提前推进时间线，击破首领后进入下一幕。

其中 AI 洗稿党会复制，来源警察会制造预警区域，币圈主题把插针、K 线和资金风险转成战斗行为。名称、外观和行动共同服务于新挑战。

牢马首领战则把阶段、护卫和地面预警接成复合压力。玩家需要先读懂危险，再决定路线。

资源在项目里分成三类：流量用于重抽、热搜投流、Boss 破招和地图设施；粉丝提供援护，也能救帖；结算热度用于局外成长。Youzi 的成长页进一步提供专属升级与账号变体。

这些是完整项目中的具体安排。你自己的范围应根据切片成本与试玩表现确定，再逐幕制作、检查和保存稳定版本。

第八步：测试和打磨。问题出在哪里，证据是什么？

每一步都要试玩，完整版本还要查系统同时发生时有没有冲突。比如暂停、升级、目标计时和结算之间，单独能运行的功能可能互相影响。

数值也在这一阶段重测：用第三步的基准方法，比较不同角色与成长条件的升级节奏、进化时刻、首领战耗时和受击原因。发现某种构筑异常，先定位是参数叠加还是规则失效，再调整。

先让 Codex 从已确定的规则推导检查场景；发现问题后，用观察引导它定位：

请根据当前规则列出跨系统检查场景，写明操作步骤和预期结果。
我会逐项试玩，把异常的复现路径、截图或日志交给你。

收到问题后先复现，检查状态变化，说明原因与证据。
不能确认的部分列出还缺什么信息。
比较修法，修复后沿原路径复查，并检查受影响的相邻操作。
报告已经验证和仍未验证的内容。

针对这款游戏，可以推导出升级是否暂停帖子计时、守帖圈内击破圈外敌人是否计数、引用帖被拆是否结束传播链、合成是否替换旧攻击，以及重开是否清理上一局状态等检查题。

手机端也从操作场景推导。先别决定摇杆在哪边，想清楚两只手各自承担什么，哪些操作需要同时发生：

准备让手机玩家使用当前游戏。
请读取现有操作，推演连续战斗、技能使用、升级和暂停的触控过程。

比较可行的移动方式与按钮布局，
说明视野遮挡、手指移动距离和多指操作的取舍。
推演松手、开菜单、切后台和旋转屏幕时，输入应该怎样结束。

选定后实现，给出浏览器布局检查与真机试玩路线。
区分可以自动验证的项目和必须亲手操作的项目。

固定摇杆位置稳定，但要一直把手放在同一区域；浮动摇杆允许在左侧重新落指，仍需处理起点、松手和多指状态。按钮放在哪里，要让移动与技能同时可用，也不能挡住关键战场信息。

比较后再实现，先用浏览器检查遮挡、弹窗滚动和按钮位置，再用真机检查双手操作、触控手感与持续战斗性能。

《X 幸存者》的结果是左侧浮动摇杆、右侧位移和发帖。下面展示这个布局，属于手机尺寸浏览器预览，不能代替真机触控验收。

最后找第一次接触游戏的人，少解释，观察他们在哪里停住。看到“没点发帖”，先分清没看见、不理解还是收益不足，再决定改按钮、说明或规则。

第九步：发行。玩家能否打开、理解并玩完这一版？

本地跑起来以后，还有交付问题：哪些文件必须带上，玩家会不会拿到缓存旧版，更新会不会丢进度，出了问题怎样恢复？

如果你还没有自己的域名和服务器，可以先用 GitHub Pages 或 Netlify 的免费计划 部署上线。这类静态网页游戏可以先使用平台提供的网址，拿到玩家反馈后再考虑自定义域名和后续投入。

先让 Codex 读取实际项目，再选发布方案：

我想先发布一个可分享链接的试玩版，目前没有域名和服务器。
请读取项目，梳理运行必需的文件、依赖和存档方式。

优先比较 GitHub Pages 和 Netlify 的免费部署方案。
核对当前免费条件，说明这个项目是否适用、需要哪些配置，
以及怎样使用平台提供的网址上线。
检查资源路径、版本缓存、存档兼容与测试入口。
列出已满足的交付条件和实际缺口。

方案确认后，准备发布文件、上线步骤与完整验收路线。
保留上一版并提供恢复步骤。
发布说明只写本轮实际完成并验证的内容。

选 GitHub Pages，可以把发布文件放进公开仓库，在 Settings → Pages 选择发布分支和目录，得到 用户名.github.io/仓库名/ 形式的项目网址。发布设置说明。

选 Netlify，可以连接代码仓库，也可以上传整理好的发布目录，使用平台生成的 项目名.netlify.app 网址。确认页面已经公开，再把链接发给玩家；免费计划的额度按官方说明核对。部署说明。

部署后，用最终链接走一遍选角、战斗、升级、发帖和结算，再换浏览器、用手机打开。页面能访问只是起点，玩家要能拿到完整资源并完成游玩。

上线初期先邀请一小批人试玩，准备真实截图、操作说明和反馈入口。后续也继续用证据推动判断：

下面是这一批试玩反馈和复现记录：[填入实际材料]
请区分故障、理解障碍、平衡问题与新功能愿望。

按影响范围、证据和修复成本建议优先级。
对尚不明确的问题提出下一轮观察方法。
给出下一版的最小改动范围，以及发布后应当复查的路径。

项目会在一轮轮讨论、选择、实现和复查里逐渐生长。

我是八万仔，我爱我的朋友，谢谢大家。