Prune stale docs and update .hermes content
Delete a large set of outdated documentation (many files under docs/ and .hermes/plans/, including audits, design, prd, technical, planning, assets, and todos). Update and consolidate .hermes content: refresh shared-memory pages (decision-log, development-workflow, document-map, pitfalls, project-overview, team-conventions) and several skills/references under .hermes/skills. Also modify AGENTS.md, README.md, UI_CODING_STANDARD.md, docs/README.md and .encoding-check-ignore. Purpose: clean up stale planning/audit material and keep current hermes documentation and related top-level docs in sync.
This commit is contained in:
@@ -1,413 +0,0 @@
|
||||
# Build 系统重构 PRD：标签-属性相似度模型
|
||||
|
||||
更新时间：`2026-04-02`
|
||||
|
||||
## 1. 背景
|
||||
|
||||
当前 Build 系统的核心实现位于：
|
||||
|
||||
- `src/data/buildDamage.ts`
|
||||
- `src/data/buildTags.ts`
|
||||
|
||||
现状不是“标签各自独立生效”，而是：
|
||||
|
||||
1. 先收集角色标签、装备标签、套装标签、Buff 标签。
|
||||
2. 再计算“每个标签与其他所有标签”的相似度。
|
||||
3. 用标签之间的整体相互作用，得到最终 `buildDamageMultiplier`。
|
||||
|
||||
这套机制已经能跑，但存在 4 个明显问题：
|
||||
|
||||
1. 解释成本高。玩家很难理解“为什么我多带一个标签，所有旧标签的贡献都变了”。
|
||||
2. 平衡难度高。任意新增一个标签，都会对整个标签集合产生连锁影响。
|
||||
3. 角色感不够强。当前倍率更像“标签团簇强度”，而不是“这个标签是否适合当前角色属性”。
|
||||
4. 扩展不稳定。策划继续扩标签、套装、Buff 时，组合爆炸会越来越明显。
|
||||
|
||||
因此，本次重构目标是把 Build 系统从“标签互相影响”改为“标签分别匹配玩家扮演角色的属性画像”，让每个标签的收益来源更直观、更可控。
|
||||
|
||||
## 2. 目标
|
||||
|
||||
### 2.1 产品目标
|
||||
|
||||
建立一套新的 Build 计算模型：
|
||||
|
||||
- 不再计算标签与标签之间的互相影响。
|
||||
- 改为计算“每个标签”和“角色每个属性”的相似度。
|
||||
- 再根据角色属性分布，决定该标签的修正加成倍数。
|
||||
- 所有标签的总收益由“单标签贡献求和”得到，而不是由“标签网络效应”得到。
|
||||
|
||||
### 2.2 设计目标
|
||||
|
||||
新系统需要满足：
|
||||
|
||||
1. 可解释：每个标签为什么强、强在哪个属性上，都能拆出来看。
|
||||
2. 可控：新增一个标签，只影响它自己的贡献，不扰动全局。
|
||||
3. 贴角色：敏捷型角色更容易吃满“突进/快剑/追击”类标签，智力/精神型角色更容易吃满“法修/法力/符阵”类标签。
|
||||
4. 可扩展：装备、Buff、套装仍然可以继续产出标签，但标签结算方式统一且稳定。
|
||||
|
||||
### 2.3 非目标
|
||||
|
||||
本期不做：
|
||||
|
||||
1. 不重做掉落、锻造、拆解循环。
|
||||
2. 不引入防御端 Build 抗性系统。
|
||||
3. 不重新设计角色基础四维属性。
|
||||
4. 不依赖运行时在线 embedding 服务。
|
||||
|
||||
## 3. 核心方案
|
||||
|
||||
## 3.1 基本思想
|
||||
|
||||
每个 Build 标签不再和其他标签比较，而是改为和以下 4 个角色属性做比较：
|
||||
|
||||
- `strength`
|
||||
- `agility`
|
||||
- `intelligence`
|
||||
- `spirit`
|
||||
|
||||
每个标签都会拥有一个“属性亲和度向量”，表示它分别贴近哪类属性。
|
||||
|
||||
示例：
|
||||
|
||||
- `快剑`：更偏 `agility`，次偏 `strength`
|
||||
- `重击`：更偏 `strength`
|
||||
- `法修`：更偏 `intelligence`
|
||||
- `护体`：偏 `spirit + strength`
|
||||
- `符阵`：偏 `intelligence + spirit`
|
||||
|
||||
角色自身也有属性分布。系统将角色属性归一化后，与标签属性亲和度做匹配，得到该标签在当前角色身上的“适配度”。
|
||||
|
||||
最终伤害加成不再来自“标签互相增幅”，而来自“每个标签在当前角色上的适配度贡献”。
|
||||
|
||||
## 3.2 新公式
|
||||
|
||||
### 角色属性权重
|
||||
|
||||
```ts
|
||||
roleAttributeWeight[attr] = character.attributes[attr] / totalAttributes
|
||||
```
|
||||
|
||||
其中：
|
||||
|
||||
```ts
|
||||
totalAttributes =
|
||||
strength + agility + intelligence + spirit
|
||||
```
|
||||
|
||||
### 标签属性亲和度
|
||||
|
||||
每个标签维护一个四维向量：
|
||||
|
||||
```ts
|
||||
tagAttributeAffinity = {
|
||||
strength: 0~1,
|
||||
agility: 0~1,
|
||||
intelligence: 0~1,
|
||||
spirit: 0~1,
|
||||
}
|
||||
```
|
||||
|
||||
### 单标签适配度
|
||||
|
||||
```ts
|
||||
tagFitScore(tag, character) =
|
||||
sum(attr in [str, agi, int, spr])(
|
||||
roleAttributeWeight[attr] * tagAttributeAffinity[attr]
|
||||
)
|
||||
```
|
||||
|
||||
`tagFitScore` 结果区间固定在 `0 ~ 1`。
|
||||
|
||||
### 单标签加成倍数
|
||||
|
||||
```ts
|
||||
tagBonusMultiplier =
|
||||
1 + baseTagBonus * tagFitScore * sourceCoefficient
|
||||
```
|
||||
|
||||
建议首版参数：
|
||||
|
||||
- `baseTagBonus = 0.12`
|
||||
- `sourceCoefficient`
|
||||
- Buff 标签：`1.0`
|
||||
- 角色固有标签：`0.9`
|
||||
- 武器标签：`0.85`
|
||||
- 防具标签：`0.75`
|
||||
- 饰品标签：`0.8`
|
||||
- 套装合成标签：`0.9`
|
||||
|
||||
### 最终 Build 总倍率
|
||||
|
||||
为了避免标签过多时指数膨胀，首版采用“加法累计，再转倍率”的方式：
|
||||
|
||||
```ts
|
||||
buildBonus =
|
||||
clamp(sum(eachTagBonusDelta), 0, 0.6)
|
||||
|
||||
buildDamageMultiplier = 1 + buildBonus
|
||||
```
|
||||
|
||||
其中：
|
||||
|
||||
```ts
|
||||
eachTagBonusDelta = baseTagBonus * tagFitScore * sourceCoefficient
|
||||
```
|
||||
|
||||
这意味着：
|
||||
|
||||
- 标签越多，总收益越高。
|
||||
- 但每个标签只看自己和角色属性是否匹配。
|
||||
- 新增一个标签，不会反向修改旧标签贡献。
|
||||
|
||||
## 3.3 示例
|
||||
|
||||
角色属性：
|
||||
|
||||
- `strength = 8`
|
||||
- `agility = 10`
|
||||
- `intelligence = 4`
|
||||
- `spirit = 3`
|
||||
|
||||
归一化后：
|
||||
|
||||
- `strength = 0.32`
|
||||
- `agility = 0.40`
|
||||
- `intelligence = 0.16`
|
||||
- `spirit = 0.12`
|
||||
|
||||
标签亲和度假设：
|
||||
|
||||
```ts
|
||||
快剑: { strength: 0.35, agility: 1.0, intelligence: 0.1, spirit: 0.05 }
|
||||
突进: { strength: 0.45, agility: 0.95, intelligence: 0.0, spirit: 0.0 }
|
||||
法修: { strength: 0.0, agility: 0.1, intelligence: 1.0, spirit: 0.6 }
|
||||
```
|
||||
|
||||
则：
|
||||
|
||||
```ts
|
||||
快剑 fit = 0.32*0.35 + 0.40*1.0 + 0.16*0.1 + 0.12*0.05 = 0.534
|
||||
突进 fit = 0.32*0.45 + 0.40*0.95 = 0.524
|
||||
法修 fit = 0.40*0.1 + 0.16*1.0 + 0.12*0.6 = 0.272
|
||||
```
|
||||
|
||||
可以直观看到：
|
||||
|
||||
- 同样是标签，`快剑/突进` 对敏捷角色收益高。
|
||||
- `法修` 在这名角色身上的收益明显偏低。
|
||||
- 原因不再是“它和其他标签不合群”，而是“它和当前角色属性画像不匹配”。
|
||||
|
||||
## 4. 数据结构改造
|
||||
|
||||
## 4.1 `BuildTagDefinition` 扩展
|
||||
|
||||
当前 `src/types/build.ts` 中的 `BuildTagDefinition` 需要新增：
|
||||
|
||||
```ts
|
||||
attributeAffinity: {
|
||||
strength: number;
|
||||
agility: number;
|
||||
intelligence: number;
|
||||
spirit: number;
|
||||
};
|
||||
```
|
||||
|
||||
完整建议：
|
||||
|
||||
```ts
|
||||
interface BuildTagDefinition {
|
||||
id: string;
|
||||
label: string;
|
||||
category: BuildTagCategory;
|
||||
aliases: string[];
|
||||
description: string;
|
||||
attributeAffinity: {
|
||||
strength: number;
|
||||
agility: number;
|
||||
intelligence: number;
|
||||
spirit: number;
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## 4.2 运行时明细结构
|
||||
|
||||
`src/data/buildDamage.ts` 需要将当前的 `BuildDamageBreakdown` 从“标签两两贡献表”改成“标签-属性贡献表”：
|
||||
|
||||
```ts
|
||||
type BuildDamageBreakdown = {
|
||||
tags: string[];
|
||||
buildDamageBonus: number;
|
||||
buildDamageMultiplier: number;
|
||||
rows: Array<{
|
||||
label: string;
|
||||
source: 'buff' | 'character' | 'equipment' | 'set' | 'monster';
|
||||
fitScore: number;
|
||||
sourceCoefficient: number;
|
||||
bonusDelta: number;
|
||||
attributeContributions: {
|
||||
strength: number;
|
||||
agility: number;
|
||||
intelligence: number;
|
||||
spirit: number;
|
||||
};
|
||||
}>;
|
||||
};
|
||||
```
|
||||
|
||||
这样 UI 或调试日志能直接回答：
|
||||
|
||||
- 这个标签吃的是哪条属性
|
||||
- 吃了多少
|
||||
- 为什么它比另一个标签强
|
||||
|
||||
## 4.3 相似度来源
|
||||
|
||||
旧版曾生成过标签-标签相似度矩阵，但新方案不再以“标签-标签相似度矩阵”为主数据源。
|
||||
|
||||
建议改为新增：
|
||||
|
||||
- `src/data/buildTagAttributeAffinity.ts`
|
||||
|
||||
用于存放标签到四维属性的静态向量。
|
||||
|
||||
首版推荐手工维护，原因：
|
||||
|
||||
1. 标签总量不大，人工校准更稳定。
|
||||
2. 当前目标是产品可控性，不是自动发现语义簇。
|
||||
3. 四维属性向量远比标签两两矩阵更容易审表和平衡。
|
||||
|
||||
后续如果要半自动化，可再增加脚本从标签描述中生成建议值，但运行时仍只读取本地静态表。
|
||||
|
||||
## 5. 标签来源规则
|
||||
|
||||
标签来源不变，计算方式变化。
|
||||
|
||||
### 保留来源
|
||||
|
||||
1. 角色固有 `combatTags`
|
||||
2. 装备 `buildProfile.tags`
|
||||
3. 套装标签
|
||||
4. Buff 标签
|
||||
|
||||
### 新规则
|
||||
|
||||
1. 所有标签统一做规范化和去重。
|
||||
2. 每个标签独立计算与角色属性的适配度。
|
||||
3. 不再计算标签与标签之间的 pair / product / cluster。
|
||||
4. 套装标签本质上仍是标签，只是 `sourceCoefficient` 更高。
|
||||
|
||||
## 6. 伤害接入方式
|
||||
|
||||
当前 `calculateOutgoingDamage()` 的接法可以保留：
|
||||
|
||||
```ts
|
||||
finalDamage =
|
||||
round(
|
||||
baseDamage
|
||||
* functionMultiplier
|
||||
* equipmentMultiplier
|
||||
* buildDamageMultiplier
|
||||
)
|
||||
```
|
||||
|
||||
本次只替换 `buildDamageMultiplier` 的来源，不改整体伤害主链路。
|
||||
|
||||
## 7. 与旧系统的关键差异
|
||||
|
||||
| 维度 | 旧系统 | 新系统 |
|
||||
| --- | --- | --- |
|
||||
| 核心逻辑 | 标签之间互相影响 | 标签分别匹配角色属性 |
|
||||
| 新增标签的影响范围 | 会扰动整个标签集合 | 只影响自身贡献 |
|
||||
| 可解释性 | 低 | 高 |
|
||||
| 平衡成本 | 高 | 低 |
|
||||
| 角色属性参与感 | 弱 | 强 |
|
||||
| 套装/装备/Buff 接入 | 已支持 | 继续支持 |
|
||||
|
||||
## 8. 实施方案
|
||||
|
||||
### 阶段 A：数据层
|
||||
|
||||
1. 在 `src/types/build.ts` 扩展 `BuildTagDefinition.attributeAffinity`
|
||||
2. 在 `src/data/buildTags.ts` 为所有规范标签补齐四维亲和度
|
||||
3. 新增 `src/data/buildTagAttributeAffinity.ts` 或直接内联到标签注册表
|
||||
|
||||
### 阶段 B：规则层
|
||||
|
||||
1. 重写 `src/data/buildDamage.ts`
|
||||
2. 删除或下线标签两两 `contributionRows` 计算
|
||||
3. 新增 `tagFitScore`、`bonusDelta`、`attributeContributions` 计算
|
||||
|
||||
### 阶段 C：展示层
|
||||
|
||||
1. 调整 Build 面板展示文案
|
||||
2. 从“标签协同”改成“标签适配度”
|
||||
3. 为每个标签展示主属性来源，例如：
|
||||
- `快剑：敏捷主导，少量力量修正`
|
||||
- `法修：智力主导，精神辅助`
|
||||
|
||||
### 阶段 D：平衡层
|
||||
|
||||
1. 补一份全标签四维向量审表
|
||||
2. 选 5 个预设角色跑样例验证
|
||||
3. 校准 `baseTagBonus` 与 `sourceCoefficient`
|
||||
|
||||
## 9. 验收标准
|
||||
|
||||
### 功能验收
|
||||
|
||||
1. 任意标签的贡献都可以拆解到四个属性。
|
||||
2. 删除一个标签时，只减少它自己的收益，不应重算其他标签的贡献值。
|
||||
3. 同一套装备给不同属性角色使用时，Build 倍率应体现明显差异。
|
||||
4. 套装标签、Buff 标签仍能正常进入最终 Build 倍率。
|
||||
|
||||
### 数值验收
|
||||
|
||||
1. 单标签弱匹配时收益接近 0。
|
||||
2. 单标签强匹配时收益稳定且可预期。
|
||||
3. 3 到 6 个高匹配标签可形成清晰 build 成型感。
|
||||
4. 8 标签上限下，总 Build 加成不超过设计封顶值。
|
||||
|
||||
### 体验验收
|
||||
|
||||
1. 玩家能理解“为什么这个标签适合我当前角色”。
|
||||
2. 策划能直接通过改四维向量调数，不需要反复查标签图谱。
|
||||
3. 调试日志能一眼看出收益来源，而不是只能看到复杂的 pair 乘积。
|
||||
|
||||
## 10. 风险与对策
|
||||
|
||||
### 风险 1：标签语义被压平
|
||||
|
||||
问题：
|
||||
去掉标签-标签协同后，Build 可能变得过于线性。
|
||||
|
||||
对策：
|
||||
|
||||
1. 保留套装标签和 Buff 标签作为高价值来源。
|
||||
2. 用 `sourceCoefficient` 区分来源权重。
|
||||
3. 后续如需要，可增加“少量同流派奖励”，但必须是弱规则，不能回到全图互相影响。
|
||||
|
||||
### 风险 2：四维向量定义主观
|
||||
|
||||
问题：
|
||||
不同策划对“快剑更像敏捷还是力量”可能判断不同。
|
||||
|
||||
对策：
|
||||
|
||||
1. 首版先建立审表规范。
|
||||
2. 每个标签必须附一句属性说明。
|
||||
3. 先让预设角色覆盖主要 archetype，再扩充长尾标签。
|
||||
|
||||
### 风险 3：旧数据迁移成本
|
||||
|
||||
问题：
|
||||
旧标签相似度矩阵已经不再作为主数据源。
|
||||
|
||||
对策：
|
||||
|
||||
1. 新逻辑只依赖标签定义中的属性亲和度。
|
||||
2. 旧相似度矩阵生成产物已从主工程移除。
|
||||
3. 后续若需要重新引入自动建议，也应输出为审表辅助数据，而不是运行时真相源。
|
||||
|
||||
## 11. 一句话结论
|
||||
|
||||
本次 Build 系统重构的核心，不是再优化“标签之间怎么互相放大”，而是把判断标准改成“这个标签和当前玩家角色的属性画像有多匹配”，从而让 Build 倍率从复杂的标签网络效应，变成可解释、可调优、可控的单标签属性适配模型。
|
||||
Reference in New Issue
Block a user