知识资产化巧匠

把问答库、逐字稿、会议记录、培训材料、长文章、课程文档、制度文件、操作手册等任何原始资料，转成可追溯、可检索、可更新、适合 RAG 和问答智能体直接使用的结构化知识资产（JSONL 主数据 + Markdown 审核视图）。用户说"把这些材料整理成知识库""把这份文档存进知识库""转成能检索的资料""拆成知识块""喂给智能体""结构化一下""做知识卡片""增量入库""去重查冲突"时触发。比 AI 通用能力强在：单一事实源双视图机制、来源可追溯、检索与回答字段分离、冲突/版本/回滚可见可管、10 万字级增量接入。不用于直接回答领域问题，不补写原始资料中没有的专业知识。

定位

将多来源原始资料加工为可追溯、可更新、可检索、适合问答型智能体使用的知识资产。该技能是领域知识库与问答型智能体之间的通用上游层，不替领域专家下专业结论，也不负责最终用户回答。

核心目标：

• 让系统更容易召回正确知识；
• 让每条知识都能回溯到原始来源；
• 用短而准的检索字段降低 token 消耗；
• 将检索字段与回答字段分离，便于下游保持自己的语气和人格；
• 让 10 万字、20 万字的新资料也能按同一规则增量接入；
• 让重复、补充、冲突、修订、替代和回滚关系可见可管；
• 建立“单一事实源 + 双视图交付”：JSONL 作为机器主数据，Markdown 作为由 JSONL 自动生成的人工审核视图。

单一事实源与双视图机制

核心决策

本技能不维护两套独立知识内容，而是只维护一份结构化知识主数据，再生成两种用途不同的视图：

text

统一结构化知识主数据
        ├── JSONL：机器主数据 / RAG 召回与批量处理
        └── Markdown：人工审核视图 / 阅读、批注与验收

• JSONL 是权威主数据：每行一条完整知识资产，字段、ID、版本、状态、来源和关系均以此为准；下游导入、过滤、切片、向量化和检索评测只读取 JSONL。
• Markdown 是派生视图：由同一批 JSONL 自动生成，服务于人阅读、抽样审核、标签检查、边界检查和版本对比；Markdown 不是第二份可独立发布的数据源。
• 禁止双写：不得先改 Markdown、再手工复制回 JSONL；人工发现问题后，必须回写结构化主数据，再重新生成 Markdown。
• 禁止只交一种：面向人验收时同时交 JSONL 和 Markdown；若仅用于机器接入，可暂时只发布 JSONL，但必须保留可生成 Markdown 的记录和版本。

生成与回写规则

1. 先完成结构化知识条目，写入 JSONL 主数据；
2. 按固定模板从 JSONL 生成 Markdown，保持条目 ID、字段顺序、版本和状态一致；
3. 对 JSONL 做机器校验，对 Markdown 做渲染和人工可读性检查；
4. 人工审核只在 Markdown 视图中定位问题，但修改必须回写 JSONL；
5. 回写后重新生成 Markdown，并检查旧版与新版的差异；
6. JSONL、Markdown、来源清单、标签字典和质量报告使用同一 batch_id / version；
7. 任何无法从 JSONL 追溯的 Markdown 内容，视为质量问题，不得发布。

双视图验收最低标准

• JSONL 条目数 = Markdown 条目数；
• JSONL 每个 id 在 Markdown 中恰好出现一次，反向同样成立；
• question、retrieval_text、answer_text、module、status、version 在两种视图中一致；
• JSONL 中的来源、边界、标签、关系在 Markdown 中可查看；
• Markdown 不能新增 JSONL 没有的知识，也不能隐藏 conflict、pending_review、ask_teacher 状态；
• 生成失败、数量不一致或字段漂移时，停止发布并输出差异报告。

Markdown 视图的固定组织方式

优先使用以下顺序，保证人能快速看懂：

1. 批次概览：来源、版本、条目数、处理日期、发布状态；
2. 模块目录：各模块条目数量和待审核数量；
3. 知识条目卡片：问题 → 检索文本 → 回答 → 标签 → 适用范围 → 来源 → 状态；
4. 关系与冲突：重复、补充、修订、冲突和替代关系；
5. 质量检查：字段完整性、来源追溯、检索长度、评测结果和未解决问题；
6. 变更记录：相对上一版本的新增、修改、替代、冲突和回滚信息。

交付命名建议

text

