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>
3.1 KiB
3.1 KiB
知识源入库目录（Knowledge Source Ingest）
本目录是「结构化知识源文档」的唯一入库口，与「素材上传流水线」（backend-go/data/kb_data）并行。 数据权威源：
../../../../docs/博昇产品与渠道合作表.md（对齐《客户介绍合作协议》第二条）。
1. 链路
知识源 md（本目录）
│
▼
【摄入 Ingestion】解析 front-matter + 三个固定 section
│
▼
【审批 Audit】pending → approved / rejected
│
│ approved 后拆成三路
├──→ product 表 （status=active，可浏览）
├──→ knowledge_chunk （AI 检索知识）
└──→ question 表 （可考试）
2. 格式契约（强制，摄入脚本依赖此格式）
每个知识源 md 必须包含：
-
YAML front-matter（元数据）：
knowledge_source：权威来源（如「博昇产品与渠道合作表 V1.0」）version：源版本category：产品分类（capital_consulting/qualification_counseling/ai_consulting/ai_tools_platform/general）domain：知识域（company/product/sales），题目组卷按此抽题audit_status：审批态（pending→approved/rejected）
-
三个固定 section（按
##二级标题分块）：## 结构化产品数据→ 摄入product表## AI 检索知识→ 摄入knowledge_chunk表（自然语言段落，供 Go 原生向量/关键词检索 + LLM）## 考试题目→ 摄入question表
3. 题目答案契约（统一 list 形式）
题型 type |
answer 格式 |
|---|---|
judge |
[true] / [false] |
single |
[正确选项索引]（0 起） |
multiple |
[正确选项索引1, 索引2, ...] |
options 为选项文本数组；domain 取 company / product / sales。
4. 审批状态机
pending ──审批通过──▶ approved ──▶ 生效（product active / chunk 入库 / question active）
│
└──审批驳回──▶ rejected（含理由，不生效、不进库、前台不可见）
5. 文件清单
| 文件 | 内容 | category |
|---|---|---|
01_通用规则.md |
结算基数、两档比例、版本更新机制 | general |
02_资本咨询类.md |
产品 1.1–1.3 | capital_consulting |
03_资质认定辅导类.md |
产品 2.1–2.3 | qualification_counseling |
04_AI咨询与实施类.md |
产品 3.1–3.6 | ai_consulting |
05_企业级AI工具与平台.md |
产品 4.1–4.16 | ai_tools_platform |
6. 代码侧已实现（Go）
完整设计见
../../../../docs/04_Backend/BE05_Knowledge_Ingest_Module.md（知识入库体系总设计）。
internal/model/knowledge_source.go—— 知识源文档表internal/model/knowledge_chunk.go—— 来源扩展（media_file_id 可空 + knowledge_source_id）internal/api/knowledge.go—— md 解析 + 摄入 + scan / audit / status- GORM AutoMigrate 自动建表（无需独立 init 脚本）