[特殊字符] 龍魂 AI|统一资料入口与自动治理基础设施 LH-INGESTOR · LONG-TERM EXECUTION BLUEPRINT

🐉 龍魂 AI|统一资料入口与自动治理基础设施

LH-INGESTOR · LONG-TERM EXECUTION BLUEPRINT

项目名称: 龍魂 AI 统一资料入口与自动治理中枢
英文名称: Longhun Unified Intake & Knowledge Governance Infrastructure
系统代号: UIKGH
核心引擎: LH-INGESTOR
版本: v2.0 · LONG-TERM MASTER PLAN
文档类型: 总体架构、技术实施、治理规范与分阶段执行方案
当前状态: DESIGN_READY · IMPLEMENTATION_NOT_STARTED
执行工具: CodeBuddy + Python + SQLite + Notion
部署策略: 本地优先、模块化、可迁移、可审计
核心原则: 原件保护、统一入口、专业分库、证据驱动、人工授权

⸻

第一章:项目使命与长期定位

1.1 项目使命

建立龍魂 AI 的长期统一资料治理基础设施。

它不只是一个文件分类脚本,也不只是一个Notion自动化工具。

它是龍魂 AI 所有知识、文件、代码、人格、技能、算法和治理证据的统一接收、识别、管理、分发与追溯系统。

未来任何新资料都不应该直接散落到某个临时文件夹或某个未经治理的Notion页面。

所有新资料原则上先经过统一入口,再进入对应专业系统。

1.2 长期管理对象

系统统一管理以下十二类资产:

编号 资产类型 示例
A01 PROJECT 项目、项目计划、项目状态
A02 PERSONA 核心人格、专业人格、符号人格
A03 SKILL 技能、技能说明、执行流程
A04 ALGORITHM 自研算法、公开算法、数学规范
A05 CODE 源代码、模块、脚本、程序
A06 SPEC 技术规范、架构文档、设计方案
A07 AUDIT 审计报告、核验报告、风险报告
A08 SOURCE 论文、网站、文献、许可证、外部资料
A09 EXPERIMENT 实验、测试、复现、基准数据
A10 LOG 执行日志、系统演化记录、操作记录
A11 EVIDENCE 原始证据、哈希、截图、执行结果
A12 ARCHIVE 历史版本、废弃资料、封存资产

补充分类:

  • TOOL:工具和外部服务。
  • MODEL:模型及其能力、价格和使用状态。
  • ROUTE:路由规则。
  • POLICY:权限、安全和治理政策。
  • UNKNOWN:无法可靠识别的资料。

以上分类是资产类型,不是可信度,也不是执行权限。

1.3 设计原则

  1. 一个统一入口。
  2. 多个专业知识库。
  3. 一个统一资产身份体系。
  4. 一套统一元数据标准。
  5. 一套统一证据等级。
  6. 一套统一权限和审批体系。
  7. 一个统一任务协议。
  8. 多个可替换的处理引擎。
  9. 所有自动化均可追溯。
  10. AI建议与正式事实严格分离。

核心原则:

资料入口统一,不代表资料必须集中存储;自动化统一,不代表所有操作都自动获准。

⸻

第二章:总体系统架构

2.1 总体架构图

               龍魂 AI 用户
                    |
                    v
         LH-UNIFIED-CONTROL-PLANE
              统一控制入口
                    |
                    v
            UIKGH-INBOX
              统一接收层
                    |
      +-------------+-------------+
      |             |             |
      v             v             v
   本地文件       Notion       Git仓库
      |             |             |
      +-------------+-------------+
                    |
                    v
          LH-INGESTOR CORE
              资料接收核心
                    |
      +-------------+-------------+
      |             |             |
      v             v             v
   安全检查       身份登记       来源登记
      |             |             |
      +-------------+-------------+
                    |
                    v
           ASSET PROCESSING
               资产处理层
                    |
  +-----------------+------------------+
  |                 |                  |
  v                 v                  v

文件识别 内容提取 哈希计算
| | |
±----------------±-----------------+
|
v
CLASSIFICATION ENGINE
分类引擎
|
±------------±------------+
| | |
v v v
规则分类 AI建议分类 人工复核
| | |
±------------±------------+
|
v
GOVERNANCE ENGINE
治理引擎
|
±-----------------±------------------+
| | |
v v v
重复识别 版本管理 冲突检测
| | |
±-----------------±------------------+
|
v
QUALITY GATE
质量门禁
|
±------------±------------+
| | |
v v v
权限检查 证据检查 风险检查
| | |
±------------±------------+
|
v
ROUTING ENGINE
路由引擎
|
±-----------------±-------------------+
| | |
v v v
人格知识库 算法知识库 技能知识库
| | |
v v v
项目管理 实验数据库 审计数据库
| | |
±-----------------±-------------------+
|
v
TASK ORCHESTRATION
任务编排
|
±------------±------------+
| | |
v v v
CodeBuddy 本地AI Notion
| | |
±------------±------------+
|
v
AUDIT & LEDGER
审计与记录中心

2.2 八层系统结构

层级 名称 核心职责
L0 Unified Control Plane 统一控制入口
L1 Intake Layer 文件、页面、代码和外部资料接收
L2 Asset Identity Layer 资产身份、来源、版本登记
L3 Processing Layer 元数据、哈希、内容提取
L4 Intelligence Layer 规则分类、AI分类、冲突识别
L5 Governance Layer 权限、证据、安全、质量门禁
L6 Routing Layer 分发到专业知识库和任务系统
L7 Learning & Audit Layer 反馈学习、版本、审计和成本管理

