乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > CNCF 项目中的 AI 现状:首批数据观察

CNCF 项目中的 AI 现状:首批数据观察

当前时间： 2026-04-30 11:54:05 更新时间： 2026-04-30 分类：软件教程 评论(0)

CNCF 项目中的 AI 现状:首批数据观察

CNCF TAG Developer Experience
AI 已经进入开源开发现场，这件事大家大概都感受到了。
但问题是：在 CNCF 项目里，维护者和贡献者到底怎么用 AI？
  •  他们用哪些工具？
  •  AI 真的提升了效率吗？
  •  项目有没有正式规范？
  •  维护者又担心什么？
为了更具体地回答这些问题，CNCF TAG Developer Experience 近期启动了一项调查，希望了解人工智能正在如何影响开源开发。
这项调查本身也很值得关注。因为这是 CNCF 社区第一次以数据方式，系统性观察 AI 在 CNCF 项目中的实际使用情况。更重要的是，社区反应非常快速：初步反馈中，近一半是在第一周内收到的。
这说明一件事：
AI 辅助开发已经不是一个遥远趋势，而是许多开源维护者和贡献者每天都在面对的现实问题。社区也确实需要更清楚、更共同的参考原则，来讨论 AI 该如何被使用、披露与治理。
截至目前，调查已经收集到来自 133 位受访者的数据，涵盖近 100 个不同项目。因此，这些初步观察虽然还不是最终报告，但已经具备一定代表性，可以让我们先看到云原生生态中的一些重要趋势。
接下来，就是这份首批数据所呈现出的几个重点观察。
谁在回答？
首先，这份调查的反馈主要来自真正站在第一线的人。
绝大多数受访者都是以代码贡献为核心的参与者，他们日常关注的重点包括代码提交、CI/CD、基础设施等实际开发与维护工作。
同时，也有大约 20% 的受访者，除了工程工作之外，还同时承担发布管理、文档维护等关键角色。
这代表这份调查并不是从旁观者角度看 AI，而是来自真正参与项目运行、代码维护和社区协作的人。因此，这些反馈对于理解 AI 在开源项目中的真实影响，特别有参考价值。
维护者如何使用 AI：工具与工作流
过去我们谈到 AI 工具，可能会想到网页上的聊天机器人。
但现在情况已经不同了。
现代 AI 工具已经开始深度进入开发者的日常流程，不再只是“打开网页问问题”这么简单。
调查显示，近半数受访者已经直接在 IDE 或命令行界面中使用 AI 助手。也就是说，AI 已经被放进开发现场，成为写代码、看代码、调试和处理日常工作的辅助工具。
图表 1：AI 工具使用方式
从工具来看，Claude Code 和 GitHub Copilot 是目前较明显领先的工具。
比较有意思的是，只有少数贡献者，大约 10%，仍然主要依赖基础聊天机器人，并通过手动复制、粘贴的方式使用 AI。
与此同时，也有一批进阶用户已经进入更高层级的使用方式。他们不只是把 AI 当成问答工具，而是把 AI 直接嵌入项目自动化流程，例如用于 Pull Request 审查、issue 分类等任务。
这也是一个很关键的观察：
AI 在开源项目中的角色，正在从“个人辅助工具”慢慢走向“项目工作流的一部分”。
AI 最能发挥作用的地方
那么，AI 到底在哪些地方最有帮助？
从受访者反馈来看，贡献者最明显感受到生产力提升的地方，集中在以下几个方面：
  • 编写和重构代码。
  • 改进文档与调试。
  • 理解不熟悉的代码库。
  • 分析 Pull Requests。
