2024 年之后，独立游戏开发者最关心的一个问题不再是“我不会画画怎么办”，而是“我一个人能不能在合理时间内做完一款能上架的游戏”。放置类游戏《细菌克星》就是在这个背景下诞生的项目：它由一个人完成主要开发，AI 承担了大量代码生成、素材创作和文案整理工作，最终通过了 Steam 平台的审核并正式上线。这篇文章会把整个开发链路拆开讲清楚，包括玩法设计、技术选型、核心系统实现、Steamworks 接入、商店页上架，以及上线前后真正容易踩的坑。
我的判断很直接：AI 不会让一个没有想法的策划做出好游戏，但它能让一个已经有玩法想法的人，用过去三分之一的时间把想法变成 Steam 上的真实产品。放置类游戏尤其适合这件事，因为它的系统边界清晰、玩法闭环简单、数值驱动明确，几乎是为 AI 辅助开发量身定制的品类。
这篇文章对于三类读者最有价值：打算做第一款独立游戏但担心工程量的人；已经在用 AI 写业务代码、想尝试游戏开发的后端或前端工程师；以及已经做完玩法原型、但卡在 Steam 上架流程的独立开发者。读完你可以得到一条从零到上线可复用的路线，以及哪些环节必须自己守、哪些环节可以放心交给 AI 的具体边界。
1. 放置类游戏：单人开发者最适合切入的品类
放置类游戏（Idle Game / Incremental Game）的核心特征，是玩家只需要极少量的操作，游戏就会自动产出资源。最有代表性的例子是浏览器起家的 Cookie Clicker，玩家不断点击一块饼干获取数字，再用数字购买自动产出设施，关闭页面后回来还能领取离线收益。这类游戏的玩法深度不在操作上，而在数值成长的节奏上。
从开发角度看，放置类游戏有三个对其他品类不一定成立的优势：
第一，玩法系统闭环。放置游戏不需要复杂的三维场景、物理碰撞、AI 敌人或者多人同步，核心只需要“资源产出—资源消耗—成长升级”这一个循环。这意味着玩法的核心逻辑可以用很小的代码量先跑通，整个项目不会在早期失控。
第二，工程边界清晰。存档、UI、数值、成就、离线收益，每个模块都相对独立。对于 AI 辅助开发来说，模块边界越清晰，AI 生成的代码越不容易互相污染，人工审查的难度也越低。如果做一个开放世界 RPG，AI 生成的代码分散在上百个文件里，出了问题很难定位；但放置游戏的核心逻辑可能只有十几个脚本，AI 生成的每一段代码都能很快被验证。
第三，留存验证成本低。放置游戏的乐趣来自“数字变大的快感”，所以验证一个版本是否好玩，不需要邀请大量玩家做复杂的问卷调查，只需要观察两个指标：玩家愿意挂机多久，愿意点多少次。这非常符合单人开发者的验证能力。
《细菌克星》选择的是“消灭细菌、净化实验室”的主题。玩家扮演一名实验室消毒专家，通过点击消灭培养皿里的细菌，获得净化值，再用净化值购买紫外线灯、自动消毒机器人等升级设施。游戏的循环是：点击杀菌获得净化值，净化值购买自动设施，自动设施提高单位时间产出，离线后回来领取离线收益，解锁新的细菌图鉴和成就。这个主题的好处是世界观简单，美术可以用扁平化风格承载，而且“细菌繁殖”和“数字膨胀”在直觉上是匹配的——你会觉得细菌越变越多是合理的，净化值越变越大也是合理的。
2. 《细菌克星》的核心玩法与系统拆解
正式编码之前，先把游戏拆成六个核心系统，每一个做完之后都能独立验证。
第一个是点击系统。玩家点击画布上的细菌，立即获得一次净化值。点击产出由基础值和点击等级加成决定，公式很简单：BaseClickOutput + clickLevel * 0.2。点击系统是游戏的第一层反馈，它必须足够“爽”，所以每次点击要考虑轻微动画、数字飘字和音效，这些效果可以用 Unity 的 UI 动画和 AudioSource 快速实现。
第二个是自动产出系统。当玩家拥有自动消毒设备后，设备每隔一秒钟产生一次净化值。自动产出是所有放置游戏的“发动机”，它的数值成长决定了游戏的节奏。这里我采用了经典的指数增长公式：BaseAutoOutput * AutoGrowth^autoLevel，其中 AutoGrowth 是 1.15。前期增长速度平缓，后期升级成本越来越高，玩家就需要在“点击加速”和“等待自动产出”之间做选择。
第三个是升级系统。升级项可以拆成两类，一类是点击增强，一类是自动产出增强。每次升级都会增加净化值消耗，消耗公式也需要和产出公式匹配，否则游戏会在某个数值区间突然变得无法推进。这里真正容易踩坑的地方是数值曲线不收敛：产出是指数上涨，但升级成本是线性上涨，那么后期玩家会无限膨胀；反过来，升级成本涨得太快，玩家会在第 20 级左右就彻底失去动力。比较稳妥的做法是先让 AI 生成一组候选数值表，再用一个简单的模拟脚本跑 50 个小时的挂机曲线，观察瓶颈出现在哪一级，再人工调整权重。
第四个是离线收益系统。玩家关闭游戏一段时间后，再打开时按时间差补发一部分净化值。离线收益需要设置上限，否则玩家离开一个月回来直接满级，游戏生命周期就崩了。《细菌克星》的离线收益上限是 8 小时，超过部分按 8 小时计算。这个上限值放在常量类里，方便后续根据玩家反馈调整。
第五个是图鉴和成就系统。图鉴用来收集不同种类的细菌，每解锁一种细菌就获得属性加成；成就是用来自我驱动玩家完成特定目标，比如“累计点击 1000 次”“拥有 10 台自动消毒设备”。放置类游戏的留存核心就是目标感，没有成就系统的话，玩家会在数字增长变慢的第一时间流失。
第六个是存档系统。存档负责保存玩家当前净化值、累计产出、点击等级、自动产出等级和上次保存时间。存档使用 JSON 序列化，本地用 PlayerPrefs 保存。存档系统虽然看起来简单，但它是上线后事故率最高的模块之一，后面会专门讲。
六个系统的关系是单向依赖：点击系统和自动产出系统产生净化值，净化值驱动升级系统，升级系统反向强化产出，离线收益在玩家回归时补发产出，图鉴和成就提供长期目标，存档把这一切的状态持久化。单依赖关系让 AI 生成的代码非常容易拆分和审查。
3. 技术选型与环境准备
《细菌克星》的客户端选择了 Unity 加 C#。原因是放置类游戏大量依赖 UI 交互和定时器，Unity 的 UGUI 和 MonoBehaviour 生命周期天然适合这种玩法；同时 Unity 对 Steamworks 的支持非常成熟，无论是官方的 Steamworks.NET 还是社区方案，都能在几个小时内接入完成。你完全可以用 Godot 或者纯 Web 实现放置游戏，但从“后续要上 Steam、要接成就、要云存档”这个目标回溯，Unity 的项目资料和插件生态是最省事的。
开发环境建议如下：
- 操作系统：Windows 10 或 Windows 11，打包 Windows 客户端最方便。
- Unity：推荐使用 LTS 版本，项目版本以实际工程为准。放置游戏没有特别依赖新版本渲染特性的地方，稳定优先。
- IDE：Visual Studio 或 JetBrains Rider 均可，关键是能配合 AI 插件做代码补全。
- 版本控制：Git 加 Git LFS。Unity 工程的场景文件、贴图资源比较大，必须启用 LFS 避免仓库体积失控。
- Steam 开发者账号：在 Steamworks 官网注册开发者账号并完成实名验证，然后创建应用获得 AppID。
- Steamworks SDK：从 Steamworks 下载站获取对应 SDK，Unity 项目建议直接通过包管理安装 Steamworks.NET。
- AI 工具：一个用于对话式编写代码的大语言模型，一个 IDE 内的代码补全插件，还有一个用于生成 2D 素材的文生图工具。具体工具版本不重要，重要的是建立自己的工作流。
环境准备这一步最容易犯的错误，是希望把环境一次配到完美再动手。实际经验是：先装 Unity 和 Git，跑通一个最简单的场景，再逐步加 Steamworks。不要在第一天就接 AI 插件、配 CI、搭云存档，这些都会变成拖延上线的借口。
4. 用 AI 搭建开发工作流
AI 辅助开发不是“把需求丢给 AI，然后等一个完整游戏”，而是把开发过程拆成三个可重复的工作流。
第一个工作流是需求对话式编码。给 AI 描述清楚模块需求，要求它输出完整脚本而不是片段。关键是提示词里要包含输入、输出、边界条件和文件路径。以离线收益计算器为例，可以这样写：
你是一名经验丰富的 Unity C# 开发者。请为放置类游戏编写一个离线收益计算器。 要求： 1. 提供静态方法 Calculate(GameData data, DateTime lastSaveTime, DateTime now)。 2. 离线超过 8 小时按 8 小时计算。 3. 产出公式为：离线秒数 * BaseAutoOutput * 1.15^autoLevel。 4. 返回 double 类型。 5. 如果 lastSaveTime 大于等于 now，返回 0。 6. 请给出一段可直接放入 Unity 工程的代码，并给出三个边界测试用例。这个提示词包含了 AI 需要知道的所有关键信息。如果你的问题描述含糊，AI 就会给出一个看起来正确但无法直接编译的通用模板。让 AI 生成代码时，永远要求它给出可运行的完整文件，而不是高亮的核心片段，因为你还需要审查它。
第二个工作流是报错修复闭环。Unity 的编译报错、运行时报错，直接把日志复制给 AI，附带上对应的脚本文件和操作步骤。例如“点击按钮后净化值没有变化，控制台也没有报错”，AI 通常会先建议你检查 UI 事件绑定和数据引用。这个闭环能省下大量搜索时间。但要记住，AI 给出的修复建议是基于概率的，不是基于你项目里真实状态的，所以每一条修复都必须自己验证。
第三个工作流是素材与文案生产。细菌图标、按钮背景、UI 装饰这类 2D 素材，可以用文生图模型生成初稿，再在像素级做人工整理和重绘。需要特别注意的是，Steam 商店页面对 AI 生成内容有披露要求，所以团队需要在项目文档里记录哪些素材使用了 AI 生成，使用的工具和生成参数是什么，避免审核环节被要求补充说明时无从下手。
还有一条贯穿始终的原则：AI 输出的所有东西都是草案，不是最终交付物。代码要逐行审查，美术要人工重绘关键部分，文案要对着 Steam 审核规范核对一遍。AI 负责把“从 0 到 1”的时间缩短，人工负责把“从 1 到能上线”的质量补齐。
5. 核心系统实现：放置循环、离线收益与存档
下面给出《细菌克星》中三个最核心的模块代码，文件路径和逻辑说明都已经标注好，可以直接放到 Unity 工程中跑通。
首先是常量类，集中管理所有数值曲线参数。
// 文件路径：Assets/Scripts/Core/GameConstants.cs namespace BacteriaKiller.Core { public static class GameConstants { // 点击基础产出 public const double BaseClickOutput = 1.0; // 自动净化设备的基础产出 public const double BaseAutoOutput = 0.5; // 自动产出的成长倍率 public const double AutoGrowth = 1.15; // 离线收益上限（单位：小时） public const int MaxOfflineHours = 8; } }然后是数据模型。注意净化值这类长期数值使用 double 而不是 int，因为放置游戏运行一段时间后数值会非常大，int 会迅速溢出。
// 文件路径：Assets/Scripts/Models/GameData.cs using System; namespace BacteriaKiller.Models { [Serializable] public class GameData { public double purifyValue; // 当前净化值 public double totalEarned; // 累计获得净化值 public int clickLevel; // 点击升级等级 public int autoLevel; // 自动净化等级 public string saveTime; // 上次保存时间 } }核心管理器负责点击产出和自动产出。这里使用累加器控制自动产出节奏，而不是每帧都增加产出，这样即使是 144Hz 的显示器也不会导致产出速度异常。
// 文件路径：Assets/Scripts/Core/BacteriaManager.cs using System; using BacteriaKiller.Models; using UnityEngine; namespace BacteriaKiller.Core { public class BacteriaManager : MonoBehaviour { public GameData data = new GameData(); private float _accumulator; public void OnClickBacteria() { double output = GetClickOutput(); data.purifyValue += output; data.totalEarned += output; } private void Update() { _accumulator += Time.deltaTime; if (_accumulator >= 1f) { _accumulator -= 1f; AddAutoOutput(); } } private void AddAutoOutput() { double output = GetAutoOutput(); data.purifyValue += output; data.totalEarned += output; } public double GetClickOutput() { return GameConstants.BaseClickOutput + data.clickLevel * 0.2; } public double GetAutoOutput() { return GameConstants.BaseAutoOutput * Math.Pow(GameConstants.AutoGrowth, data.autoLevel); } } }这里面真正容易出错的地方是 Math.Pow。在 Unity 中新手容易写成 Mathf.Pow，但 Mathf.Pow 的参数和返回值是 float，指数增长几十级后精度损失会非常明显，大数值会出现跳动。放置游戏的数值系统必须使用 System.Math，这一点 AI 生成的代码有时会忽略，人工审查时一定要盯住。
接下来是离线收益计算器。它和 BacteriaManager 共用 GameConstants，保证产出公式的一致性。
// 文件路径：Assets/Scripts/Core/OfflineRewardCalculator.cs using System; using BacteriaKiller.Models; namespace BacteriaKiller.Core { public static class OfflineRewardCalculator { public static double Calculate( GameData data, DateTime lastSaveTime, DateTime now) { if (lastSaveTime >= now) { return 0; } TimeSpan offline = now - lastSaveTime; double maxSeconds = TimeSpan.FromHours(GameConstants.MaxOfflineHours).TotalSeconds; if (offline.TotalSeconds > maxSeconds) { offline = TimeSpan.FromSeconds(maxSeconds); } double baseOutput = GameConstants.BaseAutoOutput * Math.Pow(GameConstants.AutoGrowth, data.autoLevel); return offline.TotalSeconds * baseOutput; } } }最后是存档管理。存档时间以字符串形式保存，读取时先检查 PlayerPrefs 中是否存在键，避免首次运行时报空引用。
// 文件路径：Assets/Scripts/Core/SaveManager.cs using System; using BacteriaKiller.Models; using UnityEngine; namespace BacteriaKiller.Core { public static class SaveManager { private const string SaveKey = "BacteriaKiller_SaveData"; public static void Save(GameData data) { data.saveTime = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss"); string json = JsonUtility.ToJson(data); PlayerPrefs.SetString(SaveKey, json); PlayerPrefs.Save(); } public static GameData Load() { if (!PlayerPrefs.HasKey(SaveKey)) { return new GameData(); } string json = PlayerPrefs.GetString(SaveKey); GameData data = JsonUtility.FromJson<GameData>(json); if (data == null) { return new GameData(); } return data; } } }用 Unity 跑通这组代码的验证步骤很简单：新建一个空场景，创建一个 GameObject 挂上 BacteriaManager，再创建一个按钮，按钮的 OnClick 事件绑定到 BacteriaManager 的 OnClickBacteria 方法。运行后点击按钮，看到净化值增长；等待一秒，看到自动产出生效；手动调用一次 SaveManager.Save 和 Load，确认存档能正确恢复。这一步跑通了，放置游戏的核心循环就成立了一半。
6. Steamworks SDK 接入与商店页上架
游戏本地逻辑跑通之后，下一步是接入 Steamworks 并准备上架。过程可以拆成三个部分：开发者账号与 AppID、Steam 客户端接入、商店页面和构建上传。
Steamworks 开发者在官网完成注册后，需要创建应用并等待 Valve 审核。拿到 AppID 之后，Unity 工程中需要把 AppID 写入steam_appid.txt文件，否则在编辑器和本地构建里调用 SteamAPI.Init 会失败。这个文件通常放在 Assets 根目录或构建输出目录，具体位置以 SDK 文档为准。
Unity 集成 Steam 推荐使用 Steamworks.NET 包。接入的核心代码只有一个初始化管理类：
// 文件路径：Assets/Scripts/Steam/SteamManager.cs using Steamworks; using UnityEngine; namespace BacteriaKiller.Steam { public class SteamManager : MonoBehaviour { private void Awake() { if (!SteamAPI.Init()) { Debug.LogError("SteamAPI 初始化失败，请检查本地是否已启动 Steam 客户端"); } } private void OnDestroy() { SteamAPI.Shutdown(); } } }这段代码放在一个常驻 GameObject 上，游戏启动时先初始化 Steam，销毁时正常关闭。注意 SteamAPI.Init 的成功依赖两个条件：Steam 客户端在运行，以及 AppID 配置正确。如果调试时失败，优先检查这两个条件，而不是代码本身。
上架流程中第二重要的是构建和上传。Steam 使用 Depot 的概念来管理构建内容，你需要为游戏创建一个包含完整构建文件的 Depot，配置 Depot 路径，然后通过 SteamPipe 命令行工具上传。上传过程本质上是把本地构建目录和 Steam 的 Depot 建立映射，第一次配置稍繁琐，之后每次更新都是重复相同操作。这里要特别提醒：上传前一定要在本地用“仅限自己可见”的途径测试一次完整构建，确认从 Steam 客户端启动游戏后，存档、Steam 初始化、音频都正常，再考虑公开。
商店页面是上架的关键门槛。需要准备的素材包括：横版宣传图、竖版宣传图、最少 5 张截图、一段宣传视频、游戏简介、标签分类和价格设定。文案部分可以用 AI 生成初稿，但必须人工核对，因为 Steam 对游戏描述的审核比较严格，不能出现虚假宣传或误导性内容。如果素材中含有 AI 生成内容，上传审核时需按平台要求如实披露。
7. 上线前后常见问题与排查思路
开发和上线过程中，《细菌克星》遇到过的典型问题整理成一张表，按现象、原因、排查方式和解决方案四列列出。这些问题在放置类游戏里非常普遍，可以直接复用排查思路。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 点击按钮后净化值不变 | UI 事件未绑定，或按钮引用了错误的 GameData 实例 | 检查 Inspector 中 OnClick 绑定，以及 GameData 是单例还是 new 出来的临时对象 | 使用统一管理器持有 GameData，按钮事件只绑定管理器方法 |
| 自动产出不增加 | Time.timeScale 被暂停逻辑改为 0，或累加器逻辑异常 | 查看日志确认 Update 是否执行，检查暂停代码 | 产出逻辑不要依赖 timeScale，改用独立计时 |
| 离线收益为 0 | saveTime 字符串解析失败，或玩家上次存档时间异常 | 打印 DateTime.Parse 的结果 | 解析失败时返回 0，并统一时间格式，增加异常保护 |
| 存档丢失 | PlayerPrefs 被清除，或云存档覆盖了本地新存档 | 查看保存键名、平台差异和云存档同步日志 | 接入 Steam 云存档时使用独立文件名，保留一份本地上一次备份 |
| SteamAPI 初始化失败 | 本地未启动 Steam，或 steam_appid.txt 缺失 | 确认 Steam 进程和 AppID 配置 | 按 SDK 要求放置 steam_appid.txt，教程环境先通过 Steam 启动 |
| 大数字显示混乱 | double 数值过大时直接 ToString，出现科学计数法 | 检查 UI 文本是否直接绑定原始数值 | 实现单位缩写格式化，例如 1.2K、3.4M、5.1B |
| 商店审核要求补充 AI 内容说明 | 商店截图或描述中的素材由 AI 生成 | 查看 Steam 审核消息要求 | 如实披露 AI 生成素材，保留生成记录，必要时人工重绘关键素材 |
这里最影响上线进度的是商店审核。审核消息一般会明确告诉你缺什么，按要求补齐即可，不需要过度担心。但从实际经验看，最容易拖慢进度的反而是本地构建问题：你本地运行正常，打包出来后存档路径变化、Steam 初始化失败、字体丢失，这类问题必须提前按照“从 Steam 客户端启动构建”的方式测一遍。
8. AI 辅助开发的边界与实战建议
AI 在《细菌克星》开发中承担了大量工作，但它的边界非常清楚。可以放心交给 AI 的任务包括：样板代码生成、模块脚手架、报错日志分析、单元测试用例编写、商店页面文案初稿、数值表格初稿、素材初稿。不能交给 AI 的任务包括：核心玩法决策、数值平衡的最终调整、Steam 审核合规、玩家隐私数据处理、支付和账号相关逻辑。这些任务一旦出错，不是改几行代码能补救的。
给读者一条最实用的建议：AI 生成的每一段代码，你都要在心里回答三个问题。这段代码放在哪个文件？它在什么时候被调用？如果运行失败，第一步日志应该出现在哪里？能回答这三个问题，说明你已经理解了这段代码的逻辑，AI 给你的是可维护的代码；回答不了，说明你只是复制了一段自己看不懂的内容，它迟早会在某个上线前夜变成无法定位的 bug。
工程层面的最佳实践还可以再补充几条：
- 存档数据从一开始就写入版本号。哪怕现在只有一份存档，也要预留 version 字段，否则后续加新字段时会出现旧档全部作废的尴尬。
- 所有数值常量集中在 GameConstants 类。放置游戏调数值非常频繁，常量散落在各个脚本会让 AI 补全和人工排查都变得困难。
- 离线收益必须有上限。这是放置游戏的底线设计，没有上限的离线收益会在第一个假期毁掉整个游戏的经济系统。
- 大数字格式化要提前实现。放置游戏运行几天后数值就会突破百万，直接显示完整数字会让 UI 失控。
- 产出逻辑使用累加器而不是每帧累加。每帧累加会让产出速率受到帧率影响，低端手机上会产生明显差异。
- 用协程或定时器替代 Update 中频繁的字符串拼接和 UI 刷新。UI 刷新频率控制在每秒一次即可，不需要每帧刷新。
- 上线前模拟时长跨天和跨平台的存档迁移。时间字符串解析、时区差异在测试中很难被注意，但玩家真实环境里一定会遇到。
从项目管理角度看，建议保留所有与 AI 的对话记录，按模块归档。这不是为了证明“游戏是 AI 开发的”，而是因为 AI 生成的代码往往没有注释，重新阅读时只能靠对话上下文理解当初的设计意图。这些记录就是最真实的开发文档。
9. 复盘与下一步安排
《细菌克星》上线后，我复盘发现 AI 真正节省的不是“写代码”的绝对时间，而是“从想法到可运行原型”的反馈时间。放置游戏的乐趣在于数值成长，但数值曲线是否舒服，必须跑起来才能感知。过去改一版数值需要改代码、重新编译、重新跑挂机模拟，现在把需求描述给 AI，几分钟就多一个可测试版本。这种高频反馈，才是 AI 辅助开发最大的杠杆。
如果你也想验证自己能否独立做完一款上架 Steam 的游戏，最务实的路线不是先花两个月学完一套完整课程，而是直接用 AI 搭一个最小可玩版本：一个画布、一个按钮、一个产出管理器、一个存档管理器，先跑通“点击—产出—升级—离线收益”的循环。这个循环成立之后，再花一个周末接入 Steamworks，把游戏变成能从 Steam 商店页启动的产品。
上线只是开始。下一步值得投入的方向有三个：检验数值曲线和玩家留存数据，根据真实反馈调整 AutoGrowth 和升级成本；把成就系统和 Steam 成就打通，给玩家跨平台的目标感；接入 Steam 云存档，解决玩家换电脑后的存档迁移问题。这些功能对应的技术门槛都不高，但每一项都能明显提升一款放置游戏的生命周期。做完这些，《细菌克星》这个项目的完整开发链路才算真正闭环，而你也可以说自己完整地经历了一款从 AI 辅助开发到正式上线的游戏产品。
