# AI 原生游戏的运行时物品生成设计建议

更新时间：`2026-04-02`

## 0. 设计目标

这份方案针对当前项目，回答的是：

**如果要把运行时物品生成做成“AI 原生”，应该怎样设计，才能既贴合背景 / NPC / 当前事件，又不会把数值系统做崩。**

这里的“AI 原生”不是指“让模型直接胡乱造装备”，而是指：

- 物品的**语义、出处、命名、关系、叙事理由**由 AI 根据上下文生成
- 物品的**稀有度、build 标签、数值预算、持久化结果**由本地规则编译和裁剪

一句话：

**AI 决定这是什么，规则决定它能做什么。**

## 1. 设计原则

## 1.1 物品必须是“当前故事的一部分”

运行时物品不该只是“随机掉了个稀有剑”。

每个重要物品都至少回答 4 个问题：

1. 它为什么会出现在这里？
2. 它和哪个场景背景有关？
3. 它和哪个 NPC / 势力 / 怪物有关？
4. 它对当前玩家 build 为什么有意义？

## 1.2 物品收益以“标签倾向”优先，纯数值为辅

建议把 AI 原生物品的主要收益做成两大类：

1. **获得 build 标签**
   - 永久标签：主要由装备 / 稀有饰品 / 关键遗物提供
   - 限时标签：主要由消耗品 / 临时护符 / 战场符箓提供
2. **少量直接数值**
   - 只做补充，不做主菜
   - 避免数值碾压 build 语义

也就是说，运行时物品的第一身份应该是：

**“把玩家的构筑推向某种风格”**

而不是：

**“给一个更大的攻击数字”**

## 1.3 物品生成必须显式读取上下文

建议运行时物品生成必须至少读取以下上下文：

- 世界背景
- 当前场景 / 地标 / 氛围
- 当前 encounter / 相关 NPC / 相关怪物
- 最近 1~3 个关键剧情行为
- 玩家当前装备与激活 build 标签
- 玩家当前缺口
  - 续航不够
  - 控场不足
  - 缺切后
  - 缺护体
- 当前奖励渠道
  - 宝藏
  - 交易
  - 委托
  - 掉落
  - 观察所得

## 1.4 AI 只产出“意图”，本地编译成成品

不要让 AI 直接返回最终 `InventoryItem`。

建议让 AI 先返回的是“物品意图”：

- 物品主题
- 物品来源
- 关联对象
- 倾向标签
- 永久 / 限时
- 用途类型

然后本地再把它编译成：

- `category`
- `rarity`
- `tags`
- `statProfile`
- `useProfile`
- `buildProfile`
- `value`

这样才能稳定、可测试、可平衡。

## 2. 建议的系统结构

建议把新系统拆成 4 层。

## 2.1 上下文采样层

输入一份统一的 `RuntimeItemContext`：

```ts
type RuntimeItemContext = {
  worldType: WorldType | null;
  customWorldProfile?: CustomWorldProfile | null;
  sceneId?: string | null;
  sceneName?: string | null;
  sceneDescription?: string | null;
  landmarkHints?: string[];
  encounter?: Encounter | null;
  relatedNpcState?: NpcPersistentState | null;
  recentStoryMoments: StoryMoment[];
  playerCharacter: Character;
  playerEquipment: EquipmentLoadout;
  activeBuildBuffs: TimedBuildBuff[];
  activeBuildTags: string[];
  generationChannel: "treasure" | "npc_trade" | "npc_reward" | "monster_drop" | "quest_reward" | "discovery";
};
```

这一层的目标不是做物品，而是把“这次生成到底是在什么局面下发生”说清楚。

## 2.2 AI 意图层

让模型只生成一个轻量蓝图：

```ts
type RuntimeItemIntent = {
  narrativeTheme: string;
  sourceKind: "npc" | "scene" | "monster" | "faction" | "quest" | "ancient";
  sourceName: string;
  reasonToAppear: string;
  itemArchetype: "equipment" | "consumable" | "material" | "relic" | "quest";
  permanence: "permanent" | "timed";
  desiredBuildTags: string[];
  desiredStatBias: Array<"hp" | "mana" | "outgoing" | "mitigation" | "cooldown">;
  relationHooks: string[];
};
```

重点是：

- AI 负责“它像什么”
- 不负责“最终数值是多少”

## 2.3 本地编译层

本地把 `RuntimeItemIntent` 编译成正式物品：

- 先做标签规范化
  - 走 `normalizeBuildTags`
- 再判定品类
  - 装备 / 消耗品 / 材料 / 稀有品 / 剧情物
- 再套预算
  - rarity budget
  - stat budget
  - tag budget
  - duration budget
- 最后写入：
  - `buildProfile`
  - `statProfile`
  - `useProfile`
  - `value`

## 2.4 叙事回写层

物品成品生成后，再把这些信息回写到叙事文本：

