3. 设计方法与信息架构

为什么不只做"搜索框 + 文件列表"，而要为每个资料域、项目、政策、客户生成可导航、可问答、带源码引用的结构化知识页面。

核心理念

DeepWiki = 仓库级知识地图 + 模块级说明文档 + 源码级引用 + 问答入口。

迁移到企业资料库：

企业知识页 = 资料域级知识地图 + 项目/政策级说明 + 文件/页码级引用 + 权限过滤后的问答。

四类知识页

单页内容模板

# 项目/资料域标题

相关原始资料
- SVN 路径 A
- Word 留档 B
- 盖章 PDF C
- 表格 D

本页范围
- 覆盖哪些业务问题
- 不覆盖哪些敏感或未确认内容

## 业务概览
项目、客户、时间、主体、关键结论。
来源：文件、页码、字段。

## 资料结构
合同、交付件、发票、会议纪要、政策依据、评审材料。

## 核心流程
从立项到交付/评审/回款的流程图。

## 关键实体
客户、我方主体、政策、项目、联系人、金额、日期。

## 缺口与风险
缺失文件、版本不一致、OCR 低置信度、待人审字段。

## 可提问问题
围绕当前资料域的推荐问题。

三条核心约束

1. 先说明范围：先说明本页覆盖范围。哪些资料因权限不可见、哪些来自 AI 推断、哪些已人审确认。
2. 证据可见：先列出相关源文件，正文持续给来源（文件、页码、chunk_id）。
3. Cross-link：复杂主题不在一页塞满，跳转到子页面。项目页 → 合同页 → 交付件页 → 发票页。

导航结构

建议三栏：

左侧树示例：

企业知识中枢
  资料库总览
  合同与交付
    项目 A
    项目 B
  政策与评审
    黄埔文旅
    广东教育
  财务与回款
  内部制度
  标签与权限治理

引用机制

推荐引用数据结构：

{
  "doc_id": "D-2026-0001",
  "svn_path": "/商务合作/黄埔文旅/合同/项目合同.docx",
  "svn_revision": "12345",
  "source_kind": "word",
  "page": 3,
  "chunk_id": "C-2026-0001-003",
  "bbox": null,
  "field_key": "contract_amount",
  "parser_version": "docx-parser-0.2.1",
  "review_status": "confirmed"
}

可直接迁移的 12 条设计

1. Last indexed：所有资料页显示索引时间、SVN revision、解析版本。
2. Relevant source files：页面顶部列出本页依据的原始资料。
3. 来源（来源）：段落级引用必须可点击回原文。
4. 本页目录：长页面右侧页内目录。
5. Wiki tree：左侧是业务知识树，不是纯文件树。
6. Cross-link：页面之间互相引用，避免长文堆叠。
7. Refresh wiki：原文变化后可重新生成。
8. Edit Wiki：人工修订摘要和字段，进入审计。
9. Ask this repo/page：围绕当前资料域提问。
10. Source-linked diagrams：流程图和架构图也要绑定来源。
11. 范围说明：每页说明覆盖范围和不覆盖范围。
12. Open issues：把解析失败、缺失资料、权限不足、待确认结论显性化。

继续阅读

• 4. 决策建议 · 这 12 条设计如何落到产品功能。
• 1. 系统总览 · 分层架构中"应用编排层"如何承载知识页。