docs: 对象命名规范 AR09 与标准化讨论文档入库

- 新增 docs/02_Architecture/AR09_Object_Naming_Standard.md（规范性文件，非设计稿）：
  十节结构 —— 原理 / 判据 / 对象术语表 / 五层命名规范 / 命名模式库 /
  如何检查（人工五问 + 6 个机器守卫）/ 如何修复（迁移顺序 + 改名六步法）/
  现状问题登记（逐条带 file:line）/ 反例库 / 修订记录。
  核心判断：名称即契约，改名前先查已靠名字建立的协议表
- 02_Architecture/README.md 登记 AR09，并说明其规范性定位（约束新增代码，
  与 TOP_CODING_RULES.md 的 G03 配套），与 AR01–AR08 设计稿区别
- 收入本轮讨论与调研文档：对象命名标准化清单、对象标准化与解耦总则、
  六层架构与三对象建设重点阶段性复盘、目录结构化迁移说明、
  AionUi 对照分析两篇

Co-Authored-By: Claude Code <noreply@anthropic.com>

docs/2026-09-17_六层架构与三对象建设重点阶段性复盘.md

@@ -0,0 +1,267 @@
+# 六层架构与三对象建设重点阶段性复盘
+
+> 日期：2026-09-17
+> 性质：对前序讨论的客观复盘，不替代既有总架构文档
+> 关联文档：
+> - `docs/01_System_Overall/SY21_Unified_Role_Skill_Action_Architecture.md`
+> - `docs/01_System_Overall/SY22_Role_Skill_App_Unified_Task_Architecture.md`
+> - `docs/对象标准化与解耦总则.md`
+
+---
+
+## 一、这份复盘要解决什么
+
+前序讨论中，围绕以下问题进行了多轮来回：
+
+- 现有六层架构是否还成立
+- 专员 / 技能 / 应用三个对象应不应该成为当前建设重点
+- 当前是否需要优先补绑定关系
+- AionUi 的经验应该学到什么程度
+
+这份复盘的目标不是重写总架构，
+而是把前面讨论中哪些判断成立、哪些判断说过头了，正式收口。
+
+---
+
+## 二、已经确认成立的判断
+
+### 1. 当前系统确实处于“后端有对象表，前端曾长期存在静态目录”的混合态
+
+这个判断成立。
+
+虽然近期已经持续推进目录解耦，
+但从整体历史包袱和代码结构看，
+系统前期确实存在：
+
+- 后端有对象模型和接口
+- 前端以静态配置驱动大量真实目录
+
+这也是后续做对象标准化与目录统一的现实起点。
+
+### 2. “先强对象，再补关系”是当前阶段更合理的优先级
+
+这个判断成立。
+
+原因不是关系层不重要，
+而是当前对象成熟度还没有达到“复杂关系优先”的阶段：
+
+- 专员还没有形成强编排能力
+- 技能还没有强壮到值得被大量稳定复用
+- 应用当前更像产品化入口，而不是复杂能力编排器
+
+因此，当前更合理的顺序是：
+
+```text
+先把专员、技能、应用各自做强
+再在成熟度足够时补关系层
+```
+
+### 3. AionUi 最值得学习的是对象资产化，而不是总架构替换
+
+这个判断成立。
+
+当前对 AionUi 的借鉴边界应明确为：
+
+- 学它的助手/员工对象化
+- 学它的规则资产化
+- 学它的技能包思维
+- 学它的运行态工作台思维
+
+不应盲目学习：
+
+- Electron 外壳
+- 个人工具导向产品形态
+- 创意娱乐类助手堆叠
+- 过度端侧逻辑
+
+---
+
+## 三、前序讨论中说过头的地方
+
+### 1. 不能因为三个对象重要，就推导出“应该改总架构”
+
+这个推导证据不足。
+
+三个对象重要，说明：
+
+- 第五层对象层需要做强
+- 第六层运行治理层需要做实
+
+但这并不自动构成“六层架构应被替代”的理由。
+
+要否定既有总架构，至少应出现下列情况之一：
+
+1. 层级职责定义错误
+2. 多层长期重叠、互相冲突
+3. 关键对象在原架构中无法安放
+4. 原架构直接阻碍产品落地
+
+截至本次复盘，没有充分证据表明六层架构已满足上述否定条件。
+
+### 2. “当前建设重点”不能被误说成“主架构发生替换”
+
+更准确的表达应为：
+
+**六层架构不变，当前建设重点落在第五层对象层与第六层运行治理层。**
+
+也就是说：
+
+- 这是架构内聚焦
+- 不是架构替换
+
+---
+
+## 四、关于六层架构的最终判断
+
+## 4.1 六层架构继续成立
+
+`SY21` 与 `SY22` 形成的六层总架构继续有效：
+
+1. 外部连接层
+2. 本体与语义上下文层
+3. 总线与编排层
+4. 能力层
+5. 对象层
+6. 工作台与运行治理层
+
+特别是 `SY22` 已经明确把第五层升级为：
+
+```text
+对象层（Expert / Skill / App）
+```
+
+这说明六层架构本身已经能够容纳“专员 / 技能 / 应用”三类核心对象，
+并不存在“对象出现后就装不下”的结构性问题。
+
+## 4.2 六层架构仍然有意义
+
+六层架构的意义在于它仍然能解释整个平台为什么成立：
+
+- 外部系统如何接入
+- 语义和对象如何统一
+- 能力如何分层
+- 任务如何运行
+- 治理如何落地
+
+因此它仍应继续作为：
+
+- 平台总架构
+- 长期演进底图
+- 文档与治理总语言
+
+而不是被轻易推翻。
+
+## 4.3 当前不需要改架构，当前需要做的是在原架构内把重点层做强
+
+当前最合理的做法不是改层数，
+而是继续在既有六层框架内推进：
+
+- 第五层：对象标准化、对象独立化、对象目录统一
+- 第六层：任务容器、状态、产物、留痕、项目运行统一
+
+第一到第四层仍然成立，
+但当前不应继续投入过多抽象设计精力。
+
+---
+
+## 五、关于三个对象的当前建设重点
+
+### 1. 专员
+
+当前优先级应放在：
+
+- 身份稳定
+- 规则稳定
+- 开场与引导稳定
+- 能承接任务
+
+而不是强求它现在就大量调技能。
+
+### 2. 技能
+
+当前优先级应放在：
+
+- 单独拿出来就有价值
+- 输入输出稳定
+- 结果可靠
+- 产物真实可用
+
+技能不够强时，专员大量调用技能只会放大不稳定性。
+
+### 3. 应用
+
+当前优先级应放在：
+
+- 成为真正可用的产品化入口
+- 拥有清晰主界面
+- 承载状态、结果和留痕
+- 直接解决某类工作场景
+
+当前不应为了结构完整性而要求 App 过早承担复杂编排职责。
+
+---
+
+## 六、关于绑定关系的阶段性判断
+
+绑定关系仍然重要，
+但对当前阶段而言，
+它不是最高优先级。
+
+更准确的判断是：
+
+- 长期看，关系层必须存在
+- 当前看，优先级低于对象本身做强
+
+因此当前应坚持：
+
+```text
+先强对象，再补关系
+先做成立，再做复杂协作
+```
+
+等到以下信号稳定出现时，再提高关系层优先级：
+
+- 一个专员稳定复用多种技能
+- 一个技能被多个专员反复复用
+- 一个应用需要切换默认专员或能力组合
+- 后台出现真实的配置、运营和灰度需求
+
+---
+
+## 七、与 AionUi 的客观比较
+
+当前更准确的比较结论是：
+
+- 我们的六层底座和企业化治理能力，比 AionUi 更完整
+- AionUi 在上层对象资产化、规则资产化、技能包化方面更成熟
+
+因此：
+
+- 不需要因为学习 AionUi 而推翻现有六层总架构
+- 需要借鉴 AionUi 的，是第五层对象层如何做成真正产品资产
+
+换句话说：
+
+**AionUi 更值得学习的是“对象如何做强”，不是“总架构如何重画”。**
+
+---
+
+## 八、本次复盘后的正式结论
+
+本次复盘后，正式收敛为以下判断：
+
+1. 六层架构继续成立，当前没有充分证据否定它
+2. 当前不改总架构，而是在原架构内强化重点层
+3. 当前重点是第五层对象层与第六层运行治理层
+4. 专员 / 技能 / 应用应先各自独立做强
+5. 绑定关系重要，但不是当前第一优先级
+6. 学习 AionUi，应重点学习对象资产化，不应机械替换总架构
+
+最终可统一表述为：
+
+```text
+六层架构不变；
+当前优化重点放在第五层对象层与第六层运行治理层；
+先把专员、技能、应用各自做强，
+再在成熟度足够时补关系层和更复杂的协作编排。
+```