围绕库存与顾客需求制作书店经营游戏

书店经营游戏真正有意思的地方，在于玩家要先决定进什么货，再看到当天顾客的需求。先从一家店、两种书目、一条简短且固定的顾客队列，以及会延续到销售后的现金开始。这样就能形成一个说得清的选择：平均分配库存，还是把更多本数押在需求更高的书上。下文的例子是原创的纸面教学模拟，规则和数值均为虚构，并非试玩结果或真实顾客调查。第一版不需要完整书目或逼真的供应链，只要有一个能看见后果的进货决策即可。这里的数值刻意设得很小，方便逐项核算，无需电子表格。本文将展示如何写清库存规则、跟踪账目，并要求生成一个行为可检查的精简原型。

从一个库存决策开始

适合作为第一天的循环包含四个相连步骤：查看需求、下单、按现有库存接待顾客，并用结果规划下一次订货。顺序很重要。如果顾客先到、玩家后选库存，进货就不再是决策；如果每卖一本书，现金和库存都立即重置，玩家也看不出选择的成本。

第一版先不加入房租、工资、折扣、装饰评分、随机需求、替代书目或日间补货。这些系统以后可以带来新选择，但也会让人难以判断顾客为何买到或没买到书。目录先限为两种陈列书目，每位顾客只请求其中一种的一本。打烊时，玩家应能把需求列表与货架库存、现金余额逐项对照。

写一份精简的库存规则

向生成工具提出制作要求前，先固定一套规则。下面“纸灯书店”的例子纯属虚构，价格和顾客顺序只是为了方便演算，不代表市场数据或真实书店行为。

当天没有其他支出或收入来源，因此账目是封闭的：下单之后，只有售书会改变现金。缺货请求记为未满足需求，但不产生销售，也不会扣除库存。

逐步核对基准账目

先订两本推理、两本旅行书。四本共花 12 枚硬币，开店时还剩 2 枚。前两位推理书顾客各买一本。第三位提出推理书需求时，店里已无库存，因此这位顾客离开，该请求被记录下来。之后旅行书顾客买走一本，陈列架上还剩一本旅行书。

把这个结果当作库存分配的演算示例，而不要据此预测真实读者会买什么。需求队列是事先固定的，现金结果则由选定规则推导而来。明确这些假设，其他人才能检查算术并有依据地调整设计。

只调换一本书，重放这一天

再比较另一种订单：三本推理、一本旅行。订单仍为 12 枚硬币，因此开店时同样剩 2 枚。起始现金、价格和四条需求都保持不变。前三位推理书顾客都能买到，最后一位旅行书顾客也买到。四位顾客全部得到满足，订来的四本书也全部售出。

这是从同一个 14 枚硬币初始状态进行的平行纸面演算，并不是基准方案打烊、现金变为 17 后的第二个营业日。这里只改变了订单分配。在这条虚构需求队列下，推理书较多的订单没有留下滞销库存，并在模型中多收入 5 枚硬币。这个数字只是固定样例规则的结果，不是实测提升，更不能推导出推理书总该多进。

给第一版构建一个完整提示词

把背景、初始状态、规则和可观察的检查项合并成一个请求。无需指定的实现细节可以留给工具决定，但每个操作结束后必须满足什么条件要写清楚。

制作一款可在浏览器游玩的书店经营小游戏，名称为“纸灯书店”（Paper Lantern Books）。
店内只陈列两种书：推理和旅行。这是一个虚构的教学原型，不是真实书店模拟。

每个新营业日开始时有 14 枚硬币，且没有库存。开店前，玩家可下单，订单总量必须恰好 4 本；每种书不得超过 3 本。每本进价 3 枚硬币。超过 4 本总量的订单必须被拒绝。玩家确认前，要显示订单总价和剩余现金。

本教学日采用固定顾客队列：推理、推理、推理、旅行。每位顾客请求一本书。若所需书目有库存，就恰好扣除一本并增加 5 枚硬币；若缺货，就记录一次未满足需求，不增加现金。不可用另一种书替代。不要增加房租、工资、随机需求、折扣、借款或营业中补货。

队列结束后，显示订购数量、各书目售出数量、剩余库存、未满足需求次数、销售收入和打烊现金。账目必须与订单和销售规则一致。提供重开操作，恢复 14 枚现金、空的初始库存、相同队列与原始规则。

在构建中显示并检查以下情形：四本订单花费 12 枚，剩余 2 枚；五本订单因超过上限被拒绝；另一个初始现金为 11 枚的独立情形中，12 枚订单因现金不足而被拒绝，且现金和库存不变。顾客买到匹配书目时扣除一本并增加 5 枚；缺货时记录未满足需求但不产生销售。先运行“推理 2 本 / 旅行 2 本”，结果为满足 3 人、未满足 1 人、剩余旅行书 1 本、打烊现金 17 枚。重开后运行“推理 3 本 / 旅行 1 本”，结果为满足 4 人、无人未满足、库存清零、打烊现金 22 枚。说明任何未按要求工作的规则，不要悄悄改动演算数字。

这份提示词让结果可以逐项核对，但并不能证明生成的构建一定会正确执行规则。检查构建后，把屏幕上的订单、销售、未满足请求、库存和现金与上面的两份账目比较。如果结果有误，就定位差异：先看订单是否被接受，再核对销售是否扣一本并增加 5 枚，最后检查打烊现金是否等于下单后的余额加销售收入。

增加系统前先核对账目

• 订单检查：确认 4 本书花费 12 枚，并从 14 枚起始现金中留下 2 枚。分别测试 5 本上限，以及初始现金为 11 枚时现金不足的情况。
• 库存检查：按顺序跟踪每一条需求。满足顾客时恰好扣除一本匹配书目；需求未满足时库存和现金都不变。
• 现金检查：统计成功销售数量，乘以单价 5，再加上下单后剩余的 2 枚。基准方案应为 17；对照重放应为 22。
• 重置检查：在两种订单之间重开游戏，确认现金、初始库存、队列和规则都恢复一致。

如果最终现金对不上，不要一次改动多项规则。保持队列和价格不变，找出账目第一次出现差异的操作，并要求只修正对应规则。两种演算都一致后，再尝试新队列，或单独增加每日支出，并为这项设计变化重新列出前后账目。

把规则约定转成第一版可玩草稿

SEELE 的 Free AI Game Maker 页面介绍了一般创作流程：用日常语言描述游戏想法，查看可玩的 2D 或 3D 结果，并在 Workspace 中迭代。本文的库存规则是一份供通用创作请求使用的建议简报；该页面没有介绍专门的书店模板。本文示例没有经过生成构建审查，因此固定队列、订货上限、销售规则和现金账目都只是待验证的要求，不是已确认的产品行为。如果你尝试这份简报，请用两份纸面账目核对结果。

准备好描述一个聚焦的游戏想法并检查可玩起点时，可以访问免费 AI 游戏制作工具。第一次检查先保留固定队列；等能解释原始结果后，再一次只调整一条进货规则。