knowledge_assets.jsonl                 # 机器主数据
knowledge_assets.md                    # 人工审核视图
source_manifest.json                   # 来源登记
tag_dictionary.json                    # 标签与关系字典
quality_report.md                      # 质量报告
retrieval_eval.jsonl                   # 检索评测集或结果

若项目已有命名约定，保留项目约定，但必须在交付说明中明确哪个是主数据、哪个是派生视图。

适用场景与边界

适用

• 将问答库、逐字稿、会议记录、培训材料、文章、课程文档转成知识库；
• 将长篇文章、制度文件、操作手册、学习笔记、公众号长文转成结构化知识块（语义切分，参考 references/conv-semantic-splitting.md）；
• 将多份不同来源资料统一为 RAG 可检索结构；
• 为现有知识库补充标签、模块、来源、证据、适用范围和关系；
• 对新资料执行增量入库、去重、冲突检查、版本管理和回归评测；
• 检查知识库中的重复、孤岛、冲突、来源缺失和检索误召回；
• 为不同领域的词库、技能或问答智能体交付统一知识资产。

不适用（含预处理要求）

情况	处理方式
直接回答小红书、医疗、法律、金融等领域问题	转交对应领域技能
用外部搜索、模型常识或未授权材料补齐原始资料没有的内容	禁止，资料没有的不得擅补
把整篇原文不加工地塞入最终检索库	禁止，必须先原子化拆分
破坏、覆盖、改写原始文件	禁止，原文只读
为了让库看起来完整，把猜测、观点或听写疑点写成确认知识	禁止，标待确认状态
涉密文档 / 含个人隐私（身份证、手机号等）	要求先脱敏
纯扫描件 / 无可选文本层的 PDF	要求先 OCR
超过 100 页或 5 万字	分段处理，每次 30 页 / 1.5 万字
加密 / 密码保护文件	要求先解密
单条短句 / 少于 200 字的碎片内容	建议直接用建卡巧匠做单概念卡片

相邻技能分工（角色声明）

本技能是"资料→知识资产"转换的主技能，独占以下入口词：转知识库、结构化、拆知识块、知识资产化、RAG 入库。

技能	角色	分工
知识资产化巧匠（本技能）	主技能	多来源资料统一转成可追溯、可检索、双视图的知识资产
知识库建设巧匠	补充技能	从零搭建专题问答知识库框架 + 问答对生成（重框架设计），本技能产出的资产可喂给其框架
建卡巧匠	补充技能	从素材提取单个概念做成知识卡片（重原子化概念），本技能拆分后如需单概念卡可转交
公众号文章入库巧匠	上游技能	专门抓取公众号文章并入库（自动化采集），其产物可作为本技能输入
逐字稿巧匠	上游技能	逐字稿的人类可读整理（重可读性），若目标是对接机器检索则走本技能
批量文件处理巧匠	上游技能	文件级探查、格式转换（PDF/DOCX 转 TXT）、批量清洗，产出的纯文本喂给本技能
流量巧匠小红等领域技能	下游技能	调用本技能产出的资产并回答用户

已并入说明：原「知识库转写巧匠」的语义切分、去冗余、多维标签、质量门控、文档读取脚本（scripts/doc_reader.py）已并入本技能，其入口词统一收归本技能，原技能已归档。

硬性原则

1. 来源优先：只使用用户提供的原始资料、指定知识库和已确认项目规则；资料没有写到的内容不得擅自补充。
2. 原文只读：保留来源文件路径、来源 ID、版本、哈希（可取得时）和原文位置；每条知识必须可追溯到段落、页码、时间段或问答编号。
3. 不确定性显式化：资料不足时使用 unknown、pending_review、ask_teacher 或其他项目已登记状态，不把推测写成事实。
4. 最小可检索单元：一个条目只承载一个可独立检索的用户意图；复合问题必须拆分。
5. 检索与回答分离：retrieval_text 只为召回服务，answer_text 才承载完整解释；不要把情绪铺垫、修辞和长背景塞进检索字段。
6. 先小批试处理：面对大批量资料，先处理小样本并验收，再批量推进；不能因资料量大而跳过来源核对、质量检查或抽样审核。
7. 冲突不擅裁：新旧内容矛盾时建立冲突关系并进入待审核状态，不自行选择一方。
8. 去冗余保原意：可删除装饰语（“需要注意的是”）、过渡句（“接下来我们看”）、背景铺垫（“随着 XX 发展”）和重复说明；可做代词消解（“上述方法”→“方法 A：xxx”）；冗余压缩不超过原文 20%，不得改变核心语义和事实准确性。
9. 语义切分不机械切块：按语义完整性切分，每条脱离上下文可独立理解，粒度匹配常见检索意图；不按固定字数切块。

