从提问到知识库：我的 AI 辅助学习与知识沉淀工作流

过去，当我想弄清楚一个陌生的技术问题时，最自然的方法通常是搜索。

打开 Google，输入关键词，依次阅读官方文档、博客、Stack Overflow、论坛、论文或视频。某篇文章解释了一个概念，却默认你已经理解另外三个概念；另一个回答解决了实际问题，却没有解释为什么；还有一些资料可能已经过时。真正耗费时间的，往往不只是找到资料，而是把这些分散的信息筛选、连接、比较，并最终在脑中建立起一个完整的知识结构。

AI 很大程度上改变了这个过程。

现在，当我突然想弄懂一个问题时，我可以直接从一个很模糊的疑问开始：先让 AI 帮我展开这个领域的知识地图，再沿着其中不理解的地方不断追问；当我觉得自己已经理解之后，还可以让它反过来向我提问，检查那些“好像看懂了、其实没有真正弄明白”的地方。

但我渐渐发现，仅仅完成一次对话仍然不够。

一次 AI 对话很容易随着时间被遗忘。今天花一个小时弄懂了 Render Graph、物理引擎或 Git Rebase，几个月后再遇到类似问题时，可能只剩下一些模糊印象。于是我开始尝试把这些探索进一步整理：重新设计知识结构，确认重要结论，查证关键来源，再让 AI 将它们组织成一篇结构完整的 MDX 文章，配上 Mermaid、公式、表格或必要的交互图表，最终放进自己的 FumaDocs 网站。

这样一来，一次临时的好奇心就不再只留下几段聊天记录，而会经历这样的变化：

我越来越喜欢这种方式，并不是因为它可以快速“生产文章”，而是因为它形成了一个很自然的闭环：

想知道一个东西 → 真正把它弄懂 → 把理解结构化 → 留下一份以后还能继续使用和更新的知识。

这里的文章更像是一种知识载体。

真正重要的并不是文字究竟由谁逐句敲出来，而是我是否提出了正确的问题，是否理解了其中的因果关系，是否能够判断 AI 的解释是否可靠，以及最终留下来的结构是否真正代表了我此刻对这个问题的理解。

因此，我更愿意把这套方法称为：

AI 辅助学习与知识沉淀。

它不是简单地“让 AI 替我写文章”，也不是把 AI 的回答原样存档，而是试图回答一个更重要的问题：

当答案越来越容易获得，我们应该怎样把一次性的 AI 对话，真正转化成自己的长期知识？

经过一段时间的尝试，我逐渐形成了一套这样的流程：

Curiosity → Map → Explore → Challenge → Outline → Verify → Write → Review → Publish → Revisit

后面的每一步，其实都在解决一个不同的问题：先知道自己应该学什么，再真正理解它；先确认自己不是“似懂非懂”，再把零散探索重新组织；最后通过查证、整理和持续修订，把短暂的对话变成可以长期积累的知识。

1AI 改变的，不只是搜索

AI 最容易被理解成一个更方便的搜索框。

但如果只是把：

Google 搜索

替换成：

问 ChatGPT

其实低估了它对学习过程带来的变化。

1.1传统搜索真正昂贵的是“整合”

传统搜索大致经历这样的过程：

搜索引擎非常擅长解决：

哪里可能存在答案？

但它通常不会替你解决：

这些答案之间是什么关系？

假设我要理解一个物理引擎。

搜索很容易让我分别找到：

• Broad Phase；
• Narrow Phase；
• GJK；
• SAT；
• Contact Manifold；
• Sequential Impulse；
• PGS；
• Island；
• Sleeping。

但真正困难的是意识到：

Collision Detection
├── Broad Phase
└── Narrow Phase

Dynamics
├── Integration
└── Constraints

Constraint Solver
├── Contact Constraints
└── Joints

Simulation Management
├── Islands
└── Sleeping

这里已经不再只是“找资料”。

