UnityAI调整

modules/frameworks/UI窗口系统/界面拼接.md

@@ -4,7 +4,7 @@
 
 ## 一、输入与目标
 
-开始拼接前，先向开发者确认目标分辨率、横竖屏、SafeArea 与屏幕适配要求，以及窗口是全屏、弹窗还是局部面板。已经明确提供的信息不重复询问；项目现有配置可作为确认依据，但不得直接套用某个项目的分辨率。
+开始拼接前，先向开发者确认目标分辨率、横竖屏、SafeArea 与屏幕适配要求，以及窗口是全屏、弹窗还是局部面板。开发者已经明确提供的信息不重复询问；项目现有 CanvasScaler 等配置只能作为参考，不能代替需求确认，也不得直接套用某个项目的分辨率。未确认时可继续检查结构与资源，不先定稿依赖分辨率的切图尺寸和布局。
 
 同时检查：
 
@@ -15,7 +15,15 @@
 
 先理解当前项目的窗口基类、Item 基类、SFUI/UIMono、资源加载、节点绑定与事件规范，优先复用相似窗口。给出简短的节点、切图、复用和验证方案；已明确授权的方案直接实施。不为拼界面另建框架或修改无关业务、第三方库。
 
-不能只凭截图选择近似资源。设计图中的可检查对象必须使用语义正确的现有资源；缺失资源应明确记录，不能用无关图片顶替。
+优先复用语义和视觉均匹配的现有资源，或从提供的分层源文件提取。只有示意图时，可以在任务授权范围内拆图、抠图和处理透明边缘；不能只凭截图选择近似资源。缺失或无法准确提取的部分按下述规则明确暴露。
+
+### 缺失与质量问题必须可见
+
+- 始终保证开发者能够明确看到哪儿有问题、哪儿缺东西。记录具体窗口、节点或画面区域，以及缺少的资源、质量问题、影响和需要提供的素材。
+- 被遮挡、源图低清、元素不完整或无法干净分离时，报出问题；即使没有其他可用素材，也不补画、重绘、生成式填补或猜测还原缺失内容，不用其他图片、假数据或隐藏节点掩盖缺口。
+- 抠图中的裁剪、透明边缘处理和尺寸调整仅处理已有可见内容，不能借机补造原图中缺失的部分。
+- 对照预览中，在问题位置使用明确的诊断文字或标注框，例如“缺少关闭按钮素材”“图标无法完整提取”；标注是给开发者定位问题的诊断信息，不是替代美术资源，也不能混入正式运行资源。不能仅依赖容易被忽略的空白或控制台日志。
+- 暂时无法渲染时，先提供具体节点路径、资源路径或示意图区域说明，并按 [工作流清单](../../../rules/40-工作流清单.md) 修复验证环境；恢复后补充可视化标注。问题可以保留为待解决项，但不能宣称对应资源或视觉效果已验收完成。
 
 ## 二、推荐层级
 
@@ -143,7 +151,7 @@ JSON 生成适合批量创建稳定层级和组件，不代替视觉校对、业
 - 重复切页、开关及启用窗口无重复回调、状态残留或缺失引用。
 - Unity Console 无本次新增 Error，运行时实际显示通过确认。
 
-编译通过、Prefab 保存成功或 JSON 生成成功不能代替视觉和交互验收。无法完成的检查明确说明，不能宣称已验证。
+编译通过、Prefab 保存成功或 JSON 生成成功不能代替视觉和交互验收。资源缺失与质量问题必须按本文在预览和交付中明确标出；验证环境不可用时，按 [工作流清单](../../../rules/40-工作流清单.md) 先修复再验证。无法自行解除的阻塞明确说明，保持相关检查未完成，不能仅报告“未验证”便宣称任务完成。
 
 交付时说明修改的窗口、脚本和资源，确认的基准分辨率与适配方式，主要图片尺寸及三宫格/九宫格设置，已完成的编译、视觉和交互验证，以及未验证内容、已知限制和必要后续操作。
 

modules/frameworks/编辑器工具/MCP工具/Codex_Unity_MCP使用规则.md

@@ -111,6 +111,7 @@ Bridge 把菜单任务排队到 Unity 主线程。同步导入大量资源、创
 - 需要跨 Domain 追溯或菜单超时取证时，以目标工程的 Unity `Editor.log` 补充验证。
 - 日志结论应保留消息、堆栈、资产路径和统计值，区分 Error、预期 Warning 与无关历史日志。
 - Prefab 结构、动画采样和引用检查属于 Editor 证据；Game View、Play Mode、APK 或微信真机效果必须单独验证。
