经济实用的可处理资产归档方案

DeepSeek 与 Codex 的归档分工：从低成本归档到正式方法论整合

在个人方法论系统中，“归档”并不是一个单一动作。

原始对话、项目复盘、Incident、Obsidian 笔记等材料，通常需要先经过一次低成本整理，再进入正式 Repository。若把这两个阶段混在一起，既容易浪费高能力模型额度，也容易让正式方法论仓库被尚未验证的内容污染。

更合理的做法，是把归档拆成两个层级：

DeepSeek
= 归档层
= Raw Source → Archive Package
 
Codex
= 整合层
= Archive Package → Canonical Repository

前者负责“把散乱信息整理成可处理资产”，后者负责“把这些资产正式纳入方法论系统”。

---

一、整体架构

最基本的流程如下：

Raw Source
↓
DeepSeek Archivist
↓
Archive Package
↓
Codex Repository Maintainer
↓
Canonical Artifact
↓
Dashboard Review
↓
Commit & Push
↓
GitHub CI

其中：

Raw Source

可以是：

• AI 长对话；

• 项目复盘；

• Debug / Incident；

• Obsidian 笔记；

• 已完成但尚未入库的 Skill；

• 方法论讨论；

• 学习理论草稿；

• Agent 工作记录。

Archive Package 则是经过整理后的高密度中间层，不属于 canonical truth。

---

二、DeepSeek 单次归档 SOP

适用场景

DeepSeek 单次归档适合处理一个相对完整的主题，例如：

一段 AI 对话
一个 Incident
一篇 Obsidian 笔记
一次项目复盘
一个研究主题

理想状态是：

1 个主要 Source
→ 1 个 Archive Package

---

目录结构

可以使用如下 staging workspace：

AI_Methodology_Archive_Staging/
├─ instructions/
│  ├─ Methodology_Archival_SKILL.md
│  └─ Archival_SOP.md
│
├─ inbox/
│  └─ source.md
│
└─ output/

其中：

instructions/
= 怎么归档
 
inbox/
= 归档什么
 
output/
= 归档结果

---

Step 1：确定本轮 Scope

归档前先明确：

本轮处理哪些 Source

避免把 Inbox 中其他遗留文件顺带重新归档。

例如：

本轮：
inbox/prepare-sync-incident.md
 
不处理：
inbox/old-note.md
inbox/deferred-topic.md

---

Step 2：执行 Preservation Gate

任何 Source 都不能直接默认压缩。

需要先判断：

COMPRESS_ALLOWED
PRESERVE_FULL
REFERENCE_CANONICAL

COMPRESS_ALLOWED

适用于：

• 普通长对话；

• 探索性讨论；

• Incident；

• 临时笔记；

• 项目复盘。

可以进行结构化压缩。

PRESERVE_FULL

适用于：

• 完整 Skill；

• 完整 SOP；

• 完整 Principle；

• Schema；

• Tests；

• 已较成熟但尚未确认 canonical 状态的 Artifact。

处理原则：

保留完整原件
+
Archive Package 只做导航和摘要

不得：

完整 Artifact
→ 摘要
→ 后续根据摘要重建

REFERENCE_CANONICAL

适用于已经存在于正式 Repository 的 Artifact。

处理方式：

记录 Artifact ID / path / version
↓
对新讨论生成 change candidate
↓
后续 Codex重新读取 current canonical Artifact

Archive Package 不替代 Repository 本体。

---

Step 3：区分信息归属

需要明确区分：

FACT
USER_EXPLICIT
USER_ACCEPTED
AI_PROPOSED
INFERENCE
HYPOTHESIS
SUPERSEDED
OPEN_QUESTION

这一步非常重要，因为方法论归档最大的风险之一，是把“AI曾提出过的方案”误写成“已经确认的方法”。

例如：

AI：
建议把某 Skill 升级到 v0.2。
 
用户：
先不要改，继续测试。

正确归档：

AI_PROPOSED
+
USER_EXPLICIT: defer

而不是：