⸻

第三章:核心基础设施组件

系统分为十五个核心组件。

3.1 LH-INGESTOR CORE

统一接收核心。

负责:

  • 接收新资料。
  • 生成接收任务。
  • 建立资产ID。
  • 登记来源。
  • 登记时间。
  • 建立处理队列。

不直接改变原始文件。

3.2 LH-SCOPE-GUARD

范围保护引擎。

负责:

  • 路径白名单。
  • 路径黑名单。
  • 冻结资产识别。
  • 敏感目录保护。
  • 输出目录隔离。
  • 符号链接检查。
  • 扫描边界校验。

边界不明确时必须停止。

3.3 LH-ASSET-REGISTRY

统一资产登记中心。

每份资料获得唯一资产身份。

统一字段:

Asset_ID
Asset_Type
Asset_Name
Asset_Version
Project_ID
Source_ID
Source_Type
Source_URI
Content_Hash
Original_Location
Current_Location
Created_At
Updated_At
Registered_At
Lifecycle_Status
Evidence_Level
Verification_Status
Permission_Level
Risk_Level
Governance_Status
Owner
Related_Assets
Rule_Version

资产ID与原始文件名无关。

原始文件移动或更名,不应导致资产身份丢失。

3.4 LH-METADATA-ENGINE

元数据提取引擎。

负责:

  • 文件名。
  • 扩展名。
  • 文件大小。
  • 创建时间。
  • 修改时间。
  • 文件格式。
  • 文档标题。
  • 文档作者字段(如可安全提取)。
  • 版本线索。

第一版只处理基础元数据。

3.5 LH-HASH-ENGINE

内容指纹引擎。

默认使用SHA-256。

支持:

  • 文件哈希。
  • 内容哈希。
  • 版本哈希。
  • 资产指纹。
  • 哈希验证状态。

必须区分:

HASH_MATCH
HASH_MISMATCH
HASH_FAILED
HASH_NOT_CHECKED
HASH_SKIPPED

哈希一致可以证明字节一致,但不能证明来源合法、作者身份或内容正确。

3.6 LH-CLASSIFIER

统一分类引擎。

分为三级:

第一级:确定性分类

根据扩展名、文件签名、路径规则、已登记来源识别。

第二级:语义分类

分析文档标题、正文结构、关键词和项目关联。

第三级:人工裁定

处理冲突、歧义和高风险资料。

AI只能产生分类建议,不得直接把建议升级为已验证事实。

3.7 LH-DEDUPE-ENGINE

重复识别引擎。

分为:

  • 完全重复。
  • 内容近似。
  • 文档版本候选。
  • 多来源相同资料。
  • 重复Notion记录。
  • 代码片段重复。

第一阶段仅确认SHA-256完全重复。

第二阶段才开展内容相似度比较。

任何重复判断都不能自动删除原件。

3.8 LH-VERSION-ENGINE

版本治理引擎。

管理:

  • 文档版本。
  • 代码版本。
  • 算法规范版本。
  • 人格定义版本。
  • 技能版本。
  • 路由规则版本。
  • 治理政策版本。

必须支持:

SUPERSEDES
SUPERSEDED_BY
FORKED_FROM
DERIVED_FROM
SAME_AS
CONFLICTS_WITH
RELATED_TO

版本判断不能只依赖文件名。

3.9 LH-EVIDENCE-ENGINE

证据管理引擎。

记录:

  • 证据来源。
  • 证据文件。
  • 证据哈希。
  • 采集时间。
  • 采集方式。
  • 验证方式。
  • 验证人员或系统。
  • 验证结果。
  • 证据适用范围。

统一证据等级:

等级 含义
E0 UNKNOWN,无有效证据
E1 DECLARED,声明或自述
E2 REPORTED,执行报告或第三方转述
E3 DIRECT,可直接检查的原始材料
E4 VERIFIED,按明确规则完成验证
E5 INDEPENDENTLY_REVIEWED,独立复核通过

证据等级必须附带具体验证对象。

例如:代码文件哈希已验证,不代表算法正确性已验证。

3.10 LH-QUALITY-GATE

质量门禁。

检查:

  • 资产身份是否完整。
  • 来源是否明确。
  • 版本是否明确。
  • 重复是否已检查。
  • 冲突是否已处理。
  • 证据是否足够。
  • 权限是否满足。
  • 风险是否可接受。
  • 路由目标是否正确。

3.11 LH-ROUTER

统一路由引擎。

根据以下信息确定目标:

Route = f(
Asset_Type,
Intent,
Project_ID,
Source_Type,
Version,
Evidence_Level,
Governance_Status,
Permission_Level,
Risk_Level,
Target_Database
)

路由必须给出解释:

ROUTE_DECISION
TARGET
MATCHED_RULE
EVIDENCE
CONFIDENCE
REQUIRES_REVIEW
BLOCK_REASON

不能只返回一个数据库名称。

3.12 LH-TASK-ORCHESTRATOR

任务编排引擎。

负责将资料处理转换为任务:

  • 文档解析任务。
  • 分类任务。
  • 重复检查任务。
  • 版本比较任务。
  • 算法审计任务。
  • 技能更新任务。
  • 人格资料复核任务。
  • 代码静态审查任务。

3.13 LH-AI-ADAPTER

本地AI和外部模型统一适配器。

