学习与维护方法 — Wu Chenfeng

本知识库以主要技术问题组织正文，领域入口见知识地图。阅读时沿输入与数据变化理解机制，维护时把文章边界、命名、归属和验证状态分别记录。

定向检索

Obsidian 搜索正式知识时使用：

text

path:"知识库" 关键词

日常阅读从正式知识开始。正文中的相关主题链接用于继续学习。本机维护来源用于核对原始语境、例子和实现细节。

文章阅读

先找到这项技术解决的问题，再看它如何改变数据或执行流程。遇到公式时，先确认变量代表什么，不需要先背公式。

读完后至少能用自己的话回答：

它解决什么问题？
核心机制是什么？
成本转移到了哪里？
哪些条件下会失效？
在引擎或帧捕获中能看到什么证据？

再选一个正文输入，手工写出中间状态与输出。随后只改变一个条件，例如共享边方向、纹理尺寸、任务先后或对象寿命，预测哪里先出错，再用正文定位原因。能复述定义而无法完成这两次推演时，应回到对应机制补齐理解。

这些问题用于检查理解，不需要变成固定的文章章节。

知识补充

主归属确认

补充新术语之前，先检查它是否属于现有主题中的一个小节。独立文件的依据是独立的主要技术问题。

例如各向异性过滤通常作为纹理采样专题的一节，与采样足迹和 mip 选择一起解释。独立平台格式与压缩预算可以进入压缩专题。

关系与细节

如果一个概念已经存在，但与上下游技术没有联系，应先补清楚关系。例如讲 PCSS 时，需要先说明 Shadow Map 的深度比较、PCF 过滤和光源尺寸，而不是直接增加采样代码。

内容与证据类型

已核验事实：已经核读规范、官方文档、源码、论文或可靠技术演讲，并记录支持该断言的具体位置、版本与适用条件。
解释和推导：为了帮助理解而重新组织的说明。
实践记录：某个版本、平台或项目中的观察结果。

实践记录不能直接当成所有引擎和硬件都成立的规则。

来源优先级

图形 API 规范、引擎官方文档和源码。
论文、SIGGRAPH/GDC 等正式技术演讲。
GPU 厂商和平台官方资料。
有完整推导或实验的技术文章。
课程笔记、视频转录和个人总结。

课程笔记适合提供解释线索，但底层细节仍需要更可靠的来源核验。

代码示例

代码用于说明算法的关键数据流。适合加入正文的内容包括空间变换、资源读写、采样循环、索引计算、同步边界和核心公式。与主问题无关的窗口创建、资源路径等工程样板可以通过来源工程查阅。若错误处理、资源管理或同步本身就是主问题，对应分支与状态变化应在正文展开；抽象函数需要给出定义或链接到负责该机制的专篇。

代码长度由解释与复现需要决定。机制片段裁剪工程样板，完整样例保留必要上下文，并满足这些条件：

代码块标明 glsl、hlsl、cpp、csharp 或其他准确语言；
代码前说明输入、输出、坐标空间、资源格式和必要前提；
代码中的变量名称与正文公式保持一致；
代码后解释执行顺序、成本和可观察的错误现象；
示例包含一个可以独立完成的验证方法。

跨 API 的算法优先给出 API 中立伪代码或一个最小 Shader 函数。涉及资源绑定、内存布局和同步语义时，再补充对应 API 或引擎写法。机制片段按标注范围表达当前机制，并说明省略的状态创建与生命周期管理。完整样例提供复现所需上下文，验证结果对应实际运行的入口与环境。

引用外部代码时保留来源名称、章节或源码路径，并确认许可证允许当前使用方式。知识库采用重新组织和改写后的最小示例。代码来自个人实验时，记录运行环境和验证结果。

全库示例覆盖检查

每篇适合代码化的正式知识文章至少包含一个关键示例。示例可以是 Shader、C++、C#、Python、命令、配置、数据结构定义或伪代码。导航页、术语表和纯概念索引不强制加入代码。

