课程时长：120 分钟
技术栈：IntelliJ IDEA + Spigot API 1.21.1 + AI 助手
核心目标：实现 **GUI 界面（第 13 课）与经济系统（第 14 课）**的深度整合。学习编写涉及多个模块的复杂业务逻辑，处理“库存检查”与“余额扣除”的同步性，培养模块化编程思维。
一、 任务背景 (Mission Background)
有了银行和货币，玩家们迫切需要一个花钱的地方。今天，你将担任**“全栈开发者”**，把之前的 UI 技术和银行技术结合起来，打造一个“自助商店”。玩家输入 /shop 即可打开精美的货架，点击商品自动扣费并发货。这是你迈向复杂系统集成的关键一步！
二、 学习路线图 (Technical Map)
-
编程技能：跨类方法调用（在 Shop 类中调用 Bank 类的余额）、物品给予逻辑、条件分支判断。
-
工程思维：模块集成 (Integration) —— 确保商店扣的钱就是银行里的钱；异常处理 —— 钱够但背包满了怎么办？
-
AI 素养：利用 AI 优化“多重条件检查”逻辑（先检查钱，再检查位子，最后扣费），避免逻辑混乱。
三、 核心项目：商品交易引擎 (Sprint 1: 45 min)
1. 搭建货架（GUI）
我们需要一个 9 格的商店，第一格卖“钻石”，价格 500。
推荐 Prompt（提示词）：
“我正在使用 Spigot 1.21.1。我已经有一个银行系统类 BankSystem 可以增删余额。请帮我写一个商店监听器：
监听 InventoryClickEvent，判断标题是否为‘§6§l自助商店’。
如果玩家点击了第 0 格（钻石图标）：
检查玩家余额是否大于等于 500。
检查玩家背包是否有空位。
如果满足条件：扣除 500 余额，给玩家 1 个钻石，发送成功消息。
如果不满足：发送对应的错误提示音和文字。”
2. 代码解析：逻辑的“原子性”
-
关键点：必须遵循 “检查 -> 扣除 -> 给予” 的顺序。
-
Vibe Check：问问 AI，为什么不能先给玩家钻石再扣钱？（提示：万一扣钱的代码执行失败了，玩家就白拿了钻石，这叫“刷物漏洞”）。
四、 多任务挑战：复杂交易功能 (Sprint 2: 45 min)
真正的商店不仅能买，还得能卖，还得能“批发”。
五、 工程思维：模块间的“握手” (Engineering Logic: 15 min)
工程师的深度思考：
-
接口调用：商店插件怎么知道玩家在银行里有多少钱？
-
建议：不要在商店类里重新写一套存钱逻辑。通过 Main.getBank().getBalance(uuid) 这种方式调用。这叫单一职责原则。
-
-
安全性检查：如果玩家在商店打开时，通过其他手段（如另一个插件）花光了钱，点击瞬间会报错吗？
-
AI 任务：询问 AI “如何确保在高并发交易下（玩家手速极快），余额不会被扣成负数？”
-
六、 联机调试与 Debug (Testing: 15 min)
-
穷光蛋测试：余额为 0 时点击钻石，确保既拿不到钻石也不会扣钱。
-
满背包测试：把背包塞满，看看钱是否会被扣除？（正确逻辑应该是：背包满了就不扣钱也不发货）。
-
刷钱测试：尝试快速连点，检查余额变动是否正常。
-
AI 纠错：如果玩家拿走了货架上的图标（防盗失效），请将你的 InventoryClickEvent 代码发给 AI 检查哪个 setCancelled(true) 漏写了。
七、 自学习与探究 (Self-Learning)
拓展思考：
-
配置化商店：能否让 AI 写一个逻辑，从 shop.yml 里读取商品 ID、名字和价格，而不是在 Java 代码里写死？
-
可视化反馈：购买成功时，在玩家头顶冒出绿色“+”粒子，失败时冒出红色烟雾。
八、 成果交付 (Deliverables)
-
演示：展示你从余额 1000 块开始，在商店购买钻石、余额实时变少、物品进入背包的全过程。
-
代码截图：展示你是如何引用 BankSystem 里的余额检查方法的。
-
Prompt 记录：记录你如何通过 AI 实现“批量购买价格计算”的提示词。
九、 老师的 Vibe Tips (结语)
“今天你完成了一个真正的系统集成。在软件世界里，单一的功能（如 UI 或 数据库）很容易，但让它们协同工作（Integrated）才是最有挑战性的。利用 AI 帮你理清复杂的逻辑分支，而你作为系统架构师，要确保钱和物在你的规则下公平流动。”