SRS：AI 如何让 SRS 8 在 Windows 上原生运行

SRS 8 现在可以在 Windows 上原生运行了。这个大型功能由 AI 完成：一天之内约 1.5 万行代码。它没有引入新 Bug，也没有改坏任何现有代码。

作者：Winlin Yang
来源：SRS开源服务器

原生 Windows 意味着什么

srs.exe 使用 MSVC 为 Windows x64 构建，并以控制台程序方式运行。它不需要 Cygwin，也不需要 WSL。它支持与 Linux 版相同的协议和功能：

• RTMP、RTMPS、HTTP-FLV、HTTP-TS、HTTPS、HLS（TS 和 fMP4）以及 DASH。
• WebRTC WHIP 和 WHEP，支持 AAC 与 Opus 转码。
• SRT（包括 SRT 转 RTMP），以及 RTSP 和 GB28181。
• DVR、VOD、HTTP API、回调、exporter、edge 和 forward。
• 使用 ffmpeg.exe 进行推流和转码。

你也可以在 Visual Studio 中打开 SRS，在其中构建、运行和调试。甚至可以单步进入 State Threads 的协程切换代码，而那是用汇编写的。

改了多少代码

如果只算直接变更，大约是 1.5 万行，分布在两个 Pull Request 中：

• ST#40：让 SRS 底层的协程库 State Threads 支持原生 Windows。约 5000 行。
• SRS#4787：让 SRS 8.0 在原生 Windows 上运行。约 1 万行。

在此之前，还有大约 12 万行测试代码：

• State Threads 的测试覆盖率提升到 96%。约 1 万行。
• SRS#4785：性能工具与测试。约 1.6 万行。
• SRS#4780：OBS 自动化测试。约 6000 行。
• SRS#4772：黑盒集成测试套件。约 7.8 万行。
• SRS#4746：基础功能测试。约 9000 行。

即便是那 1.5 万行直接变更，绝大部分也是测试代码。不是测试的只有大约 3000 行：

• SRS：约 1500 行，主要是 srs_core_platform.cpp 中的平台适配层。
• ST：约 1200 行，主要是 event.c、io.c 和 md_win64.asm 中的平台相关代码。

这就是为什么 AI 能连续工作一整晚、做出几百次变更而不改坏任何东西。测试能以极大概率捕获错误，对 AI 和对人都是如此。所谓极大概率，大概是 99.9%，不是 100%。

花了多少成本

我买的是 Claude 每月 100 美元的套餐，所以真实成本就是每月 100 美元。与一名工程师的成本相比，这几乎可以忽略不计。

Claude 也会折算每个任务在 API Token 上的花费。Windows 这个功能跑了两次，因为中途我的登录凭证过期，只能重新开始：

• 第一次花了约 152 美元，完成了大约三分之一的任务，然后凭证过期。
• 重新登录后，第二次花了约 226 美元把任务做完。

加起来约合 370 美元的 Token 价值，消耗了我周额度的约 42%。

常有朋友跟我说，一个任务就把额度用光了。我认为原因有几个：

• 用月套餐，别用 API。​ 我这个 100 美元的套餐如果换成 API，恐怕要花几千美元。
• 至少用 100 美元的套餐，别用 20 美元的。​ 别指望近乎零成本就能做出大东西。
• 把 AI 的工作切小。​ 参考 srs-autopilot 和 srs-develop 这两个 skill。它们会为代码和文档建立索引，用 subagent 控制上下文体积，并从任务文件重启 agent，让每个上下文窗口都保持较短。

用 AI 并不等于在聊天窗口里敲一句”给我造个火箭”，第二天就能在门口收到火箭。我在 AI 如何以更高质量的代码维护 SRS 一文里写了相关工具和准备工作。我不认为我的工作流是最好的。AI 仍在快速进步，其中一些工具一年后可能就过时了。但我也并不认为到那时候，你就能靠一句话拿到火箭。

