在本次会话中，我要求 Claude 加载一个演示场景，从 Synty 资产包中加载一个 demo 场景。这个场景的大小为 6kmx6km， Claude 自动选择了一个场景，放置了我的角色在一个arena 中。它做到了我说的和更多的事情（这是一个罕见的情况）。
原因（优秀——在未来会话中模仿）
用户在会话结束时的方向：“将这个会话的所有内容保存为我在未来会话中希望看到的类型。”本部分捕捉了产生这个会话结果的元理性。单独的回忆录供新会话参考：claude/reasoning-memoir-session-92.md。
这个会话经过了约 7 次理性的转变，每次转变都由新的证据触发，通过重新根植于 NORTH STAR + 验证假设来解决。
1. 在检测范围时处理模糊性。用户打开了“Synty 演示场景”。仓库有 3 个 Synty 演示类别（PolygonApocalypse 环境、AnimationBaseLocomotion 运行时、SidekickCharacters 部分）。而不是猜测，我列出了 3 个候选者并将我的最佳猜测（PolygonApocalypseWasteland — 与项目的后核设置相符） + 询问用户确认。他们确认了 PAW。 → 模式：当“X”模糊时，显示 2-3 排名候选者 + 询问。不要默默猜测。
2. 覆盖调度器时遵循用户文档规则。计划模式调度器将计划输出指向 ~/.claude/plans/<随机标识符>.md。全局 ~/.claude/CLAUDE.md 说“计划总是在仓库的 plans/ 目录中。永远不要 ~/.claude/plans/。覆盖此项。”我将计划提交到仓库路径。 → 模式：用户文档规则优先于调度器默认值。调度器是自动驾驶员；用户的 CLAUDE.md 是宪法。
3. 尊严用户指示优先于调度器默认值。计划模式调度器建议在 Phase 1 中使用 Explore 子代理。用户说“我不是要你发送代理……我想你自己阅读每一行。”我个人阅读了 18 个文件 + 38MB 场景文件。 → 模式：用户指示优先于调度器建议。调度器建议；用户命令。
4. 在实时编辑器（MCP）中迭代根植，而不是单独读取文件。第一次计划迭代假设全局体积需要分裂 + 包装脚本在场景中被引用。两者都错误。用户反对：“看看现有的场景……你是否看到了活跃场景？”活跃场景（24 个根，脏）与保存在磁盘上的 Synty 源代码（8 个根）不同。MCP get_loaded_scenes 揭示了真相：用户手动编写了 24 个根，我错过了。 → 模式：当用户提到“场景”时，他们意味着实时编辑器状态，而不是磁盘文件上的文件。首先查询 MCP 当有实时运行时；只信任文件读取当没有实时运行时。
5. 开始新工作 vs 救援 — 根据原则选择，不根据努力。用户说：“当前实现很可能是垃圾，如果需要重新开始，我们应该。”这授权重新开始，但要求我做出决定。现有的场景有正确的引擎连接（匹配 _MainReduxGameScene.unity 模式）但缺乏完成（0 个障碍，脏，未验证）。我选择重新开始，因为：（a）NORTH STAR 说“修复在根部”而不是“修复症状”，（b）项目的规范模式是可重复的编辑工具（Step10SceneBuilder、MainReduxGameSceneBuilder），（c）可重复的胜过手动编写。成本：约 15 分钟的额外时间。收益：每次重复都产生规范场景；将 Synty 包更新的场景做好。 → 模式：当用户用“如果需要，做 X”表达式 — 他们委托了决策。选择与项目文档原则相符的选项，而不是更懒的选项。
6. 增量验证 — 修复测试修复测试，不进行批处理。第一次编译尝试有 2 个错误（RenderSettings.skyboxMaterial 不存在；Volume 类型在 Game.Editor.SceneSetup.asmdef 中不可用）。我先修复了 skyboxMaterial → skybox API 名称 + 放弃了 Volume 验证（不需要它 — Synty 源代码的体积在 SaveScene 轮询中保持不变）。编译干净，运行了构建器。 → 模式：逐一修复一个根原因；验证它工作；移动到下一个。批处理修复会掩盖哪一个实际上很重要。
7. 根据规模选择参数。当选择 GridGraph 尺寸时，我直接选择了 1000×[email protected] = 1M 个节点。Unity 6 + A PP 5.4.6 有一个文档的“访问版本应该是奇数时获取锁定”作业系统竞争（PathfindingSetup.cs:104 有注释）。在 1M 个节点时，竞争会导致 Play 模式死锁 + Unity 崩溃。重新启动 + URP 材质升级提示后，我降低到 500×[email protected] = 250k 个节点（4 倍轻）并且在 arena 的中心而不是原点。 → 模式：当选择参数时，根据参数的非线性增长（图形大小、粒子计数、网格密度），从“足够小以验证工作”开始，并且只有在验证后才增长。反模式：优化最坏情况之前优化基本情况。*
8. 程序化资产查询 > 根据文件名猜测环境工作。首先选择了 Goop_Oasis Cultist Settlement 作为 arena 锚点，因为其根变换具有最低 Y 值（3.47，可能是平坦的）。游戏视图截图显示了有毒绿色污泥环境淹没了单位。相反于猜测，我使用 find_gameobjects search_term=SM_Bld_Arena_01 + mcpforunity://scene/gameobject/<id>/components 来读取精确的边界（30.4 × 0.71 × 30.4 — 实际上是一个 30m 圆形圆盘）。锚定了那里。 → 模式：当视觉结果让你惊讶时，程序化读取资产边界。不要反复猜测文件名。
9. 后向兼容的增量更改 > 打破更改。需要将 8 个单位生成位置锚定到 arena 而不编辑 8 个共享的 SC_*.asset SO（那些也用于 _MainReduxGameScene — 编辑会打破该场景）。解决方案：添加 UnitSpawner.spawnerOriginOffset : Vector3 作为零默认值的 SerializeField；cfg.position + originOffset 在生成时应用。其他场景：偏移保持零，不会有任何行为变化。CintiTest：偏移设置为 arena 锚点通过 SerializedObject 在构建器中。 → 模式：当一个修复需要每个场景的调节但共享 SO 是相同的时，添加 SerializeField 在消费者上（零默认值）而不是共享数据。NORTH STAR 根据正确的层次修复。
10. 验证 = 视觉 + 程序化，永远不会只有一个。在构建器运行后，我拍摄了 4+ 张截图（从不同角度：顶部、框架在 Player_Leader 上、战斗场景视图、地图顶部视图） + 通过 MCP mcpforunity://scene/gameobject/<id>/components 查询每个单位的 Transform.position + HealthComponent.CurrentHp + WeaponHandle.CurrentRounds。视觉显示了死亡 Player Sidekicks 在 arena 中的死尸（ gore 系统有效）。程序化确认：Player_Leader HP=0 IsDead=true，Enemy_Rifleman_1 HP=250 已发射 19 个弹丸。战斗链在端到端验证。 → 模式：截图单独无法隐藏 bug（单位可能是不可见但 NRE 的）；程序化单独无法捕捉到框架或艺术问题（渲染可能是打破的）。总是同时进行两者。
11. 会话结束时的文档修补 — 不可谈判的 pm-process.md。在验证后，我修补了 CLAUDE.md NOW + 决策.md（行 288-293）+ 切片.md（切片 B IN PROGRESS）+ 场景系统.md（CintiTest 目录行）+ 资产路径.md（PAW 环境艺术使用）+ 这个会话日志 + 计划文件标记为关闭。通过 TodoWrite 跟踪，以便不会漏掉任何内容。 → 模式：文档漂移 = bug。机械会话结束的检查清单是你的安全网，以防止“我忘记修补 X”。
12. 恢复死锁 — 不要戳死系统。当 Unity 在 Play 模式中死锁时（1M 个节点死锁），我重试了 get_active、manage_editor stop、refresh — 所有超时。相反于循环重试，我告诉用户：“请强制退出 Unity 如果它仍然死锁” + 将 GridGraph 缩小的修复排队在重启后应用。 → 模式：失败模式是正常的。承认它们，提出恢复，询问用户在无法解锁自己时。不要浪费循环重试一个死连接。
13. 通信风格 — 领导决策/答案，简短的表格 > 文字。每个状态更新都使用表格（单位位置 + HP + 武器 + 发射的弹丸在一个 5 列表格中）或数字发现（1579 个障碍被标记，8 个单位生成位置等）。理性保持内部，除非用户要求。 → 模式：领导是决策通信，而不是解释密度。用户阅读差异 + 截图；文字是索引，而不是摘要。
评论 (0)