Appearance
本文是"边玩边学"系列的第四篇，演示如何处理跨多个文件的复杂 Bug。问题场景：玩家靠近墙壁时，交互提示"E"消失，无法与旁边的物品或箱子互动。Kiro 定位到根因（updatePlayerProximity 未过滤非交互对象），并提出用 Infinity 质量做过滤的快速修复。文章重点讨论为何这个快速修复在长期看是有问题的，以及如何用语义化的 interactive 属性做更正确的重构——这个重构横跨 22 个文件，展示了 Kiro 处理大规模多文件改动的能力。
本模块假设你已按照环境搭建说明在本地启动了游戏。
在之前的模块中，我们：
这两个任务都相对独立。现在来尝试横跨多个文件的复杂任务。
理解问题
玩家反映"E"键有时不按预期工作：靠近墙壁时，即使站在物品或箱子旁边，交互提示也会消失。
问题出在这里：找出距离玩家最近对象的函数，没有过滤掉墙壁。当玩家靠近墙壁时，函数把墙壁标记为最近对象——但墙壁并不是可交互的。
尝试向 Kiro 描述这个问题：
Sometimes when the player is closer to the wall than to an
interactive object like an item or the chest, then the interact
prompt does not appear over the interactive object.审视 Kiro 提出的方案
Kiro 应该能正确定位问题。它可能会提出：在过滤逻辑中排除物理质量为 Infinity 的对象（因为墙壁使用 Infinity 质量来模拟不可移动性）。
这个方案技术上可行，但值得停下来思考：
- 如果未来存在质量有限但不可交互的对象怎么办？
- 如果存在质量为
Infinity但实际可交互的对象怎么办？
这个修复把"是否可交互"这个逻辑，绑定到了一个语义上无关的属性（物理质量）上。当前能用，但迟早会引发隐蔽的 Bug。
做系统性的跨文件重构
与其把问题局限在 game-object-system.ts 一个文件里，不如做更彻底的重构——在每个游戏对象创建时，明确声明它是否可以交互。
尝试这个 prompt（注意使用 # 引用具体函数/类型）：
In #GameObject add a new required property `interactive`.
In #updatePlayerProximity filter out non interactive objects.
All calls to #addObject throughout the code need to set interactive to true or false.结果应该类似这样：不是修改一处，而是横跨多个文件的 22 处改动。这次重构确保了游戏对象 API 具有正确的语义含义——任何读到代码的人（和 AI）都能从属性名直接理解对象是否可交互，而不需要靠理解物理质量的副作用来推断。
本模块的三项核心收获：
- 在接受 AI 生成的代码之前先想几步。代码今天能用不代表它设计正确，需要评估长期影响。
- 在 prompt 中用
#引用具体函数、类或类型。这能增强模型的上下文精准度，让结果更可靠。 - 命名即 API 设计。确保代码中的属性和函数有准确的语义含义，不要用一个属性承载多种不相关的行为。
进入下一个任务：
常见问题
Q：# 引用语法在哪些情况下最有用？
当你需要 Kiro 精确操作代码库中的某个具体符号（函数、接口、类）时，# 引用能避免 Kiro 猜测或混淆同名的不同实体。对于大型项目，这是提升 prompt 精准度最有效的技巧之一。
Q：22 个文件的改动，如何确保 Kiro 没有遗漏？
Kiro 完成重构后，可以追问 "Are there any other places in the codebase that call addObject or create game objects that we might have missed?"。让 Kiro 自己做完整性检查，比人工审查更高效。
Q：如果重构过程中 Kiro 改错了某个文件，如何处理？
每次大规模重构前，建议先 commit 当前代码作为检查点（git add . && git commit -m "before interactive refactor"）。如果某个文件改错了，可以单独 git checkout -- 文件路径 恢复，再用更精确的 prompt 重新处理该文件。