正文
示例文章:用于体验 Wiki 的阅读、分类与知识关联。除明确引用的公开资料外,流程、配置和情境均为原创设计示例,不代表生产系统现状或测试结果。
知识库的价值不只是存下文章,而是让下一次问题能沿着已有解释继续。读者既能找到结论,也能判断这条结论根据什么、确定到哪里。
先分清资料、理解与规则
Karpathy 的 LLM Wiki 思路区分三层:保留原始来源、持续整理相互链接的 Wiki 页面,以及约定结构与维护方式的规则文档。本文只概括这一结构,不把它当作某个产品的实现证明。阅读原始资料
在我们的演示里,一份资料可以成为多个主题的依据,一篇文章也可以综合不同资料。分类回答“放在哪里”,文章回答“如何理解”,来源回答“为什么这么说”。

原创概念插图;箭头表达知识组织关系,不代表实际服务调用。
给每次整理一个明确落点
以“角色在不同镜头里是否保持一致”为例,原始资料可以是一张角色定稿图,知识文章则解释哪些识别特征必须保留。不要把原图的文件名当成全部知识,也不要用文章覆盖原图。
| 层次 | 本示例保存什么 | 读者如何使用 |
|---|---|---|
| 原始资料 | 参考图、笔记、公开网页 | 核查细节和上下文 |
| 知识文章 | 结论、条件、解释与关联 | 解决一个具体问题 |
| 维护规则 | 命名、引用和审阅约定 | 判断整理是否一致 |
这条创作问题可以继续读 角色素材卡:让跨镜头一致性可检查,而不是把所有主题塞进同一篇长文。
草稿与发布,表达的是不同承诺
以下是拟议的整理流程,不是后台自动化的执行日志。
查看流程图源码
flowchart LR
S[收集来源] --> D[写出草稿]
D --> R[审阅条件]
R --> P[发布知识]草稿可以保留未知项。发布之前应检查标题是否准确、引用是否支持附近的结论,以及描述的是事实还是建议。文章“已发布”并不自动表示其中所有设计都已经实现。
让关联帮助继续阅读
关联不是随机推荐。它应告诉读者:为什么下一篇与当前问题有关。
- 想改善文章的可读性:长文排版:让代码、表格和插图各司其职。
- 想把一次产物变成下一轮输入:视频制作的质量回环。
- 想知道生图入口选择的条件:生图路由:先保留任务约束,再选择入口。
这里的链接由作者明确写入;它们不代表系统已经推断出所有知识关系。
来源与依据
- Karpathy · LLM Wiki 设计思路
收录日期:2026-10-09