eaiadminandClaude Code
14f303459e
本提交含两部分。第一部分是本轮工作；第二部分是此前一直留在工作区、
从未提交的对象化重构，与第一部分在文件上互相咬合（internal/repository
整个包都是未跟踪状态，且 api 层已有文件引用它），无法拆成两个可编译的提交。
一、仓库层收口 A1 批（本轮工作）
把 api 层手写的 store.DB 查询收进具名仓库方法，只给真正获益的对象做方法，
不机械包裹全量。本批迁移 22 处裸查询（courses.go 9 / media.go 12 / products.go 1），
新增方法：
- MediaFileRepo.ListByBind / ListForAudit / MarkExtracted
- KnowledgeChunkRepo.CountByMediaFile
- ProductRepo.GetVisibleByID
两条业务口径改由仓库单点持有，避免各处手写漂移：
「只有 approved 素材出现在课程详情」与「已停用产品不在课程详情露出」。
修掉两个真实缺陷：
- ProductRepo.GetByID 缺 Where 条件。此前 GET /api/products/{id} 对任意 id 都返回
第一条产品、对不存在的 id 返回 200，且 PUT /api/products/{id} 会覆盖第一条产品
—— 数据损坏级。全仓扫描确认这是唯一一处同型写法。
- ProductRepo.Delete 写 status="deleted"，而 DELETE 处理器文档与回包都声称
"inactive"，接口在说谎；管理员用 status=all 拉列表会看到前端不认识的状态。
已对齐为 inactive（与 CourseRepo.Delete 一致）。
删除 8 个零调用且列名不存在的死方法（一调即 SQL 报错）：
- media_file 上的 file_path / file_type / approval_status 三列并不存在，
GetByPath / ListByType / UpdateStatus 全废
- knowledge_chunk 上的 space_id 列不存在（模型早已改为 knowledge_space_key），
List / Total / ListBySpaceIDs / DeleteBySpace / SearchByVector 全废
取舍边界：能对当前 schema 跑通的死方法保留，跑不通的删或修。
CourseRepo.List 补齐 status=all 档（此前传给它会当作 status='all' 过滤出空列表）。
该方法此前零调用，现与产品列表语义对齐。
验证：go build ./... 与 go test ./... 全绿；另用真实 HTTP 请求验证 34 项
（课程 17 / 产品 3 / 素材 14），跑在数据库副本与独立 KB_DATA_DIR 上，
含 multipart 真上传 → 审批 → pdftotext 提取 → 分片入库的完整链路。
二、此前未提交的对象化重构（非本轮工作）
- 新增 internal/repository 仓库层、connectors、skills、specialists、xapps、jsonutil，
model/task_record|task_run|task_artifact、api/task_runtime|action_definition|chat_message
- 删除 api/app_definition、connectors、my_app_center、notification、office_skill、
export_docx|pptx|xlsx、official_account_* 等，随 XApp/Skill/Specialist/Connector
可插拔打包方向（AR10/AR11）调整
- 资产目录归位：backend-go/knowledge_source → assets/knowledge/source、
training_materials → assets/training/materials；README 内相对路径同步加深两级；
deploy env 补 ASSET_ROOT_DIR 并改 KNOWLEDGE_SOURCE_DIR / TRAINING_MATERIALS_DIR
- 前端新增 skills/ specialists/ connectors/ xapps/ 目录与对应页面
验证：前端 npm run build 通过（7.26s）。
Co-Authored-By: Claude Code <noreply@anthropic.com>
6.4 KiB
对象标准化与解耦总则
一、目标
这个项目后续不再围绕“某个页面怎么写”来扩能力， 而是围绕三类核心对象做长期演进：
- 专员
- 技能
- 应用
目标不是把功能堆起来，而是把这三类对象做成：
定义稳定
+ 关系清晰
+ 数据源唯一
+ 前后端解耦
二、统一结构
三类对象以后都按同一种思路建模：
对象定义 + 绑定关系 + 运行态数据
1. 对象定义
定义“这个对象是什么”。
必须由后端保存，前端只能消费，不能再本地拼真数据。
对象定义至少要包含这几类字段：
keylabeldisplay_codeeailogic_codetierworker_typesourcesummarystatesort_order
如果是面向用户展示的对象，还要有：
badge / market_tagcoloricon_textcover_tone
2. 绑定关系
定义“它和谁有关系”。
以后不要再把绑定关系散在 prompt、seed 文本和前端配置里。
关系必须可显式表达，比如：
- 专员绑定哪些技能
- 应用默认挂哪个专员
- 应用默认挂哪些技能
- 对象能打开到哪个入口
3. 运行态数据
定义“这次执行过程中发生了什么”。
这层和目录定义分开，不能混。
例如：
- 当前任务挂了哪个专员
- 当前会话挂了哪个技能
- 当前用户收藏了哪个应用
- 最近使用了哪些应用
- 任务执行过程产出了什么文件
三、三层职责
1. 专员
专员只负责：
- 理解任务
- 拆解步骤
- 决定何时调用技能
- 决定输出的协作方式
专员不是技能，也不是应用入口。
专员的本质是：
规则层 / 编排层 / 协作层
2. 技能
技能只负责：
- 执行动作
- 接收输入
- 产生结果
- 输出产物
技能不负责“扮演谁”，也不负责“对外怎么卖”。
技能的本质是：
执行层 / 工具层
3. 应用
应用只负责：
- 面向用户提供一键入口
- 预装默认专员
- 预装默认技能
- 预装默认提示词
应用不应该承载规则本体，也不应该直接替代技能。
应用的本质是：
产品化入口层
四、解耦原则
原则 1：后端是唯一目录源
以后目录对象必须以后端表为准。
前端只能做：
- 请求
- 归一化
- 渲染
前端不能再承担：
- 正式编号生成规则
- 正式目录维护
- 对象真数据拼装
原则 2：页面不能成为数据源
目录页、详情页、加号菜单、聊天胶囊都只能消费 store， 不能各自再维护一份对象数组。
原则 3：配置文件不能充当生产目录
配置文件最多只允许承担：
- fallback
- 样式增强
- 本地 demo
不能承担：
- 生产目录
- 正式编号
- 主入口映射
原则 4：对象定义和用户态分离
全局对象属于系统目录。
用户收藏、最近使用、自定义应用，属于用户态。
这两层必须分开：
系统目录 != 用户偏好 != 运行态挂载
原则 5：编号必须系统化
编号不是前端算出来的临时 UI 字符串， 而是正式对象属性。
统一规则：
- 专员：
专 / EAI-S- - 技能：
能 / EAI-K- - 应用：
应 / EAI-A- - 连接器：
连 / EAI-C-
五、标准对象视图
前端消费对象时，应尽量收敛到统一视图，而不是每类对象各起一套随意字段。
建议统一成：
CatalogObjectView
- key
- type
- label
- displayCode
- logicCode
- badge
- tier
- workerType
- summary
- color
- iconText
- coverTone
- openRoute
- state
- sortOrder
扩展字段可以挂在各自域内，但公共展示层尽量对齐。
六、绑定关系标准
后面不再继续把绑定关系藏在自由文本里。
应该逐步补成显式关系：
specialist_skill_bindingxapp_specialist_bindingxapp_skill_bindingspecialist_connector_binding
最终应该形成：
对象定义表
+ 对象关系表
+ 运行态任务表
而不是：
对象定义表
+ seed 里一段字符串
+ 前端里一段数组
+ prompt 里再提一次
七、后续开发规则
以后新增一个专员、技能、应用，顺序必须是：
- 先定义它属于哪一层
- 再写后端对象定义
- 再补绑定关系
- 最后前端消费目录
禁止反过来：
- 先在前端做个入口
- 再在页面里写死配置
- 最后再考虑后端有没有这对象
八、当前项目的正确方向
这个项目后续最重要的不是再多做几个按钮， 而是把平台真正推进到：
专员层
+ 技能层
+ 应用层
+ 连接器层
四层稳定分离、统一建模、统一编号、统一目录源。
这样后面不管是对标 AionUi、MyGPT，还是继续扩办公生产力能力， 都不会再陷入“每扩一个能力，就前后端各写一遍”的结构性债务。
九、当前阶段判断
虽然长期结构上仍然需要关系层， 但当前阶段不要把“复杂绑定关系”当成第一优先级。
原因不是这个逻辑不成立， 而是当前对象成熟度还没有到那一步：
- 专员还没有形成稳定、强编排能力
- 技能还没有强壮到值得被专员大量调用
- 应用当前更像产品化入口，而不是复杂能力编排器
所以当前更符合实际的推进顺序是：
1. 先把对象本身做强
- 专员先做成稳定对象：有身份、有规则、有入口、能承接任务
- 技能先做成强能力：单独使用就有价值，输入输出稳定，结果可靠
- 应用先做成强入口：打开就能用，能直接产出，不强求复杂编排
2. 暂时不为了“结构漂亮”提前过度设计关系层
现阶段不要把大量精力投到：
- 专员大量调用技能
- 应用绑定复杂技能树
- 为了理论完整性提前拆很多关系表
如果对象本身不强，关系层只会变成空架子。
3. 关系层仍然重要，但属于下一阶段
当下面几件事开始稳定出现时，再提高关系层优先级：
- 一个专员开始稳定复用多种技能
- 一个技能被多个专员反复复用
- 一个应用需要切默认专员或默认能力组合
- 后台出现真实的配置、运营和灰度需求
所以当前项目的阶段性原则是：
先强对象，再补关系
先做成立，再做复杂协作
这条判断优先级高于“结构看起来够不够完整”。