灰契行者制作心得：用AI做游戏的SOP

本文系用户投稿，不代表机核网观点

本文含有AI生成，请注意甄别

给《灰契行者》新增一组资源牌时，我要处理的东西远不止十二张卡文和插画。减费要真正参与结算，目标选择要能取消，中文和英文提示要一致，旧存档里的牌组、金币和未开卡包也要保留下来。源码完成之后，还要把这些东西一起放进玩家实际打开的游戏包。
我是 Scott1743，正在一个人借助 AI 制作这款单人卡牌 RPG。做过几轮扩展和修复之后，我开始把一项任务按六个环节来梳理：核对需求与现状、写清规则、做最小样品、实现与专项检查、独立包验收、记录与回归。
下面用资源牌扩展和相关制作经历，说明这套 SOP 怎么落地。它是在制作中逐渐整理出来的；下一次做类似扩展，我会把小样和每步的完成条件放得更靠前。判断方向、决定取舍、接受结果由我来做，AI 协助查找依据、制作、实现和执行检查。

每一步都留下一个可以检查的结果。流程图使用 SVG 绘制，正文采用同源导出的图片。
1 核对需求与现状 先确定本轮改什么
开始前，我会让 AI 先看当前代码、数据和构建记录，列出新要求与现状的差别。项目里同时留着早期设计、后来的改动和已经打出的游戏包；只找到一份提到相关功能的文档，还不能确定现在运行的规则。
接着把任务缩到一轮可以判断的范围。以资源牌扩展为例，交给 AI 的要求可以写成：
目标： 新卡能够进入收藏、组入牌组，并在正常战斗中使用。
保留： 现有收藏、金币、自定义牌组、编辑草稿、已购买卡包和进行中的挑战。
边界： 围绕批准的新卡方案实现，不顺手重做已有卡牌、敌人和经济体系。
完成条件： 卡牌效果、提示与画面一致，旧档能恢复，独立包里能实际操作。
这一步需要留下的是一份本轮任务单。AI 可以帮我发现冲突、提出选项；涉及玩法和范围的选择，我先确认，再让它往下做。目标还说不清时，继续拆任务会比直接铺开代码更有用。
2 写清设计与规则 把卡文变成可以判断的结果
“消耗护甲，换取抽牌和下一张法术减费”，读起来是一句话，执行时却要回答一串问题：最多消耗多少，没有护甲还能不能打，减费取计划消耗量还是实际扣除量，哪些法术能享受，什么时候失效？
项目里的“回炉折算”最多消耗三点护甲，抽一张牌，并按实际消耗量提供后续优惠。验收例子就可以先写出来：只有两点护甲时，实际消耗两点，优惠也只能按两点计算；支付卡牌费用后，没有护甲时仍然抽牌，但不会凭空得到三点优惠。适用学派、持续时间、同类优惠如何处理，也要写明。
我会让 AI 把正常状态、资源不足、目标不适用等情况列出来，每项写清“操作前是什么、执行什么、之后应该变成什么”。这些预期先从设计决定，后面再拿来核对实现。
同样要提前说明持久状态。新增卡牌使用新的 ID，旧的 ID 继续代表原来的东西；已经购买的卡包、正在进行的战斗、手牌上的临时优惠，更新后各自怎样恢复，都属于设计的一部分。
这一步的产物是规则说明和一组有预期结果的例子。能明确判断一次操作对不对，才有条件进入实现；有矛盾就先留在设计阶段解决。
3 做最小切片 先验证一段能操作的体验
下一轮遇到这样的扩展，我会先挑一张牌，把最容易出问题的完整路径做出来：它能进入手牌，显示费用，选中目标，确认结算，结束回合。需要选择器的，还要试取消和重新选择。
小样可以先使用占位素材。这个阶段更值得确认的是：规则能否通过现有界面表达，操作是否顺手，玩家能不能看明白结果。方向合适，再扩大到整组卡牌和正式美术；如果操作本身不成立，就回到设计调整。
《灰契行者》早期原型已经实际走过换牌、出牌和敌方完整回合，后续扩展也分别做了规则与原生交互检查。把这些检查更早集中到一个小样上，是我会保留到下一轮的做法。