而是在建立一个知识模型。

1.2AI 把“知识整合”提前了

和 AI 对话时，这个过程可以变成：

AI 并没有消灭阅读、判断和验证。

它真正压缩的是中间大量机械性的工作：

• 术语整理；
• 概念归类；
• 初步比较；
• 上下文补全；
• 关系解释；
• 表达转换；
• 从不同角度重新解释。

于是人的注意力可以更多地集中到：

哪里不对？

哪里我还没理解？

这个解释有没有遗漏关键条件？

真正值得继续追问的是什么？

但这里马上出现了另一个问题。

2答案越容易得到，越容易产生“我已经懂了”的错觉

AI 最大的优点，同时也是它最危险的地方之一：

解释通常太顺了。

你问：

Sequential Impulse 是什么？

AI 很快给出一个结构完整、措辞清楚的解释。

读完之后，你可能产生一种非常自然的感觉：

原来如此，我懂了。

但如果继续问：

为什么叫 Sequential？

或者：

为什么需要迭代？

或者：

它和 Projected Gauss-Seidel 到底是什么关系？

或者：

为什么不一次求解整个约束系统？

刚刚那种“已经理解”的感觉可能很快消失。

2.1“能够认可解释”不等于“能够重建解释”

认知心理学中有一个很有意思的现象叫做 Illusion of Explanatory Depth，解释深度错觉。

Rozenblit 和 Keil 的研究发现，人们常常会高估自己对复杂机制的理解程度；当真正被要求详细解释机制如何工作时，对自己理解程度的评价会下降。¹

这项研究当然不是针对 AI 学习进行的，但它提醒了一个非常适合 AI 时代的问题：

一个解释读起来很合理，并不能证明我们已经掌握了它。

尤其是 AI 可以随时补全缺失的推理链时，我们很容易把：

“这个解释我看得懂”

误认为：

“这个解释我自己也能够建立出来”

这两件事并不相同。

2.2必要的认知摩擦不能全部消失

过去学习效率低，有很多摩擦其实毫无价值：

• 搜索几十个关键词；
• 找到失效链接；
• 在十篇文章中寻找同一句定义；
• 被过时教程误导；
• 为了一个术语翻很多资料。

这些摩擦当然应该尽可能减少。

但还有另一类摩擦非常重要：

• 尝试自己解释；
• 回忆一个概念；
• 推导为什么需要这个机制；
• 比较两个方案；
• 找出反例；
• 回答没有资料摆在眼前的问题。

关于 retrieval practice（检索练习） 的实验研究表明，主动从记忆中提取已经学过的信息，不只是测量学习结果，也可以促进之后的保持。²

让 AI 对我进行追问，并不等同于这些研究中的具体实验条件，但它提供了一个很有价值的方向：

不要永远让 AI 继续解释；有时候应该把解释权交还给自己。

于是，我逐渐把整个学习过程拆成几个阶段。

3第一阶段：先建立地图，而不是直接寻找答案

面对一个陌生领域时，我现在很少一开始就要求：

帮我写一篇完整文章。

因为这时候最大的未知甚至不是答案，而是：

我根本不知道这个领域有哪些问题。

3.1知识地图解决的是“未知的未知”

假设我第一次研究 Render Graph。

我可能只知道一个词：

Render Graph

如果立即让 AI 写文章，它当然可以生成一篇看起来相当完整的内容。

但问题是，我还没有判断文章结构是否合理的能力。

更好的第一步是：

如果我要系统理解 Render Graph，需要理解哪些核心概念？这些概念是什么关系？

于是可能得到：

Render Graph
├── 为什么存在
│   ├── 手工 Pass 管理的问题
│   ├── Resource Lifetime
│   └── Dependency
│
├── Graph
│   ├── Pass
│   ├── Resource
│   └── Dependency
│
├── Compilation
│   ├── Pass Culling
│   ├── Lifetime Analysis
│   └── Resource Aliasing
│
└── Engine Integration
    ├── Unity Render Graph
    ├── HDRP
    └── Custom Pass

