1. tiny11builder 不是“魔改工具”而是 Windows 镜像工程的标准化流水线你在网上搜“tiny11builder”十有八九会看到一堆“一键精简”“秒变轻量”“告别卡顿”的标题。但我要先泼一盆冷水tiny11builder 本身不删任何系统文件也不绕过微软签名验证更不是什么破解补丁或注入式修改器。它本质上是一套高度封装、可复现、可审计的 PowerShell 自动化脚本集合其核心逻辑完全建立在微软官方支持的 DISMDeployment Image Servicing and Management和 ADKAssessment and Deployment Kit技术栈之上。换句话说它干的活你用管理员权限打开 PowerShell手动敲几十行 DISM 命令也能完成——只是没人愿意这么干。我第一次接触 tiny11builder 是在给一家做工业边缘计算设备的客户部署系统时。他们要求 Windows 11 IoT Enterprise LTSC 镜像必须控制在 8GB 以内且所有预装应用、后台服务、遥测组件必须彻底剥离同时保留 .NET Framework 3.5、Windows Subsystem for LinuxWSL、Hyper-V 平台虚拟化能力——这三者在默认镜像里是互斥的启用 WSL 就得开 Hyper-V开了 Hyper-V 就得留一堆驱动和服务留了服务体积就上去了。当时我们试过手动 DISM 操作光是清理“Windows Defender Antivirus”这个功能包就因为依赖关系错综复杂反复失败了 7 次最后一次还导致镜像无法启动。直到发现 tiny11builder 的--no-defender参数背后其实是先用DISM /Image:C:\mount /Get-Features列出所有可卸载功能再逐个分析Parent和Dependents字段最后按拓扑排序生成卸载序列——这才是它真正值钱的地方把微软文档里零散、晦涩、极易踩坑的 DISM 依赖规则变成了一个可预测、可回滚、可日志追踪的执行流。所以别把它当成“绿色软件”去双击运行。它是一条微型的 Windows 部署产线输入是微软原版 ISO比如en-us_windows_11_iot_enterprise_ltsc_2024_x64_dvd.iso输出是符合你定制策略的 WIM/ESD 文件。中间每一步——挂载、清理、精简、注入、提交、导出——都调用的是DISM.exe这个微软亲儿子所有操作日志默认写入logs\目录你可以随时用DISM /Get-WimInfo /WimFile:output.wim验证结果。它不黑箱它只是把黑箱般的 DISM 手动操作变成了白盒化的配置驱动流程。这也是为什么它能稳居 GitHub Trending 前列不是因为它多神秘而是因为它把一件极其专业、极易出错、文档极不友好的底层部署工作降维成了“改几个 JSON 参数 点一次 Start-Build.ps1”的事。你不需要背熟DISM /Image:C:\mount /Disable-Feature /FeatureName:NetFx3 /Remove的全部语法只需要在config.json里把netfx3: false设为true脚本就会自动判断该用/Enable-Feature还是/Disable-Feature并处理好前置依赖。这种“语义化封装”才是 tiny11builder 的真实定位——它是 Windows 部署工程师的 CLI 工具链不是小白用户的“一键加速器”。提示tiny11builder 的 GitHub 仓库里src\目录下全是.ps1脚本functions\子目录里每个.ps1文件都对应一个 DISM 操作模块如Remove-AppxProvisionedPackage.ps1、Disable-Telemetry.ps1。建议初学者先通读Start-Build.ps1主流程再对照DISM官方文档看每个函数的参数映射——这比直接跑脚本更能理解它到底在干什么。2. 精简不是“删删删”而是基于 Windows 功能层级的精准外科手术很多人以为“精简 Windows”就是删掉C:\Windows\SystemApps里的 Metro 应用或者用第三方工具禁用一堆服务。tiny11builder 完全不走这条路。它的精简逻辑严格遵循 Windows 的四层功能架构模型层级技术载体tiny11builder 控制方式典型操作示例体积影响L1功能包FeaturesWindows 功能如 .NET Framework、Telnet Client--no-netfx3,--no-telnetDISM /Disable-Feature /FeatureName:NetFx3单项 50–200MBL2可选组件Optional Features新式可选功能如 WSL、OpenSSH Server--no-wsl,--no-opensshDISM /Disable-OptionalFeature /FeatureName:Microsoft-Windows-Subsystem-Linux单项 100–500MBL3预配应用Provisioned Apps首次登录时自动部署的 UWP 应用如 Mail、Weather--no-appsDISM /Remove-ProvisionedAppxPackage /PackageName:Microsoft.Windows.Photos单项 20–100MBL4系统组件PackagesWindows 更新包、语言包、驱动包--no-langpacks,--no-driversDISM /Remove-Package /PackageName:Package_for_KB1234567~31bf3856ad364e35~amd64~~10.0.1.1单项 1–50MB关键点在于L1 和 L2 层的操作是“禁用”L3 和 L4 层的操作是“移除”。禁用Disable只是让功能不可用但文件仍保留在镜像中占用空间移除Remove则是物理删除文件释放空间。tiny11builder 默认对 L1/L2 采用禁用因部分功能存在硬依赖对 L3/L4 则直接移除——这是它体积压缩效果显著的核心原因。举个具体例子--no-apps参数。它不只是删掉开始菜单里的图标而是执行以下完整链路挂载 WIM 镜像到C:\mount\windows运行DISM /Image:C:\mount\windows /Get-ProvisionedAppxPackages获取所有预配包列表过滤掉Microsoft.DesktopAppInstallerwinget 依赖、Microsoft.VCLibs.140.00.UWPDesktop桌面应用依赖等关键包对剩余包逐个执行DISM /Image:C:\mount\windows /Remove-ProvisionedAppxPackage /PackageName:xxx清理注册表残留通过注入cleanup-apps.reg这个过程之所以可靠是因为它不靠文件名匹配易误删而是严格依据DISM /Get-ProvisionedAppxPackages返回的PackageName字段——这是微软定义的唯一标识符。我曾见过有人用批处理遍历SystemApps目录删*Mail*结果把Microsoft.Windows.CloudExperienceHost登录界面核心也删了导致系统无法进入桌面。tiny11builder 绝对避免这种野蛮操作。再看一个高频需求关闭遥测。网上流传的“组策略禁用”或“注册表修改”只能作用于已安装系统对离线镜像无效。tiny11builder 的--no-telemetry实际做了三件事禁用 L1 层的DiagTrack服务DISM /Disable-Feature /FeatureName:DiagnosticPolicyService移除 L4 层的遥测更新包DISM /Remove-Package /PackageName:Package_for_KB4074588~...注入预设的telemetry-off.reg到镜像HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection路径这三重保险确保镜像部署后从开机第一秒起就不再发送任何遥测数据——不是“关不掉”而是“根本没机会开”。注意--no-defender是最常被误解的参数。它并非彻底删除 Windows Defender而是禁用Windows-Defender-Default-Definitions功能包并移除所有预装的病毒定义更新包.cab文件。镜像里仍保留MpCmdRun.exe和基础扫描引擎但无定义库则无法查杀。若你需要保留 Defender应使用--defender-minimal它只移除 UI 组件和实时防护服务保留命令行扫描能力。3. 构建环境不是“装个 PowerShell 就行”ADK 版本与 Windows 版本必须精确对齐很多人跑 tiny11builder 失败90% 的原因出在环境准备阶段。它不像普通 PowerShell 脚本对运行环境有硬性依赖必须安装与目标 Windows 版本匹配的 Windows ADKAssessment and Deployment Kit且 ADK 版本不能低于目标系统版本。这不是建议是 DISM 引擎的底层限制。以构建Windows 11 26H2内部代号“Cobalt”镜像为例你必须安装ADK for Windows 11, version 26H2Build 26000不能用 ADK 24H2Build 24660即使它能启动但在处理26H2新增的CloudExperienceHost组件时会报错0x80070002找不到指定文件更不能用 ADK 22H2Build 22621它根本不认识26H2的新功能包命名规则我在实际项目中遇到过一个经典案例客户提供的 ISO 是Windows 11 Enterprise LTSC 2024 (Build 26100)但运维同事图省事直接装了最新版 ADK 26H2 Preview。结果脚本在Mount-WimImage.ps1步骤卡死日志显示DISM failed with error 0x80070057。排查了 3 小时才发现Preview 版 ADK 的DISM.exe对26100的WinPE驱动包解析有 Bug必须降级到ADK 26H2 RTM (Build 26000.1)才能正常挂载。ADK 的安装也不是全选就行。tiny11builder 只需要其中三个组件Deployment Tools必选提供DISM.exe、Oscdimg.exe、MakeWinPEMedia.exeWindows Preinstallation Environment (WinPE)必选提供WinPE驱动和工具用于创建可启动介质User State Migration Tool (USMT)可选仅在需要迁移用户数据时用tiny11builder 默认不用其他如Windows Assessment Tools、Application Compatibility Toolkit完全不用装它们不仅不参与构建还会拖慢安装速度、增加系统负担。PowerShell 版本同样关键。tiny11builder 要求PowerShell 5.1 或更高版本Windows 10/11 自带但严禁使用 PowerShell Core7.x。因为DISM的 PowerShell 模块Dism是 .NET Framework 依赖的而 PowerShell Core 基于 .NET Core无法加载脚本中大量使用的Get-WmiObject、Set-ItemProperty等 cmdlet 在 PowerShell Core 中已被弃用或行为不同Start-Build.ps1开头的#requires -Version 5.1就是硬性检查如果你在 Windows Server 上运行务必确认ExecutionPolicy设置。常见错误是Set-ExecutionPolicy RemoteSigned -Scope CurrentUser只对当前用户生效而 tiny11builder 需要以管理员身份运行所以必须执行Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force否则会在Import-Module Dism步骤报错File xxx.ps1 cannot be loaded because running scripts is disabled on this system。最后是磁盘空间。构建一个 8GB 的精简镜像临时空间需求远超想象挂载 WIM 需要 2 倍镜像大小ISO 5.2GB → 挂载后占用 10.4GBDISM 清理过程会产生大量临时文件C:\$WINDOWS.~BT\Sources\最终导出 WIM 时DISM /Export-Image会先解压再压缩峰值占用可达 15GB因此系统盘通常是 C:\必须预留至少 30GB 空闲空间。我见过太多人因空间不足在Export-WimImage.ps1步骤失败错误码0x80070070磁盘空间不足看似简单但日志里埋得很深新手往往花半天才定位到。4. 配置文件 config.json 是你的“精简宪法”每个字段都决定最终镜像的基因tiny11builder 的灵魂不在 PowerShell 脚本里而在config.json这个配置文件中。它不是简单的开关列表而是一个结构化的镜像策略声明。理解每个字段的含义和取值逻辑是定制出符合你需求镜像的前提。一个典型的config.json结构如下{ sourceIso: D:\\ISO\\win11_iot_ltsc_2024_x64.iso, outputDir: D:\\tiny11_output, wimIndex: 1, architecture: amd64, edition: IoTEnterprise, features: { netfx3: true, telnet: false, iis-webserver: false }, optionalFeatures: { wsl: true, openssh: false, hyperv: true }, apps: { removeAll: true, keepList: [Microsoft.DesktopAppInstaller, Microsoft.VCLibs.140.00.UWPDesktop] }, telemetry: off, defender: minimal, language: zh-CN, drivers: [] }关键字段深度解析wimIndex指定 ISO 中哪个 WIM 文件作为源。一个 Windows ISO 通常包含多个索引Index 1Windows 11 HomeIndex 2Windows 11 ProIndex 3Windows 11 EnterpriseIndex 4Windows 11 IoT Enterprise LTSC你不能凭名字猜必须用DISM /Get-WimInfo /WimFile:D:\sources\install.wim查看。wimIndex错了构建出来的就是错误版本——比如你想要 LTSC却用了 Index 1 的 Home 版后续所有精简都白费。edition这个字段直接影响脚本加载的精简策略。tiny11builder 内置了针对不同版本的优化规则IoTEnterprise默认禁用Windows Update Medic ServiceUsoSvc因为 IoT 场景不允许自动更新Enterprise保留Group Policy相关组件但禁用Work Folders企业云同步Education移除所有Microsoft Teams预配包但保留OneDrive教育版如果你把edition设为Pro却想构建LTSC脚本会警告但不会阻止结果就是镜像缺少 LTSC 特有的Windows Defender Application Guard组件导致部署后某些安全策略失效。features和optionalFeatures这两组布尔值看似简单但背后有强约束。例如wsl和hyperv必须同时为true或同时为false。因为 WSL2 依赖 Hyper-V 平台如果只开wsl:true而hyperv:false脚本会在Validate-Features.ps1步骤直接退出报错WSL2 requires Hyper-V to be enabled。这不是 bug是设计上的强制校验。apps.keepList这是最易出错的字段。keepList里的包名必须与DISM /Get-ProvisionedAppxPackages返回的PackageName完全一致包括大小写和版本号。例如Microsoft.Windows.Photos是正确的microsoft.windows.photos或Photos都会失败。tiny11builder 提供了一个辅助脚本Get-AppxList.ps1你可以先挂载 ISO运行它获取所有可用包名再复制粘贴到keepList中避免手输错误。telemetry取值不仅是on/off还有basic和enhanced。basic会保留Diagnostic Data Viewer诊断数据查看器UI但禁用所有上传enhanced则只禁用Activity History和Advertising ID保留核心遥测——这是为合规审计场景设计的灰度选项。实操心得我习惯在首次构建时先用--dry-run参数运行脚本.\Start-Build.ps1 --dry-run。它不会真正挂载镜像而是模拟整个流程输出将要执行的 DISM 命令列表。你可以仔细检查每一条命令是否符合预期比如确认DISM /Remove-ProvisionedAppxPackage是否真的避开了你keepList里的包。这比盲目构建后再修复快得多尤其当你在批量定制多个客户镜像时--dry-run是必备的安全阀。5. 构建失败不是“脚本坏了”而是 DISM 日志里藏着完整的故障地图当 tiny11builder 报错时第一反应不该是重装、重启或换电脑而是立刻去看logs\目录下的日志文件。tiny11builder 的日志设计非常专业每个主要步骤都有独立日志Mount.log、RemoveApps.log、Export.log且每条 DISM 命令的输入参数、返回码、标准输出/错误都会被完整记录。DISM 的错误码不是随机数字而是微软定义的 HRESULT 值每个都有明确含义。最常见的错误码及应对方案错误码含义根本原因解决方案0x80070002文件未找到ADK 版本过低不识别新系统组件升级 ADK 至匹配版本或确认sourceIso路径正确0x80070005访问被拒绝未以管理员身份运行 PowerShell或C:\mount\目录被其他进程占用右键 PowerShell → “以管理员身份运行”任务管理器结束dismhost.exe进程0x80070070磁盘空间不足临时空间不足尤其在Export-WimImage.ps1步骤清理 C:\ 驱动器确保 ≥30GB 空闲或修改config.json的outputDir到空间充足的盘符0x80070490元素不存在wimIndex错误或edition与 ISO 不匹配运行DISM /Get-WimInfo /WimFile:D:\sources\install.wim确认索引检查 ISO 是否为 LTSC 版本0x80073701挂载失败ISO 文件损坏或C:\mount\目录存在残留文件用certutil -hashfile your.iso SHA256校验 ISO MD5手动删除C:\mount\*后重试我遇到过一个特别隐蔽的故障脚本在Remove-Telemetry.ps1步骤失败日志显示0x80073701。按常规思路我以为是 ISO 损坏重下了三次 ISO 都不行。最后发现问题出在C:\mount\目录的 NTFS 权限上——之前一次失败的构建残留了C:\mount\windows目录其所有权被设置为某个已删除的域账户导致当前管理员无法写入。解决方案不是删目录而是用icacls C:\mount /reset /T重置所有子目录权限。另一个高频陷阱是DISM 安装输入法报错740。这其实不是 tiny11builder 的问题而是 Windows 输入法框架的权限缺陷。当脚本尝试注入自定义输入法时通过DISM /Add-Package会触发 UAC 提权但自动化脚本无法交互。解决方案是在config.json中禁用--no-inputmethod改用部署后通过Set-WinDefaultInputMethodOverridePowerShell 命令设置绕过 DISM 的提权环节。最后强调一个黄金法则永远不要跳过Validate-Image.ps1步骤。这个脚本在导出前会执行DISM /Check-Health检查镜像完整性DISM /Cleanup-Image /StartComponentCleanup清理组件存储DISM /Get-WimInfo /WimFile:output.wim验证导出镜像的索引和大小如果这一步失败说明镜像已损坏强行使用会导致部署后蓝屏或功能缺失。我曾帮一个客户修复过一个“构建成功但部署后无法联网”的问题根源就是Validate-Image.ps1被跳过DISM /Cleanup-Image未执行导致网络堆栈组件损坏。重新运行验证脚本后问题自然消失。踩坑实录某次为客户构建Windows 11 26H2镜像所有步骤都显示 success但部署后发现Windows Terminal无法启动报错0x80004005。排查日志发现Remove-Apps.ps1在移除Microsoft.WindowsTerminal时因--no-apps参数过于激进连带删除了Microsoft.VCLibs.140.00.UWPDesktop终端依赖的运行库。解决方案是在config.json的apps.keepList中显式加入该包名。这个教训让我养成了一个习惯每次新增keepList都用DISM /Get-AppxPackage -AllUsers | findstr VCLibs在干净系统上验证其存在性确保包名准确无误。6. 镜像交付不是“拷个 ISO 就完事”启动介质与部署策略决定最终体验构建出output.wim只是完成了 70% 的工作。剩下的 30%是让这个精简镜像真正落地到物理设备或虚拟机上。tiny11builder 本身不生成可启动 USB但它提供了完整的WinPE集成方案这才是工业部署的关键。标准交付流程分三步第一步创建 WinPE 启动介质tiny11builder 的Create-Media.ps1脚本会从 ADK 安装目录复制WinPE基础镜像winpe.wim注入DISM、BCDEDIT、Notepad.exe等必要工具添加tiny11-deploy.ps1脚本实现“一键部署”逻辑# tiny11-deploy.ps1 核心逻辑 $targetDisk Get-Disk | Where-Object {$_.Size -gt 30GB} | Select-Object -First 1 Initialize-Disk -Number $targetDisk.Number -PartitionStyle GPT New-Partition -DiskNumber $targetDisk.Number -UseMaximumSize -AssignDriveLetter | Format-Volume -FileSystem NTFS -NewFileSystemLabel Windows Expand-WindowsImage -ImagePath X:\sources\install.wim -Index 1 -ApplyPath D:\ -Compact这段脚本自动识别大于 30GB 的磁盘初始化为 GPT创建 NTFS 分区并将output.wim解压到D:\。你无需手动分区也无需记住diskpart命令。第二步注入驱动与定制化脚本工业设备往往需要特定网卡、串口、GPU 驱动。tiny11builder 支持在config.json的drivers字段指定驱动路径drivers: [ D:\\drivers\\realtek\\rtl8168.inf, D:\\drivers\\intel\\igfx.inf ]脚本会在 WinPE 启动时自动运行pnputil /add-driver加载这些驱动确保部署过程能识别硬件。更进一步你可以在scripts\目录下放置post-install.ps1它会在 Windows 首次启动时自动执行完成激活slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX网络配置New-NetIPAddress -IPAddress 192.168.1.100 -PrefixLength 24 -InterfaceAlias Ethernet应用安装Start-Process D:\\apps\\docker-desktop.exe -ArgumentList /S -Wait第三步验证与签名精简后的镜像必须通过微软的signtool签名否则在 Secure Boot 启用的设备上无法启动。tiny11builder 不内置签名功能但提供了Sign-Image.ps1模板# Sign-Image.ps1 $cert Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -match YourCompany} Set-AuthenticodeSignature -FilePath D:\tiny11_output\install.wim -Certificate $cert你需要提前在本地证书存储中导入有效的 EV 代码签名证书。没有签名的镜像在 Dell、HP 等品牌商用机上会直接黑屏报错Secure Boot Violation。最后提醒一个实战细节不要用 Rufus 或 BalenaEtcher 直接写入 tiny11builder 生成的 ISO。因为 tiny11builder 输出的是install.wim文件而非标准 ISO 结构。正确做法是用Create-Media.ps1生成WinPEUSB将output.wim复制到 USB 的\sources\目录覆盖原install.wim用oscdimg.exe重新生成 ISO如果需要oscdimg -n -bD:\winpe\efi\microsoft\boot\efisys.bin D:\winpe D:\tiny11.iso这个流程确保了启动介质的兼容性和可靠性。我经手的 200 台工业设备部署从未因启动介质问题失败过——因为每一步都源于 tiny11builder 的标准化设计而不是靠运气。个人体会tiny11builder 的最大价值不是帮你省了多少时间而是消除了部署结果的不确定性。以前我们交付一个定制镜像客户总要问“这个版本确定能跑 Docker 吗”“那个串口驱动肯定包含了吧”。现在我把config.json、drivers\目录、scripts\目录打包发过去客户自己运行Start-Build.ps1得到的镜像和我本地构建的一模一样。这种可复现性才是企业级部署的基石。它把“经验”变成了“代码”把“人”变成了“流程”。