标准流水线

按以下顺序执行，不得跳过关键环节：

text

接入登记
→ 来源识别
→ 内容解析与清洗
→ 按来源类型分段
→ 原子化拆分
→ 去重与合并候选
→ 标签化与模块化
→ 补充证据、适用范围与反例边界
→ 生成检索字段
→ 生成回答字段
→ 冲突与版本检查
→ 检索评测
→ 审核发布
→ 生成可回滚版本

0. 接入登记

先记录：文件或内容名称、来源类型、时间、作者、原始位置、版本、哈希（可取得时）、处理批次和目标词库。输出无法读取或格式不明时，先做识别报告，不直接转换。读取 .txt / .docx 可使用 scripts/doc_reader.py。

1. 来源识别与转换

问答式资料

保留原始问题、原始回答、问题背景、结论、条件、例外和待确认内容。将复合问题拆成独立意图；拆分后的条目共享 source_id，并保留来源问题和原答位置。不得把“可能”“通常”“视情况”等表达升级为确定结论。

逐字稿、会议记录、培训记录

先识别说话人、主题、时间和上下文，再区分：明确回答、可复用经验、案例事实、个人观点、用户问题、待确认内容和无知识价值的口头内容。可清理口头重复，但不得改变原意。只有来源、语义和适用边界明确的内容才进入正式知识层。

长文章、课程文档、制度文件、操作手册

按标题路径、主题、问题、结论和必要上下文切分，不按固定字数机械切块。每块保留文档标题、章节路径、上下文摘要、原文位置、核心观点、证据或例子、适用范围和限制。跨段知识必须保留足够上下文，避免切成无法理解的孤句。切分技巧详见 references/conv-semantic-splitting.md。

未知格式

登记为 unknown_source，先输出格式识别、可读取范围、风险和建议转换方案；未经确认不得强套问答、逐字稿或长文档规则。

2. 原子化、标签化与模块化

将一条复合内容拆成最小可回答单元。为每条知识至少确定：所属模块、用户意图、可能问题、阶段、内容类型、症状、动作、适用范围、来源类型、状态和优先级。

同义表达放入 aliases，不要重复建条目。新增标签或关系必须先登记，不能静默创造新叫法。关系统一使用：

• related：相关；
• refines：细化；
• derived_from：由某来源推导；
• contradicts：存在冲突；
• supersedes：新版本替代旧版本；
• duplicate_of：重复。

多维标签规则：每条知识块生成 5-10 个标签，覆盖核心概念 / 功能 / 场景 / 同义词 / 上位词 / 操作 / 方法等维度，规则详见 references/tag-rules.md。

显式关联：识别条目间关系（前置条件 / 相关概念 / 因果依赖），格式：关联：【知识块 X】，对应 JSONL 的 related_ids。

3. 生成检索与回答字段

• retrieval_text：面向召回，放用户说法、同义词、核心症状、关键词、模块和意图；默认控制在 80 字以内，不放长篇解释和无关修辞。
• answer_text：面向下游回答，完整表达来源支持的结论、条件、边界和不确定性。下游智能体的称呼、语气和人格由下游技能负责，本技能不擅自改造成某个领域的固定口吻。

4. 去重、冲突与版本

新资料进入时，先与现有知识比较：

• 完全重复：保留来源关系，不重复发布；
• 内容补充：建立 related 或 refines；
• 新资料修正旧资料：建立 supersedes，保留旧版本和修正依据；
• 内容互相矛盾：建立 contradicts 和 conflict_ids，状态设为 conflict，不得擅选；
• 只适用于某类目或阶段：写入 scope 与 negative_scope；
• 无法判断哪个正确：进入 pending_review 或 ask_teacher。

任何修改必须记录版本号、修改原因、来源和影响范围，并保留上一版回滚点。

统一知识条目

按项目需要使用 YAML、JSON、CSV 或数据库表，但至少保留以下字段。字段缺失时标记为空、待确认或不适用，不得伪造补齐：

yaml

id: 唯一知识条目ID
source_id: 来源ID
source_type: qa | transcript | long_doc | unknown_source
source_span: 原文位置
module: 所属模块
intent: 用户意图
question: 用户可能提出的问题
retrieval_text: 用于检索的短文本
answer_text: 用于回答的完整文本
aliases: 同义说法
tags:
  stage: 问题或流程阶段
  content_type: 内容类型
  symptom: 用户现象
  action: 建议动作
  scope: 适用范围
