daluandou/CODELY.md

## Codely Structured Memories

### User
- [2026-09-09 13:43:50] 用户是 10 年 Java 后端开发，可以提供后端接口，但当前项目处于原型验证阶段，暂不需要服务器。

### Feedback
- [2026-08-28 11:36:37] 用户偏好 Unity 操作分步骤执行：一次只做一个明确动作并先验证结果，避免连续执行大量工具调用导致超时。**Why:** 之前连续操作出现 Stream idle timeout。**How to apply:** Unity 场景、Prefab、组件和运行验证都采用“读取→单步修改→确认”的节奏。
- [2026-08-30 22:44:50] 每实现一个角色技能，都要同步更新《场景和角色设计.md》文档末尾的角色与技能描述表格。**Why:** 用户希望实现进度与设计文档保持同步。**How to apply:** 后续新增或修改角色技能时，在同一任务中追加或更新对应表格行。
- [2026-08-31 14:52:17] 角色配色应以自然、克制的主体色为主，每个角色加入一到两处对比度较强的颜色作为识别点，避免整体过于花哨或过于朴素。**Why:** 用户希望角色既有视觉记忆点，又保持统一、易建模的造型。**How to apply:** 后续角色提示词使用材质和种族决定主体配色，仅在围巾、护腕、局部毛色等少量位置加入强对比色。
- [2026-08-31 15:30:02] 角色技能表中的攻击速度应以“普攻间隔（秒/次）”展示，而不是“次/秒”。**Why:** 用户更直观地关注单位每隔多少秒攻击一次。**How to apply:** 后续新增或调整角色数值时统一使用秒/次，并按间隔数值维护平衡。
- [2026-09-01 14:10:12] 用户在 Unity 脚本或 Animator 问题排查中可优先要求“先改、不运行验证”，此时只执行读取、针对性修改和必要的编译/配置确认。**Why:** Play Mode 或视频验证容易触发 Stream idle timeout。**How to apply:** 除非用户明确要求运行验证，否则遇到类似超时后先不进入 Play Mode。
- [2026-09-03 14:32:39] 眩晕状态特效应优先使用 Unity Particle System，并以星星贴图作为粒子，而不是用运行时复制多个 Sprite 作为最终实现。**Why:** 用户明确希望得到真正的粒子效果，Sprite 复制只能作为临时占位。**How to apply:** 后续制作眩晕及类似循环状态特效时，优先创建可复用的粒子 Prefab 并接入通用状态系统。
- [2026-09-04 10:39:23] 后续所有角色图片生成提示词禁止出现米白色衣服，并一并排除象牙白、奶油白、乳白色及其他近似暖白色服装。**Why:** 用户明确要求角色服装不再使用米白色。**How to apply:** 新增或改写任何角色提示词时，服装与护甲优先使用明确的冷色、深色或自然色，并在提示词中写出排除项。
- [2026-09-04 11:21:06] 角色辨识度优先依靠大轮廓、简化脸部、职业特征大色块和少量核心识别点，不依赖复杂细节或精细贴图；尤其要适配 2.5D 远距离显示。**Why:** 用户希望即使模型和贴图较粗糙，也能一眼识别角色职业与身份。**How to apply:** 后续角色提示词优先设计头部框架、面部符号、服装剪影和能力核心，控制小装饰与高频纹理。
- [2026-09-04 14:12:02] 需要 Play Mode 验证时先询问用户，由用户手动点击 Play 并反馈结果，不要自动进入 Play Mode。**Why:** 可节约时间并避免 Unity 运行验证导致工具等待或超时。**How to apply:** Unity 动画、角色行为和运行时问题排查中，完成编辑态修改后停在编辑器等待用户验证。
- [2026-09-05 10:16:49] Unity 运行验证默认不由助手自动进入 Play Mode；完成编辑态修改、编译和场景保存后，等待用户手动点击 Play 并反馈结果。**Why:** 用户希望避免运行验证导致等待或超时。**How to apply:** 角色、动画 Event 和技能接入任务优先做编辑态验证，除非用户明确要求自动运行测试。
- [2026-09-09 12:11:59] 当用户明确指出现象和修复目标时，优先按用户给出的事实做针对性修改，不继续进行冗长排查。**Why:** 用户明确指出法师没有生成火球，并要求直接给新建火球 Prefab 补脚本。**How to apply:** 先读取目标资产确认，再执行最小必要修改；只有修改仍失败时才扩大排查范围。
- [2026-09-09 13:43:50] 能量恢复速度应该更慢一些，用户建议改为 3 秒恢复 1 格。**Why:** 1 秒 1 格太快，不利于战斗节奏控制。**How to apply:** 召唤系统能量恢复速率应偏慢，给玩家资源压力。
- [2026-09-09 20:37:24] 用户希望提前实现数据架构而非临时方案，即使当前阶段功能简单。**Why:** 用户有 10 年后端开发经验，理解数据分层的重要性，希望逐步完善而非推倒重来。**How to apply:** 对于有明确扩展方向的功能（升级、存档、联网），优先设计可扩展架构并临时写死数据，而非等需求明确后再重构。
- [2026-09-10 18:38:45] 正交俯视视角（38-43°）下，垂直墙面几乎看不见（只能看到墙顶），因为墙面平行于视线方向被自身遮挡。适合的装饰物：高耸物体（旗帜、石柱）、有明显剪影的物体（木箱、碎石堆）、对比色强的物体；不适合：低矮平面物（矮墙、栅栏）、细长水平物（绳索）。**Why:** 这是正交俯视视角的固有盲区，无法通过调整角度完全解决（角度太平会牺牲战场全局视野）。**How to apply:** 场景装饰设计时优先使用垂直高度≥2米的物体，避免依赖水平或低矮结构。
- [2026-09-14 18:24:56] 用户认可"参考游戏是基地离得远、镜头更远、单位推进慢"的观感方向（2026-09-14 数值改慢后反馈"好多了"）。**Why:** 之前双方距离近+移速快，单位两三秒就接触，战斗缺乏观察窗口。**How to apply:** 后续地图/镜头调整优先加长双方距离、拉远摄像机；数值宁慢勿快。
- [2026-09-16 22:18:14] 召唤系统：找不到合适位置时直接在召唤师前方强制生成，不显示警告，不退还能量。**Why:** 用户要求召唤必须成功，不被取消。**How to apply:** MainCharacterCombat.cs 的召唤逻辑
- [2026-09-16 22:18:30] 召唤打断移动：主角点击召唤时必须立即停止移动，调用 SummonerClickMovement.ClearTarget() 来实现。**Why:** 用户要求召唤时即使在移动也要立刻停下。**How to apply:** BeginSummon 开始时停止移动
- [2026-09-17 10:06:34] 召唤师移动后连续召唤动画超时问题：SummonerClickMovement.HandleMovement() 每帧设置 animator.SetInteger("speed", 1) 干扰召唤动画。**Why:** 即使召唤时调用了 ClearTarget()，下一帧 Update 还是会覆盖动画参数。**How to apply:** 召唤期间禁用移动脚本 (clickMovement.enabled = false)，召唤完成后重新启用 (enabled = true)。已在 MainCharacterCombat.Summon() 和 FinishSummon() 中实现。