USER_ACCEPTED: upgrade to v0.2

---

Step 4：提取可复用结构

DeepSeek 的主要任务包括：

Minimal Timeline
Root Cause
Reusable Lessons
Candidate Artifacts
Tests / Regression
Human Gates
Deferred Candidates
Open Questions

重点不是“把内容总结得很短”，而是：

尽量减少后续 Repository Maintainer 重新阅读原始材料的成本。

---

Step 5：生成 Archive Package

推荐命名：

YYYY-MM-DD__topic__archive-package.md

例如：

2026-09-02__prepare-sync-incident__archive-package.md

---

Step 6：人工快速检查

不需要全文逐句审阅。

只检查几个高风险点：

有没有把 AI 建议写成已确认结论？
有没有漏掉明确决定？
有没有漏 SUPERSEDED？
有没有压缩成熟 Artifact？
有没有幻觉 Repository 状态？
有没有擅自说“已经 canonical”？

没有明显问题即可接受。

---

三、DeepSeek 批量归档 SOP

当 Inbox 中已经积累多个 Source 时，可以批量执行。

但需要注意：

批量输入不等于生成一个巨大的 Archive Package。

假设有：

Source A
Source B
Source C
Source D

推荐：

A → Package A
B → Package B
C → Package C
D → Package D

而不是：

A+B+C+D
→ mega-package.md

除非这些 Source 本身属于同一个连续事件或同一个项目。

---

推荐目录

archive-run-2026-09-02/
├─ inbox/
│  ├─ source-a.md
│  ├─ source-b.md
│  ├─ source-c.md
│  └─ source-d.md
│
├─ output/
│  ├─ a__archive-package.md
│  ├─ b__archive-package.md
│  ├─ c__archive-package.md
│  └─ d__archive-package.md
│
└─ RUN_MANIFEST.md

---

Step 1：建立 Run Scope

先声明：

本轮真正处理哪些文件

避免：

• 已归档 Source 被重复处理；

• Deferred 内容意外进入正式流程；

• 不相关项目被混入当前批次。

---

Step 2：Source 状态分类

可以只使用少量状态：

INBOX
ARCHIVED
DEFERRED
OUT_OF_SCOPE

批量运行时先筛掉：

ARCHIVED
DEFERRED
OUT_OF_SCOPE

只处理新的 INBOX。

---

Step 3：每个 Source 独立归档

每个 Source 都单独执行：

Preservation Gate
↓
Attribution
↓
Extraction
↓
Archive Package

这样单个 Package 出现问题时，不会污染整个批次。

---

Step 4：做 Cross-Package Analysis

所有 Package 完成后，再做一次批次级分析。

主要检查：

Package A 和 Package B
是否在讨论同一个 Artifact？
 
Package C
是否已经 supersede Package A 的旧方案？
 
多个 Candidate
是否实际上是同一个概念？

这一阶段只做关联，不直接 canonicalize。

---

Step 5：生成 RUN_MANIFEST

例如：

run_id: archive-2026-09-02-01
 
processed:
  - source-a.md
  - source-b.md
  - source-c.md
 
outputs:
  - a__archive-package.md
  - b__archive-package.md
  - c__archive-package.md
 
deferred:
  - source-d.md
 
repository_integration_required: true

核心原则：

Source independence first
Cross-package consolidation second

---

四、Codex 单次整合 SOP

Codex 更适合被视为：

Repository Maintainer

它的主要输入不应是数万字原始聊天，而应该是：

Archive Package
+
需要 PRESERVE_FULL 的原件

严格来说，这一步不是“第一次归档”，而是：

Canonical Integration。

---

Step 1：Repository Preflight

进入正式修改前，需要读取：

AI_BOOTSTRAP
AGENTS
SYSTEM-ONTOLOGY
CONVENTIONS
Registry
git status

先确认当前 Repository 状态，而不是依赖旧聊天记忆。

---

Step 2：读取 Archive Package

重点关注：

Candidate Artifacts
Preserved Artifacts
Change Candidates
Human Gates
Tests
Open Questions
Deferred