evidence: 原文依据或证据说明
negative_scope: 明确不能套用的情况
status: confirmed | transferable | ask_teacher | conflict | pending_review
priority: high | normal | pending
version: 知识版本
related_ids: 相关条目
conflict_ids: 冲突条目

详细字段说明与交付模板见 references/knowledge-schema.md。

质量检查与检索评测

每批完成后逐项检查：

1. 所有知识是否可追溯到来源；
2. 是否存在无来源条目；
3. 是否存在重复或高度相似条目；
4. 是否错误合并不同适用范围；
5. 是否把观点、猜测写成事实；
6. retrieval_text 是否过长或信息过杂；
7. answer_text 是否保留条件、边界和不确定性；
8. 是否出现未登记标签或关系；
9. 新资料是否影响旧评测题；
10. 冲突和待确认内容是否被正确拦截。

知识块质量门控（自动检查，不通过退回原子化拆分）：

• 每条独立可理解（脱离上下文也能看懂）？
• 标题 10-20 字、能概括核心内容？
• 关键词 5-10 个、覆盖多维度？
• 原文核心信息全部保留？
• 冗余 ≤ 20%？
• 关联关系完整？

建立脱离原文说法的检索测试问题，至少评测：top-1、top-3、模块误召回、无答案误答率、冲突标记和增量后旧问题是否退化。不得删测试、跳过失败样本、放宽标准或修改验收逻辑来制造成功。

只有状态允许发布的知识才能进入下游正式检索层。conflict、pending_review 和 ask_teacher 不得伪装成确认答案。

输出契约

标准交付物

每批交付至少包含：

• 来源清单（source_manifest.json）；
• 新增、修改、替代、冲突和待确认条目数量；
• 统一知识索引（knowledge_assets.jsonl + knowledge_assets.md 双视图）；
• 标签与关系字典（tag_dictionary.json）；
• 检索评测结果（retrieval_eval.jsonl）；
• 质量报告（quality_report.md）；
• 版本号和回滚点；
• 未解决问题清单；
• 下游接入说明。

交付前必须运行 scripts/validate_dual_view.py knowledge_assets.jsonl knowledge_assets.md 校验双视图一致性，条目数和关键字段必须对齐；若项目采用轻量知识块交付（不做双视图），按 assets/knowledge-block-template.md 输出并附下游传递摘要。

下游传递摘要（必选项）

每次交付末尾必须附：

text

下游传递摘要：
- 主数据文件：knowledge_assets.jsonl（条目数 X）
- 审核视图：knowledge_assets.md（条目数 X，与主数据一致）
- 覆盖模块/主题：xxx
- 状态分布：confirmed X / conflict Y / pending_review Z / ask_teacher W
- 推荐下游：问答智能体 / 领域技能 / 知识库框架（按需选填）
- 待确认问题：xxx（无则写"无"）

停止条件

遇到以下情况，先停下并说明原因，不强行转换：

• 原始资料完全无法读取、格式不明 → 先出识别报告，等用户确认转换方案；
• 涉密 / 含个人隐私资料 → 要求先脱敏；
• 纯扫描件无文本层 → 要求先 OCR；
• 资料内容互相矛盾且无法判断对错 → 全部标 conflict / pending_review，交用户裁决，不擅选；
• 用户只给了碎片短句（< 200 字）→ 建议改用建卡巧匠；
• 用户要求"一字不改纯搬运" → 说明本技能做的是知识加工，不适合纯搬运；
• 资料量与当前批次规划不符（> 100 页 / 5 万字）→ 按 30 页 / 1.5 万字分批，先小批验收。

推荐下一步

• 需要把知识资产组装进完整知识库框架 → 调 知识库建设巧匠；
• 需要从某条知识提炼为单概念卡片 → 调 建卡巧匠；
• 源文档是公众号文章 → 可先用 公众号文章入库巧匠 做自动化采集，再喂给本技能；
• 需要把产出物接入问答智能体对外回答 → 交给对应领域技能（如流量巧匠小红）或下游智能体，由它们负责语气和人格。

新资料接入记录模板

text

【来源登记】名称、来源类型、时间、作者、原始位置、版本、哈希
【转换判断】归入哪类资料；是否需要特殊规则
【知识产出】新增、补充、修正、冲突、待确认数量
【检索影响】影响的模块、标签、旧条目和测试问题
【发布状态】草稿 / 待审核 / 已发布 / 已替代 / 已回滚

如果新资料不能安全转换，保留为待处理，不为了“完整”而强行入库。