LLM Wiki

Appearance

Built 26/04/16 17:00commit 95b5faf

Codex LLM Wiki Skill ​

中文 | English

Summary ​

这个来源把抽象的 LLM Wiki 模式落实成一个可复用的 Codex skill bundle：它打包了维护者姿态、根目录解析顺序、双语规则、调度模型、PDF ingest 策略，以及将仓库型 markdown wiki 作为持续系统运行所需的辅助脚本。

Source ​

Translation Freshness ​

  • 当前导入的 raw 双语对已经吸收最新规则，包括 PDF ingest 路径、更窄的 taxonomy patrol 指导，以及显式的预推送本地验证步骤。
  • 这个 bundle 的 raw markdown 入口现在为维护规范和参考文档都提供了最新的双语导航。

主要观点 ​

  • 把 LLM Wiki 从概念性 gist 落成了 Codex 可执行的维护方法。
  • 明确 root resolution 顺序，使同一个 skill 能在多个 vault 上运行，而不用写死仓库假设。
  • 定义了双语维护纪律，把 .zh.md 当作持续维护的 sibling，而不是一次性导出。
  • 把自动化拆成内容巡检和目录巡检两类任务，让 ingest 漂移与目录重构使用不同节奏。
  • 把 raw PDF backlog 处理提升为默认维护流程的一部分：保留原始 PDF、创建 markdown raw sibling、按短文档/长文档分流翻译路径，并在版面重要时保留视觉证据。
  • 将辅助脚本的职责限制在狭窄的结构性任务上：vault 引导、OCR 提取、lint、调度运行、调度状态与配置衔接、raw/ 与 wiki/ 的安全路径移动，以及 git remote 同步辅助。

核心观点 ​

  • 真正的阅读、综合、冲突处理和页面修订仍应由模型完成，而不是由脚本完成。
  • index.md 和 log.md 是运行原语，不是附带文件。
  • Raw source 的内容实质保持稳定，但当 source family 结构或可导航性需要时，raw 路径可以重组。
  • 翻译新鲜度是持续维护义务；落后的 sibling 应明确标记，而不是悄悄漂移。
  • 自动化应避免重叠运行，并能从先前状态继续，而不是盲目重启每次巡检。
  • 任何会影响渲染结果的 scheduled 或手动维护，都应在 commit / push 前完成本地验证或构建。
  • 例行清理不应只等同于卫生清理；应先判断是否已有一两个明显、窄范围的 taxonomy 移动更值得落地。

对本库整理的启发 ​

  • 为之前只在概念层描述的维护循环补上了具体的脚本化实现。
  • 更清楚地区分了抽象模式页面与可复用操作 bundle。
  • 让 llm-wiki 自身变得可作为一个 source family 被理解：它由一个维护规范、三份参考文档，以及现在已被完整列出的工具面组成。
  • 也为本库后续遇到 PDF backlog 时提供了明确策略，不再把 PDF ingest 质量和翻译分流留成隐含约定。

开放问题 ​

  • 未来是否要把这些辅助脚本逐个 ingest 成独立的一等实现来源，而不是只把它们作为一个整体的操作型 source family 来处理。