工程知识编译层与公开边界

RailWise 不把所有 PDF、报告和项目资料直接切块交给模型检索。工程资料有上下文、版本、权限和项目边界，跳过整理层会让模型把个案、旧版本或未核实结论误当成通用答案。

Raw Sources -> Compiled Engineering Wiki -> Public Knowledge Base -> Products & Agents

每一层解决什么问题

层级	处理内容	解决的问题	是否公开
Raw Sources	标准原文、手册、报告、会议纪要、现场记录、模板	保留原始依据与语境	否
Compiled Engineering Wiki	概念、方法、实体、案例、风险与关联	统一术语，解释适用范围，发现冲突与缺口	默认否
Public Knowledge Base	脱敏、审核、可引用的场景、参考和方法页	让工程人员与外部 Agent 使用稳定公开知识	是
Products & Agents	检索、写作、任务上下文与工作流辅助	将可信公开知识带入具体工作，不替代判断	按产品权限

为什么不能直接把散乱资料喂给 RAG

• 同一术语在不同项目、不同标准版本中的含义可能不同。
• 项目报告常含有客户、坐标、合同、现场状态等不可公开内容。
• 经验结论可能只对某一工况有效，不能被模型扩展为通用阈值或处置规则。
• 原始资料缺少关系索引，模型很难判断“哪一版标准、哪个场景、哪一步骤”才是当前问题的依据。

编译层先补足主题、来源、适用范围、实体关系、风险和不确定性，公开层再只保留能长期维护与引用的部分。

内部 Wiki 条目的最低结构

每个内部条目至少应记录：

字段	用途
来源与版本	能回溯标准、资料、时间和可信度
适用范围	明确工程对象、工况、阶段与不适用边界
实体关系	关联标准、结构物、仪器、方法、产品模块和案例
方法步骤	将经验转成可复核的操作路径
风险与冲突	标注常见误用、争议结论和待核实事项
公开版本	记录对应公开页面、脱敏范围与审核状态
审核记录	记录人工复核人、时间与后续修订理由

公开与内部的边界

公开知识库只发布已经脱敏、审核、可长期维护的知识。项目原始资料、客户名称、坐标、合同、原始监测数据和未公开结论不进入公开层，也不应被公开 Agent 入口返回。

涉及工程风险、规范条文、限值、频率和现场处置时，公开页只能提供检索线索、方法框架与引用依据；正式决定必须以现行标准原文、项目文件和责任人的复核为准。

维护动作

1. 先检索现有主题，优先补充和修订已有条目。
2. 新结论必须保留来源、范围与不确定性说明。
3. 冲突结论和知识缺口先记录在内部治理层，不能直接写成公开结论。
4. 发布前完成脱敏与人工审核，并更新对应公开页面的复核时间。
5. 从公开页回收使用反馈，推动下一轮 Wiki 编译与修订。