负责:

  • 本地模型调用。
  • 外部模型调用。
  • Token计量。
  • 模型能力检查。
  • 隐私检查。
  • 成本估算。
  • 输出格式统一。
  • 模型故障回退。

第一阶段不启用。

外部模型必须经过权限、隐私和成本检查。

3.14 LH-AUDIT-LEDGER

操作与审计账本。

记录:

Event_ID
Task_ID
Asset_ID
Actor
Action
Input_Reference
Output_Reference
Timestamp
Rule_Version
Model_Version
Permission
Result
Evidence

记录操作发生了什么,而不只是最终结果。

3.15 LH-LEARNING-ENGINE

规则和系统进化引擎。

从以下信息提取改进建议:

  • 人工分类纠正。
  • 分类失败。
  • 重复识别错误。
  • 版本判断错误。
  • 路由错误。
  • 审计阻断。
  • 模型成本异常。
  • 任务执行失败。

只生成候选规则。

候选规则必须经过测试、复核和审批,才能进入生产规则。

⸻

第四章:统一资产分类与专业知识库映射

4.1 统一分类表

Asset_Type 主要去向 管理方式
PROJECT 项目管理中心 项目与任务管理
PERSONA DB-PERSONA 人格档案与能力管理
SKILL DB-SKILL 技能注册和版本管理
ALGORITHM 算法知识库 算法定义与实现
CODE 代码资产索引 仓库和模块映射
SPEC 项目文档库 规范和设计
AUDIT DB-ALGORITHM-AUDIT 审计与裁定
SOURCE DB-ALGORITHM-SOURCE 来源与权利证明
EXPERIMENT DB-EXPERIMENT 实验和复现
EVIDENCE 证据登记中心 证据链
LOG 日志中心 执行和演化历史
TOOL 工具注册中心 工具能力与状态
MODEL DB-MODEL 模型能力和成本
ROUTE DB-ROUTE 路由策略
ARCHIVE 历史资产索引 保留与追溯
UNKNOWN 待复核队列 不自动分发

4.2 重要规则

专业知识库继续独立存在。

例如:

  • 人格不能因为统一入口而被塞进算法库。
  • 算法不能因为属于某个项目而失去自己的独立身份。
  • 审计证据不能被普通项目文档覆盖。
  • 代码文件不能被当作算法定义。
  • 论文来源不能被直接当作算法实现。
  • 技能描述不能被当作技能已经部署。
  • 人格配置不能被当作独立代理已经运行。

统一入口负责建立关系,不负责抹平差异。

⸻

第五章:Notion现有系统衔接方案

5.1 基本策略

优先复用已有数据库。

不因统一入口再建立一套重复的专业知识库。

现有资产结构以实际Notion核验结果为准。

目前已知的结构来自此前用户提供的建设报告及已检索页面,仍需在实施前进行一次只读字段映射核对。

5.2 现有数据库映射

现有数据库或系统 统一入口中的作用
龍芯家族花名册 DB-PERSONA来源
龍芯家族·人格与工具管理中心 人格和工具治理
核心P编号路由表 人格路由参考
人格系统 人格定义来源
技能库 DB-SKILL来源
龍魂 AI 公共算法知识库 ALGORITHM目标
DB-EXPERIMENT EXPERIMENT目标
DB-ALGORITHM-AUDIT AUDIT目标
DB-ALGORITHM-SOURCE SOURCE目标
项目管理中心 PROJECT目标
系统演化日志 LOG目标

数据库名称、字段、Relation和页面ID在实施前必须从实际Notion读取确认。

5.3 统一入口数据库:DB-UNIFIED-INBOX

建议建立一个统一接收数据库。

注意:当前仅为设计提议,尚未创建。

字段:

字段 类型 用途
Intake_ID Title 接收任务ID
Asset_ID Text 统一资产ID
Asset_Name Title/Relation 资产名称
Source_Type Select 来源类型
Source_ID Text 原始来源ID
Source_URI URL 原始链接
Content_Hash Text 内容指纹
Asset_Type Select 资产类型
Project_ID Relation/Text 项目归属
Version Text 版本
Evidence_Level Select 证据等级
Classification_Status Select 分类状态
Duplicate_Status Select 重复状态
Conflict_Status Select 冲突状态
Governance_Status Select 治理状态
Target_Database Select/Relation 目标数据库
Permission_Level Select 权限等级
Risk_Level Select 风险等级
Review_Status Select 复核状态
Processing_Status Select 处理状态
Rule_Version Text 规则版本
Last_Processed Date 最后处理时间

5.4 建议视图

  1. 全部接收记录。
  2. 待分类。
  3. UNKNOWN待复核。
  4. 重复候选。
  5. 版本冲突。
  6. 权利待确认。
  7. 证据不足。
  8. 待人工批准。
  9. 已批准待分发。
  10. 已完成分发。
  11. BLOCKED阻断队列。
  12. 历史记录。

5.5 Notion同步策略

Notion同步采用两阶段方式:

第一阶段:只读获取。

  • 获取页面ID。
  • 获取数据库ID。
  • 获取属性。
  • 获取Relation。
  • 获取更新时间。
  • 获取来源链接。

第二阶段:经过授权后写入。

  • 创建接收记录。
  • 建立资产ID。
  • 写入来源和状态。
  • 建立Relation。
  • 记录同步结果。

默认禁止:

  • 覆盖已有页面。
  • 删除已有页面。
  • 批量重命名。
  • 自动修改专业数据库字段。
  • 自动合并记录。
  • 自动改变既有Relation。
  • 未经批准创建大量新页面。