### Project
- [2026-08-28 14:26:56] 弓箭手远程箭矢的设计要求：保持发射时高度水平飞行，命中目标后直接结算伤害并销毁，不产生实体物理击退。**Why:** 当前玩法希望远程攻击是命中判定而非物理推动。**How to apply:** 后续调整箭矢、Projectile 或弓箭手攻击逻辑时保持这一行为。
- [2026-08-28 18:06:13] 小游戏对外名称确定为《召唤之战》，整体采用竖屏布局；主界面不需要“技能、背包、属性”入口或相关模块。**Why:** 备案与产品定位已确定，UI 需保持简洁并适配竖屏。**How to apply:** 后续设计备案图、主菜单或游戏 UI 时遵循此名称、方向和功能范围。
- [2026-08-29 11:44:51] 《召唤之战》战斗设计倾向简化：单位解锁后立即拥有完整技能，升级只提升基础数值；战斗召唤栏采用底部正方形头像卡片，战斗场景第一版优先将背景图贴到现有 BattlePlatform，而非制作完整3D场景。
- [2026-08-31 11:31:00] 角色图片生成统一采用 3D 卡通、非写实、单角色正视图；人形角色使用标准 A-pose，非人形角色使用稳定自然姿态。**Why:** 便于 3D 建模与动画制作，并符合《召唤之战》的视觉方向。**How to apply:** 后续新增各章节角色提示词时遵循该标准，并记录在《角色与技能说明.md》。
- [2026-09-02 16:44:35] 主角定位确定为“召唤师优先、法师辅助”的人类召唤师，主要战斗力来自召唤单位，主角仅用基础法术补刀和牵制；视觉上需要通过召唤核心、学院符文和独特剪影与普通法师区分。**Why:** 保持召唤系统的核心地位并提高主角辨识度。**How to apply:** 后续主角技能、模型、动画和 UI 设计都应围绕召唤师身份展开。
- [2026-09-02 23:50:59] 《召唤之战》状态效果方案确定：所有可控制单位共用 Stun/StatusEffect 系统，眩晕暂停当前 Animator 与战斗逻辑，使用通用头顶星星提示，重点角色以后再补专属眩晕动画。**Why:** 降低首版制作量并保持各单位行为一致。**How to apply:** 新增眩晕、减速、沉默等控制效果时优先扩展通用状态组件，不在技能脚本中直接操作具体角色动画。
- [2026-09-03 18:09:56] 《召唤之战》大招统一在下一次普攻开始前判定：先通过现有寻敌逻辑获得有效目标，能量满则优先释放大招并消耗能量，跳过本次普攻；没有有效目标时不释放且保留能量。**Why:** 避免普攻命中击杀目标后仍立即触发大招。**How to apply:** 后续新增或修改角色技能时遵循该统一触发时机。
- [2026-09-03 18:52:21] 《召唤之战》采用 2.5D 战斗呈现，角色设计需要在俯视斜角和远距离下保持清晰剪影与可读的大色块。**Why:** 用户希望角色在实际战斗镜头中仍容易区分。**How to apply:** 后续角色图片、模型、服装和特效设计优先考虑 2.5D 视角下的轮廓识别，不依赖细小装饰。
- [2026-09-03 19:12:39] 角色图片提示词与游戏内装备分离：盾卫的角色本体图片必须明确不出现盾牌，塔盾作为独立武器/装备资产单独生成与配置。**Why:** 便于后续替换和挂载装备，避免角色模型自带盾牌影响游戏配置。**How to apply:** 后续生成盾卫或其他可换装角色图片时，只描述身体与服装本体，不把可独立配置的装备画进角色图。
- [2026-09-06 22:14:43] 《召唤之战》当前先确定每关携带 5 种角色，战斗中固定显示 5 张召唤卡；UI 采用大框底图加独立可复用卡片、角色头像和运行时状态元素。**Why:** 先控制竖屏战斗界面复杂度并便于调试。**How to apply:** 后续召唤 UI、卡组和能量系统按 5 个固定卡位设计，不把动态文字、冷却和能量豆烘焙进静态图片。
- [2026-09-09 12:23:17] 攻击系统已从动画结束 Event 改为攻击命中 Event 触发。UnitBase 通过 OnAttackEffect() 统一处理四种攻击类型：MeleeDirect（近战直接伤害，已实现）、RangedProjectile（远程锁敌飞行物，已实现）、MeleeArea（近战范围，预留）、RangedArc（远程抛物线，预留）。攻击动画结束由脚本自动检测 normalizedTime，不再依赖 OnAttackAnimationEnd Event。**Why**: 用户需要远程攻击等箭矢碰撞后才扣血，而非动画中途直接伤害。**How to apply**: 所有攻击动画只需在命中帧添加 OnAttackEffect Event；近战保持 MeleeDirect，远程单位设为 RangedProjectile 并配置 projectilePrefab/projectileSpawnPoint。
- [2026-09-09 20:37:24] 召唤能量和冷却系统已完成，玩家角色数据架构已完成：ManaSystem 单例管理能量（最大 10，3 秒恢复 1 点），MainCharacterCombat 扩展能量检查（人类士兵消耗 2，弓箭手消耗 3），SummonCardButton 接入冷却逻辑（5 秒冷却，UI 显示遮罩和倒计时），能量豆 UI 已配置，冷却遮罩在非冷却时完全隐藏。CharacterData 支持基础属性和升级成长，PlayerCharacterData + PlayerDataManager 实现玩家角色等级和属性计算，召唤时传递最终属性给 UnitBase。