+- 错误必须向开发者明确报告；环境不可用时先修复再继续验证，处理顺序与阻塞交付要求统一见 [工作流清单](../../../../rules/40-工作流清单.md)，不能以连接失败代替完成验证。
 
 ## 八、UI 生成
 

rules/20-开发规则.md

@@ -32,6 +32,56 @@
 - `if`、`else`、`for`、`foreach`、`while`、`do` 等控制语句必须使用 `{}`，即使语句体只有一行也不得省略。
 - 所有方法必须完整书写方法体和 `{}`，禁止使用表达式体（`=>`）等省略写法。
 
+## 面向对象设计六大原则（辅助参考）
+
+以下原则仅用于辅助理解职责、依赖和扩展方式，不作为独立的强制开发规则或验收门槛。以现有开发规则、项目架构、兼容性要求和实际需求为准；存在取舍时，不用六大原则覆盖这些约定。
+
+遇到相关设计问题时按需参考，无需每次开发逐条检查或说明不采用的理由。优先复用项目现有结构，选择最小可行实现；不能仅因某段代码不符合某项原则就要求拆类、增加接口、引入模式或重构。
+
+### 1. 单一职责原则（SRP）
+
+- 一个类或模块应围绕一个内聚职责组织，具有同一类变更原因；不按方法数量或代码行数机械拆类。
+- 展示、业务状态、网络传输和资源加载等独立变化的职责应有明确边界，避免集中到一个窗口、MonoBehaviour 或万能管理器中。
+- 方法围绕一个明确目的组织；可以组合步骤，但不夹带无关副作用。拆分时复用现有模块，避免只有转发作用的空壳层。
+
+### 2. 开闭原则（OCP）
+
+- 对已经确认的变化点，优先通过现有配置、组合、策略或扩展入口增加行为，减少反复修改稳定核心流程。
+- 不为尚不存在的变化预建扩展体系，也不为了消除所有 `if` / `switch` 强行引入模式。
+- 修复缺陷或调整已有行为仍可直接修改源码；涉及公共接口、协议或数据兼容性时，按工作流确认影响并验证现有调用。
+
+### 3. 里氏替换原则（LSP）
+
+- 子类型替换基类型后，必须继续满足调用者依赖的契约：不加强前置条件、不削弱结果保证，并保持基类不变量及约定的失败行为。
+- 不以空实现、无条件抛出“不支持”异常或额外类型判断掩盖不成立的继承关系；无法满足契约时优先组合或拆分能力接口。
+- Unity 生命周期重写必须遵循当前基类的初始化、清理和完成回调契约；不能只看签名相同就认为可替换。对修改影响的基类调用路径做针对性验证。
+
+### 4. 依赖倒置原则（DIP）
+
+- 高层业务规则与易变的底层细节通过稳定契约协作；抽象围绕业务需要定义，不能只是复制底层 SDK 的全部接口。
+- 沿用项目已有接口、事件和公开入口；底层框架不得反向依赖具体游戏业务。程序集方向仍遵循 [架构说明](10-架构说明.md)。
+- 需要隔离网络、平台 SDK、存储等易变实现时，在明确边界使用接口、委托或现有桥接机制；不要求每个具体类都有接口，不新增无必要的容器或全局服务定位层。
+
+### 5. 接口隔离原则（ISP）
+
+- 调用方只依赖自己需要的能力；不要让实现类因一个大接口被迫提供无关方法或无效实现。
+- 按内聚的角色与能力拆分接口，避免万能接口；也不机械拆成大量单方法接口。
+- 扩展共享接口前检查所有实现者与调用者，评估兼容性；独立能力优先使用独立契约，不随意给既有公共接口加成员。
+
+### 6. 迪米特法则（LoD，最少知识原则）
+
+- 模块通过直接协作对象的公开能力完成工作，避免穿透多个对象的内部结构、任意修改其他模块状态或依赖易变的深层节点路径。
+- 优先通过项目现有管理器入口、查询方法或事件交互，减少对他人内部实现的了解；合法的数据读取和集合访问不因调用链长就机械包装。
+- 不为了缩短调用链添加无意义的转发层，也不把所有调用改成全局事件或单例。状态由所属模块维护，生命周期与事件解绑责任必须明确。
+
+### 辅助使用边界
+
+- 需要分析职责或依赖问题时，可借助相关原则判断；不要求逐项打勾，不靠类名或模式数量评价代码，也不把完全符合六大原则作为完成条件。
+- 不顺带重构无关历史代码；发现既有问题时说明影响，只有阻碍当前需求且获得对应范围授权时才调整。
+- 原则与现有开发规则、兼容性、性能或交付范围发生取舍时，以当前规则与实际需求为准；仅对影响本次行为或维护成本的实际取舍作必要说明。公共接口和架构调整仍遵守 [工作流清单](40-工作流清单.md)。
+- Unity 中同时核对序列化、Prefab 引用、生命周期、资源释放与目标平台限制；原则不能成为破坏这些约束的理由。
+- 验证与改动匹配：检查受影响的调用者和实现者，必要时验证替换行为、边界失败路径及资源清理。文档检查或编译通过不代表运行时契约已经得到验证。
+
 ## 框架与业务边界
 
 - 业务代码通过 `HFFunCatalogue` 等统一入口访问资源、UI、场景和其他框架能力。