这一刻我得到的还不是知识本身。

我得到的是：

知识的搜索空间。

这一步很重要，因为它让我第一次看见：

自己不知道什么。

3.2地图不是最终目录

这里还需要区分两种结构：

学习地图解决的是：

这个领域有哪些东西？

文章目录解决的是：

为了让读者理解，我应该按照什么顺序讲这些东西？

两者经常相关，却不一定完全相同。

探索阶段可以非常发散。

最终文章必须收敛。

这也是为什么我不会在拿到知识地图之后，立刻让 AI 把它扩写成文章。

下一步应该是——把地图上的关键节点真正问懂。

4第二阶段：沿着问题向下挖，而不是沿着目录机械阅读

有了地图之后，我会开始大量追问。

这里的“疯狂追问”并不是随机聊天。

长期下来，我发现很多技术问题其实可以沿着一条非常稳定的链条向下挖。

4.1一条通用的追问梯子

例如从：

Render Graph 是什么？

一路可以继续问：

为什么现代渲染器需要 Render Graph？

如果没有它，以前的 Render Pass 是怎么管理的？

Render Graph 到底记录了什么？

为什么知道依赖关系之后可以自动剔除 Pass？

Resource Lifetime 和内存复用是什么关系？

Unity 的 Render Graph 和 Render Feature、Render Pass、HDRP Custom Pass 又是什么层级关系？

第一问得到的是术语定义。

后面的追问才开始建立系统模型。

4.2最重要的问题经常是“为什么不能更简单？”

我尤其喜欢追问：

为什么不能直接……？

例如：

为什么碰撞检测不能直接遍历所有物体？

为什么 Constraint Solver 不能直接一次算完？

为什么 Git 不能只保留最终文件状态？

为什么 Render Graph 不能只是一个 Pass 列表？

为什么 Dot Product 不直接定义成夹角？

这种问题很有价值，因为很多复杂系统都是从一个更简单的方案演化出来的。

理解：

简单方案为什么不够

通常比背下：

复杂方案是什么

更容易建立真正稳定的理解。

5私人化的问题并不是文章的缺陷

探索阶段完全没有必要追求“通用”。

我甚至会直接问：

我还是没懂。

不要用论文语言，再解释一次。

拿 Unity Rigidbody 举例。

你刚才说 A 和 B 很像，它们究竟是不是同一个东西？

如果完全不用这个系统会怎样？

这些问题可能很私人，也可能表达得并不优雅。

没有关系。

因为这时候真正的目标不是写文章，而是：

消除自己的理解断点。

问题越贴近自己的认知状态，学习效率反而越高。

真正需要“去私人化”的，是后面的写作阶段。

6第三阶段：不要继续解释，让 AI 反过来问我

当一个主题已经讨论了一段时间之后，我现在越来越喜欢加入一个阶段：

让 AI 停止回答。

然后让它开始提问。

6.1从回答者变成考官

最简单的 Prompt 可以是：

根据我们刚才讨论的内容，问我一些问题，
检查我是不是真的理解了，而不是只是觉得自己听懂了。

还可以更有针对性：

找出我最可能只是记住术语、但实际上没有理解的地方。

或者：

让我不用这些专业术语，重新解释一次这个机制。

或者：

给我一个反例或边界情况，看我能不能解释。

或者：

假设这是一次技术面试，根据我的回答继续追问。

6.2理解的测试不是“我看过没有”

真正值得测试的是：

我能不能从头重建这个模型？

例如研究 Dot Product 时，不只是问：

点积公式是什么？

而是：

为什么结果是一个标量？

为什么它可以判断方向相似程度？

为什么垂直时是 0？

为什么归一化之后可以直接拿结果和阈值比较？

