- Linux 内核要求采用统一且严格的编程风格，优先考虑可读性，避免不必要的抽象或过度使用预处理器。
- 只要人类开发者对错误承担全部责任，并且在整个过程中保持透明，就可以使用人工智能辅助代码集成。
- 我们配备了自动化验证工具和严格的人工审核流程，以防止系统退化并确保系统稳定性。
进入 Linux 内核开发领域并非易事。一行代码要想被主分支接受，仅仅“能运行”是不够的；它必须遵循极其严谨的设计理念，优先考虑长期可维护性而非短期开发速度。
近来，争论的焦点集中在人工智能如何融入这个生态系统上。最初几乎完全的怀疑态度已经演变为一种务实和现实的态度，即人工智能被视为一种工具，类似于键盘或集成开发环境（IDE），只要它不成为提交劣质代码的借口。
黄金标准：代码的风格和质量
内核有着非常明确的代码风格指南，这并非建议，而是强制性要求。当开发者提交补丁时，如果代码不符合指南，审核人员很可能会要求他们重新格式化整个代码，因为代码的统一性对于成千上万的程序员快速理解系统的任何部分都至关重要。虽然像clang-format这样的工具可以帮助自动化这个过程，但最终还是要依靠人的判断。
新手常犯的一个错误是试图清理旧文件的格式，仅仅为了出现在变更日志中。社区会将此视为无关紧要的噪音，通常会遭到拒绝；只有当格式更改带来真正的功能改进时，才会被接受。此外，建议避免过早地引入抽象层。在内核中，过度的灵活性会降低性能并模糊逻辑，因此只有在绝对必要时才应实现抽象。
内核编程中的常见陷阱
使用 C 预处理器是另一个关键点。尽管 #ifdef 它们很有用，但代码中充斥着条件编译会使代码难以阅读。一般原则是： 将预处理器限制在头文件范围内 或者可以留空以便编译器进行优化的函数。类似地，宏也应该替换为 在线功能 尽可能采用后者，因为后者可以提供类型保证，避免危险的多次评估。
但是，这些功能不应过度使用。 inline如果代码中充斥着这些元素，会导致最终二进制文件体积膨胀，从而耗尽处理器缓存。 减慢系统执行速度在现代硬件中，空间就是时间：更紧凑的代码通常效率更高。另一方面，并发性是不可妥协的。任何共享资源都必须可用。 由锁保护 这是理所当然的，因为在开发代码时忽略多处理器系统无异于自取灭亡。
倒退与稳定的危险
在 Linux 生态系统中，导致功能回归是绝对不允许的。功能回归指的是，当一项改进破坏了其他用户已经正常运行的功能时。Linus Torvalds 对此态度坚决：任何破坏现有功能的更改通常都会立即回滚，无论这些更改带来了多少新优势。这一点在用户空间 ABI中尤为重要，因为 ABI 必须无限期地保持完整，以避免破坏外部软件。
验证和文档工具
为了防止错误影响最终用户，内核配备了一系列工具。从关注所有 GCC 警告到使用lockdep 检测死锁，整个工作流程必须严谨。其他值得注意的工具包括用于检测内存地址混淆的sparse和允许大规模语义更改的Coccinelle 。
至于文档，它不再是可有可无的，而是必不可少的。每个补丁都必须包含详细的变更日志，解释解决方案背后的“原因”。新的用户空间接口和启动参数必须有完整的文档。此外，我们鼓励使用kerneldoc，以确保任何加入项目的开发人员都能理解内部 API。
人工智能的融合
目前对于LLM（邮件列表管理）的立场很明确：如果人工智能能够增加技术价值，我们欢迎它，但它不能取代人类的判断。人们的关注点已经从将人工智能视为纯粹的营销手段，转向将其应用于分类和自动化审查任务，例如Sashiko系统，该系统有助于在人工干预之前检测漏洞和CVE（通用漏洞编号）。然而，真正的问题不在于人工智能本身，而在于大量未经任何预先过滤的自动化报告充斥着邮件列表。
对于人工智能使用者而言，透明度和问责制至关重要。尽管关于“由……辅助”之类的标签存在争议，但其基本原则是，无论代码是否由机器人生成，提交代码的人都应对每一行代码承担法律和技术责任。人工智能辅助代码的标准没有降低；它必须达到与手写代码完全相同的质量、测试和可维护性标准。
Linux 内核开发遵循一套严格的规范，最终代码的质量优先于开发方法。只要遵循标准风格，避免回归错误，并且人工智能仅用于辅助问题分类和缺陷检测（而非绕过人工审核），系统就能持续演进。我们尊重不使用人工智能的自由，但技术效率和个人责任感才是确保操作系统内核保持健壮性和可扩展性的唯一支柱。