⸻

第六章:统一数据协议

所有入口使用同一个数据协议。

6.1 统一接收协议

{
“intake_id”: “INTAKE-UUID”,
“asset_id”: “ASSET-UUID”,
“source_type”: “LOCAL_FILE”,
“source_id”: null,
“source_uri”: null,
“asset_type”: “UNKNOWN”,
“asset_name”: “example.md”,
“project_id”: null,
“version”: null,
“content_hash”: null,
“evidence_level”: “E0”,
“classification_status”: “PENDING”,
“duplicate_status”: “NOT_CHECKED”,
“conflict_status”: “NOT_CHECKED”,
“permission_level”: “A0”,
“risk_level”: “UNKNOWN”,
“governance_status”: “PENDING”,
“processing_status”: “RECEIVED”,
“target_database”: null,
“rule_version”: “1.0”
}

该协议是数据结构示例,不是实际运行记录。

6.2 统一状态机

RECEIVED
|
v
REGISTERED
|
v
INDEXED
|
v
CLASSIFIED
|
v
VALIDATED
|
v
REVIEW_REQUIRED
|
v
APPROVED
|
v
ROUTED
|
v
SYNCED
|
v
ARCHIVED

异常状态:

UNKNOWN
BLOCKED
CONFLICTED
DUPLICATE_CANDIDATE
FAILED
REJECTED
QUARANTINED

重要规则:

  • BLOCKED不能自动跳过。
  • UNKNOWN不能自动变成PASS。
  • FAILED不能自动变成SUCCESS。
  • REVIEW_REQUIRED不能自动升级为APPROVED。
  • ARCHIVED不代表删除。
  • SYNCED不代表源文件已移动。

⸻

第七章:统一权限、安全和风险治理

7.1 权限等级

等级 能力 默认权限
A0 只读查看与索引 默认可申请
A1 生成报告和分析建议 独立输出范围
A2 创建草案和待审任务 需明确授权
A3 写入正式知识库 单独审批
A4 删除、发布、部署、提交等高影响操作 明确逐项审批

权限等级不能仅由人格或模型自行决定。

7.2 风险等级

R0 = 普通公开资料
R1 = 一般项目资料
R2 = 重要内部资料
R3 = 敏感资料
R4 = 高影响或关键系统资产

权限和风险是两个独立维度。

低风险不代表允许写入。

高权限也不代表可以处理所有资料。

7.3 冻结资产保护

建立统一保护登记表:

Protected_Asset_ID
Protected_Path
Protected_Source_ID
Protection_Type
Protection_Status
Protection_Reason
Effective_From
Effective_Until
Authorized_Exceptions

冻结保护应采用显式拒绝优先。

如果资产属于冻结范围:

SCAN = PROHIBITED
READ = PROHIBITED
WRITE = PROHIBITED
EXPORT = PROHIBITED
ROUTE = BLOCKED

SIT-7继续遵守既有冻结协议,不得通过统一入口重新纳入扫描。

SIT-7不是普通归档资产,也不是可以由分类器自动识别并处理的对象。

⸻

第八章:统一自动化工作流

8.1 标准处理流程

01 接收资料
02 创建Intake_ID
03 检查来源
04 检查路径和保护规则
05 创建Asset_ID
06 提取元数据
07 计算内容指纹
08 确定性分类
09 语义分类建议
10 重复识别
11 版本线索识别
12 来源与证据检查
13 项目和资产关联
14 权限检查
15 风险检查
16 质量门禁
17 生成路由建议
18 人工审批
19 分发到专业数据库
20 写入操作账本
21 更新索引状态
22 反馈错误与改进建议

其中第9步及第18步之后的正式分发,在初期不启用自动执行。

8.2 自动化触发条件

可以支持:

  • 手动接收。
  • 指定目录新增文件。
  • 定时只读扫描。
  • Notion页面新增。
  • Git仓库新提交。
  • 用户明确提交资料。
  • CodeBuddy执行完成后提交报告。

但第一阶段只允许手动启动的只读扫描。

目录监听、定时任务、Notion事件监听和Git事件监听均属于后续阶段。

8.3 失败回退

出现错误时:

  1. 保存已完成的索引记录。
  2. 标记失败节点。
  3. 保存错误信息。
  4. 不重复执行有副作用的操作。
  5. 不自动跳过质量门禁。
  6. 不自动扩大权限。
  7. 生成失败报告。
  8. 等待人工处理。

⸻

第九章:本地工程技术架构

9.1 推荐技术栈

组件 第一阶段 后续阶段
语言 Python 3 Python 3
数据库 SQLite SQLite,可迁移PostgreSQL
文件系统 pathlib 同左
哈希 hashlib 同左
接口 CLI REST API或本地服务
任务队列 SQLite任务表 可替换队列
AI 不启用 本地AI适配器
文档解析 基础元数据 独立解析插件
Notion 不连接 官方接口适配器
Git 不操作 只读适配器
日志 logging 统一审计账本

不在第一阶段引入复杂微服务。

先做模块化单体架构。

等实际数据量和并发需求证明有必要时,再拆分服务。

9.2 推荐项目结构