- [2026-09-09 20:37:24] 玩家角色数据架构已完成：CharacterData 存储基础属性（1级）和成长值（每级加成），PlayerCharacterData 存储玩家角色等级和星级，PlayerDataManager 单例管理玩家拥有的角色和当前卡组（临时写死）。召唤时从 CharacterData + PlayerCharacterData 计算最终属性并传递给 UnitBase.InitializeFromPlayerData()。升级系统正常工作（1级 100血/50攻，3级 120血/60攻）。后续扩展：存档系统、卡组配置界面、升级界面、角色解锁、后端接口。
- [2026-09-09 22:17:58] 第一关地图重新设计已完成：地图扩展到120单位（Z: -24到96），创建3个波次生成器（WaveSpawner）在Z=25/55/85，添加视觉标识物（旗帜、石柱、石墙）标记战斗区域。摄像机修正：旋转(43,0,0)位置(0,18,-5)，朝向+Z方向与主角前进方向一致。召唤系统优化：初始状态无冷却遮罩，冷却时间从5秒改为1秒（能量已控制召唤频率）。
- [2026-09-10 11:03:00] 第一章第一关地图（Level1-1.scene）已完成：120单位长地图（Z: -24到96），使用用户自制的6类真实3D模型装饰（石墙/木栅栏/旗帜/木箱/石柱/碎石堆），共34个物体分布在左右装饰带和3个波次标记位置。摄像机设置为2.5D视角（位置0,18,-5，旋转43°）。**Why:** 地图基础结构已完成，可以开始添加战斗逻辑和敌人生成器。**How to apply:** 后续关卡可复制此场景作为模板，调整装饰布局即可。
- [2026-09-10 18:38:13] 第一关地图（Level1-1.scene）已采用"皇室战争"风格简化设计：移除所有边界矮墙（俯视角只能看到墙顶），改用旗帜+石柱交替排列标识边界（X=±5.5，Z轴8个位置交替）；保留中间战道掩体（木箱×6、碎石堆×4）；天空改为纯色蓝灰色+线性雾效（起始40m，结束100m）；摄像机添加边界Clamp限制（X: -7~7, Z: -32~93，宽松模式），主角靠近边界时摄像机停止跟随；光照调整为从后上方照射（50°, 0°, 0°），角色正面清晰可见。**Why:** 正交俯视视角下垂直墙面几乎看不见（只能看到墙顶），旗帜+石柱有高度和轮廓，视觉识别强。**How to apply:** 后续关卡延续此风格，避免使用低矮平面装饰物。
- [2026-09-10 18:38:32] 召唤逻辑已优化碰撞处理：当目标位置被占用时，自动螺旋搜索周围空位（左右搜索8次×前后3层×2方向，约102个候选点）；如果所有位置都被占用，自动退还能量豆并取消召唤，避免浪费能量。参数：summonSearchCount=8, summonDepthSearchCount=3, summonSearchStep=0.8f, summonDepthSearchStep=1f。
- [2026-09-11 14:55:27] 敌人血条颜色问题已修复：WorldHealthBar 在 Awake() 时根据 GameObject.tag 判断颜色，WaveSpawner 在 Instantiate() 后设置标签会导致时序错误（血条已创建成绿色）。解决方案：直接在敌人 Prefab 上设置 Enemy 标签，确保 Awake() 时标签已正确。已修改狼人/蓝色怪物/弓箭猎人/石巨人四个 Prefab。**Why:** 血条颜色在对象创建时确定，后设置标签无法自动刷新。**How to apply:** 后续新增敌人 Prefab 时直接在 Prefab 上设置 Enemy 标签，不依赖运行时代码设置。
- [2026-09-16 14:22:13] 2026-09-13 玩法大转向：从闯关推图改为"建筑生产+自动作战+主角辅助"的对攻玩法（见《召唤之战-核心玩法.md》）。旧闯关玩法由用户在另一台电脑的分支保存，当前 main 按新玩法开发。提交 beab4cf 已实现：GoldSystem/GoldMine 金币经济、Barracks 兵营产兵、BuildingPlacementManager 建筑摆放、CharacterData 新增 productionInterval/buildingCost、UnitBase/Projectile 支持攻击建筑、CoreBattleTest.scene 验证场景、CameraFollow 重写（WASD/鼠标/触摸拖动+缩放）。胜负目标改为摧毁对方主建筑。**How to apply:** 2026-09-16 起玩法进一步改为"召唤师对决"（见同日新条目），建筑/经济/产兵系统已封存、不再作为主线，相关脚本留作素材。

