Part 0.1 编码伦理与开源精神
欢迎来到 zero-to-sglang 课程，作为课程的第一课，所谓德成而上，艺成而下，我们希望在进行技术教学之前，能够传播良好的开源精神，以及如何在开源社区中与他人沟通交流合作。在 AI 时代下，写代码比审查代码要简单太多，所以我们也希望所有开源贡献者能为自己的代码负责，尊重技术，也尊重每一个 reviewer 的时间。
文章中的内容看上去确实很常识，但是确实是我们在维护开源社区中遇到的典型案例，所以提出来希望能够引起大家的自觉。
Coding ethics
1. 对自己的代码负责
首先要说明，开源社区并不反对用 AI 写代码，所有程序员都在用。但是对于生产环境中，我们希望提交出去的代码，作者自己认真读过，并且知道它为什么这么写。
无论是古法 Stack Overflow 参考的，还是 AI 编写的，或者是自己手打的，都是合理的代码。但是在 AI 时代下，以前写 500 行要一个小时，甚至一个下午，而现在只需要 30 秒。但 reviewer 读这 500 行、判断它对不对，还是要大量的时间。这其实是一种隐形的工作量和责任的转化，也正因如此，每一个社区的贡献者需要有自觉去维护自己的代码，否则项目将无法进行下去。
所以，在开源的贡献中，可以在提 PR 之前问自己几个问题：
- 这个 PR 解决的问题是什么，有没有明确的 motivation？
- 这个 PR 的成果是什么，如何才能复现得到的成果？
- 这个 PR 涉及到的代码区域和部件具体是什么，函数调用逻辑是什么，侵入性如何？
- 随便拿出一个函数，我能说出删了它会怎样吗？
有一个答不上来，就先不要提交。尽量保证 PR 不要过大，并且自己能够完全理解，也可以减少 reviewer 来审查的成本，以及后续的沟通成本。因此，就涉及到第二章的问题。
2. 沟通时说人话
issue、PR 描述、review 回复、群里交流，请用自己的话写，不要把 AI 的回复整段贴出去。
道理和上一条相同，还是尊重别人的时间。AI 生成的回复长什么样大家也很容易看出来。两百字里有用的信息可能只有十五个字，剩下的全是 AI 的包装。
比如很典型的例子：
感谢您的 review！您提出的观点非常有价值。关于是否启用 CUDA Graph 的问题，我进行了深入的分析。1. 性能方面：CUDA Graph 可以有效减少 kernel launch 的 CPU 开销，对小 batch 场景有显著收益…… 2. 显存方面：需要考虑 graph capture 带来的额外显存占用…… 我做了实验，结果大概是……综上所述，如果要追求极致性能，我建议打开 CUDA Graph，但是要追求小显存，我建议不打开。我认为当前的实现是一个合理的权衡。期待您的进一步指导……
试了。开 CUDA Graph 后 batch=n 的 decode step 从 xx ms 降到 xx ms，以下是优化前后 profile 的图表。graph capture 多出来占用的显存是 yy。
第二种简洁明了，一眼就知道说了啥，而第一种就是典型的 AI slop——刚才随手让 AI 生成的，给人的可信感非常低。
同时，当维护者看到 AI 味的回复，第一反应就是"这个 PR 八成也是生成的，本人没读过"，会直接影响别人对你代码的信任。
3. Profile 永远是第一步
Profile 永远是任何性能相关的工作的第一步。
正确的顺序是：profile，找到瓶颈，改，再 profile，对比。我们要避免射箭画靶的行为，并不是说做一个优化，做完了，merge 进 repo 就完事了。因为在开源的实践中，很多人都会犯一个错误：要优化的那部分很可能一共只占 3% 的耗时。占 3% 的东西优化到零，端到端也只快 3%。
所以动手之前先回答一个问题：我要改的这段，在真实负载下占多少时间？答不上来就先去测，这一小时能帮你省下两个星期。
这也是为什么我们说不要功利性地为了 merge 一个 PR 积攒项目经验。因为抱有这样心态的人越多，类似上文说的垃圾 PR 越多，好的 PR 就会被淹没在其中。
因此，我们建议性能 PR 至少有如下三样指标：
- PR 前后的对比数据。
- 可复现的命令。
- Profile 证据。 别人想看的不是"快了 12%"，而是"为什么快了"。用 profile 软件测试并且绘制时间图，学会看和解释时间图，确保 PR 真正解决了 motivation 中列出的问题。
4. 总结：什么样的第一个 PR 不受欢迎
根据前文的讨论，总结几个坏 PR 的坑，希望大家提出之前自查：
- AI 生成的、本人没读过的大 PR。上千行，问哪里哪里答不上来。
- 性能 PR 不带任何数据、可复现结果等。
- 不经过设计重构核心模块，侵入性过强。
- 未经讨论就做设计决策：加新依赖、引入新抽象、改默认参数。
- 同时开十个 spam PR，PR 没有清晰的 motivation。
那么好的第一个 PR 长什么样？小，完整，真正解决一个 existing issue，有验证。我们往往建议：先了解，后提问，最后贡献。一个好的 PR 作者，首先是能找到系统问题并且提出 issue 的人。
Open-source spirit
我为人人，人人为我
这门课要用到的每一样东西——PyTorch、FlashAttention、SGLang、你下载的那些开源权重，甚至包括这个课程本身，都是开源，即别人无偿给你的。所以开源社区的默认心态很简单：你受益于别人留下的东西，也顺手把自己的东西留下来，让这个循环转下去。具体到这门课的学习过程：也许后面你会在 mini-SGLang 时踩很多坑，部署环境会有问题，花十分钟把坑写清楚发出去，下一个人就少花几个小时。开源精神就是这么件事。贡献也不只是代码，文档、翻译、复现 benchmark、帮人定位 issue，和写 kernel 同等重要。
开源社区欢迎想学习技术、愿意为技术做贡献的人，因为每个人都是从不会开始的。不欢迎的，是把开源当刷简历工具的人。为了简历参与开源本身没有问题，几乎所有人的动机里都有这部分；有问题的是把手段和目的搞反，目标变成 PR 数量而不是解决问题。
这一课收尾就三点：尊重他人的时间，尊重技术，对自己的代码负责。写代码不像是建大桥，桥塌了要承担法律责任。但是同作为工程师，希望每一位参与课程的同学，能有自己作为工程师的骄傲和责任，真正在开源社区做到我为人人，人人为我。
德成而上，艺成而下。请大家时刻保持这一份开源精神，带着它进入接下来的代码学习。