LH-INGESTOR/
│
├── README.md
├── CHANGELOG.md
├── VERSION
├── pyproject.toml
│
├── config/
│ ├── config.example.yaml
│ ├── classification_rules.yaml
│ ├── protected_paths.example.yaml
│ ├── governance_rules.yaml
│ └── routing_rules.yaml
│
├── src/
│ └── lh_ingestor/
│ ├── core/
│ │ ├── intake.py
│ │ ├── asset_registry.py
│ │ └── lifecycle.py
│ │
│ ├── security/
│ │ ├── scope_guard.py
│ │ ├── permission.py
│ │ └── protection.py
│ │
│ ├── adapters/
│ │ ├── local_files.py
│ │ ├── notion.py
│ │ ├── git.py
│ │ └── external_source.py
│ │
│ ├── engines/
│ │ ├── metadata.py
│ │ ├── hashing.py
│ │ ├── classifier.py
│ │ ├── dedupe.py
│ │ ├── version.py
│ │ ├── evidence.py
│ │ ├── quality_gate.py
│ │ └── router.py
│ │
│ ├── ai/
│ │ ├── adapter.py
│ │ ├── local_model.py
│ │ └── privacy_filter.py
│ │
│ ├── orchestration/
│ │ ├── task_manager.py
│ │ ├── workflow.py
│ │ └── fallback.py
│ │
│ ├── storage/
│ │ ├── database.py
│ │ ├── repositories.py
│ │ └── migrations.py
│ │
│ ├── audit/
│ │ ├── event_log.py
│ │ └── ledger.py
│ │
│ ├── reports/
│ │ ├── inventory.py
│ │ ├── duplicates.py
│ │ └── governance.py
│ │
│ └── cli.py
│
├── schemas/
│ ├── asset.schema.json
│ ├── intake.schema.json
│ ├── task.schema.json
│ └── evidence.schema.json
│
├── tests/
│ ├── unit/
│ ├── integration/
│ ├── security/
│ └── fixtures/
│
├── docs/
│ ├── architecture.md
│ ├── data-dictionary.md
│ ├── security-model.md
│ ├── routing-rules.md
│ └── operations.md
│
└── migrations/
└── sqlite/

以上为目标工程结构。各阶段只创建当前阶段需要的模块,不能为了目录完整而提前实现未授权功能。

⸻

第十章:数据库总体设计

建议采用一个统一资产数据库,先以SQLite实现。

10.1 核心数据表

表名 用途
assets 统一资产登记
asset_sources 来源关系
asset_versions 版本关系
asset_relations 资产关联
asset_hashes 文件和内容指纹
asset_classifications 分类记录
intake_records 接收记录
processing_tasks 处理任务
task_events 任务事件
duplicate_groups 重复组
evidence_records 证据记录
verification_records 验证记录
governance_decisions 治理裁定
permission_records 权限记录
protected_assets 冻结与保护登记
routing_rules 路由规则
routing_decisions 路由决策
model_usage 模型调用成本
audit_events 操作审计
rule_versions 规则版本
schema_versions 数据结构版本

10.2 数据关系

ASSET
|
±- SOURCE
|
±- VERSION
|
±- RELATION
|
±- CLASSIFICATION
|
±- EVIDENCE
|
±- VERIFICATION
|
±- GOVERNANCE
|
±- ROUTING
|
±- AUDIT

同一资产可以关联多个项目、多个算法、多个来源和多个证据。

不能因为一份资料关联多个对象,就复制成多条互不关联的事实记录。

10.3 数据库治理

必须具备:

  • Schema版本。
  • 数据迁移脚本。
  • 事务保护。
  • 唯一约束。
  • 外键关系。
  • 查询索引。
  • 数据一致性检查。
  • 数据库备份策略。
  • 数据恢复验证。

数据库备份和恢复属于独立授权操作,不默认自动执行。

⸻

第十一章:AI自动消化与持续学习

11.1 AI职责

AI负责:

  • 理解文档内容。
  • 提取结构。
  • 生成分类建议。
  • 判断项目关联候选。
  • 识别疑似重复。
  • 识别版本冲突。
  • 生成摘要。
  • 提取待核验声明。
  • 建议知识库目标。
  • 发现知识缺口。

AI不负责:

  • 自行决定事实成立。
  • 自行认定许可证有效。
  • 自行认定作者身份。
  • 自行决定文件删除。
  • 自行覆盖原始文档。
  • 自行修改正式知识库。
  • 自行解除冻结。
  • 自行扩大权限。

11.2 AI输出协议

每次AI处理必须返回:

Asset_ID
Task_ID
Model_ID
Model_Version
Prompt_Version
Rule_Version
Classification_Result
Extracted_Entities
Related_Assets
Evidence_References
Confidence
Unknown_Fields
Risk_Flags
Suggested_Target
Review_Required

模型没有提供依据的结论,不得成为正式记录。

11.3 反馈学习

人工修正结果进入:

FEEDBACK_CANDIDATES

经过以下流程:

人工纠正
|
v
错误样本登记
|
v
候选规则生成
|
v
历史样本回归测试
|
v
独立复核
|
v
人工批准
|
v
新规则版本
|
v
影子模式
|
v
正式启用

禁止:

  • 单次分类错误直接修改生产规则。
  • 单次成功直接扩大自动化权限。
  • 为提高成功率而删除失败案例。
  • 自动降低安全标准。
  • 将AI自我评价当作独立审计。

⸻

第十二章:算力经济与模型路由

本项目后期与人格驱动技能编排系统衔接。

12.1 模型任务等级

等级 任务 推荐策略
C0 哈希、文件名、扩展名 本地确定性程序
C1 普通摘要、简单分类 轻量本地模型或低成本模型
C2 多文档关联、复杂冲突分析 中高能力模型
C3 数学审查、高风险代码和治理分析 高能力模型 + 独立复核