rules/40-工作流清单.md

@@ -22,7 +22,7 @@
 4. 搜索调用入口、数据流、Prefab、配置、生成器和测试方式。
 5. 按 [架构说明](10-架构说明.md) 确认修改对象是真实源码还是生成结果。
 
-无法从仓库发现的信息才向用户确认。已有修改默认属于用户，必须保留并在其基础上工作。
+实现信息优先从仓库核实，无法发现时再向用户确认。需要开发者决定的需求不以现有配置代替确认：UI 目标分辨率与适配要求遵循 [界面拼接](../modules/frameworks/UI窗口系统/界面拼接.md)，项目已有 CanvasScaler 配置只能作为参考，开发者已明确确认的信息不重复询问。已有修改默认属于用户，必须保留并在其基础上工作。
 
 ### 2. 分析与确认
 
@@ -71,6 +71,16 @@ dotnet build GameHF.csproj --no-restore -v:minimal
 
 其他程序集按实际改动替换项目文件。构建结果需区分既有警告和本次新增错误。
 
+### 5.1 错误报告、环境修复与重新验证
+
+- 始终让开发者明确看到哪里出错、哪里缺少内容：发现错误或缺失时，及时说明具体位置、实际证据、影响范围和当前状态；原因尚不确定时明确标为待定位，不能猜测为已知原因。
+- 处理顺序为：发现并报告问题 → 定位原因 → 修复 → 重跑失败步骤 → 完成受影响的必要验证。不得吞掉错误、静默跳过步骤、用假数据或替代结果掩盖失败，也不能把已知错误说成验证通过。
+- 验证环境不可用时，必须先诊断并修复与本次验证有关的环境，再继续验证；不能只以“环境不可用”结束工作并宣称任务完成。按现有项目版本和配置做必要修复，不顺带升级、重装或重配无关环境，不清除用户工作。
+- 区分既有错误与本次新增错误；既有错误阻碍本次验证时也必须报告并处理。超出已授权范围的修复，先定位并说明必要操作与影响，再取得相应授权；能在现有授权内完成的修复直接推进。
+- 修复依赖账号、许可证、外部服务恢复或用户操作而无法自行完成时，明确具体阻塞、已尝试的修复和所需操作，保持相关验证未完成，不能虚报成功；条件恢复后继续修复与验证。
+- 环境恢复后重新确认目标工程和环境身份，重跑原失败步骤及受影响的必要检查。命令超时或执行结果未知时，先核实日志与产物，确认未执行或失败后再重试，避免重复修改。
+- 验证范围按实际改动确定，确实不适用的检查说明原因；缺少环境或验证失败不能归为“不适用”。检查脚本执行成功不代表编译、视觉、交互或设备验证通过。
+
 ### 6. Unity 与 MCP 验证
 
 需要 Unity 自动化时：
@@ -80,7 +90,7 @@ dotnet build GameHF.csproj --no-restore -v:minimal
 3. 调用 `unity_get_console_logs` 检查新增 Error 和关键 Warning。
 4. Prefab/UI 任务继续做结构与实际显示验证，不能以“文件已生成”作为完成条件。
 
-连接失败时停止后续 Unity 命令并报告原因，不假设命令已经执行。
+连接失败时停止依赖该连接的后续操作，按上节完成错误报告与环境修复；连接恢复并确认目标工程后再继续验证，不假设失败或超时的命令已经执行。MCP 的连接、Domain Reload 与超时取证细节见 [MCP 使用规则](../modules/frameworks/编辑器工具/MCP工具/Codex_Unity_MCP使用规则.md)。
 
 ### 7. 文档同步
 
@@ -118,6 +128,7 @@ dotnet build GameHF.csproj --no-restore -v:minimal
 - [ ] 相关程序集编译通过。
 - [ ] Unity Console 无本次新增错误。
 - [ ] UI/Prefab 或平台行为完成实际验证。
+- [ ] 错误、缺失和阻塞均已明确报告；必要的环境修复及重新验证已完成，没有把未完成或失败的检查当作通过。
 - [ ] 长期文档按影响同步，没有写入流水账。
 - [ ] 两个仓库状态分别检查，未触碰用户无关修改。
 - [ ] 未经明确要求没有提交或推送。