当这些问题可以脱离原文，用自己的语言重新解释时，知识才开始真正变成自己的。

7第四阶段：先设计文章，再写文章

经过知识地图、追问和理解验证之后，终于可以开始写文章了。

但我现在不会立刻让 Agent 输出一篇几千字甚至上万字的 MDX。

我会再插入一个很短、但非常重要的阶段：

Outline。

7.1文章目录本身就是知识模型

一个常见的问题是，AI 很容易生成这样的目录：

## Broad Phase
## Narrow Phase
## GJK
## SAT
## Contact Manifold
## Solver
## PGS
## Island
## Sleeping

每个标题单独看都没错。

但放在一起，它们几乎没有表达任何知识关系。

更合理的结构应该类似：

## 碰撞检测

### Broad Phase

### Narrow Phase

#### SAT

#### GJK

### Contact Manifold

## 约束求解

### Contact Constraint

### Sequential Impulse 与 PGS

## 模拟管理

### Island

### Sleeping

目录不仅仅负责导航。

它本身就是作者对这个领域的理解：

哪些概念属于同一层？

谁包含谁？

谁依赖谁？

哪些是主干，哪些是细节？

因此，如果目录是错的，正文写得再漂亮，也很难成为真正清楚的文章。

7.2先改几百 Token，而不是重写几千 Token

直接生成长文的问题是成本很高。

更好的流程是：

一个框架只需要很少的输出，就可以提前发现：

• 主题跑偏；
• 范围过大；
• 顺序错误；
• 章节层级不合理；
• 重复内容；
• 缺少关键前置知识；
• 某个细节被错误地提升为主章节。

这比全文生成之后再返工高效得多。

7.3Outline 阶段一起决定标题、Slug 和 Tags

我也会在这个阶段顺便让 AI 给出：

• 推荐标题；
• 两三个候选标题；
• MDX 文件名；
• URL slug；
• tags；
• 一句话 description。

例如：

Title:
从提问到知识库：我的 AI 辅助学习与写作工作流

Slug:
ai-assisted-learning-workflow

Tags:
ai, learning, writing, knowledge, workflow

这些东西看起来只是元数据，其实也在迫使我们回答：

这篇文章究竟在讲什么？

如果连一句话 description 都很难写清楚，往往意味着文章本身的边界还没有确定。

8第五阶段：把私人探索蒸馏成公共文章

到这里，才真正进入“写作”。

但最终文章不应该是：

把聊天记录整理一下。

探索过程本来就是跳跃的。

可能先问 A，再跳到 D，发现不懂 B，又回来补 C。

文章则必须重新设计。

8.1私人问题应该被抽象，而不是删除

例如对话中的问题可能是：

我还是不明白为什么不直接把所有物体两两检查碰撞？

最终文章里可以转化成：

### 为什么需要 Broad Phase？

对话中可能是：

Unity 里面这个 Render Pass、Render Feature、Render Graph 和 Custom Pass 到底乱七八糟是什么关系？

最终可以变成：

### Render Graph 与 Pass 系统处在什么层级？

私人问题之所以有价值，是因为它通常来自一个真实存在的理解障碍。

好的技术文章恰恰应该解决这些障碍。

8.2从定义转向因果链

最终文章尤其应该避免这种写法：

A 是……
B 是……
C 是……
D 是……

我更希望文章建立这样的关系：

出现了什么问题
↓
最直觉的方案是什么
↓
它为什么不够
↓
于是引入什么机制
↓
这个机制怎样工作
↓
又付出了什么代价

也就是从：

What

进一步写到：

Why → How → Trade-off

这是我现在最看重的一点。

9不同知识应该选择不同的表达形式

FumaDocs 对我很有吸引力的地方，不只是它能够显示 Markdown。

更重要的是，MDX 允许不同类型的知识使用不同的表达方式。

FumaDocs 本身提供了 Callout、Tabs、Steps、Accordion 等文档组件，而 MDX 也允许项目继续加入自己的可视化组件。³