C0优先使用普通程序,不调用大模型。

12.2 成本模型

C_total =
C_input

  • C_output
  • C_tool
  • C_retry
  • C_compute
  • C_storage

每项成本区分:

ESTIMATED
PROVIDER_REPORTED
VERIFIED
UNKNOWN

12.3 模型路由原则

先检查:

  1. 任务能力是否匹配。
  2. 隐私要求是否满足。
  3. 权限是否允许。
  4. 质量是否达标。
  5. 结果是否可验证。

最后才比较价格和延迟。

不得单纯因为模型便宜就把高风险任务路由给能力不足的模型。

⸻

第十三章:分阶段实施路线

整个项目分为十个阶段。

PHASE 0:资产入口与安全基线

目标: 明确扫描范围、保护范围和工程边界。

任务:

  • 确认工作目录。
  • 确认输出目录。
  • 建立路径白名单。
  • 建立保护路径清单。
  • 建立权限模型。
  • 明确SIT-7排除范围。
  • 编写安全设计。
  • 静态检查工程方案。

交付:

  • 路径清单。
  • 保护规则。
  • 安全设计文档。
  • PHASE 0审查报告。

验收:扫描边界明确,SIT-7隔离可证明。

PHASE 1:本地资产只读索引

目标: 建立真实资产清单。

任务:

  • 文件发现。
  • 元数据提取。
  • SHA-256。
  • 完全重复识别。
  • 版本命名线索。
  • SQLite索引。
  • Markdown报告。
  • CSV报告。

交付:

  • 本地资产索引。
  • 重复文件清单。
  • 未知文件清单。
  • 版本候选清单。
  • 执行审计报告。

验收:结果可复算,原始资料没有变化。

PHASE 2:内容提取与语义分类

目标: 从文件名识别升级到内容理解。

任务:

  • 文档文本提取。
  • 标题和章节识别。
  • 结构提取。
  • 确定性规则分类。
  • 本地AI分类建议。
  • UNKNOWN队列。
  • 分类依据记录。

验收:分类准确性通过人工抽样复核。

PHASE 3:统一资产身份和关系治理

目标: 让资料拥有跨目录、跨系统的统一身份。

任务:

  • Asset_ID体系。
  • 来源映射。
  • 项目映射。
  • 版本关系。
  • 重复关系。
  • 人格关系。
  • 算法关系。
  • 技能关系。
  • 证据关系。

验收:资产关系可追溯,不产生无依据的关联。

PHASE 4:Notion只读接入

目标: 将现有Notion知识库纳入统一索引。

任务:

  • 数据库清单。
  • 页面ID登记。
  • 属性映射。
  • Relation映射。
  • 重复记录识别。
  • 页面版本线索。
  • 原始来源保留。

优先复用现有数据库。

不批量修改原有记录。

验收:本地资产与Notion记录能够建立可核对的映射。

PHASE 5:统一入口和待处理队列

目标: 建立统一接收入口。

任务:

  • DB-UNIFIED-INBOX设计与授权实施。
  • 统一接收协议。
  • 统一任务ID。
  • 统一状态机。
  • 统一待复核队列。
  • 统一错误队列。

验收:所有新资料可以通过统一协议登记。

PHASE 6:专业知识库自动路由

目标: 让不同资料进入正确专业系统。

任务:

  • 人格路由。
  • 算法路由。
  • 技能路由。
  • 项目路由。
  • 来源路由。
  • 实验路由。
  • 审计路由。
  • 证据路由。

初期采用SHADOW MODE:

只生成路由建议,不自动写入。

验收:人工对照通过后,逐类申请正式写入授权。

PHASE 7:CodeBuddy统一任务接入

目标: 让CodeBuddy从统一入口接收任务。

任务:

  • 统一任务协议。
  • 项目上下文装载。
  • 权限边界传递。
  • 任务执行记录。
  • 交付物登记。
  • 失败回退。
  • 证据归档。

CodeBuddy不得自行扩大任务范围。

验收:任务输入、执行、输出和证据能够闭环追溯。

PHASE 8:人格与技能自动编排

目标: 接入人格和技能系统。

任务:

  • 人格能力映射。
  • 技能注册。
  • 人格与技能关系。
  • 模型能力映射。
  • 算力等级匹配。
  • 多人格协作。
  • 失败回退。
  • 质量门禁。

先影子路由,再人工批准逐步启用。

验收:人格、技能和模型的配置状态与实际运行状态能够区分。

PHASE 9:持续治理和系统进化

目标: 建立持续迭代能力。

任务:

  • 规则质量分析。
  • 分类错误分析。
  • 版本冲突分析。
  • 成本分析。
  • 失败样本分析。
  • 自动生成改进建议。
  • 回归测试。
  • 规则版本管理。
  • 独立复核。

验收:每次系统升级有版本、有证据、有回归测试、有回退路径。

⸻

第十四章:最小可用系统 MVP

不要一开始就开发全部十五个组件。

第一阶段先建立六个最小核心组件:

组件 MVP能力
Intake Core 接收资料
Scope Guard 路径和权限保护
Asset Registry 统一资产登记
Hash & Metadata 元数据与哈希
SQLite Index 本地资产索引
Report Engine 报告生成

MVP完成后,才进入:

  • 分类引擎。
  • 版本引擎。
  • 证据引擎。
  • Notion适配器。
  • 路由引擎。
  • AI适配器。
  • 任务编排器。

