从 GitHub issues 到可检索排障页：本站如何整理内容

GitHub issue 很适合记录单个用户当时遇到的问题，却不适合直接当作排障手册：相同故障会被反复提交，标题写法不同，回复散落在评论里，功能请求还会和真实故障混在一起。

CC Switch Wiki 的目标，是在不丢失来源的前提下把这些记录整理成可检索的主题页。

完整抓取，不截断原文

数据管道同步公开 issue 的标题、正文、标签、状态与评论。Pull Request 单独标记，不计入 issue 覆盖率；页面引用的编号必须能在本地数据快照中查到。

先区分“故障”和“想要的新功能”

“希望支持某个供应商”和“切换供应商后配置丢失”不是同一种内容。前者是功能请求，不能伪装成已有修复；后者才属于排障范围。

没有足够重复证据的个案不会强行写成确定的主题页。已关闭且有讨论的长尾问题会进入更多已解决的问题，直接链接原帖。

按簇内有区分度的信号聚类

聚类会参考 HTTP 状态码、稳定报错短语、文件路径、环境变量、平台、客户端和主题。一个词如果在簇内几乎每条 issue 都出现，就不适合作为拆分维度。

这一步把同一根因的重复报告放在一起，也防止“本地代理”这种高频背景词把无关问题混成一页。

页面结构固定，来源可以回查

每个主题页都按 Symptom / Cause / Fix 展开，并列出受影响版本、平台、FAQ 和 Source Issues。报错原文、日志、命令、代码、文件路径和产品名保持原样，方便搜索和逐字核对。

发布前有四道闸门

1. 结构和不可变字段校验；
2. 版本、路径、症状和引用 issue 的来源审计；
3. 中英文页面一一对应；
4. 整站构建、内部链接、Pagefind、canonical、hreflang 与 JSON-LD 校验。

任何一项失败，页面就不会部署。更新日志也直接从管道报告生成，不让模型替数据“写总结”。

当前覆盖数字、统计口径与非官方声明见关于本站。