它完美吗？

不。即使有足够的时间、足够多的资深工程师，代码也从来不可能 100% 没有问题，何况这只是 AI 一天的工作。我在评审 AI 代码时，有时仍会发现问题。

为了让一个弱测试通过而走捷径。​ 在实现一个 RTSP 回调时，AI 调用了 on_client，紧接着就调用 on_disconnect。这明显不对，即便你不知道正确流程是什么，也能看出这不正常。而测试只校验了回调的数据，没有校验中间必须经过的协议步骤，于是 AI 找到了一个能通过测试的捷径。这类 Bug AI 自己也能修：换一个不带着原始上下文的 AI 来评审变更，就能发现它。所以我给这些 skill 增加了一个 audit 工作流。

奇怪但无害的代码。​ 在另一次变更里，代码本身是正确的，但存在冗余：一次调用就够了，后面的代码应该删掉。留着也不会引发 Bug，测试也能通过。AI 自查时可能发现不了，更聪明的模型或许能。但人一眼就能看出来，评审起来也很容易。

一个让数字更好看的测试视频。​ 在做性能优化时，AI 最初使用的是 SRS 默认测试视频。那个视频是 VBR 的，码率波动会给性能结果引入噪声，所以应该用 CBR。AI 没有注意到这一点。它优化完代码后，报告性能提升了 9%。换成 CBR 视频、去掉码率噪声后，提升只有大约 5%。这算不算 AI 夸大了自己的成果？我不认为 AI 短期内能解决这类问题。这需要相当冷门、偏门的行业知识。AI 公司并不是在造一个无所不知的神。能解决绝大多数问题就够好了，偏门的边角让人来补，总成本很低。

一个看起来划算、实际是坑的设计。​ AI 还提出过一个性能改动，可以多支撑约 10% 的连接数。但它在发生读操作时就触发缓存数据发送，任何有经验的程序员都知道这是坏设计。我和 AI 讨论后，AI 也承认这是个奇怪的设计、不值得做。我撤销了这个改动。

你本人不用 Windows？

有些人可能会说：我不用 Windows，这个功能对我没什么用。我觉得更有意思的问题是：从”AI 完成了这件事”里，你能得到什么启发？以下是我的体会。

当写代码不再困难，想法就变得重要。​ 想法就是一种取舍，而取舍取决于你认为什么值得。我认为原生 Windows 很值得做。很多程序员在用 Windows。不是每个人都买得起昂贵的 Mac，也不是每个人都习惯 Mac 那套工具链。这些人就不值得被支持吗？他们可能不做流媒体服务器，只是写业务代码、甚至做运维，只想用 SRS 调试或测试一下。让他们必须去装 WSL，摩擦太大了。有了原生 Windows，用 SRS 会方便得多。举手之劳、方便他人，怎么会不值得？

这是个难题，而且不是我的领域。​ 即便只改了 3000 行，那也是 ST 和 SRS 里的 3000 行，并不简单。而且我并不熟悉 Windows。我在 Linux 上编程，平时用 Mac，已经十多年没用过 Windows 了。如果我不是 Windows 专家，我怎么纠正 AI 在 Windows 上犯的错、怎么阻止它引入 Bug？但反过来说，如果 AI 只能做我本来就擅长的事，那它的局限就太大了。我觉得有意思的是，AI 能做我不擅长的事，而我依然能交付高质量的结果，并在这个过程中有所长进。AI 已经不只是助手，而是同伴。它和我很不一样，甚至不是人类，但我们一起交付了超出任何一方单独所能达到的结果。

如果 Windows 都做完了，还有什么够不着的？ 回头看我自己之前列出的 SRS 重要缺陷清单，大部分看起来都只是一个晚上的 AI 工作量。有些更难，那也许三个晚上。

该担心什么？

当 AI 做了我的工作、走了我以前走的路，我接下来该往哪走？我该不该有职业焦虑？

