Karpathy 式 Wiki 在工程知识库中的实践

Karpathy 式 Wiki 的关键不是用一个好看的知识图，而是把“资料越来越多”变成“知识越来越清楚”的维护机制。RailWise 将这个方法用于工程监测、测量、标准参考与产品经验。

从文档集合变成知识系统

一个 PDF 文件夹可以保存资料，却不能告诉使用者：这份资料适用于什么工况、依据是哪一版标准、和哪种仪器或方法有关、结论是否已经复核。Wiki 编译要补上这些关系。

收集原始资料 -> 提取主题与证据 -> 统一术语与实体 -> 建立方法页和关联 -> 人工审核 -> 发布公开版本

工程 Wiki 的编译原则

• 原始证据不丢失：每个可复用结论都能回到标准、手册、记录或经过授权的内部资料。
• 范围先于结论：先说明工程对象、工况、阶段和限制，再写方法或建议。
• 关系胜过堆叠：场景要能连接标准、仪器、数据、报告和产品工作流。
• 冲突显式记录：版本差异、不同做法和待确认问题不能被模型悄悄抹平。
• 公开前人工把关：只有可脱敏、可复核、可长期维护的内容进入 kb.railwise.cn。

人、产品与 Agent 如何使用

使用者	从公开层获得什么	必须保留的边界
工程人员	场景路径、参考依据、方法框架、复核清单	不以摘要替代标准原文和项目要求
WorkWise	写作、方案、报告和资料整理的专业背景	对外文稿、数据与结论需责任人复核
RAILWISE-CLI	智能体任务的检索与专业上下文	引用来源，不能把公开知识当作现场指令
RAILWISE-OS	企业私有部署中连接内部 Wiki 的公开方法参考	私有数据与访问权限不进入公开站点

公开页面应如何继续演进

公开知识库不是内部 Wiki 的镜像，而是经过筛选后的长期入口。每次新增或修订内容，应优先补足它和场景、标准、参考库、产品上下文之间的关系，而不是孤立增加一篇文章。