docs(设计文档): 补充天赋系统与英雄属性的边界定义

明确属性型与机制型天赋的区别，建立配置规范：
1. 属性型效果必须使用 Attrs 作为 Key
2. 机制型效果需使用独立枚举 Mechanic
3. 新增配置校验规则避免误用

assets/script/Design3.md

@@ -31,6 +31,28 @@
   - 废弃 `TalEffet` 中的 Key 定义，统一使用 `Attrs` 枚举作为 Key。
   - 在 `TalComp.addTal` 中读取 `tConf.count` 写入 `talent.count`，并保证所有“次数型天赋”的消耗端也使用同一套 Key。
 
+补充：TalSet 与 HeroAttrs 的“可一一对应”边界（避免后续继续混淆）
+
+- 结论：可以建立一一对应，但必须先把“键域”拆开。
+  - 重要澄清：**“有条件触发”不等于“机制型”**。
+    - `TriType`/`Trigger` 只决定“什么时候触发”；
+    - “属性型/机制型”决定“触发后往哪里写数据、怎么被消耗”。
+  - **属性型效果（可一一对应）**：所有本质是“修改某个战斗属性”的天赋，统一用 `Attrs` 作为唯一 Key。
+    - 例：减伤 -> `Attrs.DMG_RED`，反伤 -> `Attrs.THORNS`，风怒倍率/风怒触发相关如果要做成属性，也应落到 `Attrs.WFUNY`。
+    - 这一类天赋的表现形式建议只允许：数值型（VALUE）或百分比型（RATIO）的叠加/消耗。
+  - **机制型效果（不可强行一一对应）**：本质是“改变行为/流程”的天赋，不要硬塞进 `Attrs`，而应该走独立的机制 Key。
+    - 例：下次技能额外释放（D_SKILL）、下 N 次普攻必暴（C_ATK）、下 N 次技能必暴（C_SKILL）。这些不是“暴击率+X%”，而是“保证命中事件改写”，语义不同。
+    - 强行映射到 `Attrs.CRITICAL` 会造成策划误配：玩家以为是概率加成，但实际是保底机制，体验会断层。
+
+- 推荐的设计规范（给策划与程序统一语言）：
+  - **字段含义固定化**：
+    - `effet` 只表达“这是属性型还是机制型”。
+    - `key` 才是具体作用目标：属性型 `key = Attrs.*`；机制型 `key = Mechanic.*`（独立枚举，值域不与 Attrs 重叠）。
+  - **配置校验规则**：
+    - 只要是属性型天赋：必须能在 `HeroAttrs.ts` 找到同名或同义的 `Attrs`；找不到就不允许配置。
+    - 只要是机制型天赋：必须有对应的消耗点（例如攻击/技能系统里明确消耗一次），否则 count 只会累加成“无效库存”。
+    - 现状提醒：`TalAttrs` 的确已经把一部分属性（冻结/眩晕/击退/沉默/暴击等）映射到 `Attrs`，但这只覆盖了 `BUFF` 这类“属性叠加”分支；计数型效果如果仍用 `TalEffet` 作为 Key，就会再次出现写入/读取不一致。
+
 ## 二、把 SkillSet 变成“少字段但强表达”的可配置系统
 
 当前 SkillConfig 字段很多，但真正稳定生效的只有少数（ap/map/DType/RType/EType/speed/dis/hit/cd/cost/sp_name）。