历史完整正文：统一前文章逐篇保留

这里保存课程统一前提交 f2cdf30 中的完整 Markdown 原文。它不是摘要，也不是重新概括后的版本；两个目录中的历史文章按原文件逐篇复制，用来保证任何细节、ASCII 图、代码、案例和面试说明都不会因课程重组而消失。

历史完整正文
├── 01-architecture-originals
│   ├── 原体系结构与硬件目录的 16 篇 Markdown
│   ├── CPU、Cache、NUMA、GPU、CUDA、OpenMP、MPI
│   └── NPU、训练优化、性能工具与趋势
│
└── 02-parallel-originals
    ├── 原并行计算目录的 14 篇 Markdown
    ├── 并行基础、CPU/GPU、CUDA、异构与分布式
    └── 并行模式、性能工程、案例与学习项目

归档、备份与当前文档的区别

三者解决不同问题。

类型	目标	是否日常编辑	主要验证
当前文档	提供最新权威知识	是	内容准确、链接和构建
归档	保留可查阅历史版本	很少	来源、完整性和可读性
备份	灾难后恢复数据	否	可恢复性与保留策略

归档需要稳定入口和上下文。 仅把旧文件压缩保存虽然可以备份，却不方便读者搜索、链接和比较。

当前文档允许重构、合并和更新。 归档则优先保持来源可追溯，不能无记录地改写历史语义。

为什么知识库需要历史层

课程重构通常会：

• 合并重复主题；
• 统一术语；
• 调整编号；
• 缩短冗余内容；
• 更新 API 与工具；
• 改变学习顺序；
• 删除失效示例。

这些修改提高当前课程质量，却可能隐藏历史细节和决策过程。

历史层允许回答：

• 某个旧链接原来指向什么；
• 某段代码在哪个版本出现；
• 当前结论与旧结论有什么差异；
• 合并时是否遗漏了图、案例或边界；
• 某个术语为什么被替换；
• 旧性能数字来自什么环境。

来源提交

本归档声明来源为 Git 提交 f2cdf30。

提交哈希提供仓库内可验证定位。 它比“2025 年旧版”更精确。

git show --stat f2cdf30
git ls-tree -r --name-only f2cdf30
git show f2cdf30:path/to/file.md

查证时应使用仓库实际对象，而不是依赖网页缓存或本地记忆。

文件集合完整性

集合完整性检查原目录中的每篇文章都进入归档。

步骤包括：

1. 列出来源提交目标目录；
2. 列出当前归档目录；
3. 规范化路径分隔符；
4. 比较文件名集合；
5. 检查重命名映射；
6. 记录新增、缺失和额外文件；
7. 人工复核特殊 README 与 Overview。

source paths
  - archived paths
  = missing

archived paths
  - source paths
  = extra or renamed

文件数量相同不代表集合相同。 必须比较路径和映射。

单文件完整性

单文件完整性关注内容是否在复制、编码和格式化中损坏。

检查：

• 标题；
• Frontmatter；
• 段落；
• 代码围栏；
• ASCII 图；
• 表格；
• 图片；
• 站内链接；
• 外部链接；
• 文件结尾；
• 编码和换行。

可以比较 Git Blob 或规范化后的哈希。 如果为了修复链接而改动，应记录差异原因。

路径映射

课程合并后，旧目录与新目录可能不是一一对应。

old architecture article
  -> current unified article
  -> archived original copy

映射表至少记录：

• 旧路径；
• 归档路径；
• 当前权威路径；
• 迁移类型；
• 是否需要重定向；
• 备注。

迁移类型可能是直接移动、合并、拆分、替代或仅归档。

站内链接策略

归档文章中的相对链接可能因目录移动而失效。

处理方式按优先级：

1. 保留原链接并提供兼容重定向；
2. 在归档复制中修复路径并记录变更；
3. 添加“当前版本”链接；
4. 无目标时明确标记历史缺失；
5. 禁止生成不存在的替代链接。

修复链接不能改变正文技术结论。

外部链接与引用

外部文档可能移动、下线或更新语义。

归档应保留原引用，并在必要时增加：

• 原访问日期；
• 对应软件版本；
• 新地址；
• 存档地址；
• 当前替代资料；
• 失效说明。

不要把新版文档链接直接替换旧版后，继续声称它支持原文的版本相关结论。

代码示例的历史环境

旧代码可能依赖：

• 已弃用语言标准；
• 旧编译器；
• 旧 CUDA Toolkit；
• 特定 MPI；
• 已变化的构建系统；
• 旧操作系统；
• 不再可用的硬件。

归档代码首先用于理解历史正文。 如果要运行，应明确复现环境。

可以补充现代迁移说明，但不要把原代码完全替换后仍称为原文。

性能数字的解释

性能数字只对记录的工作负载和环境成立。

归档数字需要尽量保留：

• CPU/GPU 型号；
• 内存和拓扑；
• 编译器和选项；
• 输入规模；
• 线程、进程和设备数；
• 预热和样本；
• 正确性标准；
• 测量命令。

缺少环境时，数字只能作为历史叙述，不能用于当前选型。

术语变化

硬件和并行领域术语会随标准与厂商资料演进。

维护者可以增加术语注释：

historical term
  -> current preferred term
  -> reason or scope difference

注释应与原文区分，避免读者误以为旧文当时使用了现代术语。

安全与隐私修订

历史归档不是泄漏信息的理由。

发现以下内容必须处理：

• 真实密钥；
• Token；
• 内部账号；
• 私有服务器地址；
• 个人敏感信息；
• 不应公开的数据；
• 有危险副作用的无警告命令。

