玩家会先查看一个目标的攻击预览，再考虑换目标或打开属性面板。AI 也应该决定是否值得花时间查看，而不是在做决定之前自动拿到所有目标的精确答案。

这个提案允许 AI 提出较高层的查询，但把每项查询分解成有顺序、能中断、要核对结果的界面动作。

flowchart LR
 A[Visible observations] --> B[UI Interpreter]
 B --> C[Game AI]
 C --> D[Interaction Runtime]
 D --> E[Interface actions]
 E --> A

图 1：这是目标流程，不是完整实现声明。新信息只有在操作后实际观察到，才能返回给 AI。

1. 为什么还需要解释层和执行层？

Perception 只报告本次画面里的元素。UI Interpreter 负责解释页面、选择状态、对象关联和记忆是否过期；Game AI 决定下一步想知道什么或做什么；Interaction Runtime 负责定位、发出输入并核对结果。

这些是职责边界，不要求立刻拆成多个服务或目录。先在现有模块里实现有测试的小步骤，出现真实复用需要时再抽取包。Simulator 继续执行规则，不变成识别侧的答案数据库。

2. 查询两个目标的预览会怎样执行？

AI 提出“查看这个法术对两个已看到目标的预览”。执行层先检查当前界面证据，然后依次打开魔法书、选择法术、悬停第一个目标、等待并读取预览，再尝试第二个目标。每次读取都附带来源和时间；结束时取消选择，不自动确认施法。

如果弹窗遮挡、目标消失或界面已进入另一回合，就返回已完成的部分和中断原因。执行层不能为了填满结果而偷查隐藏状态，也不能把上一次显示的伤害当成这一次的答案。

3. 批量接口只是操作便利，不是免费信息

批量请求需要预算、截止时间、已完成项和最终界面状态。它在内部依然是连续的小操作，每一步都可以失败或被取消。只有真实界面本来就同时显示的信息，才可以一次返回。

“当前能否尝试悬停”可以依据已有观察判断，但这个检查本身不能暗中做一次新的悬停。新的信息收集必须算作显式动作。AI 因此能够权衡继续查看的成本和决策价值。

4. 怎样验收，哪些还没做？

第一条完整验收流程是打开、选择、悬停、读取、取消，再检查时间、目标对应和界面状态。后续测试中断、过期对象、部分完成以及不能泄漏未来或隐藏信息。

已有单法术原型验证了有限的查询与取消边界，尚未接成默认 AI，也不是商业游戏的执行器。完整解释、追踪、批量操作、目标定位与执行权限仍待实现。引入新的共同字段和接口之前，Perception 与消费方必须按模块治理规则再讨论。

规范提案保存在代码仓库的 docs/architecture/visible-object-interaction-contract-v1-draft.md。已经冻结的子集只有薄观察接口 v1。