- [2026-09-14 18:24:46] 2026-09-14 性能实测（9 个角色 Prefab）：大多数 5~8k 三角面/22 骨骼/512 贴图，性能没问题；两个待处理异常——蓝色怪物 34408 面（是量产低价单位，建议减面到 8k 左右）、法师贴图 2048x2048（建议缩到 512）。另建议设计层限制每方场上单位上限（约15）保性能与 2.5D 可读性，并确认方向光关实时阴影，最终以低端安卓真机小游戏包为准。**How to apply:** 后续做性能优化或新增量产型敌人时按此基准控制面数。
- [2026-09-14 21:19:53] 2026-09-13 新增建筑系统核心脚本：BuildingHealth（建筑血量+生产进度接口）、GoldSystem/GoldMine（金币经济与产出）、Barracks（兵营产兵，读取 CharacterData.productionInterval）。WorldHealthBar 增加 SetEnergy() 通用下方条接口，建筑复用该条显示生产进度，单位仍用于技能能量。BuildingPlacementManager 支持虚拟网格吸附、占位检测、金币扣除，新放置建筑自动挂 BuildingHealth。UnitBase/Projectile 的 ApplyDirectDamage/ApplySkillHit/ApplyAreaSkillDamage/HitTarget 均已接入 BuildingHealth，建筑可被近战/技能/范围/飞行物伤害。兵营 Prefab（Assets/Prefabs/建筑/兵营.prefab）已写入 Barracks+WorldHealthBar+BuildingHealth，默认阵营 Friend，场景实例保留 Enemy 覆盖。**Why:** 建筑作为可攻击目标是新对攻玩法的核心，生产进度条复用血条下方条避免额外 UI。**How to apply:** 后续新增建筑类型（防御塔/资源建筑）参照 BuildingHealth 接口；修改血条下方条逻辑时注意区分单位和建筑语义。
- [2026-09-14 21:34:17] 2026-09-14 发现：团结引擎 1.10.2 (macOS) 原生 NavMesh 烘焙失效——空场景放一个静态 Cube，用 NavMeshBuilder.BuildNavMeshData / UpdateNavMeshDataAsync / 经典全局 BuildNavMesh 烘焙全部产出 0 三角形，无报错；收集源（CollectSources）、Job 系统、AI 模块包均正常；换构建目标/域重载/重启编辑器均无效。**Why:** 原生导航烘焙在此安装上深层失效，继续用 NavMesh 会浪费时间。**How to apply:** 本项目寻路不要用 NavMesh/NavMeshAgent/NavMeshSurface，改用纯 C# 网格 A*（见 GridPathfinder.cs）；若未来升级团结版本可先重跑最小 Cube 烘焙测试再决定。
- [2026-09-14 22:55:12] 2026-09-14 伤害数字系统（WorldHealthBar.SpawnDamageNumber + DamageNumber 组件）已上线：白字黑边样式（1 白主字 + 4 向偏移黑副本，TextMesh 无原生描边所以用副本组合），入口在 TakeDamage/Heal，全场并发上限 60。两个关键坑：1) TextMesh 可读面朝本地-Z，billboard 必须用 LookRotation(selfPos - cameraPos)，方向写反会左右镜像；2) 同材质同 sortingOrder 的多个 TextMesh 渲染顺序不确定，后创建的黑色副本会盖住白字——必须显式分层：黑边 sortingOrder=60、白主字=61，白字必须最后创建或层级更高。**Why:** 用户要求白色黑边，先后修复了镜像和纯黑覆盖问题。**How to apply:** 后续做其他 3D 漂浮文字（暴击、金币）沿用 DamageNumber 模式、朝向写法和 sortingOrder 分层。
- [2026-09-15 08:09:51] 2026-09-15 决战玩法（BattleTest.scene）布阵系统已实现：BattleSetupManager 单例管理 Setup/Battle/Ended 三状态。布阵阶段：己方半场 2x2 米虚拟网格（X:-8~8, Z:-20~-8），底部 8 张卡片（代码生成 UI），点卡片选兵种→点格子放置（绿/红高亮预览），manaCost 作为人口消耗（上限 30），点已放单位可移除退人口。开战按钮生成敌方预设阵型（前排近战 Z=14 / 后排远程 Z=18，共 28 人口），全灭判定胜负（0.5 秒轮询）。SummonCardButton 已支持双模式：有 BattleSetupManager 走人口判断选兵，否则走金币建筑放置——两个场景共存互不干扰。**Why:** 用户确定决战玩法方向，网格布阵解决开局扎堆且让排兵布阵成为策略。**How to apply:** 后续决战玩法迭代（AI 阵型多样化、主角辅助技能、重开按钮）都基于 BattleSetupManager 扩展；不要在 CoreBattleTest 场景放 BattleSetupManager。
- [2026-09-15 16:03:53] NavMesh 寻路已成功接入所有单位。团结引擎完全支持 NavMesh（需安装 com.unity.ai.navigation 包）。实现方式：1) 添加 NavMeshSurface 组件并烘焙；2) 为所有角色预制体添加 NavMeshAgent；3) 修改 UnitBase.cs 的 move() 方法优先使用 NavMeshAgent.SetDestination()，并在 Start() 中禁用 CharacterController 避免冲突。CoreBattleTest 场景已创建中央分隔墙形成左右两路，单位能够自动沿路线寻路并绕过障碍物。
- [2026-09-15 17:33:54] NavMesh 寻路攻击漂移问题修复方案：单位攻击时会因 NavMeshAgent 继续工作而漂移。解决方法是在 attack() 方法和 Update() 的 State.Attack 分支中直接禁用 NavMeshAgent (navAgent.enabled = false)，在 move() 方法中重新启用。同时修复了 applyGravity() 调用已禁用 CharacterController 导致的警告（添加 controller.enabled 检查）。性能优化：寻路路径更新频率限制为 0.5 秒一次（nextPathUpdateTime + PathUpdateInterval），减少 93% 路径计算开销。
- [2026-09-15 18:42:26] 伤害数字显示规则：友方单位（Friend tag）受伤显示红色数字向下浮动，敌方单位（Enemy tag）受伤显示白色数字向上浮动，治疗显示绿色向上。技术实现：8方向黑色描边（DamageNumberOutlineWidth = 0.025f 常量）+ 1个彩色主字，共9个TextMesh。通过 gameObject.CompareTag("Friend") 判断受击者阵营。已更新到《召唤之战-核心玩法.md》文档 2.3 章节。
- [2026-09-15 19:33:31] 金币系统已完成：GoldManager 单例管理，初始500金币，右上角UI实时更新。金矿建筑产出50金币/5秒，主角产出30金币/8秒。WorldHealthBar 的 currentEnergy 改为属性（带 setter 自动调用 UpdateEnergyFill），能量条尺寸从8像素增加到12像素（EnergyPixelHeight=12，EnergyPixelWidth=100）。能量条显示金币产出进度，满了产出并重置。已更新核心玩法文档。
- [2026-09-16 14:22:13] 2026-09-16 玩法定稿为"召唤师对决"并已写入《召唤之战-核心玩法.md》：无基地/金矿/兵营/防御塔，玩家手动点地操控召唤师（移动不攻击、站定攻击），限己方半场（三分屏：己方/交战/敌方区），能量直购出兵（单位在召唤师身边生成），击杀敌方召唤师获胜，超时毒圈收缩并解除半场限制，中期混沌裂缝事件，召唤师技能 3~4 种，摇杆留作实测后升级项。**Why:** 用户多轮迭代后的最终方向，旧"建筑生产+自动作战"对攻玩法封存不删。**How to apply:** 新战斗开发一律基于召唤师对决方案；不要在新玩法场景引入金矿/兵营/建筑摆放；BuildingPlacementManager/Barracks/GoldMine 等封存留作后续建筑卡或 PVE 特殊关素材。
- [2026-09-16 14:48:52] 召唤师对决首版场景已完成（SummonerDuelTest.unity，2026-09-16）：新场景地面20×80、固定正交相机43°/orthoSize28、召唤师z=0(敌方z=35)均避开底部UI；新增 SummonerClickMovement（点地走位+clamp X[-9,9] Z[-19,6]，移动中关攻击、到点恢复）、SummonerDuelManager（点卡片按能量直召，单位在召唤师身边生成）、UnitBase 新增 summonerMode 开关（不追击、站定攻击，默认关闭不影响旧单位）；战斗界面UI从 CoreBattleTest 整树搬运复用，SummonCardButton 增加对决模式分支（无布阵/金币管理器时走能量直召+冷却）。主角已存为 Assets/Prefabs/主角/召唤师主角.prefab。**How to apply:** 后续对决玩法迭代（毒圈/胜负判定/召唤师技能）基于该场景与脚本扩展；Play Mode 验证等用户手动执行。
- [2026-09-17 09:33:46] 阵营 ID 系统已实现（替代 Unity Tag 判断敌我）：UnitTeam 组件标记 teamId，GameManager.LocalPlayerTeamId 标识本地玩家阵营，支持 PVP（真人 vs 真人 / 真人 vs 机器人）。**Why:** PVP 需要动态敌我判断，Tag 系统无法支持（双方客户端看到的 tag 矛盾）。**How to apply:** 所有敌我判断改用 UnitTeam.IsEnemy()，血条颜色用 IsLocalPlayerTeam()，新生成单位必须设置 teamId（Barracks/BattleSetupManager 已修改）。
- [2026-09-17 09:33:58] 召唤师组件精简：移除了 NavMeshAgent、UnitBase、StatusEffectController，保留 MainCharacterCombat（战斗）+ SummonerClickMovement（移动）+ WorldHealthBar（血条）。SummonerClickMovement 已改为依赖 MainCharacterCombat 而非 UnitBase。**Why:** 召唤师是特殊单位，不应使用通用 UnitBase 逻辑；直线移动不需要 NavMesh。**How to apply:** 召唤师专属逻辑用 MainCharacterCombat，普通单位用 UnitBase。
- [2026-09-17 09:34:13] 《召唤之战》场地规格：60×20（Z×X），三区划分各 20 单位 - 己方区 z∈[-30,-10]（召唤师 z=-20），交战区 z∈[-10,10]，敌方区 z∈[10,30]（敌方召唤师 z=+20）。召唤师移动限制在己方区内（SummonerClickMovement clamp Z[-29,-11]）。相机 orthoSize=22，位置(0,40,-40)，角度 43°。**Why:** 竖屏竞技场设计，双方对称 40 单位间距，防风筝规则（召唤师不能进入交战区）。**How to apply:** 所有位置/spawn 相关代码使用新的 Z 坐标范围。
- [2026-09-17 10:06:48] Projectile 伤害判定逻辑：HitTarget() 检查 UnitBase（普通单位）、BuildingHealth（建筑）、WorldHealthBar（召唤师等特殊单位）三种受击组件。召唤师使用 MainCharacterCombat + WorldHealthBar，不挂 UnitBase。**Why:** 召唤师是玩家控制的特殊单位，行为逻辑与普通 AI 单位不同。**How to apply:** 新增特殊单位必须有 WorldHealthBar 或 UnitBase 之一才能被攻击；法术球击中后调用对应组件的受伤方法（UnitBase.ReceiveDamage / WorldHealthBar.TakeDamage）。
- [2026-09-17 10:38:49] 召唤师（MainCharacterCombat）与普通单位（UnitBase）的架构差异：召唤师使用 MainCharacterCombat + WorldHealthBar + StatusEffectController，不挂 UnitBase。**Why:** 召唤师是玩家控制的特殊单位，行为逻辑与 AI 单位不同。**How to apply:** 涉及单位的通用系统（伤害、眩晕、范围效果）必须同时支持 UnitBase 和非 UnitBase 路径。已修复：Projectile.HitTarget()、UnitBase.ApplyDirectDamage()、UnitBase.ApplyAreaStun() 均添加了 WorldHealthBar / StatusEffectController 的检测分支。

### Reference
- [2026-09-09 12:23:17] 飞行物脚本 Projectile.cs 负责锁敌追踪、碰撞检测和伤害结算。箭矢预制体 ArrowProjectile_White.prefab 已配置 Projectile 组件和 CapsuleCollider（Is Trigger）。远程单位需在攻击动画松弦帧添加 OnAttackEffect Event，并在 UnitBase 中设置 attackType=RangedProjectile、projectilePrefab、projectileSpawnPoint。