但“支持很多组件”并不意味着“应该大量使用组件”。

真正重要的是：

表达形式应该匹配知识结构。

9.1Mermaid：结构关系的默认选择

对于大量技术文章，Mermaid 是我使用频率最高的可视化方式。

它很适合：

• 系统架构；
• 数据流；
• 状态机；
• 生命周期；
• 编译流程；
• 模块依赖；
• 历史演进；
• 算法流程。

FumaDocs 官方文档也提供了 Mermaid 与 MDX 集成的方式。⁴

它最大的优势是：

表达结构的成本非常低。

很多原本需要几段文字解释的关系，用十几行 Mermaid 就可以快速建立一个整体模型。

但 Mermaid 也不应该成为装饰。

如果一张图只是在表达：

A → B

而一句话已经足够，那就没有必要画图。

9.2KaTeX：公式不是为了显得更专业

数学文章中另一个容易出现的问题，是公式成为装饰。

一个好的数学表达应该回答：

这个公式到底告诉了我什么？

例如：

真正重要的不是把公式展示出来，而是继续解释：

• 为什么结果是标量；
• $\cos\theta$ 在这里意味着什么；
• 为什么垂直时结果为 $0$；
• 为什么单位向量的点积可以表示方向相似度；
• 在游戏里怎样用它判断目标是否位于视野范围。

公式是知识压缩。

文字负责把它重新展开。

9.3交互组件只应该出现在“交互真的重要”的地方

JSXGraph、Plot、D3 可以做出非常漂亮的东西。

但它们也意味着：

• 更长的代码；
• 更大的生成成本；
• 更复杂的维护；
• 更高的出错概率；
• 更容易让文章重点从知识转向表现形式。

所以我会采用一个非常简单的原则：

静态表达已经足够时，不要强行交互。

例如：

• 点积随向量夹角变化，非常适合 JSXGraph；
• 数值积分误差随步长变化，可以考虑 Plot；
• 一个普通的软件架构关系，Mermaid 就够了；
• 三个方案优缺点，表格往往比任何图表都清楚。

工具不是 KPI。

10第六阶段：AI 负责组织，事实必须能够回到来源

AI 可以非常擅长组织知识。

但“组织得很好”和“事实正确”是两件不同的事。

因此，在文章进入发布阶段之前，我会明确加入：

Verify。

10.1哪些东西尤其值得验证

并不是每句话都需要脚注。

但以下信息如果出现在文章里，我通常会优先寻找来源：

• API 行为；
• 软件版本；
• 发布时间；
• 历史事件；
• 性能数据；
• Benchmark；
• 标准；
• 论文结论；
• 官方限制；
• 某个引擎到底采用了什么算法；
• 某位开发者或公司的观点。

相反：

• 教学性的推导；
• 自己的工程经验；
• 个人判断；
• 明确标注为分析的内容；

没有必要为了“看起来专业”而强行增加引用。

10.2来源也有层级

对于技术文章，我大致会按照这样的顺序寻找来源：

这并不是说上面的来源永远正确、下面的来源永远错误。

它表达的是：

如果一个事实可以回到更接近原始信息的位置，就尽量不要只依赖二手转述。

AI 最适合做的是：

帮助我找到问题、理解资料、连接资料、解释资料。

而不是成为：

所有事实最终不可追溯的出处。

10.3引用应该帮助验证，而不是制造“学术感”

好的引用应该让读者可以继续追下去。

例如：

Unity 在某版本中引入了……

如果这是版本相关事实，就应该链接对应官方文档或 Release Notes。

而像：

我发现先做 Outline 再写正文更适合这种工作流。

这显然属于实践判断，没有必要寻找一篇论文来替它背书。

11第七阶段：写完之后，再换一个视角审查

文章写出来不意味着流程结束。

我现在更倾向于把：

Write

和：

Review

看作两个阶段。