- 它看起来像什么
- 它为什么来自这个 NPC / 地点
- 它和哪条线索或关系有关
- 玩家为什么会觉得“这东西确实该在这里出现”

这一步仍然可以交给 AI，但只能读“已经生成好的成品”。

## 3. 建议的物品类型设计

## 3.1 永久 build 标签物品

适合：

- 武器
- 护甲
- 饰品
- 关键遗物

建议规则：

- 常规装备最多给 `1` 个核心永久标签
- 稀有或史诗装备可给 `1` 个核心标签 + `1` 个协同标签
- 传说物品可以额外充当 set / faction / NPC build 锚点

示例：

- “渡口缉索短刃”
  - 永久标签：`快袭`
  - 协同标签：`追击`
  - 小量数值：`outgoingDamageBonus`

- “镇河旧誓铜符”
  - 永久标签：`守御`
  - 协同标签：`护体`
  - 小量数值：`maxManaBonus`

## 3.2 限时 build 标签物品

适合：

- 药剂
- 符箓
- 临时护符
- 战场应急工具

建议规则：

- 只通过 `useProfile.buildBuffs` 生效
- 持续 `1~3` 回合
- 一次最多提供 `1~2` 个标签
- 可叠加刷新时长，但不建议无限堆层

示例：

- “雾沼息行符”
  - `2` 回合获得：`风行`、`游击`
- “火工催压油”
  - `1` 回合获得：`爆发`
  - 同时 `cooldownReduction: 1`

## 3.3 少量直接数值物品

适合做补充，而不是 build 主轴。

建议预算：

- 武器：
  - `outgoingDamageBonus` 小幅增加
- 护甲：
  - `maxHpBonus`
  - 或少量 `incomingDamageMultiplier`
- 饰品：
  - `maxManaBonus`
  - 或轻量 `outgoingDamageBonus`
- 消耗品：
  - `hpRestore`
  - `manaRestore`
  - `cooldownReduction`

建议约束：

- 常规运行时随机物品，数值权重应低于标签权重
- 不要让一个完全无标签的高数值物品压过语义鲜明的 build 物品

## 4. 如何保证“高度贴合背景和 NPC”

## 4.1 生成必须绑定三个锚点

建议每个 AI 原生物品至少有三个锚点：

1. **场景锚点**
   - 例如矿道、渡口、祭坛、雾林、裂界前线
2. **关系锚点**
   - 某个 NPC、某个势力、某类怪物、某段旧事
3. **玩法锚点**
   - 玩家当前 build 缺口或当前风险

如果一个候选物品说不清这三个锚点，就不要发。

## 4.2 命名要使用世界词汇表，不要只按品类随机拼接

建议名字由三部分组成：

```text
来源词 + 关系词 + 品类词
```

例如：

- “锁风渡缉索短刃”
- “药谷回岚灵露”
- “断碑旧誓护心佩”
- “裂界巡守压纹符”

来源词来自：

- 场景 / 地标
- NPC 身份
- 势力 / 流派
- 当前任务线

而不是仅仅：

- 稀有前缀 + 武器名

## 4.3 描述文案要回答“为什么现在拿到它”

建议每个重要物品描述都带一句运行时来源理由：

- 是谁留下的
- 是从谁身上掉的
- 为什么这时能交易给你
- 为什么这次观察能发现它

这样玩家会感觉它是叙事结果，而不是系统掉表。

## 5. 建议的平衡规则

## 5.1 稀有度决定预算，不直接决定强度飞跃

建议把稀有度主要用于控制：

- 可带多少标签
- 是否允许 set / faction 锚点
- 叙事权重和经济价值

而不是简单理解为：

- 稀有度越高，数值就暴涨

建议预算参考：

| 稀有度 | 永久标签 | 限时标签 | 数值预算 |
| --- | --- | --- | --- |
| common | 0~1 | 1 | 很小 |
| uncommon | 1 | 1~2 | 小 |
| rare | 1+1协同 | 2 | 中等偏小 |
| epic | 2 或 set 锚点 | 2 | 中等 |
| legendary | 2 + 关系锚点 | 2~3 | 中等，但仍受上限约束 |

## 5.2 当前阶段优先支持“补短板”和“定方向”

建议运行时物品生成时，优先做这两类决策：

1. **补短板**
   - 玩家 build 缺续航，就更容易拿到 `回复 / 续战 / 护体`
   - 玩家 build 缺切后，就更容易拿到 `快袭 / 突进 / 风行`
2. **定方向**
   - 当玩家已经有明显 build 倾向时，再投放协同物品，把这条路做深

不建议一味“追高强度”，否则玩家会频繁被迫换流派。

## 5.3 运行时物品要避免频繁彻底改流派

建议把随机物品对 build 的影响控制为：

- 大多数时候：
  - 强化现有方向
  - 或提供邻近方向
