llm-wiki 和 vps-service-hub 应该如何分工
Decision（决策）
llm-wiki 负责沉淀长期可复用的知识、判断和结构化结论；vps-service-hub 负责记录这台 VPS 的运维事实、服务状态、端口、域名、反代流程和操作台账。
两者允许有交集，但不应混成一套东西。
Context（背景）
随着 Quartz 站点真的在 VPS 上被反代出来，出现了一个很自然的问题：
这些讨论到底该进知识库，还是该进 VPS 运维 hub。
如果边界不清楚，很容易把临时运维细节灌进 llm-wiki，或者把本应长期复用的判断只留在运维台账里。
Criteria（判断标准）
分工应该满足：
- 运维信息集中、可执行、可复查
- 知识判断长期可复用
- 不让 llm-wiki 退化成操作流水账
- 不让 vps-service-hub 只剩零散路径和端口，缺少上下文
- 遇到同类问题时，能立刻知道该去哪个系统找答案
Facts（事实）
- vps-service-hub 当前已经负责记录这台 VPS 上的服务、端口、域名、OpenResty / 1Panel 路径、反代与 HTTPS 流程。
- 本次 Quartz 站点的反代、DNS、证书、服务暴露等事实，已经实际写入或补强到了 vps-service-hub。
- Buu 当前更关心的长期问题包括：Wiki 网站应该呈现成什么样、Quartz 在整套系统里的角色、Markdown 与展示层如何分工。
- 这些问题并不是一次性操作细节，而是后续会持续影响选型、记录方式和 review 标准的判断。
Interpretation（解释）
所以更自然的边界是：
- vps-service-hub 记录“这台机器上怎么做、做成了什么、在哪、怎么维护”
- llm-wiki 记录“为什么这样做、这意味着什么、以后类似问题该怎么理解”
也就是说，前者偏运维事实，后者偏知识资产。
Current Rule（当前规则）
- 域名、端口、反代、证书、1Panel / OpenResty / Cloudflare 具体流程，优先进入 vps-service-hub。
- 长期有效的判断、概念解释、系统角色划分，优先进入 llm-wiki。
- 一次性的调试细节、临时报错、具体证书 id 等，不写进 llm-wiki。
- 如果某个运维动作背后形成了稳定规则，可以把“规则层”写进 llm-wiki，把“执行层”继续留在 vps-service-hub。
- 遇到是否入 wiki 的判断时，优先问：这是不是以后还会反复复用的知识结论？
Exceptions（例外）
- 某些服务既是 VPS 上的真实服务，又是长期研究对象时，可以两边都记，但内容层次必须不同。
- 如果某个运维流程稳定到已经接近通用方法论，可以在 llm-wiki 中单独抽象为规则页。
- 如果某条知识判断只对这台 VPS 有意义，则仍优先留在 vps-service-hub。
Review Trigger（复查触发条件）
以下情况出现时，应复查这条分工：
- llm-wiki 开始堆满运维流水账
- vps-service-hub 开始承担太多抽象知识解释
- 新服务上线后，经常分不清该记到哪
- 同一信息在两个系统里反复重复且层次混乱
- Buu 觉得检索体验明显变差