CNCF TAG Developer Experience 近期启动了一项调查,希望了解人工智能(AI)正在如何影响开源开发。这也是 CNCF 社区第一次以数据方式,系统性观察 AI 在 CNCF 项目中的实际使用情况。
“AI 辅助开发已经不是一个遥远趋势,而是许多开源维护者和贡献者每天都在面对的现实问题。社区也确实需要更清楚、更共同的参考原则,来讨论 AI 该如何被使用、披露与治理。”
目前,CNCF 共收集到来自 133 位受访者的数据,涵盖近 100 个不同项目,得到了具备一定代表性的初步观察结果。绝大多数受访者都是以代码贡献为核心的参与者,他们日常关注的重点包括代码提交、CI/CD、基础设施等实际开发与维护工作。也有大约 20% 的受访者,除了工程工作之外,还同时承担发布管理、文档维护等关键角色。
维护者如何使用 AI:工具与工作流

调查显示,近半数受访者已经直接在 IDE 或命令行界面中使用 AI 助手。也就是说,AI 已经被放进开发现场,成为写代码、看代码、调试和处理日常工作的辅助工具。
从工具来看,Claude Code 和 GitHub Copilot 是目前较明显领先的工具。只有约 10% 的少数贡献者仍然主要依赖基础聊天机器人,并通过手动复制、粘贴的方式使用 AI。
也有一批进阶用户已经进入更高层级的使用方式。他们不只是把 AI 当成问答工具,而是把 AI 直接嵌入项目自动化流程,例如用于 Pull Request 审查、issue 分类等任务。AI 在开源项目中的角色,正在从“个人辅助工具”慢慢走向“项目工作流的一部分”。
AI 最能发挥作用的地方
从受访者反馈来看,贡献者最明显感受到生产力提升的地方,集中在以下几个方面:
- 编写和重构代码。
- 改进文档与调试。
- 理解不熟悉的代码库。
- 分析 Pull Requests。
AI 使用与官方政策之间的落差

这份调查中,最值得关注的发现之一,是“大家已经在用 AI”,但“正式规范还没有跟上”。也就是说,个人层面的 AI 使用已经相当普遍,可是项目层面的正式治理政策仍然明显落后。
约三分之二的受访者表示,他们不知道项目是否有特定 AI 指南,或确认其主要代码仓库中并没有正式政策。此外,绝大多数项目在公开文档或贡献指南中,也没有明确提到 AI 使用。
简单来说,AI 已经进入工作现场,但规则还在路上。虽然已经有少数项目开始制定比较清楚的政策,试图为生态树立参考方向,但整体来看,云原生生态仍然处在摸索阶段。
尤其是面对 AI 生成代码、AI 辅助提交、AI 参与审查等新情况,项目到底应该如何定义责任、质量、安全与透明度,目前还没有形成一致做法。
社区态度与代码审查

虽然正式规则还不完整,但社区对于 AI 的整体态度并不是抗拒的。从调查来看,整体氛围更接近开放、务实、接受。大约三分之一的贡献者表示,AI 使用通常是被允许的。相对而言,明确禁止 AI 使用的比例非常低,低于 4%。
这种态度也反映在维护者处理 AI 生成贡献的方式上:
- 大多数维护者仍然按照标准审查流程处理,不会因为怀疑使用了 AI 就采用特殊过滤机制。
- 超过四分之一的维护者更倾向协作式处理:如果 AI 生成代码质量还不够,他们会要求贡献者继续修改,让代码达到项目质量标准,而不是直接拒绝。
- 只有极少数维护者会自动拒绝疑似 AI 生成的 Pull Request。
这说明,CNCF 社区目前更关心的不是“有没有用 AI”,而是“最后提交出来的东西是否安全、合规、可维护”。换句话说,AI 并没有被简单视为禁区。但社区也没有把它当成可以无条件接受的万能工具。
主要担忧与对透明度的呼吁
维护者最关心的问题,主要集中在三个方面:
- 安全漏洞。
- 许可证合规。
- 审查者负担,尤其是大量低投入 PR 可能带来的压力。
AI 可以提高代码产出速度,但如果质量参差不齐,就可能让维护者面对更多需要审查、验证和修正的内容。对于开源项目来说,这会进一步放大维护者原本就已经很重的工作负担。
因此,社区对于“透明度”有很强的需求。超过半数受访者认为,AI 辅助贡献应该始终要求正式披露,例如使用 “AI-authored” 标签。另有约 20% 的受访者认为,在特定情况下应该要求披露。
这意味着,维护者并不是完全拒绝 AI 生成代码。但他们希望知道哪些内容使用了 AI,以便调整审查方式、投入相应注意力,并更好地管理安全和合规风险。透明度,正在成为 AI 进入开源协作流程中的关键议题。
总结
这批首轮数据确认了一件事:AI 集成已经不再只是一个趋势,而是现代开发工作流中的核心组成部分。
对于 CNCF 和更广泛的云原生社区来说,接下来的挑战不是简单回答“要不要用 AI”,而是要思考:如何在提升生产力的同时,维持企业级开源所需要的安全标准、代码质量、许可证合规与人工监督?