- 少数特殊奖励：
  - 才允许提供“转流派锚点”

这样玩家会觉得构筑在成长，而不是被系统不断推翻。

## 6. 建议的接入点

## 6.1 宝藏奖励

当前最适合先改的是 `resolveTreasureReward`。

建议把它升级为：

- 先收集：
  - scene preset
  - treasure hint
  - 最近事件
  - 当前遭遇 NPC / 怪物痕迹
- 再生成 1 个上下文物品
- 剩余奖励继续走稳定资源：
  - 货币
  - 基础材料
  - 常规补给

这样宝藏会从“奖励池”变成“叙事发现”。

## 6.2 NPC 交易 / 赠礼 / 帮助

建议给 NPC 增加“关系定制物品”出口：

- 商人：
  - 卖与你当前 build 有关、但带其身份烙印的物品
- 帮助奖励：
  - 给限时道具或一次性符箓
- 高好感 NPC：
  - 才会给带永久 build 标签的私人遗物/信物

这样交易和关系系统就会真正联动。

## 6.3 怪物掉落

建议掉落分两层：

1. 基础掉落
   - 继续走 preset / material / loot table
2. 语义掉落
   - 从怪物生态、战斗风格、所在场景生成一个 build 倾向物品或精粹

例如：

- 重甲守卫掉：
  - `守御精粹`
  - `护体甲片`
- 雾林刺客掉：
  - `快袭羽饰`
  - `风行药囊`

## 6.4 委托奖励

任务奖励最适合给：

- 带关系来源的永久物品
- 剧情关键 rare / relic
- 能把玩家 build 往下一个阶段推一把的奖励

这类物品最适合绑定：

- 委托发布人
- 委托目标
- 地标
- 任务线真相

## 7. 建议新增的数据结构

建议在不推翻现有 `InventoryItem` 的前提下，新增一层来源元数据。

```ts
type RuntimeItemNarrativeBinding = {
  generationChannel: "treasure" | "npc_trade" | "npc_reward" | "monster_drop" | "quest_reward" | "discovery";
  sceneId?: string;
  sceneName?: string;
  relatedNpcId?: string;
  relatedNpcName?: string;
  relatedMonsterId?: string;
  relatedFaction?: string;
  storyReason: string;
  eventHook?: string;
};

type RuntimeItemMetadata = {
  origin: "catalog" | "procedural" | "ai_compiled";
  seedKey?: string;
  narrativeBinding?: RuntimeItemNarrativeBinding;
};
```

然后在 `InventoryItem` 上增加可选字段：

```ts
interface InventoryItem {
  runtimeMetadata?: RuntimeItemMetadata;
}
```

这样后面 UI、日志、剧情回放都能解释：

**这个物品到底从哪来。**

## 8. 推荐的最小落地顺序

建议不要一步把所有入口都改成 AI 原生，而是分三阶段。

## 阶段 A：先做“上下文编译器”，不改所有入口

新增：

- `src/data/runtimeItemDirector.ts`
- `src/data/runtimeItemCompiler.ts`
- `src/types/runtimeItem.ts`

先只负责：

- 接收上下文
- 生成意图
- 编译成 `InventoryItem`

## 阶段 B：先接一个入口验证

优先接：

- `treasureInteractions.ts`

因为它最独立，风险最小，最容易观察“贴合背景”的提升。

## 阶段 C：再接 NPC 与任务

等宝藏验证稳定后，再接：

- NPC 交易
- NPC 帮助奖励
- 任务奖励

最后再考虑怪物掉落的 AI 原生语义层。

## 9. 这套方案和当前仓库为什么契合

这套方案不是另起炉灶，而是直接复用当前仓库已经有的能力：

- 复用 `InventoryItem`
- 复用 `ItemStatProfile`
- 复用 `ItemUseProfile`
- 复用 `ItemBuildProfile`
- 复用 `normalizeBuildTags`
- 复用 `TimedBuildBuff`
- 复用装备、背包、锻造、build 结算
- 复用“AI 叙事，本地规则结算”的总边界

所以它不是推翻当前系统，而是补上当前系统最缺的那一层：

**上下文感知的运行时物品导演。**

## 10. 最后结论

对这个项目来说，理想的 AI 原生运行时物品生成，不应该做成“AI 随机喷装备”，而应该做成：

1. AI 根据场景、背景、NPC、最近事件和玩家 build，先生成物品语义意图。
2. 本地规则把这个意图编译成带永久或限时 build 标签、并附带少量数值加成的正式物品。
3. 物品必须能解释“为什么它会在这里，由谁带来，对当前玩家为什么有意义”。
4. 宝藏、交易、任务、掉落都逐步接入同一套导演层。

这样生成出来的物品才会同时满足三件事：

- **像故事里长出来的**
- **像 build 里需要的**
- **像系统里可控的**