其中，“理解不熟悉的代码库”这个项目特别值得注意。
大型开源项目通常结构复杂，历史包袱多，新贡献者要进入一个项目，往往需要花不少时间理解架构、模块关系、代码逻辑和既有规则。
而现在，AI 开始像一个熟悉项目的向导，帮助开发者更快进入代码脉络，降低理解大型项目的门槛。
这不只是效率问题，也可能影响未来开源社区的新贡献者参与方式。
AI 使用与官方政策之间的落差
这份调查中，最值得关注的发现之一，是“大家已经在用 AI”，但“正式规范还没有跟上”。
也就是说，个人层面的 AI 使用已经相当普遍，可是项目层面的正式治理政策仍然明显落后。
约三分之二的受访者表示，他们不知道项目是否有特定 AI 指南，或确认其主要代码仓库中并没有正式政策。
此外，绝大多数项目在公开文档或贡献指南中，也没有明确提到 AI 使用。
图表 2：AI 使用政策现状
这代表什么？
简单来说，AI 已经进入工作现场，但规则还在路上。
虽然已经有少数项目开始制定比较清楚的政策，试图为生态树立参考方向，但整体来看，云原生生态仍然处在摸索阶段。
尤其是面对 AI 生成代码、AI 辅助提交、AI 参与审查等新情况，项目到底应该如何定义责任、质量、安全与透明度，目前还没有形成一致做法。
这也是为什么这项调查重要：
它不仅是在统计工具使用情况，更是在帮助社区看见治理缺口。
社区态度与代码审查
虽然正式规则还不完整，但社区对于 AI 的整体态度并不是抗拒的。
从调查来看，整体氛围更接近开放、务实、接受。
大约三分之一的贡献者表示，AI 使用通常是被允许的。相对而言，明确禁止 AI 使用的比例非常低，低于 4%。
图表 3：对 AI 辅助贡献披露的态度
这种态度也反映在维护者处理 AI 生成贡献的方式上：
  • 大多数维护者仍然按照标准审查流程处理，不会因为怀疑使用了 AI 就采用特殊过滤机制。
  • 超过四分之一的维护者更倾向协作式处理：如果 AI 生成代码质量还不够，他们会要求贡献者继续修改，让代码达到项目质量标准，而不是直接拒绝。
  • 只有极少数维护者会自动拒绝疑似 AI 生成的 Pull Request。
这说明，CNCF 社区目前更关心的不是“有没有用 AI”，而是“最后提交出来的东西是否安全、合规、可维护”。
换句话说，AI 并没有被简单视为禁区。
但社区也没有把它当成可以无条件接受的万能工具。
主要担忧与对透明度的呼吁
当然，开放并不代表没有担忧。
维护者最关心的问题，主要集中在三个方面：
  1. 安全漏洞。
  2. 许可证合规。
  3. 审查者负担，尤其是大量低投入 PR 可能带来的压力。
这些担忧都非常现实。
AI 可以提高代码产出速度，但如果质量参差不齐，就可能让维护者面对更多需要审查、验证和修正的内容。
对于开源项目来说，这会进一步放大维护者原本就已经很重的工作负担。
因此，社区对于“透明度”有很强的需求。
超过半数受访者认为，AI 辅助贡献应该始终要求正式披露，例如使用 “AI-authored” 标签。另有约 20% 的受访者认为，在特定情况下应该要求披露。
这背后的意思很清楚：
维护者并不是完全拒绝 AI 生成代码。
 但他们希望知道哪些内容使用了 AI，以便调整审查方式、投入相应注意力，并更好地管理安全和合规风险。
透明度，正在成为 AI 进入开源协作流程中的关键议题。
总结
这批首轮数据确认了一件事：
AI 集成已经不再只是一个趋势，而是现代开发工作流中的核心组成部分。
对于 CNCF 和更广泛的云原生社区来说，接下来的挑战不是简单回答“要不要用 AI”，而是要思考：
如何在提升生产力的同时，维持企业级开源所需要的安全标准、代码质量、许可证合规与人工监督？
这也是这份初步调查最重要的价值。
它让社区第一次以数据方式，看见 AI 正在如何进入 CNCF 项目的实际工作流，也让大家更清楚看到：工具使用已经走在前面，而治理、披露和共同规则还需要继续补上。
这项工作还没有结束。
为了确保最终报告能够真正反映多元的云原生生态，CNCF TAG Developer Experience 仍然希望听到更多社区成员的声音。
调查将持续开放至 5 月 18 日星期一，以 Anywhere on Earth 的当天结束时间为准。
如果你还没有分享自己的经验，欢迎参与这项调查，帮助社区建立一幅更准确、更完整的图景：AI 正在云原生开源项目中扮演什么角色，以及未来应该如何被更负责任地使用。、
参与调查：https://docs.google.com/forms/d/e/1FAIpQLSeL_uZdmPVhqq1jrmAUCShDWshnKiZ7BnAcc_u2B7rbrWTxIA/viewform
作者：Graziano Casto、Hélia Barroso、Alessandro Pomponio、Sonali Srivastava

2026 KubeCon + CloudNativeCon + OpenInfra Summit Asia + PyTorch Conference China 议题征集与注册现已盛大开启！

立即下载赞助商企划书（https://cncf.io/sponsor）了解赞助方案和市场推广机会。

CNCF概况（幻灯片）

扫描二维码联系我们！

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。 

CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请关注CNCF微信公众号。