示例需要交代与理解机制直接相关的前提：

输入、输出和数据单位；
坐标空间、资源格式或对象生命周期；
API 状态、同步条件或调用顺序；
省略的工程样板和适用边界。

代码后的解释需要沿执行顺序说明关键步骤，并给出至少一种可观察的错误现象或验证方法。示例覆盖检查关注知识文章是否具备连接概念和工程的入口，不以代码块数量衡量文章质量。

不确定内容

没有足够证据时直接标记：

[!warning] 待补充当前资料不足以确认这一实现是否适用于所有引擎版本或 GPU。

尚未核实的机制保留问题、证据缺口和核查入口，推断明确写出成立前提。

双链使用

使用 Obsidian 打开仓库根目录，正式双链采用知识库下唯一的编号路径。Obsidian 可据文件路径解析，静态检查器以 知识库/ 作为这些双链的解析基准。双链从编号目录开始书写，例如 [[06_纹理技术/纹理采样与过滤]]。

双链只连接真正有帮助的关系：

前置知识；
数据或执行依赖；
容易混淆的对照技术；
后续可以继续深入的主题。

正文已经能自然说明的普通名词不必全部链接。

文章边界

满足以下情况之一时再考虑拆分：

两部分解决的问题完全不同；
阅读顺序已经无法自然组织；
一部分可以独立维护，并且有大量自己的来源和下游链接；
修改一个部分时经常误触另一个部分。

文章围绕一个完整问题组织，共享主要子机制的内容可以保留在同一专题。TAA、历史累积与时域重建共用抖动、重投影和校验流程，集中讲解更容易追踪数据。独立的生命周期、API 语义或版本维护边界适合专篇。

篇幅用于满足解释需要。检查机制、不变量、代码、成本、失效条件和验证证据，比固定字节数更能反映深度。检查项用于验收，正文按自然流程组织。

引擎实现的证据

实现说明记录引擎版本、包版本或源码提交、API 与平台、相关设置、源码入口和核对日期。规范与源码核对确认语义，完整工程编译、运行与帧捕获分别记录。只有实际执行并取得结果的检查才写为通过。

概念页提供稳定原理，实现页提供版本相关入口，验证页说明实验与工具。内容较少时可在同页分节；跨页内容通过前置知识、执行依赖与下一步引用连接。

模块完成检查

是否只写了定义，没有解释机制？
是否把性能收益说清楚到 CPU、GPU、带宽、内存或延迟？
是否混淆了 API 用法和底层原因？
是否存在没有来源的引擎内部结论？
是否有可以合并的重复说明？
是否可以通过一个小实验、Profiler 或帧捕获验证？

作者工作流

文章先确定一个主问题，再分别记录边界与正文动作。正文按现象、原因、机制和实现带读者推理，语言标准见技术中文写作规范，标题按主问题与行业习惯命名，范围与九维验收见知识库实施规范。

技术图与图片资产

流程、空间、依赖和寿命关系优先使用确定性Mermaid/SVG等源文件。结果证据采用真实图片，来源图保存作者、原文、许可与目标位置；用户指定图片保留原始意图。必要的技术解释可用AI图，图片数量按解释需要决定。

采用资产写入资产登记，记录类型、哈希、相对路径、目标文章章节、图注和来源/许可。未确认公开复制许可的图片登记为候选，并保留原文链接。

复现与检查状态

完整样例给入口、数据、环境、操作、预期和失败判据；片段声明所属阶段和遗漏项；伪代码明确抽象接口。规范核对、数学实验、代码编译、引擎运行、捕获和性能测量分别记录。九维验收逐项给依据，写作复读覆盖全库，包括边界保持的文章。

范围与证据报告说明复读和验收的覆盖范围；逐篇质量矩阵保存每篇文章的状态与定位依据。检查结论与正文哈希关联，修改正文后需要重新检查受影响的维度。