---

Step 3：解析 Preservation Mode

COMPRESS_ALLOWED

Archive Package 可以作为主要信息输入。

PRESERVE_FULL

必须读取完整 Artifact 原件。

不能：

Archive Summary
→ 重建 Artifact

REFERENCE_CANONICAL

必须读取：

当前 Repository 中的 canonical Artifact

然后：

Current Canonical
+
New Evidence / Change Candidate
↓
Semantic Diff

---

Step 4：Duplicate / Related Check

每个 Candidate 判断：

CREATE_NEW
UPDATE_EXISTING
ALREADY_COVERED
RELATED_BUT_DISTINCT
DEFER

优先顺序通常应是：

UPDATE_EXISTING
>
CREATE_NEW

避免 Repository 越积越多的近义 Artifact。

---

Step 5：Ontology Classification

确认内容究竟属于：

Theory
Conceptual Model
Principle
Policy
SOP
Workflow
Playbook
Skill
Protocol
Template
Schema
Test
Benchmark
Decision Record
Source / Case

重要内容并不等于 Skill。

---

Step 6：Human Gate Check

例如：

Policy 创建
核心 Principle 修改
Ontology 修改
稳定 ID 修改
Artifact 删除
稳定 Artifact 合并
MAJOR version

遇到 Human Gate 时不应自行决定。

---

Step 7：执行最小修改

原则：

只改真正需要改的地方

避免：

一个小 change candidate
→ 整个 Artifact 重写

最好采用：

semantic diff

而不是重新生成。

---

Step 8：补 Tests / Examples

真实失败：

→ Regression Test

新 Skill：

→ normal / boundary / failure cases

---

Step 9：Regenerate Derived Views

例如：

Registry
Dashboard

这些属于 derived views，不应手工维护。

---

Step 10：统一 Validation

包括：

repository validation
tests
registry consistency
dashboard build
diff check
secret scan

---

Step 11：输出 Semantic Diff Report

至少报告：

创建了什么
更新了什么
为什么
哪些被 Deferred
哪些存在 Human Gate
changed files
tests
git status

此时停止。

不自动：

commit
push

---

Step 12：Dashboard Review

正式发布：

Dashboard
↓
Prepare Sync
↓
Review
↓
Commit & Push
↓
GitHub CI

---

五、Codex 批量整合 SOP

Codex 批量模式通常比“每一个 Archive Package 启动一次 Codex”更经济。

推荐：

3–5 个 Archive Packages
→ 1 次 Codex Session

---

为什么适合批量

因为每一次 Codex启动通常都会重复：

读取 Bootstrap
读取 Registry
git status
validation
tests
build

如果每一个 Package 都独立启动一次：

Package A → 一整轮
Package B → 一整轮
Package C → 一整轮

会产生大量重复成本。

---

Step 1：Repository Preflight 只执行一次

AI_BOOTSTRAP
Ontology
Conventions
Registry
git status

---

Step 2：读取所有 Package 的高密度部分

第一遍不必全文逐字阅读。

优先：

Executive Summary
Candidate Artifacts
Preservation Manifest
Change Candidates
Human Gates

然后建立：

Batch Integration Plan

---

Step 3：Cross-Package Deduplication

例如：

Package A
→ freshness-verification change candidate 1
 
Package C
→ freshness-verification change candidate 2

不要：

先改一次
再改一次

而应该：

A + C
↓
同一个 target Artifact
↓
一次综合 Semantic Diff

---

Step 4：按 Artifact 聚合

批量归档真正需要优化的单位不是：

Package

而是：

Target Artifact

例如：

Package A ─┐
           ├→ Skill X
Package C ─┘
 
Package B ───→ Principle Y

最终应按：

Skill X
Principle Y

处理。

---

Step 5：先处理无 Human Gate 项

如果一个批次包含：

Package A
→ 普通 Skill update
 
Package B
→ Policy Human Gate
 
Package C
→ Example update