游戏实机。卡牌最终要在这里完成选择、费用预览和结算，单独看数据或素材无法替代这段操作。
4 实现与专项检查 把关联的东西一起接上
小样确认后，再让 AI 按受影响的对象完成实现。我会把需要一起检查的内容列清楚：
数据和规则： 卡牌定义与执行效果一致，非法目标不结算、不扣费，临时状态按约定消耗和结束。
界面和文字： 费用预览、可选目标、取消动作、短提示和完整卡文一致，英文同步。
美术和演出： 卡图、立绘与卡牌 ID 对应，放进卡框后重要部位可见，特效跟随实际结算结果。
存档和奖励： 新字段有恢复方式，旧收藏和进行中的内容按约定保留，新增内容不会让已有奖励重复领取。
这里有一个对卡牌游戏很重要的分工：规则先算出发生了什么，界面再显示结果。《灰契行者》的预览会在状态副本上运行同一套规则，正式动作通过校验后再扣费，演出读取结算事件。这样，预览和动画各自应该检查什么就更清楚。
资源接入也需要自己的对应关系。之前给九张随从卡补了背景，随后发现三张出场立绘的持物姿势或道具比例没有同步。后来把卡面与立绘并排核对，再进入游戏检查出场后的显示。对新增卡牌来说，文件生成了以后，还有卡框、手牌和战场这些实际使用位置。

独立包里的专用核对场景。卡面和立绘要对应同一角色，这张图用于检查素材，不是正常战斗截图。
这一步留下可运行的候选版本，以及相应的规则、交互和兼容检查结果。遇到错误时保留能复现它的状态与操作，修正对应实现；如果预期结果本身有问题，再回设计讨论，避免为了让检查通过而随手改掉预期。
5 验收同一份独立包 走真实操作并读取旧存档
源码检查完成后，我会明确记录本轮要测哪一份独立包。项目曾出现过源码已有修复、打开的旧包仍然闪屏的情况，也出现过运行中的资源包被覆盖后图片空白。它们都说明，构建物本身需要成为检查对象。
我用 Godot 运行游戏，开发中用过 Blender 和连接编辑器的 MCP 工具；构建时会排除开发插件和测试目录，把运行需要的内容放进独立包。包文件使用带内容哈希的名字，保留正在运行的旧包，让新启动的游戏读取新版。
接下来分三层验收。
第一层是规则和数据。 在目标包中检查费用、效果、资源与边界，确认打包进去的是要验证的内容。预览不应该改变正式状态，取消操作也不应该产生结算。
第二层是真实界面操作。 在独立包的实际战斗界面，通过生产控件与输入流程使用新卡。资源牌扩展里的手牌选择器，实际覆盖了打开、取消、重新选择、快速确认和入场动画尚未结束时的操作；正常与减少动态模式分别检查。直接调用一个规则函数，只覆盖这条链路中的一部分。
第三层是旧存档恢复。 那轮扩展使用固化的旧版本存档加载到新版本，逐项核对牌组、草稿、金币、收藏、已购买未开卡包和挑战状态。检查的是具体内容有没有按约定保留，而不只是“存档文件还能打开”。这些测试使用独立临时存档。

先定位失败发生在哪一层，再决定回构建、实现还是设计。修正后形成新的候选包，重新核对版本和结果。
功能与交互通过后，还要由我判断这次结果是否符合原本的目标。模拟对局可以辅助发现规则异常，玩法手感、美术方向和对真人的吸引力，仍需要实际体验和后续玩家反馈。
6 记录与回归 让下一轮能接着做
一轮任务结束时，我希望 AI 留下四样东西：
可运行的版本： 明确游戏包位置、版本和资源包身份。
本轮改动： 说明规则、数据、文字、素材与兼容处理分别改了什么。
检查结果： 记录在哪个包里执行了哪些操作、结果如何，还有哪些部分没验证。
回归项： 把实际遇到的错误保留为可重复检查的例子；经常出现的要求写入长期协作规范。
卡面与立绘一致性、同页选择只更新局部状态，已经进入项目的协作规范。资源牌的费用、目标与旧档恢复则有各自的专项检查。下一次改动碰到相同位置时，就有具体东西可以重新运行和对照。
这套 SOP 对我最有用的地方，是让一项“加张牌”“改个界面”的需求有明确的结束位置。我负责判断目标和结果，AI 协助把制作、实现和检查做具体；对于要进入游戏的改动，我会把可运行、可核对的候选版本作为这一轮的交付，再决定下一轮值得做什么。
《灰契行者》仍在开发，Steam 商店页正在审核，尚未开放公开试玩。可以先在游戏展示页看画面，或打开主宣发和玩法实机。视频采用较早版本录制，此后部分武器规则与数值继续调整。
项目部分插画、立绘和界面美术使用 AI 生成工具制作，宣传片英文旁白使用 MiniMax 合成语音；游戏交响配乐通过项目乐谱在本地编排、渲染，没有调用音乐生成模型。