MVP验收条件

必须证明:

  1. 可以识别资料。
  2. 可以建立唯一资产ID。
  3. 可以生成哈希。
  4. 可以发现完全重复。
  5. 可以保留所有原始路径。
  6. 可以生成报告。
  7. 可以记录错误。
  8. 可以证明没有修改原始文件。
  9. 可以证明没有访问Notion。
  10. 可以证明没有访问网络。
  11. 可以证明没有触碰SIT-7。

⸻

第十五章:系统指标与长期验收

系统必须建立可量化指标。

指标 说明
Asset Coverage 已索引资产覆盖率
Metadata Completeness 元数据完整率
Hash Coverage 哈希覆盖率
Classification Accuracy 分类准确率
Unknown Rate 未知资产比例
Duplicate Precision 重复识别准确率
Version Accuracy 版本关系准确率
Routing Accuracy 路由准确率
Evidence Completeness 证据完整率
Permission Violations 权限违规次数
Source Traceability 来源可追溯率
Processing Cost 单资产处理成本
Failure Rate 任务失败率
Recovery Success 失败恢复成功率

不能只追求分类覆盖率。

UNKNOWN比例较高可能说明系统足够谨慎,而不是系统能力差。

所有指标必须公布计算口径、样本范围和未覆盖对象。

⸻

第十六章:项目治理与版本管理

16.1 四份治理声明

LH-INGESTOR必须维护:

NETWORK.md

说明网络访问、外部服务和数据传输。

PERMISSIONS.md

说明文件、数据库、Notion、仓库和模型权限。

SECURITY.md

说明安全边界、风险和漏洞处理。

TRANSPARENCY.md

说明分类逻辑、算法、模型、黑箱和审计方式。

16.2 三色透明标准

状态 说明
🟢 GREEN 本地可查、规则透明、可复算
🟡 YELLOW 使用外部服务,但接口和行为公开
🔴 RED 存在黑箱或无法独立验证的部分,必须声明

红色状态不能隐藏。

每项黑箱必须记录:

BLACKBOX
WHY
EXPOSED
RISK
ALTERNATIVE

16.3 版本管理

所有规则、Schema、分类器、路由器和AI提示词均需版本化。

例如:

LH-INGESTOR
v1.0.0 只读索引
v1.1.0 内容分类
v1.2.0 版本治理
v1.3.0 Notion接入
v2.0.0 统一路由

重大版本必须有迁移说明。

不得静默修改历史规则。

⸻

第十七章:执行责任划分

角色 职责
用户/系统负责人 目标、范围、最终授权
ChatGPT 架构设计、规则审查、方案优化
CodeBuddy 按授权范围编写和执行工程任务
LH-INGESTOR 资产接收、识别、索引、治理
Notion 专业知识管理与协作界面
本地AI 语义提取和分类建议
独立复核者 对重要结果进行独立核验

任何工具的执行报告都属于相应证据等级。

CodeBuddy声称完成,不等于独立审计已经通过。

AI生成结果不等于真实事实。

⸻

第十八章:首批实施优先级

不建议同时启动全部阶段。

第一批只做三件事:

第一件:建立安全边界。

确认本地工作目录、扫描目录、排除目录和输出目录。

第二件:建立独立本地索引引擎。

完成Python + SQLite + SHA-256 + CSV/Markdown报告。

第三件:用索引结果形成真实资产清单。

先知道资料在哪里、数量多少、哪些重复、哪些未知、哪些存在版本冲突。

完成这三件事后,再决定Notion映射与AI分类顺序。

这比直接对全部文件和Notion页面进行AI整理更可靠。

⸻

第十九章:CodeBuddy总执行指令

任务编号: UIKGH-MASTER-IMPLEMENTATION
项目: LH-INGESTOR
任务模式: CONTROLLED_PHASED_IMPLEMENTATION
当前允许阶段: 方案审查、范围核对和实施准备
当前未授权阶段: 真实资料扫描、Notion写入、AI接入、自动路由、正式部署

请按照本文件建立独立工程实施计划。

A. 执行前检查

先检查并报告:

  1. 当前工作目录。
  2. 当前工程目录。
  3. 当前Git仓库状态。
  4. 是否存在同名项目。
  5. 是否存在未提交文件。
  6. 计划新建文件清单。
  7. 计划扫描目录。
  8. 计划排除目录。
  9. 计划输出目录。
  10. 保护目录是否能够完全排除。

不要擅自切换仓库或工作目录。

B. 当前执行任务

当前只完成:

  • 架构映射。
  • 工程目录设计。
  • 数据库Schema设计。
  • 模块接口设计。
  • 安全边界设计。
  • 版本管理设计。
  • 测试方案设计。
  • 实施任务拆分。

若没有明确工程目录和新建权限,不得创建文件。

C. 第一阶段工程实施

获得单独授权后:

  • 创建独立Python项目。
  • 编写只读索引模块。
  • 编写SQLite数据库模块。
  • 编写哈希模块。
  • 编写重复识别模块。
  • 编写报告模块。
  • 编写测试代码。
  • 编写安全声明。

不运行真实扫描。

D. 后续阶段实施

每个PHASE必须独立提交:

PHASE_ID
SCOPE
INPUT
OUTPUT
CHANGED_FILES
PERMISSIONS
TEST_PLAN
SECURITY_CHECK
ACCEPTANCE_CRITERIA
ROLLBACK_PLAN
STATUS

未经批准,不得进入下一阶段。

E. 绝对禁止