不必因为 Package B 需要人工决定，就让整个批次停摆。

可以：

A → 处理
C → 处理
B → Human Gate queue

前提是彼此没有依赖。

---

Step 6：统一 Validation

所有能处理的变更完成后，只跑一次完整：

validation
tests
registry
dashboard
diff check
secret scan

---

Step 7：生成 Batch Report

例如：

Package A
→ UPDATE_EXISTING
 
Package B
→ HUMAN_GATE
 
Package C
→ merged with Package A
 
Package D
→ DEFERRED

同时报告：

Changed Artifacts
Changed Files
Tests
Human Gates
Deferred
Semantic Diff

---

Step 8：决定 Commit 边界

“同一次批量归档”不代表必须一个 commit。

应按语义变化判断。

例如：

Skill changes
+
unrelated Dashboard changes

可能适合拆开。

而：

同一个 Archivist system 的 Skill + tests + protocol

可能适合一个 commit。

---

六、四种模式的关系

可以概括为：

模式	输入	输出	是否碰 canonical Repository
DeepSeek 单次	1 个 Source	1 个 Archive Package	否
DeepSeek 批量	N 个 Source	N 个 Package + Run Manifest	否
Codex 单次	1 个 Package	1 组 canonical integration	是
Codex 批量	3–5 个 Package	聚合后的 canonical integration	是

更直观地表示：

                     单次                     批量
 
DeepSeek        1 Source                N Sources
                   ↓                       ↓
            1 Archive Package       N Archive Packages
                                            +
                                      Run Manifest
 
 
Codex         1 Archive Package        3–5 Packages
                   ↓                       ↓
            1 Integration          Cross-Package Merge
                   ↓                       ↓
             Validation            Batch Validation

---

七、推荐的日常默认模式

多数情况下，并不需要每天打开 Codex。

更省成本的方式是：

日常发现高价值信息
↓
DeepSeek 单次归档
↓
Archive Package
↓
暂存

等积累到：

3–5 个 Archive Packages

再：

Codex Batch Integration
↓
Dashboard Review
↓
Commit & Push

因此长期默认工作流可以压缩为：

Source
↓
DeepSeek
↓
Archive Package
↓
积累
↓
Codex Batch Integration
↓
Dashboard
↓
GitHub

---

八、什么时候不应该等批量

以下情况可以直接：

DeepSeek 单次
↓
Codex 单次

例如：

• P0 级重要方法；

• 马上要投入实际使用的 Skill；

• 重大 Incident；

• 重要 Policy；

• 核心 Principle；

• Repository 安全问题；

• 会影响后续大量工作的关键决策。

这类内容的正式化收益高于节省一次 Codex Session 的收益。

---

九、归档系统真正优化的不是“文件数量”

这套流程最终要减少的是三种浪费：

重复阅读
重复判断
重复验证

DeepSeek 解决：

重复阅读

Archive Package 解决：

重复理解

Codex 批量处理解决：

重复 Repository 初始化与验证

因此真正理想的状态不是：

Archive Package 越短越好。

而是：

后续 Maintainer 为了做出正确决策，需要重新打开原始材料的次数越来越少。

可以用一个长期指标衡量：

raw_source_reopen_rate

例如：

10 个 Archive Packages
↓
Codex 只有 1 个需要重新阅读 Raw Source
 
raw_source_reopen_rate = 10%

如果这个比例持续下降，同时没有出现错误归因、错误压缩和错误 canonicalization，就说明归档系统正在真正降低认知成本，而不仅仅是在制造更多 Markdown 文件。

---

十、最终原则

整个归档体系可以压缩成三句话：

DeepSeek 负责把散乱信息变得可处理。
 
Codex 负责把可处理的信息变成正式资产。
 
Repository 只接收经过查重、验证和人工边界控制的内容。

以及一条贯穿整个流程的保真原则：

压缩上下文，不压缩成熟方法论。

这使得低成本模型可以承担大量第一遍阅读和整理工作，同时又不会让正式方法论仓库变成低质量摘要的堆积场。