删除或脱敏后应留下修订说明，但不能继续暴露原值。

构建与渲染验证

归档文章仍进入 VitePress 构建，因此必须保证 Markdown 可解析。

重点检查：

• Frontmatter 语法；
• 围栏是否闭合；
• 表格结构；
• 标题层级；
• 站内链接；
• 图片路径；
• 不支持的代码语言；
• HTML 使用策略。

语法高亮降级警告与构建错误应区分。 归档可保留冷门语言标签，也可以按当前渲染支持注明降级。

搜索与导航

归档内容可能在站内搜索中与当前文章同时出现。

标题、摘要和页面提示应让读者知道：

• 这是历史内容；
• 当前权威入口在哪里；
• 来源版本是什么；
• 哪些内容可能过时；
• 如何进行比较。

仅隐藏侧边栏不能解决搜索歧义。

维护变更分类

归档允许的变更分为：

无语义修复

• 断链；
• 编码；
• 围栏；
• 图片路径；
• 安全脱敏。

注释性补充

• 当前入口；
• 版本边界；
• 术语变化；
• 复现环境；
• 已知失效。

内容迁移

把仍有价值的知识核验后补到当前权威文章。 归档原文保持不变或记录迁移标记。

归档评审清单

• 来源提交明确；
• 文件集合完整；
• 路径映射可查；
• 单文件无截断；
• 链接有处理策略；
• 代码环境有说明；
• 性能数字不过度外推；
• 敏感信息已清理；
• 当前权威入口明确；
• VitePress 构建通过。

怎样阅读

• 第一次学习：先按上级目录的 00～14 权威课程阅读，它负责由浅入深建立统一心智模型。
• 查找旧内容：进入下面两个原文分组，标题和正文保持统一前版本。
• 核对内容：本目录以 Git 提交 f2cdf30 为来源，可用 Git blob/hash 再次验证。

两套原文

1. 原“计算机体系结构与硬件”全部文章
2. 原“并行计算”全部文章

课程合并只改变学习入口与知识顺序，不再以删减旧正文作为代价。

为什么需要历史正文

知识库重组常把重复主题合并为一条学习路径，但“内容重复”不代表“表达细节等价”。旧文可能保存了具体代码、图示、面试追问、工具命令和当时使用的术语。直接删除会让旧链接失效，也会使读者无法追溯新文章为何作出某种取舍。因此本目录承担的是可审计归档，而不是第二套持续演进的权威课程。

归档与备份不同。备份用于灾难恢复，通常按整个仓库恢复；归档用于日常查阅，需要稳定路径、来源说明和清晰边界。这里记录来源提交 f2cdf30，使读者能够用 Git 比较内容，确认归档不是后续重新生成的摘要。

权威课程与归档的关系

历史提交 f2cdf30
        │ 原文复制与路径保留
        v
15-original-deep-dives
        │ 提供细节查阅和差异核对
        v
当前权威课程 00～14
        │ 统一术语、消除重复、组织学习顺序
        v
后续维护只进入权威课程

新读者应先读当前权威课程，因为它建立统一概念和前置关系；当需要旧案例、旧图或迁移前的完整论述时，再进入归档。维护者发现归档中的有效内容尚未被吸收，应把事实核验后补到权威文章，而不是直接编辑历史快照。否则归档会失去“可与原提交核对”的意义。

查阅和核对方法

阅读归档时先确认文章属于体系结构原文还是并行计算原文，再检查同主题的当前文章。两者结论冲突时，以标准、硬件厂商文档和当前已核验正文为准；历史正文反映的是当时记录，不自动代表最新事实。可以使用 git show f2cdf30:<path> 查看源版本，使用 git diff f2cdf30 -- <path> 判断内容是否完全对应。

归档保留不意味着所有旧说法都应继续传播。版本相关 API、硬件参数和工具界面可能变化，旧性能数字也只对原工作负载有效。引用归档内容时，应同时说明来源版本和适用边界。

完整性的验收原则

本目录应保持两类完整性：文件集合完整，确保原目录中的文章没有漏失；单文件内容完整，确保代码块、ASCII 图和链接上下文没有被截断。目录页负责解释来源、用途和阅读方法，各原文页负责保存细节。只有明确的安全问题或法律原因才应修改归档，并留下变更说明。

通过这种分层，课程可以继续演进，同时保留可追溯证据。读者既获得清晰入口，也不会因为一次目录重构失去过去积累的技术材料。

使用归档时的实际场景

当外部笔记或旧书签仍指向迁移前文章时，归档提供稳定落点；当新课程删去了一个过细但仍有参考价值的案例时，可以在这里找到完整上下文；当维护者怀疑课程重写改变了技术结论时，可以把当前正文、归档快照和来源提交三方比较。归档因此同时服务于链接兼容、知识恢复和编辑审计。

它不适合作为新内容的默认落点。新的实验、勘误和版本更新应写入当前权威课程，并在必要时从权威文章链接到历史材料。若直接在归档中持续追加，新旧版本会再次分叉，读者也无法判断哪一份值得信任。

维护归档还要关注资源可读性：相对图片和站内链接在目录移动后可能失效，代码依赖的版本可能已停止支持。修复链接时应尽量保持正文语义，并在修改影响历史一致性时留下说明。对于无法运行的旧示例，应标注其历史环境，而不是悄悄改写成当前 API 后仍声称是原文。

最终判断很简单：需要系统学习或最新结论时读权威课程，需要追溯旧内容和重构证据时读本目录。两者目的不同，才能在避免重复维护的同时保留知识连续性。