好的，让我们开始。
如果之前您需要AllowUpgradesWithUnsupportedTPMOrCPU才能升级，那么现在也要。
如果您之前一直在用基于/product server的各路脚本的话，此方法可能不适合您。
确保您已作好发生意外的准备。
首先请下载单个 Windows ESD 安装文件。不知道在哪里？别问我要，问搜索引擎。建议的关键词为“Windows [10/11] [大版本号] 官方单 esd 文件”，然后你应该能够在 PCBeta 上找到满意的结果。拿出下载工具吧，速度将会比 Windows Update 快得多（我用了5分钟）。
下面我们要去 uupdump.net 找另一个工具。首先，确定 ESD 所包含的 Windows 内部版本号——例如，Windows 11 24H2 的官方 ESD 中版本号为26100.1742，在网站上查找它。
很好，之后你不出所料来到了这里：
搜索.exe文件。
有且只有这一个文件。下载它。不要忘记重命名。
接下来请把这两个文件放到同一个目录里面。
老生常谈——路径建议尽可能简单，无中文无空格无特殊字符。
也许您认为系统分区有点捉襟见肘，没关系，它们可以放到其它分区。安装程序会知道您的意图，并将文件尽可能放在那里。
不出所料，目前这个文件夹里面除了一个WindowsUpdateBox.exe和一个*.esd以外什么都没有。使用提升的命令提示符，运行我们的第一个命令：
start /w WindowsUpdateBox /Update /PreDownload /quiet
等待命令提示符返回。
/quiet事实上可能无效，因为加不加都不会有任何 GUI。这是正常的。之后的步骤也不会有 GUI 显示。
WindowsUpdateBox 将把自己解压到$Windows~.BT，然后没记错的话会调用里面的SetupHost.exe，但此时升级还没真正开始。
当然，对着一个毫无反应的命令提示符非常消耗耐心，因此可以额外打开任务管理器盯着 SetupHost，同时在注册表编辑器中转到HKEY_LOCAL_MACHINE\SYSTEM\Setup\MoSetup\Volatile，安装程序将在那里把自身进度以十进制放到SetupProgress键值中，如果还没到 100% 就返回，那么显然发生了一些意外情况。
在下文进行的操作中，SetupHost 会再次从 0% 开始，属于正常现象。进度将重置两次。
一旦您完成了第一个命令，现在可以运行下一个命令：
start /w WindowsUpdateBox /Update /Install /quiet
保持耐心。其会比上一步慢得多。继续等待命令提示符返回。
在此步骤中，安装程序将*.esd文件放到$Windows~.LS文件夹中，随后会从中解耦 UUP 到这里：
这里面甚至能够发现*.psf文件。
问题：ESD 的表层之下是否仍然是一堆 UUP？留给读者们思考。
再之后它在干什么就不知道了……
当完成第二步之后，运行这个：
start /w WindowsUpdateBox /Update /Finalize /quiet
这将导致自动重新启动。添加/noreboot以取消此行为。
此阶段中，安装程序应该是在设置 SafeOS。
完成之后，您可以去msconfig那边看看引导项是否正确地创建了，然后就可以重新启动。
因为中途没盯着电脑，我不确定这要重启两次还是三次。
最后 Windows 应成功来到新版本。
一些想法：
- 之前使用 ISO 升级的时候花两三个小时，这次从 12:20 到 13:35，一小时出头，还挺快的。
- 占用的磁盘空间最初远小于 ISO 升级方式。第二个命令执行完成时，我们得到的：
想想 ISO 方式创建的 NewOS 吧。它就是开了 Compact 也远不及此（这个方式当中 NewOS 文件夹是空的）。但更新完成之后就不一样了，考虑到在 LS 那边多复制的一份 ESD，另外还弄了个 Windows.old 的高达 6GB 的 WIM（有了 WIM 它仍然搞了一个 Windows.old 文件夹），加上零零碎碎的 SafeOS 和其它一些杂物，最终和 ISO 升级方式占用差不多的空间。
不过考虑到我是把它们放在了非系统分区上，可能一开始放在系统分区那里行为会有所不同。它要是不打包 WIM 的话，无论速度还是占用空间都会好得多。
升级完成之后大部分文件安装程序都不会清理，把那几个文件夹全部删除就差不多了。
可能需要您完成首次登录后再重启电脑 Windows 才会清理。
- 早在 Windows 8.1 还是 Windows 10 Preview 好像就见过 WindowsUpdateBox？这个升级方式貌似可能有点古早啊……不过那时候没有 UUP，或许是旧瓶装新酒……
- 这里使用了单 ESD 文件，不过我也很好奇如果用散装的 UUP 集能不能行。abbodi1406 的方案是把它们全部列入
ActionList.xml中喂给 WindowsUpdateBox，在早期 Windows 10 中可以工作，不过 Windows 11 不太可能。或者说，似乎也没人尝试过让 WindowsUpdateBox 单独面对这一堆 UUP 文件。走正常的 Windows Update 的时候 WindowsUpdateBox 确实是和 UUP 放在一起的，也许还真的可以？个人时间所限，看有没有人时间空余愿意尝试下了。
又及：这种 ESD 好像现在专门给 Media Creation Tool 用了……挺特别。
DaleZ 它把下载文件的目录名设为“UUP”也很奇怪呢。。。
- 基于
/product server的脚本可能无法工作是因为它们拦截注入参数的方式很可能会打断 WindowsUpdateBox 与 SetupHost 的交互，因此不推荐这样做。倒不如试试把参数加到 WindowsUpdateBox 上面，或许它能把这个传给 SetupHost 🤔……
That's all. Just having fun~
参考了 abbodi1406 的原始方法（Adagurd 网站上的脚本）和使用搜索引擎查找 WindowsUpdateBox 相关信息后得到的一堆手动部署功能更新的文章。