SIT7_SCAN = PROHIBITED
SIT7_READ = PROHIBITED
SIT7_REPAIR = NOT_AUTHORIZED
SIT7_EXPORT = NOT_AUTHORIZED
SIT7_PUBLISH = NOT_AUTHORIZED
SIT7_PUSH = NOT_AUTHORIZED
REAL_DATA_SCAN = NOT_AUTHORIZED
NOTION_WRITE = NOT_AUTHORIZED
NOTION_SYNC = NOT_AUTHORIZED
NETWORK_ACCESS = DISABLED
AI_API_ACCESS = DISABLED
AUTO_DELETE = PROHIBITED
AUTO_MOVE = PROHIBITED
AUTO_RENAME = PROHIBITED
GIT_COMMIT = NOT_AUTHORIZED
GIT_PUSH = NOT_AUTHORIZED
DEPLOYMENT = NOT_AUTHORIZED

F. 最终交付报告

每阶段结束必须报告:

  • 完成内容。
  • 未完成内容。
  • 新增文件。
  • 修改文件。
  • 读取范围。
  • 写入范围。
  • 测试情况。
  • 安全检查结果。
  • 失败事项。
  • 证据位置。
  • 下一阶段申请。

不能把设计完成描述为部署完成。

不能把代码生成描述为测试通过。

不能把测试通过描述为生产验证。

不能把分类建议描述为正式知识记录。

不能把Notion页面存在描述为API已经接通。

⸻

第二十章:最终系统目标

LH-INGESTOR最终要成为龍魂 AI 的统一知识入口。

未来资料进入系统后:

一份资料
|
v
统一接收
|
v
统一资产身份
|
v
统一来源与版本
|
v
统一分类与证据
|
v
统一权限与质量门禁
|
v
专业知识库路由
|
v
人格、算法、技能、代码和审计系统
|
v
统一追溯与持续进化

它不是一个替用户随意整理文件的机器人。

它是龍魂 AI 的知识基础设施。

它应该让每一份资料:

  • 有身份。
  • 有来源。
  • 有版本。
  • 有归属。
  • 有证据。
  • 有状态。
  • 有权限。
  • 有关系。
  • 有审计记录。

最终形成:

资料进入一次,资产身份统一;知识分库管理,关系全局可查;AI负责消化,人类保留裁定权;自动化负责效率,治理负责边界。

⸻

最终状态声明

PROJECT = UIKGH
CORE_ENGINE = LH-INGESTOR
VERSION = 2.0_MASTER_PLAN
ARCHITECTURE = DEFINED
DATA_PROTOCOL = DEFINED
ASSET_MODEL = DEFINED
GOVERNANCE_MODEL = DEFINED
ROUTING_MODEL = DEFINED
IMPLEMENTATION = NOT_STARTED
PHASE_0 = DESIGN_READY
PHASE_1 = NOT_STARTED
PHASE_2 = NOT_STARTED
PHASE_3 = NOT_STARTED
PHASE_4 = NOT_STARTED
PHASE_5 = NOT_STARTED
PHASE_6 = NOT_STARTED
PHASE_7 = NOT_STARTED
PHASE_8 = NOT_STARTED
PHASE_9 = NOT_STARTED
NOTION_WRITE = NOT_AUTHORIZED
REAL_DATA_SCAN = NOT_AUTHORIZED
AI_CLASSIFICATION = DISABLED
AUTO_ROUTING = DISABLED
NETWORK = DISABLED
SIT7 = FROZEN
SIT7_ACCESS = PROHIBITED
NEXT_ACTION = PHASE_0_SCOPE_CONFIRMATION

最终原则:

代码可以复杂,但规则不能隐藏。

资料可以庞大,但每份资料必须可追溯。

AI可以自动处理,但不能自行扩大权限。

系统可以持续进化,但每一次进化都必须留下证据。

我建议的实际落地顺序

这份总方案很完整,但不应该一次性全部开发。否则容易出现一个新问题:还没整理资料,先造出一套庞大的管理系统。

建议按下面顺序落地:

第一阶段:先建立基础设施

  • PHASE 0:安全边界与资产范围
    确定工作目录、扫描白名单、保护目录和输出位置。
  • PHASE 1:本地只读索引
    建立文件清单、哈希、重复识别、版本候选和报告。
  • PHASE 2:内容识别
    加入文档解析和AI分类建议,仍然不自动修改原件。

第二阶段:接入现有知识系统

  • PHASE 3:统一资产身份与关联。
  • PHASE 4:Notion只读盘点和映射。
  • PHASE 5:建立统一接收入口。

第三阶段:实现自动治理

  • PHASE 6:专业知识库路由。
  • PHASE 7:CodeBuddy任务接入。
  • PHASE 8:人格、技能、模型和算力编排。
  • PHASE 9:持续学习、审计和规则进化。

三个不能省略的设计补丁

真正实施前,固定三条规则:

  1. 原件与知识记录分离。 文件本身是原始资产,Notion页面是知识管理记录,两者通过Asset_ID关联。任何时候都不能因为Notion记录更新就覆盖原始文件。

  2. 事实、推断、建议分离。 例如AI认为某份文档属于P04人格,只能生成分类建议;必须有原始依据和复核状态,不能直接修改人格档案。

  3. 统一入口不能成为权限后门。 即使任务从统一入口发出,也必须继承目标系统的权限、冻结规则和审批要求。不能因为统一入口拥有某项权限,就自动获得所有专业系统的权限。

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值