eaiadminandClaude Code
ddd2d2cbd8
- 新增 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>
268 lines
6.7 KiB
Markdown
268 lines
6.7 KiB
Markdown
# 六层架构与三对象建设重点阶段性复盘
|
||
|
||
> 日期：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
|
||
六层架构不变；
|
||
当前优化重点放在第五层对象层与第六层运行治理层；
|
||
先把专员、技能、应用各自做强，
|
||
再在成熟度足够时补关系层和更复杂的协作编排。
|
||
```
|