Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 saint
|
f744d4dacb |
@@ -1,41 +0,0 @@
|
||||
# 资料追溯字段核对（阶段1 · 2026-10-17）
|
||||
|
||||
> 用途：核对资料台账所需字段与系统（后端数据模型 + 前端页面）实际字段的对应关系，确认是否满足「来源可回访、核验可追溯」的要求，并给出需补齐的字段建议。
|
||||
> 对照对象：[资料台账](material-ledger.md) 的字段 vs 后端 `knowledge_items` / `sources` / `documents` 三张表，以及前端知识管理、来源管理、知识审核页面。
|
||||
> 结论：核心追溯字段已基本覆盖，存在 5 处需补齐/确认的差异。
|
||||
|
||||
## 一、字段对照表
|
||||
|
||||
| 台账字段 | 系统对应字段（表） | 覆盖情况 |
|
||||
|---|---|---|
|
||||
| 编号 | `id`（自动生成） | ✅ |
|
||||
| 标题 | `title`（knowledge / documents） | ✅ |
|
||||
| 类别 | `category`（knowledge / documents，默认「未分类」） | ✅ |
|
||||
| 来源名称 | `sources.name`（经 `knowledge.source_id` 关联） | ⚠️ 见差异 1 |
|
||||
| URL | `source_url`（knowledge / sources） | ✅ |
|
||||
| 获取日期 | `collected_at`（documents 必填，knowledge 可空） | ⚠️ 见差异 2 |
|
||||
| 更新时间 | `updated_at`（自动维护） | ✅ 系统有，台账此前缺此列，已补 |
|
||||
| 正文摘要 | `content`（正文，最长 10 万字符） | ⚠️ 见差异 3 |
|
||||
| 真实性判断 | `verification_notes`（核验说明） | ✅ |
|
||||
| 核验日期 | `reviewed_at` | ✅ |
|
||||
| 核验人 | `reviewer` | ✅ |
|
||||
| 状态 | `verification_status`（pending / verified / rejected） | ✅ 三值与台账完全一致 |
|
||||
| 备注 | 无独立字段（sources / documents 有 `notes`，knowledge 无） | ⚠️ 见差异 4 |
|
||||
|
||||
## 二、差异与建议
|
||||
|
||||
1. **来源名称是独立实体**：知识条目本身只有 `source_url`，来源名称需先在「来源管理」登记 `sources`，再通过 `source_id` 关联。前端知识管理页目前只展示「来源网址」链接，未显示来源名称，也未在知识表单暴露 `source_id` 选择。建议：知识录入时允许选择已登记来源（`source_id`），并在列表同时显示来源名称与网址。
|
||||
|
||||
2. **采集时间在知识条目上可空**：`documents.collected_at` 必填、`knowledge.collected_at` 可空。前端知识表单已有「采集时间」输入，但后端允许为空。为满足追溯，建议知识条目也要求填写采集时间，或强制关联到含采集时间的文档。
|
||||
|
||||
3. **「正文摘要」无独立字段**：系统只有正文 `content`，无单独摘要列。台账中「正文摘要」作为登记用摘要；正式入库时以 `content`（正文/摘要原文）为准，两者须在核验时对齐，避免摘要与正文不一致。
|
||||
|
||||
4. **知识条目缺通用「备注」**：`knowledge_items` 没有 `notes`，只有 `verification_notes`（核验说明）。若需在审核之外记录备注（如过期时间、待二次确认），目前只能写入核验说明或关联文档的 `notes`。建议：给知识条目增加 `notes` 字段（需范涵宇评估，仅建议，不直接改库）。
|
||||
|
||||
5. **来源名称回填**：现有直接填 `source_url` 的条目，来源名称缺失；后续入库前应补登记到 `sources` 并关联。
|
||||
|
||||
## 三、核对结论
|
||||
|
||||
- 追溯核心字段（标题、类别、URL、获取/更新时间、核验状态、核验人、核验依据）系统均已支持，状态三值与审核规则一致。
|
||||
- 主要缺口集中在「来源名称的独立登记与前端展示」「知识条目通用备注」「摘要与正文的一致性」三点，需在阶段 2 入库前与范涵宇、吉海燕确认。
|
||||
- 数据库结构改动仅为建议，不由本文档直接执行。
|
||||
@@ -19,23 +19,21 @@
|
||||
|---|---|---|
|
||||
| 编号 | 是 | 唯一序号，格式 `K-0001`，按登记顺序递增 |
|
||||
| 标题 | 是 | 资料的简短标题，便于检索和引用 |
|
||||
| 类别 | 是 | 四选一：红色文化 / 旅游资源 / 民宿服务 / 交通出行；测试条目用「其他」并注明测试 |
|
||||
| 来源名称 | 是 | 发布方，如机构/媒体/网站名称；无来源的测试条目填「无（测试）」 |
|
||||
| URL | 否 | 来源链接；无法溯源时留空并说明 |
|
||||
| 类别 | 是 | 四选一：红色文化 / 旅游资源 / 民宿服务 / 交通出行 |
|
||||
| 来源名称 | 是 | 发布方，如机构/媒体/网站名称 |
|
||||
| URL | 是 | 来源链接；无法溯源时填「无链接」并在真实性判断中说明 |
|
||||
| 获取日期 | 是 | 采集日期，格式 `YYYY-MM-DD` |
|
||||
| 更新时间 | 是 | 最近一次更新该条目的日期 `YYYY-MM-DD` |
|
||||
| 正文摘要 | 是 | 资料关键内容的一两句话摘要，不改变原意 |
|
||||
| 真实性判断 | 是 | 核验结论依据，如「与官方公告一致」「与另一独立来源交叉印证」「无法核实」；测试条目填「无需核验（测试）」 |
|
||||
| 真实性判断 | 是 | 核验结论依据，如「与官方公告一致」「与另一独立来源交叉印证」「无法核实」 |
|
||||
| 核验日期 | 否 | 完成核验的日期 `YYYY-MM-DD`；`pending` 时可为空 |
|
||||
| 核验人 | 否 | 完成核验的人；`pending` 时可为空 |
|
||||
| 状态 | 是 | `pending` / `verified` / `rejected` |
|
||||
| 备注 | 否 | 补充说明，如过期时间、需二次确认的事项、测试标记 |
|
||||
| 备注 | 否 | 补充说明，如过期时间、需二次确认的事项 |
|
||||
|
||||
## 登记表
|
||||
|
||||
| 编号 | 标题 | 类别 | 来源名称 | URL | 获取日期 | 更新时间 | 正文摘要 | 真实性判断 | 核验日期 | 核验人 | 状态 | 备注 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| K-0001 | 【示例·占位】某景区简介 | 旅游资源 | 【示例来源，非真实】示例站点 | https://example.com/ | 2026-10-15 | 2026-10-15 | 【示例】此处为占位摘要，非真实资料 | 待核验 | | | pending | 示例行，仅演示填写格式，不构成真实资料 |
|
||||
| K-0002 | 阶段1联调测试条目 | 其他（测试） | 无（测试） | | 2026-10-17 | 2026-10-17 | 仅用于验证资料登记与持久化流程，不构成任何那拉提文旅事实 | 无需核验（测试） | | | pending | 阶段1测试条目，仅验证登记流程，不进入正式检索库，不伪装为真实资料 |
|
||||
| 编号 | 标题 | 类别 | 来源名称 | URL | 获取日期 | 正文摘要 | 真实性判断 | 核验日期 | 核验人 | 状态 | 备注 |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| K-0001 | 【示例·占位】某景区简介 | 旅游资源 | 【示例来源，非真实】示例站点 | https://example.com/ | 2026-10-15 | 【示例】此处为占位摘要，非真实资料 | 待核验 | | | pending | 示例行，仅演示填写格式，不构成真实资料 |
|
||||
|
||||
> 上表 K-0001 为**示例占位行**，K-0002 为**测试条目**，均不包含真实文旅信息。正式收集的资料按此格式逐行追加。
|
||||
> 上表仅含一条**示例占位行**，用于演示填写格式，不包含任何真实文旅信息。正式收集的资料按此格式逐行追加。
|
||||
|
||||
@@ -0,0 +1,65 @@
|
||||
# 阶段 2 知识收集清单（计划）
|
||||
|
||||
> 阶段：2026-10-19 至 2026-10-23（阶段 2：知识管理）
|
||||
> 目标：收集并登记首批 30–50 条可核验资料，完成初步分类与来源核验。
|
||||
> 维护人：杨星萱（知识库、实验与文档负责人）
|
||||
|
||||
## 一、阶段 1 知识交付物汇总（截至 2026-10-18）
|
||||
|
||||
| 交付物 | 位置 | 状态 |
|
||||
|---|---|---|
|
||||
| 资料台账模板 | [material-ledger.md](material-ledger.md) | 基础版已合入 `dev`；“更新时间”字段与测试条目 K-0002 依赖合并请求 #51，未合入前不得按已具备处理。 |
|
||||
| 审核规则 | [review-rules.md](review-rules.md) | 草案已合入 `dev`，待团队确认后定稿。 |
|
||||
| 联调验收记录模板 | [acceptance-record.md](acceptance-record.md) | 已合入 `dev`。 |
|
||||
| 字段核对反馈 | `field-feedback.md`（依赖 #51） | 其中 `source_id`、`collected_at`、`notes` 三项建议待范涵宇、吉海燕确认。 |
|
||||
|
||||
## 二、收集目标与口径
|
||||
|
||||
- 总量：30–50 条，覆盖红色文化、旅游资源、民宿服务、交通出行四类。
|
||||
- 每条资料必须来源可回访、事实可核验；未核验保持 `pending`，不得进入正式检索。
|
||||
- 只登记真实资料；不编造来源、事实或数据。演示/测试条目必须明确标注，且不得与真实资料混淆。
|
||||
- 首版不承诺实时房态、实时价格或自动联网核验；此类内容不纳入本阶段收集范围。
|
||||
|
||||
## 三、四类收集方向与数量分配
|
||||
|
||||
| 类别 | 建议数量 | 收集方向 | 来源优先级 |
|
||||
|---|---:|---|---|
|
||||
| 红色文化 | 8–12 条 | 边疆红驿相关历史背景、红色纪念地、戍边/英烈事迹、红色场馆介绍 | 政府/文旅局/纪念馆官方 > 权威媒体 |
|
||||
| 旅游资源 | 10–15 条 | 那拉提景区概况、景点介绍、游览路线、开放时间、票务/预约说明（静态）、适宜季节 | 景区官网/文旅局 > 权威媒体 |
|
||||
| 民宿服务 | 6–10 条 | 民宿类型、服务内容、位置、入住须知（静态说明） | 官方平台/文旅局 > 权威媒体 |
|
||||
| 交通出行 | 6–10 条 | 抵达交通方式、班车/自驾路线、景区内交通、天气与安全提示 | 交通部门/文旅局 > 权威媒体 |
|
||||
|
||||
## 四、来源类型与核验要点
|
||||
|
||||
1. 优先采集文旅局、景区官网、政府公告、交通部门等官方来源；权威媒体可作为补充。
|
||||
2. 一般网站与自媒体仅可作线索，不能单独作为 `verified` 的依据，除非能追溯到原始官方来源。
|
||||
3. “独立来源”是指不同发布主体的原始材料，或可追溯到不同原始材料的权威发布；转载同一公告的多个页面不视为独立来源。
|
||||
4. 关键事实须至少由一个独立来源交叉印证，方可标记为 `verified`；详细口径以 [审核规则](review-rules.md) 定稿为准。
|
||||
5. 记录资料版本、获取日期；“更新时间”仅在 #51 合并后填写，便于后续向量重建与数据集说明。
|
||||
|
||||
## 五、字段与登记要求
|
||||
|
||||
- 沿用 [资料台账](material-ledger.md) 已有字段：标题、类别、来源名称、URL、获取日期、正文摘要、真实性判断、核验日期、核验人、状态、备注。
|
||||
- “更新时间”字段在 #51 合并后纳入必填口径；在此之前不得用自定义列替代正式字段。
|
||||
- 状态仅使用 `pending` / `verified` / `rejected`。每条先登记为 `pending`；仅将 `verified` 条目交给范涵宇入库。
|
||||
|
||||
## 六、执行顺序
|
||||
|
||||
1. 优先收集官方来源的景区概况与红色文化资料。
|
||||
2. 补充交通与民宿的静态说明。
|
||||
3. 逐条完成来源、关键事实与时效性核验；信息缺失或来源存疑时保持 `pending`。
|
||||
4. 按批次提交台账与 `verified` 清单，并记录联调结果。
|
||||
|
||||
## 七、阶段验收标准
|
||||
|
||||
本阶段结束时，应提交下列可复核交付物：
|
||||
|
||||
1. 30–50 条台账记录，按四类统计数量，并区分真实资料和明确标注的测试资料。
|
||||
2. 每条记录的来源 URL 可访问检查结果；不可访问或无法回访的记录保持 `pending` 或标记 `rejected`。
|
||||
3. `pending` / `verified` / `rejected` 的数量统计，以及可交给后端入库的 `verified` 清单。
|
||||
4. 对已入库 `verified` 条目的联调验收记录，使用 [联调验收记录模板](acceptance-record.md) 记录环境、操作、结果和证据位置。
|
||||
|
||||
## 八、待定事项与依赖
|
||||
|
||||
- #51 合并前：`source_id` 选择、`collected_at` 是否必填、`notes` 是否新增，以及“更新时间”字段均尚未定稿。
|
||||
- 以上数据库与前端改动由范涵宇、吉海燕评估确认；确认结果应同步更新本清单、台账和接口文档。
|
||||
Reference in New Issue
Block a user