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>
182 lines
5.8 KiB
Markdown
182 lines
5.8 KiB
Markdown
# 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**
|
|
|
|
下一轮继续扩，不再需要重做架构判断，直接按样板复制即可。
|