示例文章：用于体验 Wiki 的阅读、分类与知识关联。除明确引用的公开资料外，流程、配置和情境均为原创设计示例，不代表生产系统现状或测试结果。
知识库的价值不只是存下文章，而是让下一次问题能沿着已有解释继续。读者既能找到结论，也能判断这条结论根据什么、确定到哪里。
从一份资料，到一张可复用的知识地图
阅读正文 ↗点击知识块看内容，点击连线看依据。没有关系的块也保留。
正在读取关系，知识块已可查看。
Karpathy 的 LLM Wiki 思路区分三层：保留原始来源、持续整理相互链接的 Wiki 页面，以及约定结构与维护方式的规则文档。本文只概括这一结构，不把它当作某个产品的实现证明。阅读原始资料
在我们的演示里，一份资料可以成为多个主题的依据，一篇文章也可以综合不同资料。分类回答“放在哪里”，文章回答“如何理解”，来源回答“为什么这么说”。
原创概念插图；箭头表达知识组织关系，不代表实际服务调用。
以“角色在不同镜头里是否保持一致”为例，原始资料可以是一张角色定稿图，知识文章则解释哪些识别特征必须保留。不要把原图的文件名当成全部知识，也不要用文章覆盖原图。
| 层次 | 本示例保存什么 | 读者如何使用 |
|---|---|---|
| 原始资料 | 参考图、笔记、公开网页 | 核查细节和上下文 |
| 知识文章 | 结论、条件、解释与关联 | 解决一个具体问题 |
| 维护规则 | 命名、引用和审阅约定 | 判断整理是否一致 |
这条创作问题可以继续读 角色素材卡：让跨镜头一致性可检查，而不是把所有主题塞进同一篇长文。
以下是拟议的整理流程，不是后台自动化的执行日志。
查看流程图源码
flowchart LR
S[收集来源] --> D[写出草稿]
D --> R[审阅条件]
R --> P[发布知识]草稿可以保留未知项。发布之前应检查标题是否准确、引用是否支持附近的结论，以及描述的是事实还是建议。文章“已发布”并不自动表示其中所有设计都已经实现。
关联不是随机推荐。它应告诉读者：为什么下一篇与当前问题有关。
- 想改善文章的可读性：长文排版：让代码、表格和插图各司其职。
- 想把一次产物变成下一轮输入：视频制作的质量回环。
- 想知道生图入口选择的条件：生图路由：先保留任务约束，再选择入口。
这里的链接由作者明确写入；它们不代表系统已经推断出所有知识关系。