tiny11builder 完整指南：如何快速打造轻量级 Windows 11 精简镜像-平芜编程栈

tiny11builder 完整指南：如何快速打造轻量级 Windows 11 精简镜像

【免费下载链接】tiny11builderScripts to build a trimmed-down Windows 11 image.项目地址: https://gitcode.com/GitHub_Trending/ti/tiny11builder

受够了十几 GB 的官方安装介质和开机就驻留后台的一堆预装应用？tiny11builder 就是一套专为这个痛点准备的开源脚本工具——它完全用 PowerShell 编写，能自动把任意版本的 Windows 11 ISO 加工成体积更小、组件更干净的精简安装镜像，全程依赖微软自家的 DISM 等原生工具，不引入第三方精简器。

tiny11builder 是什么：定位与核心价值

简单说，它是一个"镜像流水线"：从挂载后的官方 ISO 中提取系统镜像 → 剔除冗余应用与注册表项 → 用 DISM 的恢复级压缩重新打包 → 调用 oscdimg.exe（Windows ADK 自带）生成可启动的 tiny11.iso。核心价值体现在三点：

零第三方依赖：除 oscdimg.exe 外全部使用微软工具链，来源干净、可审计
通吃所有版本：不绑定特定构建号，任意 Windows 11 发布版本、任意语言、x64 与 arm64 架构均可处理
自动化收尾：内置 autounattend.xml，安装时跳过微软在线账户设置页，并以/compact压缩部署，进一步压缩安装后的磁盘占用

精简 Windows 11 能获得哪些收益

标准脚本会清掉二十多个预装 Appx 应用——Clipchamp、新闻、天气、Xbox 全家桶、邮件和日历、地图、录音机、你的应用、QuickAssist、Edge、OneDrive 等都不再随镜像出厂。与此同时还写入了一批注册表级调整：绕开 TPM、安全启动、CPU 与内存的硬件校验，关闭 7 GB 预留存储，静音遥测与广告推荐，拦截 Copilot 与 Teams 的自动安装。

综合下来，典型的变化幅度大致如下：

镜像体积：官方 ISO 约 5.5 GB，出片后约 3.2 GB
磁盘占用：安装后从 25–30 GB 压到 12–15 GB 量级
预装应用：从二十多款缩减到仅保留核心组件，后台常驻进程明显减少

标准版与 Core 版怎么选：先想清楚用途

仓库里提供两个脚本，取舍逻辑很清晰：

tiny11maker.ps1 是日常首选。它去掉大量臃肿组件，但保留了系统的可维护性——出片之后依然可以安装更新、添加语言包和启用功能，适合长期使用。

tiny11Coremaker.ps1 则往极限走：在标准移除清单之上，再砍掉 WinSxS 组件存储、Windows Update、WinRE，并将 Defender 设为禁用（需要时可手动恢复）。代价是镜像彻底"不可服务"——更新装不了、语言加不上、功能补不回。官方口径很明确：它是给虚拟机、快速测试和开发沙箱用的临时工具，不建议当作日常系统。

一句话决策：要长期用，选标准版；一次性测试环境，再考虑 Core 版。

Windows 11 精简镜像构建步骤：从 ISO 到 tiny11.iso

整个流程五步，熟练后几分钟就能跑完：

准备素材：获取官方 Windows 11 ISO（微软官网或 Rufus 均可），在资源管理器中双击挂载。另备一块空余空间充足的盘作为临时盘。

拉取代码：

git clone https://gitcode.com/GitHub_Trending/ti/tiny11builder

配置执行环境：以管理员身份打开 PowerShell 5.1，放开当前会话的策略（-Scope Process只影响本次进程，退出即还原）：
```
Set-ExecutionPolicy Bypass -Scope Process
```
启动构建：指定挂载盘符与临时盘符（只写字母，不带冒号）：
```
.\tiny11maker.ps1 -ISO E -SCRATCH D
```
参数可随意换序，用get-help .\tiny11maker.ps1可查看全部用法。随后按提示输入镜像索引（即 SKU，日常使用建议选 Pro 以获得完整功能）。
等待出片：脚本会依次完成镜像复制、应用剔除、注册表调优、清理与压缩、ISO 封装，并在脚本所在目录生成tiny11.iso。结束后自动清理中间文件并弹出 ISO 盘，全程留有tiny11_*.log日志可供复查。

进阶玩法：自定义移除列表与自动安装配置

有一定基础的用户可以在两个位置动手脚：

调整精简范围：tiny11maker.ps1 中的$packagePrefixes数组就是"移除白名单"，按包名前缀匹配 Appx 组件。想保留某款应用就删掉对应前缀，反之则可自行追加。项目是开源的，作者也鼓励按需增删。
修改安装行为：autounattend.xml 控制 OOBE 阶段的行为，目前主要做了两件事——隐藏在线账户界面、以压缩模式部署。想加本地用户创建、区域语言等节点，可直接按 unattend 规范补充。
Core 版特有条目：运行时会询问是否启用 .NET 3.5 支持，按需选择即可。
回退个别调整：脚本中的Set-RegistryValue逐条写明了每个开关对应的注册表路径，若某项调优与你的需求冲突，可以在执行前注释掉对应行。

常见坑位：执行策略、架构差异与组件回装

提前知道这几个坑，基本能少踩雷：

策略受限：若系统策略是 Restricted，脚本会询问是否改为 RemoteSigned；习惯上直接预先执行-Scope Process的 Bypass 更省事。
arm64 报错属正常：arm64 镜像的 System32 里没有 OneDriveSetup.exe，运行中闪过一条错误可以无视，不影响出片。
Edge 的"残留"：本体已删除，但设置里可能还留个别入口，属于已知现象，无实际影响。
Winget 先升级：安装后若发现 Winget 装不了软件，先到应用商店把它更新一遍。
组件"复活"：Outlook 与 Dev Home 有时会隔段时间回来，新版脚本已加强拦截，但仍是持续的博弈，介意可定期复查。
Core 版不可逆：被移除的组件事后无法补回，这是设计上的取舍而非缺陷，把它当作一次性环境使用即可。