Transcription
大家好，我是 Naven。欢迎回到 Naven Automation Labs。今天我们来快速聊一个非常非常重要的话题，那就是人工智能（AI）是否真的在影响工作岗位，或者说它是否真的在影响工作岗位？特别是关于 AI 在 IT 行业的现状，以及 AI 如何影响 IT 行业。
这是一份我找到的报告，名为“代码和开发者调查报告状态”。当我们开始谈论 AI 和所有这些事情的时候，我猜是在 2023 年，只有 6% 的用户在使用 AI。而从 2023 年到 2026 年，或者说从 25 年到 26 年，这个数字有了巨大的飞跃，目前采用率达到了 42%，尤其是在 IT 行业。这意味着 42% 的人实际上在使用 AI 提交代码。预测到 2027 年，这个数字将达到 65%。
但是，根据这份报告，96% 的开发者仍然不完全满意 AI 生成的代码是否真的正确。这不是我的个人观点，这是对全球 1149 名专业开发者进行的调查结果。这份报告由 Sonar Source 于 2026 年 2 月发布。视频结束后，我也可以分享这份 PDF，您可以下载并查看。但我还是想强调一些报告中描述的非常非常重要的主题和观点。
那么，关键问题是：AI 真的能让软件开发更快或更好吗？人们使用 AI 来进行开发和软件开发，一切都发生得非常快，在四五分钟、十分钟内就能完成。我可以构建整个应用程序，构建逻辑等等。但它只是更快吗？这是一个基于质量的快速过程吗？还是软件只是变得更快，而不是更好？这是这里最重要的主题。
我们快速浏览一下这里的重要观点，我将直接开始，不再浪费时间。看看开发者们到底是如何使用 AI 的。尝试过 AI 的开发者中有 72% 每天都在使用。AI 辅助编码如今已成为开发者工作流程的标准组成部分。72% 尝试过 AI 编码工具的开发者现在每天都在使用它们。这意味着如今 72% 的开发者每天都在使用 AI。
在每天使用 AI 的 72% 的人中，42% 的人每天使用多次，30% 的人每天使用一次，6% 的人偶尔使用，7% 的人每周使用一次，15% 的人每周使用几次。总参与人数为 1148 人。1148 名开发者参与了这项调查，这是基于此的结果。
N 代表参与调查的开发者人数，等于 1148 人。可以看到，开发者提交的 AI 辅助和生成的代码的平均比例：2023 年仅为 6%，2024 年为 19%，2024 年到 2025 年是一个巨大的飞跃，采用率达到了 42%，预计到 2026 年底将达到 55%，到 2027 年将有 65% 的开发者开始使用基于 AI 或 AI 代理的工具。
它是如何发生的？开发者在多个软件开发活动和项目中都使用 AI。88% 的人用于原型设计、实验、概念验证（POC）等。83% 用于内部非关键工作流程的生产软件。73% 用于面向客户的应用程序的生产软件。58% 用于业务关键或任务关键服务的生产软件。这份调查显示，人们在软件的不同项目和活动中都在使用 AI。
不同的用例是什么？看，这些是人们实际使用的最重要的用例。文档编写是采用率最高的，占 74%，因为 AI 在生成内容、生成文档等方面非常出色。它能漂亮地生成 PPT、演示文稿、PDF，以及一些非常惊人的图形。以前我们需要花费大量时间和精力来输入图形等内容，然后创建一份不错的报告，但现在借助 AI，您可以在 5 到 10 分钟内生成大量的报告，并生成精美的文档和演示文稿。因此，有效性为 74%，采用率也为 74%。这是我一直在谈论和解释的最重要部分。
理解现有代码，人们会遇到困难。“我无法理解这段代码，这个库是如何工作的等等。” 66% 的人使用 AI 来学习。采用率为 78%。
“零代码”编程，我完全不懂编程。我只是在光标、Visual Studio Code 或任何地方输入提示，然后开发，AI 就会为我编写代码，之后我再检查一切是否正常。特别是对于创建新项目或自由职业项目，大部分代码都是 AI 生成的。在“零代码”编程中，99% 是 AI 生成的代码，有效性为 62%，采用率为 48%。
生成测试用例，是的，您确实想生成一些手动测试用例或单元测试用例。59% 的有效性，采用率为 75%。
研究技术解决方案或探索 API 库，57% 的有效性，采用率为 59%。
将代码从一种语言翻译到另一种语言，例如 Java 到 Python，Python 到 JavaScript 等。在这种情况下，有效性为 58%，采用率为 50%。
为新代码提供开发辅助，55% 的有效性。
代码审查，人们使用率为 47%。
代码调试，44% 的有效性，采用率为 65%。
重构或优化现有代码，43% 的有效性。
在现有项目或现有源代码中添加或更新功能，占 42%，采用率为 76%。
您可以看到，Y 轴是采用率，X 轴是有效性。这是对此的表示。这些是人们实际使用 AI 进行不同活动、不同目的的主要用例。
AI 真正擅长的是什么？正如我所说，74% 的有效性，在编写文档方面非常出色，可以生成精美的 PDF 文档，还可以生成图表、JPG 文件、PNG 文件或图形。解释或理解现有代码也非常出色。事实上，我个人也在使用它。如果我想学习一门新语言或新工具，我只需给出提示，给出代码，然后请它用非常简单的语言逐行解释。它可以为我解释。
“零代码”编程，人们疯狂地使用它。人们正在创建无数的网站。您一定见过市场上提供各种广告和营销工具。人们正在使用它们，然后从 POC 的角度来看，如果他们喜欢，他们就会开始专业地使用它们，开发应用程序、框架，然后开发移动应用程序，然后发布到市场，人们也从中赚钱。
生成测试用例，人们也为此目的使用它。生成测试用例是一个非常高级的术语。它可以用于现有代码的集成测试用例，也可以用于编写单元测试用例。我也可以生成手动测试用例。这样我就不必花费 3 到 5 天的时间在 Excel 文件中编写手动测试用例，然后准备文档等。因此，通过 AI 生成测试用例也非常强大且影响深远。当然，我们还需要审查代码、审查测试用例等。但生成测试用例的有效性为 59%，人们正在使用它。
现在，开发者是否信任 AI？这非常重要。这可能是个好消息，对于那些认为 AI 会毁掉他们工作的人来说。96% 的开发者不完全信任 AI 生成的代码在功能上是正确的。这是非常非常重要的一点。它看起来很花哨，很棒，它会让你产生幻觉，告诉你“这是我生成的，报告很漂亮，测试用例都是绿色的，执行也完美无缺，逻辑等等看起来都很棒”。但当我们尝试审查它，尝试检查它是否真的有效时，96% 的开发者（这不是我的观点）不完全信任 AI 生成的代码在功能上是否正确。
AI 正在改变开发，这已不是秘密。但我们的研究发现，开发者看到了实际的好处，个人生产力平均提高了 35%。超过一半（54%）的人表示，由于 AI，他们对自己的工作更满意，82% 的开发者同意 AI 帮助他们更快地编码。71% 的人表示 AI 帮助他们更有效地解决复杂问题。毫无疑问，这种速度带来了新的挑战——信任差距。96% 的开发者不完全信任 AI 生成的代码在功能上是否正确。
4% 的人完全同意以下陈述：“我信任 AI 代码在功能上是正确的。” 完全同意的只有 4%，部分同意 25%，中立 23%，完全不同意 17%，部分不同意 31%。总计 1149 人。
所以，这就是主要部分。96% 的开发者不完全信任 AI 代码在功能上是否正确。
现在是验证瓶颈。48% 的开发者在提交 AI 辅助代码之前总是会检查它。因为这是非常严肃的事情，我们需要认真对待。这是生产代码，您需要修复任何现有错误或生产错误，或者您确实想发布一些东西，您需要确保它不会破坏现有的东西或以前的东西，它不会进行不必要的更改，它不会影响生产中的用户。因此，48% 的开发者在提交之前总是会检查他们的 AI 辅助代码，验证它，检查它，调试它，然后仔细审查它，然后才使用该代码。
问题是：“我总是在提交之前检查我的 AI 生成或辅助代码。” 48% 完全同意。27% 的人表示“是的，我有点同意”。3% 的人表示“完全不同意”。所以，可以说完全同意是 48%，完全不同意是 3%，部分不同意 11%，中立 11%。
所以，这就是调查结果。
接下来是：61% 的开发者同意 AI 经常生成看起来正确但不可靠的代码。61% 的人是这么说的。
“在多大程度上同意以下陈述，因为它与 AI 编码工具和 AI 生成代码的使用有关？” 选择：“AI 经常生成看起来正确但不可靠的代码。” 总体而言，61% 的人表示完全同意 17%，部分同意 45%，完全不同意 5%，部分不同意 15%，中立 19%。所以，总的来说，61% 的人认为它看起来正确，但不可靠。当我们调试它，检查代码时，它根本不可靠。
61% 的开发者同意从 AI 获取代码需要付出很多努力。因为无论您想从 AI 获取什么输出，AI 可能都无法达到那个水平。给出漂亮的提示，从 AI 获取代码，对于小事情、小项目来说是可以的，但对于实时项目，风险非常高，在这种情况下，61% 的开发者同意需要付出很多努力才能从 AI 获取好的代码。这取决于您的提示工程技能、您提供给 AI 的输入信息以及上下文。然后它会生成好的代码。然后您还需要对其进行审查。61% 的开发者同意我们需要经常审查代码，并且我们不同意该代码是否真的可靠。
现在，AI 的影响体现在哪里，又体现在哪里？开发者显然能更快地交付代码，这一点毋庸置疑。但这种速度是否能持续转化为更好的结果尚不清楚。虽然 70% 的人表示 AI 对他们的上市时间产生了积极影响，但不到一半（47%）的人表示它对最终用户体验和减少技术债务产生了积极影响。这是一个好迹象。这是有道理的。如果您交付的代码看起来正确但不可靠，您就不会改善用户体验或代码库的长期健康状况。
这是一个非常有趣的屏幕。AI 的影响主要体现在开发者的生产力和上市时间上，但在多个其他方面仍有增长空间。
“AI 生成或辅助代码对您的团队和公司产生了什么影响？” “非常积极的影响”和“部分积极的影响”。
开发者生产力：26% 的人表示非常积极的影响，63% 的人表示部分积极的影响。
上市时间：19% 的人表示非常积极的影响，51% 的人表示部分积极的影响。
功能或修复版本发布：13% 的人表示非常积极的影响，45% 的人表示部分积极的影响。他们并不完全满意。
代码质量：13% 的人表示非常积极的影响，45% 的人表示部分积极的影响。
代码可维护性：11% 的人表示非常积极的影响。
最终用户体验：10% 的人表示非常积极的影响。
技术债务：8% 的人表示非常积极的影响。
返工或补丁成本：7% 的人表示非常积极的影响。
缺陷率：6% 的人表示非常积极的影响。
漏洞率：5% 的人表示非常积极的影响。
停机或事件频率：4% 的人表示非常积极的影响。
停机或事件严重性：4% 的人表示非常积极的影响。
这是关于不同关键活动影响的非常有价值的数据。这些是项目中的主要活动，这是非常积极的影响与部分或部分积极影响的数据。
该报告显示，与非用户相比，AI 对代码质量、技术债务返工成本、缺陷和漏洞的影响更强。这表明拥有一个系统的验证过程是关键，可以将 AI 的速度转化为现实世界的质量改进。因此，对 AI 生成的代码进行系统验证非常重要。确保您对 AI 代码进行系统验证，然后才将代码提交到生产环境，以提高现实世界的质量。
一套新的技能和担忧。这个新的验证步骤也重新定义了“开发者”的含义。当我们问到在 AI 时代、AI 世界中哪些技能最重要时，答案是审查和验证 AI 生成代码的质量和安全性。我说了很久了，伙计们，不要盲目信任 AI 生成的任何东西，无论您是在开发、测试自动化、测试还是其他领域。如果您没有提供正确的上下文，那么 AI 很有可能产生幻觉，它肯定会这样做。所以，调查也说了同样的话：审查和验证 AI 生成的代码或数据，以确保代码的质量和安全，占 47%。
其次是高效地提示 AI 工具，这是您需要提高的主要技能，42% 的人表示。代码质量审查和验证是 AI 时代开发者最重要的技能。高效地提示 AI 工具。42% 的人认为提示非常重要，可以生成代码，确保 AI 满足要求。
将领域知识转化为代码需求，27%。您应该拥有领域知识或功能知识。
架构复杂系统和集成，25%。如果您对您正在开发的框架或系统的架构没有概念，那么 AI 可能会随意做任何事情。如果您对此没有概念，您将永远挣扎。因此，25% 的人认为集成和架构复杂系统非常重要。
识别和减轻 AI 生成代码引入的安全风险。这一点也非常重要。我们需要识别 AI 生成代码引入的安全威胁或安全风险。它看起来非常棒，工作正常，所有工作流程都完美无缺，但如果存在重大的漏洞问题或安全问题呢？尤其是在金融科技、银行业或医疗保健领域，安全性非常重要。在银行应用程序中，任何人都可以窃取数据，任何人都可以入侵数据，入侵应用程序或系统，那将是一个巨大的安全风险。因此，24% 的人对此表示担忧。
创造性问题解决和创新，23%。
维护生产环境中的系统性能、可靠性和效率，23%。当您扩展到成千上万甚至数百万用户时，这一点非常重要。在这种情况下，维护系统性能、可靠性、效率、可用性非常重要。确保它始终运行，并且在感恩节等节日期间也确实可靠。因此，23% 的人认为您应该具备这些技能。这不像“我只是给出提示，获取代码，然后就完成了”。不。对于您的自由职业项目，或者您的内部应用程序，这可能还可以。但请考虑企业级应用程序，数百万用户正在使用它，并确保系统性能达到标准。特别是电子商务应用程序，在排灯节、圣诞节、新年或感恩节期间。
制定编码标准和治理。显然，您必须确保它确实遵循编码标准。您必须了解它。
将 AI 输出集成到工作流程和工具链中，17%。
重构和调试 AI 生成的代码，16%。是的，这一点也很重要。您应该知道如何重构 AI 代码以及如何调试 AI 代码。因为明天，如果出现生产错误，您需要修复它，那么您至少应该知道如何调试 AI 生成的代码。例如，AI 在您的代码中生成了分层抽象，从一个类到另一个类，再到另一个类。在这种情况下，很难调试由 AI 生成的抽象代码。所以，我们确保我们不能完全说“如今不需要编码技能了，AI 会为我们做一切”。但根据这项调查，16% 的人认为重构和调试 AI 生成的代码非常必要。
构建弹性系统和协作与指导其他开发者，10% 的人是这么说的。
最终，AI 加速了代码生成，但它也在软件开发验证阶段造成了瓶颈。现在需要更多的工作来审查代码。事实上，我从我以前公司的几位非常好的开发者朋友那里听到了这个说法。他们也在使用它，但他们说这更令人沮丧，Navin。AI 正在生成代码，但我们不再获得那种程度的信心。我们总是担心，如果我们未经验证就将代码推送到生产环境，万一出现失误，万一发布后出现重大问题，那么所有的责任都在我们身上。在这种情况下，我们必须确保软件开发验证阶段起着非常重要的作用。
那么，关键 takeaway 是什么？很明显，新的验证瓶颈是 AI 辅助编码时代的核心挑战。验证。想想看，伙计们，验证。谁来验证代码是否正确？应用程序，例如在 QA 环境中，我作为开发者部署了。那么作为 QA，您会做什么？在这种情况下，QA 的工作将越来越多。我们需要更好的 QA，这样人们，QA 人员就可以来识别风险，识别差距，识别错误，然后作为质量人员提出重大的质量问题。那些认为 QA 测试人员等工作将消失或没有 QA 作用的人，请仔细想想。我怎么能信任 AI 生成的代码或 AI 生成的东西？在这种情况下，验证点非常重要。
所以，如果您看整体的要点，到目前为止我们所讨论的，大部分的担忧在于代码审查部分，验证部分。然后，当我将构建交给 QA 时，这是 QA 的责任。根据我的说法，QA 的工作将蓬勃发展。我不是说您必须编写那些枯燥的测试用例。但您应该知道如何将这些 AI 技术融入您的作品集中。学习正确的自动化，学习如何自动化事物，学习最新的自动化工具和技术，以及 AI，这非常重要。如果您说“我的工作只是编写测试用例，进行典型测试，然后编写 Excel 测试用例，逐一执行”，我认为这些事情将由 AI 来处理。但再次，您的探索性测试，人类的触觉，人类的智慧，专家的验证，QA，有人需要承担责任。谁来承担责任？您，作为人类，作为测试人员，您将承担责任。所以，这一点非常重要。
因此，在我看来，我不相信 AI 会杀死 QA 工作或测试人员的工作。我认为 QA 工作在未来 AI 时代将是最有前途的技能，QA 的工作将越来越多。这是我的观点。您怎么看？
我们快速继续。顶级的 AI 工具以及它们的使用方式。人们使用 GitHub Copilot 75%，ChatGPT 74%，Claude Cloud Code 48%，Gemini do AI 37%，Cursor 31%，Perplexity 21%，OpenAI Codex 最近发布 21%，JetBrains 17%，Amazon Q Developer 12%，Winer 8%，其他约 37%。这些是过去几年，或者说过去一年里，您团队中使用了哪些 AI 编码工具或 AI 功能的调查报告。
个人账户问题。超过 50% 的开发者通过个人账户使用 ChatGPT，而 78% 的人通过工作账户使用 GitHub Copilot。这也是非常有趣的数据。
“您个人如何使用以下 AI 编码工具或 AI 功能？作为您工作的一部分的软件开发任务。”
Perplexity：个人账户占 63%。我认为 Perplexity 可能最近才宣布？我不确定。几个月前，一年的订阅是免费的？所以，大多数个人账户用户都在使用它。
ChatGPT：个人账户 52%，工作账户 47%。可以说几乎是 50/50。
Google Gemini：个人账户 40%，工作账户 55%。
Claude Claude Code：个人账户 36%，工作账户 53%。
OpenAI Codex：个人账户 35%，工作账户 52%。
命令行 AI 工具：个人账户 33%，工作账户 57%。
JetBrains：个人账户 28%，工作账户 58%。
Cursor：个人账户 27%，工作账户 64%。
其他工具也有。
GitHub Copilot：个人账户仅 17%，但工作账户用户为 78%。
ChatGPT 是一个完美的例子，74% 的开发者在过去一年中使用过，其中 52% 的用户通过个人账户访问。像 Perplexity 这样的工具，63% 的用户通过个人账户登录。
谁在使用哪个工具？您也可以再次查看。SMB 指的是小型或中型公司。小型和中型企业以及大型企业。GitHub Copilot，小型或中型企业使用它，中等市场，以及大型企业 76%。您可以快速查看一下。Copilot 当然是在 Visual Studio Code 中作为插件或扩展使用的，并且对小型企业和大型企业都非常频繁地使用。对于中等市场来说，这是 76%。其他工具也是如此，您可以查看一下。
同样，Cursor、Perplexity、OpenAI Codex 更受初级开发者（工作经验少于 10 年）的青睐，11-20 年，以及 20 年以上。这些数据也可用。这也是非常有趣的数据。
这些数据清楚地表明，开发者没有等待许可。他们积极地尝试各种工具来完成工作，通常是通过个人账户。人们不会等待公司提供许可证密钥或 API 密钥。人们实际上正在获取这些东西，然后创建个人账户，每月支付 20 美元或更多，然后用于此目的。
AI 代理，AI 的第二幕是代理。64% 的开发者已经开始使用 AI 代理。AI 代理意味着我们只需给 AI 代理一些任务，例如“请设计这个框架”，然后 AI 代理将负责您的项目，包括编写代码、编写测试用例、执行等等。它将端到端地完成。
这项研究的一个关键发现是，代理式 AI 正从实验走向日常工具。25% 的开发者报告在工作流程中定期使用代理式 AI 工具，39% 已经尝试过。这意味着总共有 64% 的开发者已经开始使用这些高级代理。
65% 的开发者已经开始使用。
“是的，我们在工作流程中定期使用 AI 代理。” 25% 的人是这么说的。
“是的，我们尝试过 AI 代理，但尚未常规使用。” 39% 的人是这么说的。
“不知道如何使用或不确定。” 3% 的人是这么说的。
“不，我们目前不探索或计划使用任何 AI 代理。” 11% 的人是这么说的。
“不，但我们正在积极探索或计划使用 AI 代理。” 21% 的人正在这样做，或者正在探索这些工具。
所以，这就是可用的数据。
现在，用例等等，我们已经讨论过了。这些是使用场景。这里再次显示了相同的图表。
理解代理式用例。首先，我们为 AI 使用了它。现在是 AI 代理式用例。人们正在使用它。再次看这个：创建代码文档、自动化测试生成、自动化测试生成执行、编码应用程序、项目规划、自动化代码审查、自动化代码生成、自动化基础设施设置、自动化管理、自动化代码重构、安全漏洞和补丁，以及自动化调试和问题修复，以及自动化部署管道配置或管理。
这是 AI 代理的用例数据。
现在，我们快速看一下 AI 代理为 SMB（小型和中型企业）提供的更多价值的用例。这是“零代码”编程，正如我告诉您的，SMB 和企业级。例如，创建代码的应用程序，基于对话语言。您只需开始给 AI 代理输入提示，它就会开始为您生成代码。项目规划、任务分解和需求分析。这也是 AI 代理的一个很好的用例。安全和漏洞补丁或任何类型的修复，57% 和 47%。这是可用的数据。
我不会深入研究，因为您可以在我分享完 PDF 后自己阅读。您可以快速查看一下。AI 代理用例，适用于不同公司规模的工作和不工作的情况。再次，创建代码文档，69% 和 70%。您可以看到 AI 代理在您使用它们的各项任务中的有效性。这里几乎是相同的数据，您可以去查看一下。
现在，我们快速进入下一部分。认识新的 AI 工具。这是玩具的幻觉，正如“零代码”检查中所提到的。开发者真的信任 AI 吗？开发者在使用 AI 编码工具时看到了高水平的生产力。他们还报告了工作量减少。75% 的开发者表示 AI 减少了他们的工作量，即阻碍开发者生产力或增加挫败感的工作任务。有了这个，75% 的人或开发者认为 AI 减少了他们在繁重工作上花费的时间。繁重的工作意味着不必要、重复性的工作，或者枯燥的工作，或者我必须重复做的工作。
完全同意 24%。AI 减少了我在这方面花费的时间。部分同意 51%，不适用 1%，完全不同意 2%，部分不同意 8%，中立 14%。
但是，表面之下，情况变得更加复杂。当被问及分配给与繁重工作相关的任务（例如管理技术债务、调试遗留代码或文档不清的代码）的工作周比例时，开发者报告花费了近四分之一的时间在繁重工作上。有趣的是，平均花费在繁重工作上的时间（23% 到 25%）对于频繁使用 AI 编码工具的开发者和使用频率较低的开发者来说几乎完全相同。
所以，这也是关于重复性工作非常有价值的数据。24% 的人表示完全同意，51% 的人表示部分同意。所以，总的来说，75% 的人表示“是的，我们同意”。
所以，这是在这项繁重工作上花费的时间。这就是图表。
我现在跳过这个。这个也还可以。开发者如何使用静态分析代码审查。静态代码分析也很有趣。这是一个有趣的数据表。57% 的人使用静态分析来审查 AI 代码。这就是为什么市场上像 ESLint 或 SonarQube 这样的工具被用来审查 AI 生成的代码。7% 的人用于审查开发者编写的代码和 AI 生成的代码。49% 的人使用 AI 来进行静态代码分析审查开发者编写的代码。13% 的人表示不适用，不使用这个工具。9% 的人表示不确定。
安全。AI 和代码安全之间棘手的关系。这是一份非常庞大的报告，大约有 57 页。我不会涵盖所有 57 页。我只会谈论其中重要的观点。AI 和核心安全之间的关系是主要担忧。57% 的开发者担心使用 AI 会导致敏感数据泄露。这是非常非常重要的一点。根据我们的案例研究，根据这份报告，开发者对 AI 代码生成最大的担忧是安全性。特别是 57% 的开发者担心 AI 代码泄露敏感公司和客户数据的风险。正如我之前提到的，这一点非常重要。您不能盲目信任 AI 生成的代码。这不是一个小问题。这是大多数开发者对他们越来越需要使用的工具提出的关键担忧。
开发者对 AI 辅助或生成代码提出的十大担忧：
敏感公司或客户数据泄露 57%。
过度依赖 AI 导致团队理解能力下降 53%。
引入新的微妙安全漏洞 47%。
在生产环境中引入严重安全漏洞 44%。
功能正确性，AI 工具缺乏关于我的特定项目或代码库的足够上下文 43%。
但您可以看到，57% 是关于敏感公司或客户数据泄露，引入微妙安全漏洞，以及引入严重安全漏洞 44%。这些是与安全担忧相关的三个危险信号。
因此，焦虑并不仅限于数据泄露。开发者也高度警惕 AI 实际创建的内容。近一半（47%）的人担心引入新的或微妙的安全漏洞，44% 的人担心 AI 引入严重的漏洞，严重的すぎ安全问题。很明显，虽然 AI 提高了速度，但它也创造了一个新的风险层，开发者现在有责任管理。正如我之前提到的，这一点非常非常重要。所以，伙计们，不要盲目信任 AI。从安全的角度考虑，它真的好吗？
这些是企业与 SMB 的 AI 担忧。我将快速关注重要观点。敏感公司或客户数据泄露，小型和中型企业 54%，大型企业 61%。合规问题，行业特定或组织编码标准，28% 和 38%。直接注入和间接提示注入，25% 和 34%，20% 和 35%。
这也是关于您对 AI 辅助或生成代码的以下担忧程度。这里也强调了三个主要或四个主要观点，与敏感公司或客户数据有关。
现在，快速看一下传统的风险管理方法。36% 的组织因为 AI 而对代码质量更加严格。我们对审查更加严格，并且由于 AI 生成代码而更加关注这一点。36% 的人是这么说的。他们说我们对审查更加严格，并且更加关注。实际上，它让我的工作更容易了，但它也让我的工作更艰难了。我现在总是担心，这段代码真的正确吗？我们仍在评估和弄清楚 AI 如何影响这一点，以及需要进行哪些更改。29% 的人是这么说的。AI 工具的使用不够广泛，无法产生影响。3% 的人说。由于 AI 工具没有显著变化。18% 的人说。由于 AI 生成代码，我们在审查中不那么严格，并且不那么亲力亲为。12% 的人是这么说的。但这两个数字非常令人担忧。代码质量非常重要。37% 的组织因为 AI 而对代码安全更加严格。同样，我们对审查更加严格，并且由于 AI 生成代码而更加关注这一点。
您可以阅读这些数据。我将快速添加最后一点。尝试不解释技术债务。我们已经讨论过了。88% 的受访者至少提到一个问题。
创建看起来正确但不可靠的代码 53%。
创建不必要或重复的代码 40%。
创建不可靠或有 bug 的代码 29%。
特别是重复代码，AI 生成的代码总是存在。
创建难以维护或重构的代码 27%。我不知道它到底写了什么。它在写，我无法维护，也无法重构，因为 AI 生成的代码非常复杂，甚至普通开发者也无法重构、维护或调试。所以，这就是主要问题。
引入集成问题或兼容性问题 21%。
因此，增加安全漏洞 17%。
编写了糟糕或没有文档的代码 14%。
但 53% 创建了看起来正确但不可靠的代码。伙计们，53% 和 40% 加在一起，这太疯狂了。所以，总的来说，平均 88% 的人至少提到一个问题。这是非常令人担忧的。
之后，AI 正在处理繁重的工作。尽管对技术债务产生了负面影响，但近乎所有（93%）的人也报告了 AI 对技术债务至少有一个积极影响。开发者显然正在使用 AI 来处理最繁琐的部分，这需要大量时间和精力来管理技术债务。这意味着改进文档。我个人喜欢它，我也在使用它。编写文档，准备笔记等等。我正在使用。以前我们用来创建维基页面，编写所有图表等等。但现在，我可以创建精美的文档，测试覆盖率和调试。重构或优化现有代码，改进代码维护性，降低缺陷率，降低安全漏洞。93% 的人表示至少有一些积极影响是由于 AI 生成的代码，尤其是在测试覆盖率、调试和改进文档方面。
我认为所有这些现在都可以让您去阅读。AI 用例采用率与经验年限等。现在对我们来说并不那么重要。但几乎相同的事情，我们已经讨论过了。
但现在，伙计们，我们需要理解一件事。您可以稍后阅读这些数据。几乎相同的事情。所以，这是主要内容。Sonar Cube 的非用户。这是关于 Sonar Cube 的，我们对此不感兴趣，特别是只对 Sonar Cube。
所以，人口统计学，例如中东 1%，北美 52%，拉丁美洲 7%，亚太地区 13%，欧洲 27%。人们实际上参与了这项调查。这是可用的整体报告。
按资历划分，他们也提供了。总裁或 C 级高管，如 CEO、CTO 占 5%，副总裁 6%，总监 17%，经理或高级经理 19%，入门级个人贡献者 1%，中级贡献者 10%，以及高级领导或首席个人贡献者，43% 的人正在使用它。
编码参与度。编写代码的经理和开发者占 57%，仅经理占 15%，仅编写代码占 28%。这是来自不同人群的整体调查的混合结果。
好的，公司规模，企业级，SMB，中等市场，所有这些。这已经给出。报告由 Sonar 完成。
现在，伙计们，我们需要理解的是 AI 的作用。我再花两分钟。我知道这个视频很长，因为有很多幻灯片。所以，我的问题是 AI 将如何影响 QA？它会杀死 QA 工作还是什么？不，AI 没有杀死任何 QA。它也不会杀死，伙计们，别担心。它实际上比以往任何时候都更加关键。因为我之前告诉您，代码可用，我们正在测试它，代码是由人类编写的。但现在，如果 50-60% 的代码是由 AI 生成的，谁来验证呢？根据这份报告，开发者也不太满意。92% 的开发者表示，我们现在不完全依赖 AI 生成的代码，我们需要有扎实的 QA 背景的人来测试这个应用程序，来测试 AI 生成的应用程序，找出一些惊人的错误，以及各种错误，例如漏洞，功能问题，性能测试问题，可扩展性可靠性问题。我们需要有良好 QA 经验和测试自动化经验的人。
所以，我个人不认为它会消失 QA 工作或类似的东西。在我看来，这完全是胡说八道。相信我，我早就知道了。大部分事情，是的，数据我不确定，但我也有同样的感觉。这就是人们在行业中实际使用的，这就是实际调查。我敢肯定，未来 2026、27、28 年 AI 的采用率会越来越高，QA 的工作肯定会越来越多。
但作为 QA 或 SD，您现在可以改进什么？您的工作是采用新技术，无论 AI 方面发生什么。如何测试它。AI、ML 的基本概念。测试自动化的重要性，这非常非常重要。仅靠手动测试，您将无法生存，相信我。我说的手动测试，不是手动测试本身。我说的是手动任务，例如在 Excel 文件中编写测试用例，然后逐一执行，每次发布都做同样的事情，记录错误等等。除此之外，您一无所知，那么就会有问题。
但人类的触觉，人类的智慧，上下文驱动的测试，只有人类才能做得更好。AI 做不到。AI 不能与利益相关者、客户或客户交谈。AI 不能与开发者讨论。AI 不能就一个错误争论“你为什么提出这个？你为什么在没有修复的情况下关闭这个错误？”。所以，这些是 QA 技能或 QA 人类测试技能，我们在 QA 领域真正需要，以及像 Playwright、Selenium 这样的工具，您需要了解它们。您需要了解正确的 API 等等。如果您在这些领域有所欠缺，请开始着手解决这些问题，然后找出 AI 集成到这个工具中的用例。我不想创建定位器等等。我只想快速生成定位器，快速生成页面对象模型，快速专注于测试用例和编写逻辑，然后验证它，运行它，然后完成。这样，借助 AI，至少可以提高 30-40% 的生产力，我可以专注于我实际的上下文驱动测试工作，或者实际的功能测试。
这可能不是我们花费 6 个月或 7 个月时间来构建整个框架的日子了，我们在这里编写的每一行代码。我认为不会是那样了，因为现在 AI 将设置框架的基础。但再次，如果您不了解框架，不了解语言，不了解工具，技术，核心功能，它使用了哪些设计模式。现在想想，如果出现生产错误或测试用例失败，谁来修复？您真的要和 AI 谈论修复它吗？如果修复后又出现五个错误呢？所以，您必须非常快速，您必须有信心，无论 AI 在 Playwright、Selenium、Rest Assured 或其他任何工具中生成什么，对于 QA 或 SD 来说，我都能修复它，因为我了解事物，我了解技术，我了解工具，我了解语言。它不应该看起来像外星人。
我每天都看到“零代码”编码者发布一些东西，然后他们认为“现在我们是开发者了”。我亲眼见过。在不同的团队中，我见过人们随意开发任何东西，然后生成无数的应用程序等等，但他们不知道 AI 到底在做什么。一开始，它看起来非常花哨，非常迷人，非常令人产生幻觉，看起来非常棒。但当出现任何问题时，那将是一个大问题。所以，专注于您的技能，专注于您的核心技能，以及测试自动化和 AI 技能。我认为这对 QA 和测试人员来说不会有问题。
这就是本视频的全部内容。我也会在描述中分享这个视频的 PDF。您可以下载它，也可以查看其中包含的其他数据和数据点。
非常感谢。请将此视频分享给其他人，您的朋友，在开发、QA 领域，以及那些真正担心“我的工作会怎么样”的人。
好了，下次视频再见。保重，上帝保佑你们所有人。非常感谢。