11.1为什么不应该只让原来的 Agent 自己检查

同一个上下文有一个天然问题：

它已经接受了之前建立的结构和假设。

于是“自己检查自己”很容易变成：

在原来的思路里继续寻找局部问题。

如果条件允许，我更喜欢重新打开一个上下文，让新的 Agent 只看到文章，然后问：

请作为技术 Reviewer 审查这篇文章。

重点检查：

- 事实错误
- 过时信息
- 概念层级混淆
- 缺少来源的强断言
- 推理跳跃
- 章节组织问题
- 重复内容
- 可以删掉的 AI 套话
- 图表是否真的有必要

这一步的目标不是让第二个 AI 自动重写全文。

而是获得一个新的观察角度。

11.2Review 还应该重新问一次“这篇文章到底在讲什么”

技术文章很容易在写作过程中无限膨胀。

一开始想讲：

ECS 为什么存在？

最后可能一路写到：

• DOD；
• CPU Cache；
• SIMD；
• Archetype；
• Sparse Set；
• Job System；
• Unity Entities；
• Bevy；
• Flecs；
• Serialization；
• Networking。

每一部分都相关。

但相关不意味着应该出现在同一篇文章里。

Review 阶段应该重新问：

如果读者最终只能记住这篇文章的一条主线，它是什么？

如果一个章节不能帮助这条主线继续前进，它可能应该：

• 删除；
• 缩短；
• 移到另一篇文章；
• 变成扩展阅读。

12最终形成的工作流

经过不断调整，我现在更喜欢把整个过程分成四个主要 Prompt 阶段：

Explore
↓
Outline
↓
Write
↓
Review

但如果把真正的学习过程完整展开，它其实更长。

它不是一条真正意义上的流水线。

最后的：

Revisit → Explore

意味着它实际上是一个循环。

12.1Explore：先理解这个世界长什么样

一个很短的 Explore Prompt 就可以是：

我想系统理解这个主题。

先不要写文章，请先建立知识地图：
有哪些核心概念、前置知识和关键问题？
它们之间是什么关系？

然后我们沿着我不理解的地方继续讨论。

12.2Challenge：让理解暴露在压力下

根据我们刚才讨论的内容检查我的理解。

不要继续讲解，先向我提问。
重点找出我可能只是熟悉术语、但实际上没有真正理解的地方。

这一步没有必要每篇文章都严格执行。

但对于真正陌生、又希望深入掌握的主题，非常有价值。

12.3Outline：先把知识结构定下来

根据我们前面的讨论，为这个主题设计一篇 FumaDocs MDX 文章的框架。

暂时不要写完整正文，只输出：

1. 推荐标题、Slug 和 Tags
2. 文章核心问题与主线
3. 有明确父子关系的章节目录
4. 每章准备回答的问题和核心结论
5. 哪些地方适合 Mermaid、表格、公式、Callout 或交互图表
6. 哪些事实需要查找可靠来源
7. 哪些内容应该重点展开，哪些只需简略带过

目标是先把知识结构、范围和叙事路线设计正确。

然后人工修改框架。

直到：

只看目录，我就已经能看见整篇文章的知识结构。

再进入下一阶段。

12.4Write：把探索蒸馏成文章

Write 阶段才真正要求：

• 完整 MDX；
• 清晰的标题层级；
• Why；
• 原理；
• Trade-off；
• Mermaid；
• KaTeX；
• 组件；
• 来源；
• Frontmatter。

这时候生成长文的浪费已经大幅减少。

因为最重要的结构决策已经完成。

按照刚才最终确认的框架，结合我们此前的讨论，写成完整的 FumaDocs MDX 文章。

保持清晰的知识层级，重点解释 Why、原理、设计动机和概念之间的关系，不要机械复述聊天记录。

适当使用 Mermaid、KaTeX、表格和现有 FumaDocs 组件；交互图表只在显著帮助理解时使用。Mermaid 的关系写在同一行。

