EaiLab/pj0235-eai_agentplatform
11
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
9157df40f3ea9b2b5d1a576666e274d3656570d7
pj0235-eai_agentplatform/docs/AionUi助手到pj0235三层映射表与首个样板方案.md
T
eaiadminandClaude Code 14f303459e refactor: 后端仓库层收口（A1：课程/产品/素材）+ 收进工作区既有对象化重构 
本提交含两部分。第一部分是本轮工作；第二部分是此前一直留在工作区、
从未提交的对象化重构，与第一部分在文件上互相咬合（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>
2026-09-19 01:23:51 +08:00

5.8 KiB
Raw Blame History

AionUi 助手到 pj0235 三层映射表与首个样板方案

目标：不是继续泛读，而是把 AionUi 的助手体系拆成 pj0235 可落地的三层结构：

  • 专员：负责任务理解、规则约束、流程编排
  • 技能：负责真正执行与产物生成
  • 应用：给用户一键即用的成品入口

一、迁移原则

  1. 不学 Electron 壳 只学 AionUi 的助手封装方法、技能包方法、交付闭环方法。

  2. 优先办公生产力 绘画、故事、3D 游戏、社交发布类全部后置。

  3. 先做一个样板，再批量复制 第一个样板选 汇报 PPT，因为它最能验证：

    • 应用入口
    • 专员规则
    • 技能执行
    • 产物沉淀
    • 项目复用

二、AionUi 21 个助手 -> pj0235 三层映射

AionUi 助手 AionUi 类型判断 pj0235 专员映射 pj0235 技能映射 pj0235 应用映射 优先级 备注
Cowork 通用任务编排 通用助手 / 流程推进专员 smart-assistant 开场工作台 高 保留为总入口，不单独产品化
PPT Creator 办公交付 汇报专员 ppt-generation 汇报 PPT 高 第一优先样板
Morph PPT 演示增强 汇报专员 ppt-generation 汇报 PPT 中 可作为二阶段增强
3D Morph PPT 演示增强 汇报专员 ppt-generation 汇报 PPT 低 当前办公价值不高
Pitch Deck Creator 商务演示 售前方案专员 / 汇报专员 ppt-generation + proposal-summary 售前汇报 高 和汇报 PPT 共骨架
Dashboard Creator 数据展示 报告生成专员 table-cleanup / ppt-generation 数据看板汇报 中 适合第二批
Word Creator 办公交付 报告生成专员 longform-writing 方案 / 报告写作 高 第二个建议样板
Word Form Creator 表单模板 报告生成专员 / 流程推进专员 longform-writing 表单模板 中 可在 Word 样板后复制
Excel Creator 数据整理 报告生成专员 table-cleanup 表格整理 高 第三个建议样板
Academic Paper 长文结构化 报告生成专员 longform-writing 长文写作 中 偏长文，不是最先做
Financial Model Creator 数据模型 报告生成专员 table-cleanup 数据分析 中 适合财务线后补
Beautiful Mermaid 结构表达 汇报专员 / 方案专员 mind-map 思维导图 中 已有基础能力
Planning with Files 文件驱动规划 流程推进专员 project-planning 项目规划 高 很适合你当前项目制工作台
AionUi Butler 系统内管家 通用助手 smart-assistant 无 低 更偏产品自运维
OpenClaw Setup Expert 环境配置 无 无 无 低 当前不做
HUMAN 3.0 Coach 人类教练 / 反思 流程推进专员 progress-report 项目复盘 低 不做第一批
UI/UX Pro Max 设计创作 无 无 无 低 不属于办公主线
3D Game 创作娱乐 无 无 无 低 排除
Social Job Publisher 社交发布 公众号助手 longform-writing / copy-proofreading 内容发布 低 不是当前重点
moltbook 内容/创意类 公众号助手 longform-writing 内容应用 低 不是当前重点
Story Roleplay 娱乐/角色扮演 无 无 无 低 排除

三、推荐的第一批可迁移办公骨架

第一梯队

  1. 汇报 PPT
  2. 方案 / 报告写作
  3. 表格整理
  4. 项目规划
  5. 方案摘要

第二梯队

  1. 思维导图
  2. 表单模板
  3. 数据看板汇报
  4. 长文写作

后置

  1. 创意类
  2. 娱乐类
  3. 社交发布类
  4. 系统配置类

四、首个样板为什么选“汇报 PPT”

原因很直接：

  1. 最像 AionUi 的强项
  2. 最容易体现办公交付价值
  3. 最适合拉通“专员 + 技能 + 应用”三层结构
  4. 后续能平滑复制到 Pitch Deck、方案汇报、培训课件

五、首个样板的目标形态

应用层

  • 名称：汇报 PPT
  • 用户入口：应用广场直接打开
  • 默认行为：
    • 自动切到工作台
    • 自动挂上 汇报专员
    • 自动挂上 ppt-generation
    • 自动带入默认提示词

专员层

  • 名称：汇报专员
  • 职责：
    • 理解汇报目标
    • 压缩材料
    • 规划页数
    • 组织每页要点
    • 收口讲稿备注

技能层

  • 主技能：ppt-generation
  • 辅助技能：
    • proposal-summary
    • mind-map
    • progress-report

六、这次已落地的样板改动

本轮直接落代码，完成了下面几件事：

  1. 新增 汇报专员

    • 前端目录卡片
    • 后端种子数据
    • 岗位说明书规则
    • 绑定技能清单

  2. 把现有 PPT 生成 成品应用升格为 汇报 PPT

    • 增加默认专员绑定
    • 保留默认技能绑定
    • 优化默认提示词和文案

  3. 让应用入口支持同时挂载

    • xapp_specialist
    • xapp_skill
    • xapp_prompt

  4. 增加项目模板

    • 汇报 PPT
    • 便于后续直接复制第二个、第三个样板

七、后续复制模板

接下来要做第二个、第三个时，不要再重新想结构，直接照这个模板复制：

  1. 新增一个专员
  2. 绑定 2-4 个技能
  3. 新增一个成品应用
  4. 配一个项目模板
  5. 让应用入口默认带上专员、技能、提示词

建议顺序：

  1. 方案 / 报告写作
  2. 表格整理
  3. 项目规划
  4. 方案摘要

八、结论

这一轮的目标不是“把 AionUi 学完”，而是把它拆成可以直接复用的产品方法。

现在路线已经明确：

  • AionUi 学的是助手/技能封装法
  • pj0235 落的是专员/技能/应用三层结构
  • 第一个样板已经确定为：汇报 PPT

下一轮继续扩，不再需要重做架构判断，直接按样板复制即可。

Reference in New Issue View Git Blame Copy Permalink