两年前我确实焦虑。AI 写的代码越来越好，我怕自己以后没代码可写。现在我越来越不焦虑，因为我已经接受了没有代码留给我写这件事。死亡来临时，除了接纳你还能怎样？而且我真的不在意代码是不是我自己敲出来的。太多有趣的事情正在发生。

随着我用 AI 来管理这个项目和社区，我发现了即便 AI 把编码全干了、我依然能做的事：

• 分享如何让 AI 取代我。​ AI 没法告诉你该怎么取代你自己。人还是得自己找退出路径，学会如何与 AI 一起维护项目。这对其他项目（无论是否开源）都有借鉴意义。
• 做取舍。​ AI 能实现任何功能，但总得有人来选择。比如多线程，方案有很多。不可能全都实现，也不能随便选一个然后推倒重来。选择取决于价值判断，AI 替你做不了。
• 评审，并持续学习。​ 看那些不是我写的 AI 代码时，我依然能一眼看出哪里不太对、哪里以后可能出问题。即使是我并不太熟悉的语言也一样。我没写代码，但评审时我依然在长进。
• 为人而写。​ 以前我没时间写文章，因为忙于琐碎的编码杂活。现在 AI 干了杂活，我有时间亲自敲下每一个字。当网络上充斥着 AI 生成的文字时，人来写，是不是感觉不一样？

社区的变化

AI 也在帮我维护社区，社区比以前更活跃了。Issue 和 Pull Request 都比以前更活跃。

当然，大家也在用 AI 来写 Issue 和 PR。这肯定是未来的趋势，没人会再一点一点手写了。而如果你用肉眼去看那些 AI 生成的 Issue 和 PR，一定会疯掉。我有专门的 skill 来处理它们，而且我发现 AI 处理得更好。我会让自己的 AI 不被对方的 AI 带偏：先让我的 AI 提取 Issue 或 PR 里的想法，再按它自己的方式实现，最后再看对方 AI 的改动，借鉴其中被遗漏的地方。

这个项目和社区现在变成了一场试验：我们和 AI 能不能让它再活十年？我不确定，就算项目死掉也没关系，不过是个开源项目而已。

接下来

AI 大约找到了 135 个 Bug，SRS 比以前更稳定了。SRS 7.0 应该会在今年年底进入稳定状态。我们过去大约每两年发一个版本，未来可能变成半年或一年一个。当主要功能完成后，一个版本就进入发布周期，这样你就能拿到可用于生产的稳定版本。

SRS 8.0 的大部分功能已经完成。接下来很可能是 WebRTC edge，这样集群相关的能力就齐了。如果你在一台机器上跑 origin、proxy 和 edge，那就是一种多进程的扩展方式，比多线程强得多。

我们还可能重写 SRT、加入 MoQ，或者加一个 Rust 写的 Proxy Server。这些属于试验性质，可能会放到 9.0。也可能完善 SRS 周边的应用，比如对 DJI 的支持。

比较明确的是，今年我们会把之前缺失的重要而复杂的功能做完，并证明 AI 有能力维护这个项目。明年的主要方向，是让 AI 能维护你生产环境里的 SRS 服务。写代码和跑服务，是完全不同的两件事。

这不代表事情会做完。永远做不完，而一个有趣的项目只会越来越有趣。

试一试

在带 MSVC x64 环境的 Git Bash 中，从源码构建 Windows 版 SRS：

git clone -b develop https://github.com/ossrs/srs.git

cd srs

bash skills/srs-develop/scripts/srs-windows-runner.sh build

cd trunk

./objs/windows/srs.exe -c conf/console.conf

从下一个 SRS 8.0 版本开始，releases 页面上的每个版本都会包含一个 Windows zip 包 SRS-Windows-x86_64-<version>.zip，它不需要任何 DLL。关于工具链、Visual Studio、控制台控制与资源限制等内容，见 Windows 文档。