回顾 Windows 11 在2021年亮相的前夕，我们在几乎毫无征兆的情况下于6月15日晚上获得了一个抢跑的 Build 21996，此版本具有相当完善的 Windows 11 界面，但完成度如此之高的作品也让人好奇，Windows 11 以及整个 Sun Valley 项目缘何而起，又是如何一步步发展到6月24日发布会上的那副模样的。
Windows 11 21H2 与众不同的开发流程
仔细查看BetaWiki上关于 Windows 11 开发的描述，不难发现此版本的开发与往常不一样，它并非顺着版本号单调递增的方向线性进行，而是被分成了几组，且同时分头前进：
第一组：推送到Dev通道的版本，全部位于外部的rs_prerelease至co_release分支，基本沿用 Windows 10 的外观；
第二组：Fire Steel 分支，分支名称由fs_开头，应用 Windows 11 的界面；
第三组：_wdx_、_sh分支，专注于 Windows 11 界面开发，默认情况下沿用 Windows 10 外观。此组版本和第一组分支的版本号均从21242左右起跳，直至21390时飞跃至21990并递增到22000。
第四组：专注于 Windows 11 界面开发且版本号独立的co_refresh系列分支，这些版本在UI上的开发成果会反向集成至上述第二组分支的版本。此组分支的版本号从21660开始递增到21697，然后跳到了22112开始继续递增。
此前，来自fs_分支的多个内部版本已经由BetaWorld泄露，也有一些截图被前微软员工 Albert Yih 上传到了他的个人博客上，它们也都已经具有相对完善的 Windows 11 外观。
所以要想看到真正早期的 Windows 11 界面，可能就得深挖co_refresh分支了。然而第一个流出截图的co_refresh版本 Build 22135 已经具有了接近于正式版的外观，因此21660+的版本似乎自然而然成为了最有可能具有早期开发UI的那些版本。
终于在北京时间2025年7月5日下午16时18分，Windows 11 build 21688 (co_refresh) 分支由 BetaWiki Discord 的成员“Owl”泄露，但泄露的内容仅包含用于启动PE的boot.wim和setup.exe。
初次泄露的10个小时后，完整版也被泄露了，并且可以看到除了 Windows 11 新版的设置和OOBE以外，全部沿用 Windows 10 界面。
然而，随着Owl的这一次泄露，他也揭开了许多关于 Windows 11 开发历程中不为人知的一些细节。
并且有一点是可以肯定的：在2021年6月及更早的co_refresh版本本身在默认情况下仍然沿用 Windows 10 的外观和界面。
Cherry Hill：Windows 11 UI 设计真正的“前线”
Owl指出，之所以我们看到的21688仍然是 Windows 10 的样子，原因在于真正的 Windows 11 界面元素并不是21688系统本身的一部分，而是存在于一个叫“Cherry Hill”的appx文件中。微软内部将co_refresh定义为与 Cherry Hill 一同使用的版本，统称为21i，故21i本身并没有任何的 Windows 11 UI 设计元素、代码、对应dll文件等，只有 Cherry Hill 体验包的接口，这个接口允许 Cherry Hill 的appx被安装到21i版本上，而只有这样才能看到 Windows 11 的实际开发进程。
Cherry Hill 所包含的内容都是刚刚进行开发的内容，也就是说它们相当不完善，类似于早期版本 Windows 8 中开始屏幕的样子；此外，Cherry Hill 里的这些半成品也并未集成至任何 Windows 版本，直到这些功能被开发完善，才会集成至上述第二组，也就是 Fire Steel 版本中。这也是为什么 Fire Steel 的版本已经具有相当成熟的 Windows 11 界面和设计了。
2020年11月时一个安装了 Cherry Hill 的 Windows 11 早期版本。图源：Owl
开发完善的开始菜单集成至 Fire Steel 版本中。图为 Build 21370 (fs_dev6_flt)
哪些分支的版本可以获得 Windows 11 UI？
先说结论，现在只有 Fire Steel 和版本号跃迁之后的co_release/co_refresh有机会看到 Windows 11 的外观。
微软团队在2017年的“秋季创意者更新”中提出了 Fluent UI 的概念，并在1709及以后的版本中逐渐集成，然而始终割裂的UI使微软相关部门在2020年提出了“a tiny refresh for Windows 10”（Windows 10 界面小焕新）的构想，并且释出了一系列概念设计。
图为2020年上半年时的概念设计，可以看到已经有了圆角窗口。
在2020年春夏两季，微软内部并未提出过 Windows 11 的想法，仍然坚守“Windows 10 是最后一代系统大版本”的承诺。“Cobalt”本来也只是 Windows 10 21H2 的代号，作为 Windows 10 的一次大更新。而到了2020年秋季，微软内部提出了“下一代Windows系统”的想法，内部称之为 Cherry Hill，并且作为一个appx格式的功能启用包向满足 Cherry Hill 更高的硬件要求的计算机推送。此时，内部也有将既有 Windows 10 界面称作“Windows 经典”，而将 Cherry Hill 以 Windows 10X 的形式发布的想法。
于是在2020年8至10月，内部团队完成了 Cherry Hill 项目的设计，包括界面和功能，随后开始逐步在 Cherry Hill 包中加入和试验这些功能。
10月起（事实上可能更早），Cherry Hill 进入了开发环节，由于当时并没有创建21i，故 Cherry Hill 的测试试验集中在开头提到的第三组（_wdx_、_sh等）分支中进行。第三组版本和后来的21i一样，在系统本身安装完毕时只具有 Windows 10 的UI，只有安装了 Cherry Hill 包才会显示 Windows 11 的界面。第三组分支和第一组分支（Dev通道，即rs_prerelease、co_release）的唯一区别就在于前者也内置了 Cherry Hill 的接口，后者没有，因此即使能拿到 Cherry Hill 包，若没有属于第三组分支的版本泄露，Windows 11 的界面也无从泄露。
未安装 Cherry Hill 包的 Build 21315 (rs_wdx_dxp_ixp3)，仍采用 Windows 10 界面。图源：Albert Yih
正确安装了 Cherry Hill 包的 Build 21354 (co_release_wdx_dash)，启用了 Windows 11 界面（注意任务栏）。图源：Albert Yih
而 Fire Steel，正如前文提到的那样，是集成了稳定 Cherry Hill 功能的版本，其集成功能的数目随着 Windows 11 的开发是与日俱增的。Fire Steel 是微软内部秘密测试新功能集成情况并分发给OEM合作伙伴的版本组。
图：Owl对于 Fire Steel 性质的解释。
然而可惜的是，Cherry Hill 包只向微软内网的Store服务器推送，并且其下载安装和更新流程与正常下载安装和更新公开 Microsoft Store UWP 应用的流程相似，旧版 Cherry Hill 包会很快被新版的包所覆盖，而Owl本人并未对每个版本的 Cherry Hill 包进行存档，因此现在仅能够在 Fire Steel、21990之后的co_release和22112（此数字存疑，但大概率是22112）之后的co_refresh看到 Windows 11 的外观。
Owl表示，当Store检测到并下载安装新版本的 Cherry Hill 包时，整个explorer.exe的进程（包括任务栏、壁纸和所有的资源管理器窗口）会暂时停摆约5分钟，5分钟后，新的界面就会呈现。
而想要看到更加早期形态的 Windows 11，则需要观察早于21370的fs_分支版本。
Cherry Hill 或其类似物在2025年仍然存在
注：以下部分内容为作者猜测
虽然 Windows 11 21H2 的开发已经日渐远去，但是这样的开发思路和流程仍然被微软保留下来，如今 Insider Preview 的ge_prerelease和ni_prerelease可以看作这套模式的进阶版，_prerelease分支相当于当时的rs_prerelease和co_release，而内部还有_moment_/_current_的分支，也留着 Cherry Hill（或类似物）的接口，且这样的接口在推送到Dev（或Canary）通道的版本中并不存在，新功能的集成只会在 Cherry Hill（或类似物）中开发完善后集成至 Insider Preview 版本中，其不完善的版本只存在于 Cherry Hill（或类似物）中，这也是为什么新版资源管理器等大量新功能会在 Build 23466 中突然出现，而在先前的版本中几乎看不到其半成品的存在。
资源管理器（Build 23451）
资源管理器（Build 23466），启用了全新的UI
后记：关于Windows开发“周期”（Semester）
如今各大介绍 Windows Beta 的百科均将 Windows 11（及其服务器端）的各个版本以“周期”的形式分类，认为一个大版本对应某几个完整的周期。
然而，Owl表示，“周期”只是Azure的开发概念，除了release分支前面的两位字段，周期和Windows版本没有直接关联，而是公司层面的任务组合，包含多个项目，不只是Windows的开发。
“周期”正如我们学校里的学期（其实semester就有学期的含义），Windows的开发只是学校里的一个“科目”，而在微软这所“学校”里还有别的“科目”，比如Office开发等。每个科目的进度和学期也并没有必然联系，比如学校可以安排在第一学期学完数学的必修一，也可以安排学完必修一和二的部分章节。
Windows的开发也是如此，一个版本的开发未必会在某个周期直接结束，而是在哪个周期结束，release分支就会冠上这个周期的简称。
比如 Windows 11 2024 年更新，开发过程从2023年春季便已启动，此时上一个项目（Server v23H2）开发已经接近尾声（zn_release被创建），而2024年更新在2024年春节时期接近尾声（ge_release被创建）。
这意味着 Windows 11 2024 年更新的开发流程跨越了3个周期，从Zinc的后期一直到Germanium，因为2024年更新于Zinc的后期立项，同时发生的事情也有 Server v23H2 的定版，这两件事情均在微软公司的Zinc周期内发生。
2024年更新的定版发生在2024年2月初，此时处于微软公司的Germanium周期。
至于 Windows vNext，在2024年1月末至2月初随着 Build 27547 便已立项，此时仍然处于微软公司的Germanium周期。2024年春节后的某一时间，微软公司进入了Dilithium周期，2024年8月底进入Selenium周期，2025年5月上旬进入Bromine周期。由此可以看出微软公司层面的周期代号以6至7个月为一个单位流转，但是 Windows vNext 的开发并未随之出现硬性断代。
如果 Windows vNext 就此定版，那么它的版本分支会是br_release，这是因为定版发生在公司层面的Bromine周期内。
图：Owl对于“周期”的看法。截取自 BetaWiki Discord
2025年7月6日
MicrosoftRTX2080 编写
