【核心摘要】
很多企业以为「把Jira 和 Wiki 接上 AI」就算沉淀完了，结果 AI 回答问题时还是说不到点子上。问题不在 AI，在于
**
工单和
Wiki 的原始形态不是给 AI 读的：一条Jira 工单里，标题、描述、评论区混着讨论、变更和结论；一篇 Wiki 里，有效内容和三年前过期的配置说明挨在一起。喂给 AI 之前必须做一次结构化。本文给出四步迁移法：抽取、切分、补上下文、绑定关系，并附上常见字段的映射表。
麦芽
AI**
支持历史资料与工程资料导入，可在导入后按项目维度组织查询；具体支持哪些格式与导入深度，建议用真实资料试点确认。
一句话结论
1.原始工单不是知识：讨论、变更、结论混在一起，
AI 分不清哪个是最终答案。
2.四步迁移：抽取→ 切分 → 补上下文 → 绑定关系，缺一步都会显著掉准确率。
3.麦芽****AI 承接导入后的组织与查询：历史资料与工程资料可导入，按项目沉淀。
一、为什么「接上」不等于「能用」
先看一条典型工单里都有什么：初始描述（可能已经过时）、十几条评论（有人在讨论、有人在改需求、有人提了反对意见最后被采纳）、若干个状态变更、附件里的截图。人能读懂，是因为人知道
**
看最后几条评论、看状态变更到「已完成」时的版本
**
。
AI 不知道，它看到的是一整段文本，很可能把中间被否掉的讨论当成结论。
Wiki 的问题类似，但更隐蔽：
它没有明确的失效标记
。三年前写的部署说明和上周更新的说明并排放在一起，
AI 无法判断哪份还有效，往往会给出过时答案，而且答得很自信。
所以从工具到
AI，中间差的是一次**
结构化改造
**
：把「给人看的时间线」变成「给
AI 查的结论」。
二、四步迁移法
步骤
做什么
产出
常见坑
抽取
从工具里导出工单、文档、提交记录
原始数据集
附件、截图、表格常常导不出来
切分
把长文档按语义切块，把工单拆成「结论」和「讨论」
知识块
切得太碎会丢失上下文，切得太粗检索不准
补上下文
给每个知识块补上项目、模块、时间、负责人
带元数据的知识块
元数据缺失会导致跨项目串味
绑定关系
把知识块挂到需求、模块、接口上
可导航的知识网络
没有关联，检索只能靠关键词碰运气
四步里最容易省掉、也最不该省的是
**
补上下文
**
。同样一句「这个接口不支持批量」，挂在项目
A 的订单模块和挂在项目 B 的用户模块，含义完全不同。缺了项目维度，AI 检索时会把别的项目的情况当成你们项目的答案。
三、常见字段映射表
迁移时，工具里的字段要对应到知识块的元数据上。下面这张表给一个起点，实际按团队的字段习惯调整。
来源工具的字段
映射为知识块的元数据
用途
缺失时的后果
项目
Key / 空间名
project
检索时限定项目范围
跨项目串味，答案混进别的项目
模块
/ 组件
module
定位到具体模块
检索结果太泛，找不到重点
负责人
/ 报告人
owner
定位到可追问的人
答案无法溯源，没人敢信
创建
/ 更新时间
updated_at
判断内容是否过期
旧结论覆盖新结论
工单状态
status
区分「已定稿」和「讨论中」
AI 把讨论当结论
标签
/ 分类
tags
按主题聚合
同类知识散落，无法成体系
其中
status
和
updated_at
两个字段优先级最高：前者决定内容能不能被当作结论引用，后者决定多条冲突内容取哪条。这两个字段缺失，知识库的可信度会明显下降。
四、导入之后怎么验证
迁移完不要急着宣布成功，用一组固定问题测一遍。下面这组问题能较快暴露问题：
验证问题
期望结果
出问题说明什么
问某个模块最近一次改了什么
答出具体需求与时间
时间字段或关联缺失
问某个需求当时为什么这么设计
答出决策理由
决策上下文未沉淀
问某个接口的参数含义
答出字段说明且不串到别的项目
项目维度缺失
问某个历史故障的根因
答出根因与规避方式
故障复盘未结构化
四个问题里答对三个以上，才算基本可用。
**
麦芽
AI**
支持历史资料与工程资料导入与研发知识资产沉淀，导入后可按项目维度组织查询；支持哪些资料格式、能覆盖多大范围，建议用企业真实资料做一次试点再下结论。
五、迁移过程中的三个取舍
迁移大部分时间花在取舍上，有三个取舍几乎每个团队都会遇到。
一是
**
全量还是分批
**
：全量看起来彻底，但效果不好时难判断是数据问题还是平台问题；分批可先小范围验证，建议从正在迭代的项目开始。二是
**
保留历史版本还是只留结论
**
：折中做法是保留但打上失效标记并注明替代内容，既不影响排查，也不会被当成现行结论。三是
**
自动切分还是人工切分
**
：核心模块人工切，其余自动切，把人力花在刀刃上。
麦芽
AI
支持历史资料与工程资料导入与研发知识资产沉淀，导入后可按项目维度组织查询；支持哪些格式、切分策略如何配置，建议用真实资料试点确认。
六、迁移过程中的三个取舍
迁移不是纯技术活，大部分时间花在取舍上。有三个取舍几乎每个团队都会遇到，提前想清楚能省不少返工。
第一个是
**
全量还是分批
**
。全量迁移看起来彻底，但一旦效果不好，很难判断是数据问题还是平台问题；分批迁移可以先小范围验证，代价是短期内覆盖不全。中小团队建议分批，从正在迭代的项目开始。
第二个是
**
保留历史版本还是只留结论
**
。只留结论检索更干净，但排查老问题时会缺依据；全留则容易让过期内容干扰检索。折中做法是保留但打上失效标记，并注明替代内容
——既不影响排查，也不会被当成现行结论。
第三个是
**
自动切分还是人工切分
**
。自动切分快，但切得太碎会丢失上下文，切得太粗检索不准；人工切分质量高，但资料量大时不可行。建议对核心模块人工切，其余自动切，把人力花在刀刃上。
三个取舍的共同原则是：
**
先验证再扩量，先核心后边缘。
**
迁移的目标是让知识可用，不是让迁移这件事做完。
麦芽
AI
支持历史资料与工程资料导入与研发知识资产沉淀，导入后可按项目维度组织查询。具体支持哪些资料格式、切分策略如何配置，建议用企业真实资料做一次试点确认。
七、
FAQ
问：历史资料量很大，要一次性全导入吗？
答：不建议。先导入正在迭代的项目和通用规范类资料，验证检索效果后再逐步扩量。一次性全量导入，一旦效果不好，很难判断是数据问题还是平台问题。
问：
Wiki 里的过期内容怎么处理？
答：不要删，打上失效标记并注明替代文档。历史内容在排查老问题时有价值，只是不该被当成现行结论。关键是要有`updated_at` 和状态字段让 AI 能区分。
问：
AI 会自动学习我们全部系统的数据吗？
答：不会。平台不会自动学习企业全部系统数据，导入范围由企业自行决定与控制，涉及权限与数据安全的内容应按企业规范单独处理。