重要事实、版本信息、论文结论和官方限制应查证并提供可靠来源，优先使用一手资料，不要编造引用。

把私人探索过程重新抽象成可以独立阅读、长期查阅的公共文章，并输出完整 frontmatter 和可直接使用的 MDX。

12.5Review：把文章重新当作陌生人的文章阅读

最后再独立检查：

如果我从未参与之前的讨论，
这篇文章还能不能独立成立？

这是一个非常重要的判断标准。

13发布不是学习的终点

过去我会把写博客理解成：

我已经学会
↓
所以我写下来

现在我越来越觉得真实过程更像：

当你只是自己看看时，很多模糊理解可以被轻易放过。

但一旦准备把它公开成文章，就会自然开始追问：

这个说法真的准确吗？

这个术语是不是用错了？

这两个概念是不是混在一起了？

这个版本信息现在还成立吗？

这个结论有没有一手来源？

如果别人按照这里的描述理解，会不会被我误导？

因此：

写作本身也是一种理解测试。

这就是为什么我越来越喜欢“学完以后写成一篇文章”。

不是因为每学一个东西都必须向别人展示。

而是因为结构化表达会迫使自己面对那些原本可以含糊过去的地方。

14Blog 最终变成了一个长期知识库

普通的一次 AI 对话有一个很明显的问题：

它的生命周期通常很短。

今天我问：

Git Rebase 到底改变了什么？

半个月之后，很可能已经忘记那次对话究竟讲了什么。

而一篇文章则不同。

它有：

• 标题；
• URL；
• 目录；
• 搜索；
• 内链；
• 图表；
• 来源；
• 更新时间；
• 和其他文章之间的关系。

FumaDocs MDX 本身也天然适合把内容编译成带目录、结构化数据和可搜索页面的数据源。⁵

于是一次临时学习，可以逐渐完成这样的转化：

Question
↓
Conversation
↓
Understanding
↓
Article
↓
Knowledge Base

更重要的是，它还可以继续变化：

Knowledge Base
↓
新的项目经验
↓
新的资料
↓
新的理解
↓
更新文章

文章不是知识的墓碑。

它应该是知识当前版本的一个快照。

15最大的风险：不要把知识库变成 AI 内容仓库

当这个流程开始顺畅之后，很容易出现另一种诱惑：

一天生成五篇。

一个月生成一百篇。

因为 AI 让文字生产变得太容易了。

但文章数量本身并没有太大意义。

如果我的网站最后拥有一千篇技术文章，但其中大部分我自己都没有真正理解，那么它更像：

AI 生成内容数据库

而不是：

我的知识库。

所以我会给“发布”设置一个很简单的标准：

如果不能，这篇文章至少还没有完成它作为“学习产物”的使命。

AI 写出了文章。

不代表知识已经属于我。

16AI 时代，学习的瓶颈正在变化

互联网时代，知识获取的一个核心问题曾经是：

答案在哪里？

搜索引擎极大降低了这个成本。

AI 又进一步开始降低另一个成本：

这些答案之间是什么关系？

它可以帮助我们：

• 汇总；
• 比较；
• 重组；
• 解释；
• 改写；
• 建立初步结构。

于是新的瓶颈开始逐渐浮现出来：

我应该问什么？

这个回答可信吗？

我是不是真的理解了？

哪些信息应该连接起来？

什么才是这个领域最重要的主线？

哪些知识值得长期保留下来？

这也是为什么我越来越不愿意把这种工作流理解成：

“让 AI 帮我写 Blog。”

它更接近：

让写作成为 AI 辅助学习的最后一个阶段。

当答案越来越廉价时，真正昂贵的东西反而变成了：

好的问题、可靠的判断、真正的理解，以及能够组织知识的结构。

AI 可以大幅降低走到这些东西面前的成本。

但最后那一步，仍然需要自己完成。