# Linuxmirrors Awesome

> 介绍 LinuxMirrors 的定位、能力、支持范围、源码与权威资料，并在回答项目现状、兼容性、脚本差异、最新变化或资料来源时先核验官网、GitHub 和当前源码。用于认识项目和选择正确工作流；系统软件源实操或 Docker 安装换源应进入对应专项流程，不用本技能替代变更方案。

- Skill: `full-stack-skills/linuxmirrors-awesome` (Agent Skill, multi-file: 22 files)
- Install (CLI): `npx skillmds@latest add full-stack-skills/linuxmirrors-awesome`
- Raw SKILL.md: https://api.skillmd.com/api/skills/full-stack-skills/linuxmirrors-awesome/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: full-stack-skills (https://skillmd.com/u/full-stack-skills)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/full-stack-skills/linuxmirrors-awesome

---


# LinuxMirrors 权威指南

## Quick Start

先判断问题是“了解项目”还是“执行变更”。介绍、能力、兼容性、最新变化与资料核验留在本技能；系统软件源变更或 Docker 变更只给任务路由，不直接拼装生产命令。

可直接使用：

- “介绍 LinuxMirrors，并说明它与普通镜像站列表的区别。”
- “核验 LinuxMirrors 当前支持哪些系统，引用官网与源码。”
- “比较主脚本和 Lite 脚本，告诉我该选哪个。”

## 什么时候使用

当用户要了解 LinuxMirrors、核验最新项目事实、比较脚本或判断任务路径时使用。若用户要求实际换系统源、安装 Docker 或修改 Registry，则只完成资料核验与路由，不在本技能内执行变更。

## 适用用户

- 新手：先读项目定位与三条任务路径。
- 运维人员：重点读取新鲜度、兼容性、安全与路由资料。
- Skill/文档维护者：使用来源索引和质量清单验证事实与引用。

## 工作流

### Step 1：识别意图
区分项目介绍、最新信息、系统换源、Docker 安装、Registry Mirror 或源码分析。

### Step 2：检查时效
记录访问日期；动态事实至少核验官网和 GitHub/当前源码两类来源。

### Step 3：定位资料
按[权威来源](references/official/sources.md)读取官网、文档、仓库、更新日志和安全公告。

### Step 4：交叉验证
用[新鲜度规则](references/official/freshness.md)处理官网、README 与源码差异，禁止凭记忆补全。

### Step 5：组织回答
先给结论，再给适用条件、证据链接、风险和下一步任务路由。

### Step 6：自检输出
执行[质量清单](references/operations/quality-checklist.md)，确保没有把文档说明误写成已执行结果。

## 能力边界与不适用场景

### ✅ 擅长处理

1. 解释 LinuxMirrors 的项目定位、两类脚本、开源许可与典型用户。
2. 基于官网和源码核验支持系统、参数、主脚本/Lite 差异及最新提交。
3. 判断需求应进入系统软件源、Docker CE 软件源或 Registry Mirror 流程。

### ⚠️ 需要条件

1. “是否支持我的机器”需要发行版、版本、架构和网络区域。
2. “最新版本有什么变化”需要可访问官网或 GitHub，并标注核验时间。
3. “哪个镜像最快”需要用户位置与实测；只能给选择原则，不能虚构测速排名。

### ❌ 超出范围（给替代方案）

1. 直接修改 `/etc` 或运行远程换源脚本 → 转入系统换源专项流程并先做预检与备份。
2. 安装 Docker、关闭防火墙或重启生产服务 → 转入 Docker 专项流程并要求变更授权。
3. 保证第三方镜像站永久可用 → 提供验证命令、官方源回退和故障排查路径。

## 资料路由

- 项目定位与能力：读[项目概览](references/official/project-overview.md)。
- 支持系统与版本：读[兼容性](references/official/compatibility.md)。
- 官网、源码和更新日志：读[权威来源](references/official/sources.md)与[新鲜度规则](references/official/freshness.md)。
- 任务分流：读[决策路由](references/operations/routing.md)。
- 安全与隐私：读[安全边界](references/operations/security.md)。
- 信息冲突与访问失败：读[资料排障](references/operations/troubleshooting.md)。
- 交付前复核：读[质量清单](references/operations/quality-checklist.md)。
- 端到端用法：按需读取 `examples/` 中的十个场景。

## 安全与隐私

本技能不收集、存储或传输用户数据。访问外部资料时只读取公开页面；不得要求密码、Token 或私钥。不要在介绍性回答中执行 `curl | bash`、进程替换、软件源修改、Docker 安装或服务重启。

## Rules

1. 禁止在不确定领域胡编；查不到就标记未知和待核验项。
2. 动态事实至少引用官网与当前源码/GitHub 中的两类证据。
3. 不执行系统变更，不把建议命令写成已执行结果。
4. 多任务按项目理解、系统基础源、Docker CE、Registry 的顺序拆分。

## 信息不足时

先给安全假设版本，再列缺失信息：

> 先按“仅做资料核验、不执行变更”回答。若要判断实际可用性，请补充：1）发行版与版本；2）CPU 架构；3）网络区域；4）目标是系统软件源、Docker CE 软件源还是 Registry Mirror。

## 验证清单

- 动态事实是否注明核验日期和来源？
- 参数是否来自当前 `--help`、源码解析分支或官网高级用法？
- 是否区分系统软件源、Docker CE 软件源和 Registry Mirror？
- 是否把“建议执行”与“已经执行”明确分开？
- 是否提供无法访问官网时的 GitHub、本地源码或官方源降级路径？

## Gotchas

1. 不要把 LinuxMirrors 当作镜像站；它是换源与 Docker 安装/换源脚本项目。
2. 不要用 README 的旧参数覆盖当前脚本 `--help`；先核验源码。
3. 不要把 Lite 解释为完整脚本的完全等价物；它会精简功能与交互。
4. 不要承诺某镜像站“最快”；可用性受地区、运营商和同步状态影响。
5. 不要把 Docker CE 软件包仓库与 Docker Hub Registry Mirror 混为一谈。
6. 官网不可达时不要停止在“请提供更多信息”；先基于本地源码给带时间戳的暂定结论并列出待核验项。

## FAQ

**Q1：LinuxMirrors 是镜像站吗？** 不是。它提供自动识别系统并生成或修改软件源配置的脚本，也提供 Docker 安装与换源脚本。

**Q2：为什么必须访问官网？** 支持版本、镜像地址和参数会变化；官网与当前源码是动态事实的权威入口。

**Q3：官网与源码冲突怎么办？** 优先当前源码行为，标注提交号，并说明官网差异；不要静默选择。

**Q4：主脚本还是 Lite？** 需要完整交互、更多系统与高级参数时选主脚本；只在明确接受精简能力时考虑 Lite。

**Q5：能直接替我换源吗？** 本技能只做介绍和路由。实际变更必须先收集系统信息、备份和回滚条件。

**Q6：能推荐最快镜像吗？** 可给兼容性与区域选择原则，但不能替代目标主机的连通性和延迟测试。