尧图网站建设 
AI 编码新机遇与潜在风险并存我得说用 AI 编写应用程序听起来那是相当诱人啊单个开发者只要按计划给出提示几分钟内就能得到可运行的原型代码而不是像以前那样花费数天时间。通过反复迭代修复和改进直到开发者满意为止。根据《代码开发者现状调查》48% 的受访者已在新项目中采用了 AI 编码62% 的人认为它很有效。不过呢96% 的人并不完全相信 AI 生成的代码在功能上是正确的这确实让人有点担忧。《AI 与人类代码生成现状》报告还显示AI 发起的拉取请求比开发者发起的存在的关键问题多 1.4 倍主要问题多 1.7 倍。SAS 杰出软件开发人员 Brett Smith 吐槽说“开发者会写出糟糕的代码而 AI 会让他们更快地写出糟糕的代码。问题在于企业想当然地认为 AI 生成的代码天生就是正确的而没有像对待其他版本那样对其进行同样的测试、验证和质量把控。”对了有报告指出目前全球 41% 的代码是由 AI 生成的。为开发者编写的代码所采用的代码审查、安全扫描和测试实践可能无法应对 AI 生成代码的数量、复杂性和新风险。这些数据可不意味着 AI 编码不好但确实提醒开发者要悠着点避免犯代价高昂的错误。下面就给大家说说七个需要避免的坏习惯。坏习惯一绕过需求分析ThoughtSpot 首席数据与 AI 策略师 Sonny Rivera 提醒道“我常见的一个错误是团队为 Claude 和 Codex 等助手能快速将想法转化为见解而欢呼却没意识到瓶颈已经转移到了产品管理和语义层面。忽视这种转变你得到的结果将与预期相反交付变慢质量降低。”AI 编码可不能纵容开发者那些已知会导致软件风险和开发返工的过时行为。从想法到代码需要产品负责人遵循基本规范包括明确利益相关者、确定用户需求以及建立用户故事验收标准。那如何避免这个错误呢许多代码生成和 AI 编码工具在支持开发者工作流程时并未提供与利益相关者的正式协作流程。基于规范的开发是解决这一问题的一种方法。团队可以与 AI 协作创建产品需求文档和架构工件进行修改然后将其反馈给 AI 以生成代码。坏习惯二轻信 AI 选择的依赖项Sonatype 首席产品开发官 Mitchell Johnson 提醒 AI 编码者AI 编写的代码只是其中一部分。“如今AI 还会决定你的应用程序依赖哪些开源组件。如果这些决策不是基于最新信息而仅仅是基于模型几个月前学到的内容你可能会在不知不觉中依赖过时、被弃用或有风险的组件。”企业历来都在努力规范其软件开发堆栈。随着时间的推移许多企业在不同开发平台和版本上维护应用程序时积累了技术债务这不仅增加了成本还在扩展应用程序时带来了复杂性。如果没有明确规定 AI 编码工具可用于构建解决方案的框架、组件、库及其版本这种风险会进一步加剧。怎么避免这个错误呢提供架构要求指定可用组件目录并经常更新此文档因为开源和第三方组件的部署可能会引发新的风险。此外审查每个 AI 编码应用程序的软件物料清单和集成的 API。坏习惯三忽视非功能需求受监管行业的公司在安全、可靠性、审计和其他非功能需求方面有开发标准。即使应用程序没有特定的性能和可扩展性要求开发者也具备相关专业知识并且对用户期望有大致了解。但如果没有指导原则AI 编码工具可能会自行做出假设并采取一种无法扩展的开发策略。Southworks 首席技术官 Johnny Halife 表示“编码助手确实能显著提高你的生产力但在处理非功能需求方面比较薄弱。如果跳过设计阶段在处理复杂系统的架构、加固和组件化时往往会显得很粗糙。先由人工完成这些部分确定下来后再让 AI 助手继续工作因为生产力的提升实际上体现在这里而不是简单地让它‘为我构建一个应用程序’。”要避免这个错误就得为开发团队创建一个按类别划分的非功能需求库供他们在任何新项目或概念验证中使用。执行这一步骤确保捕获应用程序和 AI 助手特定的非功能需求并与 AI 编码工具共享。坏习惯四给予过多数据库访问权限团队中的新开发者并不总是清楚开发数据库里有什么。一个 10 年前根据符合规定的生产数据创建的用户注册数据库可能无法满足如今的数据隐私要求。与生产环境相比对开发和测试环境控制较少的企业可能会发现在让 AI 代码生成器访问这些环境之前他们需要解决新的数据治理风险。Redgate Software 集团产品经理 Tim Dalton 指出“在数据库中使用 AI 编码工具会造成严重的数据合规问题因为开发者往往忽略了开发和测试环境中的数据将未脱敏的生产数据暴露给一个能随时提取信息的工具。AI 生成的测试用例可能会将个人身份信息PII直接嵌入到最终进入版本控制的脚本中等到审计发现数据泄露时问题可能已经出现了很多次。在将任何 AI 工具集成到工作流程之前团队需要确保他们的数据得到了适当的脱敏、清理和治理真正适合与 AI 一起使用。”如何避免呢数据治理团队应创建一个测试清单在允许 AI 代码生成器访问任何数据源之前验证其数据并定义数据访问权限。坏习惯五定义功能时未考虑基于角色的访问控制RBAC在设计云原生应用程序时一个关键错误是在开发功能时没有考虑用户访问需求。其中一些应用程序可能需要进行小范围的重构以融入安全需求而更复杂的情况可能需要重新设计。对于那些在功能需求中没有预先定义访问控制的 AI 编码应用程序成本和风险会进一步增加。Kong 的 AI 专家解决方案工程师 Jason Matis 说“问题在于人们在使用 AI 编码时很少在应用程序中添加所有必要的安全和权限功能。通常只是一个简单的构建只考虑了理想情况。虽然这对于最小可行产品来说没问题但对于生产环境来说就不够了。当认证、权限和可观测性由基础设施而非应用程序代码来处理时应用程序的构建方式就无关紧要了因为访问控制已经存在。”避免这个错误的办法是创建基于角色的访问控制RBAC标准和可复用的软件组件来管理这些控制。创建一个按功能记录访问控制的模板并在使用 AI 编码实现时包含这些要求。坏习惯六依赖手动测试根据《全球质量报告》许多组织的自动化测试覆盖率低于 33%。该报告确定了八个生成式 AI 在质量工程中的应用场景如测试用例设计、需求分析和缺陷分析但在生产环境中的应用率均低于 50%。这就引发了一个问题对于积极采用 AI 代码生成和 AI 编码实践的企业来说持续测试是否足够成熟和普及。Marker Collective 首席产品官 Andrew Wyatt 表示“团队在使用 AI 编码时犯的一个错误是仅仅依靠代码审查来发现 AI 生成代码中的问题。更好的做法是将工程标准转化为工作流程中不可跳过的控制措施如测试、类型检查、代码检查、安全检查、评估和可观测性要求这些都应在代码被接受之前执行。AI 运行速度极快但流程应确保明显的错误不会被发布出去。”RSI 工程总监兼 AI 卓越中心负责人 Harshil Shah 表示新的经验法则是评估套件的发展速度应快于代码库的增长速度。“不投资于自动化评估和回归测试框架的团队实际上交付的是模型的置信度而不是其正确性。”对于那些认为 AI 编码可以让他们绕过软件开发生命周期SDLC管理最佳实践尤其是在测试 AI 助手方面的企业来说手动测试或没有正式的测试实践是重大风险。坏习惯七跳过可观测性如今的开发者普遍明白在应用程序、数据操作和 AI 助手中构建可观测性的重要性。在使用 AI 代码生成器和 AI 编码时SDLC 的部分环节实现了自动化AI 会代表开发者做出决策。DevOps 团队应该审查 AI 代码生成器和 AI 编码平台的可观测性能力以便将结果和代码追溯到 AI 的决策步骤。Grafana Labs 人工智能高级总监 Mat Ryer 说“AI 编码使 SDLC 的每个阶段都成为 AI 做出决策的地方除非你刻意关注否则你看不到这些决策。比如当一个提示生成函数的初稿时当测试套件的编写速度比人类审查速度还快时当管道认为部署安全而进行部署时。”安永全球咨询交付服务的杰出技术专家兼 AI 工程负责人 Raghuveer Subodha 表示一个常见的错误是通过模糊的提示让 AI 自己查找错误比如让它修复代码。“以这种方式提示时AI 会添加许多异常处理程序以确保代码能够编译和运行而不是诊断问题。更好的做法是让 AI 生成完整的堆栈跟踪信息并实现结构化日志记录这样就能识别和解决错误。”那如何避免呢Ryer 建议在开发 AI 助手时从始至终全面考虑可观测性理解 AI 为何做出某个决策审查出现问题的地方并评估修复方案。还有啊一个明显且重大的错误是在没有评估购买软件能力的选项的情况下就选择自行构建。仅仅因为 AI 编码让开发应用程序和 AI 助手变得更容易并不意味着企业拥有该解决方案并承担持续维护成本是个好主意。开发者还应考虑无代码的 AI 编码方式即 AI 在 SaaS 基础设施上生成应用程序并利用其平台的安全和治理能力。总之AI 编码为加速软件开发带来了新机遇但 DevOps 团队可不能忽视其速度、风险和新的复杂性哦大家可得多留意这些问题呀 AI 编码虽有新机遇，但 DevOps 团队需警惕七大坏习惯！
AI 编码新机遇与潜在风险并存我得说用 AI 编写应用程序听起来那是相当诱人啊单个开发者只要按计划给出提示几分钟内就能得到可运行的原型代码而不是像以前那样花费数天时间。通过反复迭代修复和改进直到开发者满意为止。根据《代码开发者现状调查》48% 的受访者已在新项目中采用了 AI 编码62% 的人认为它很有效。不过呢96% 的人并不完全相信 AI 生成的代码在功能上是正确的这确实让人有点担忧。《AI 与人类代码生成现状》报告还显示AI 发起的拉取请求比开发者发起的存在的关键问题多 1.4 倍主要问题多 1.7 倍。SAS 杰出软件开发人员 Brett Smith 吐槽说“开发者会写出糟糕的代码而 AI 会让他们更快地写出糟糕的代码。问题在于企业想当然地认为 AI 生成的代码天生就是正确的而没有像对待其他版本那样对其进行同样的测试、验证和质量把控。”对了有报告指出目前全球 41% 的代码是由 AI 生成的。为开发者编写的代码所采用的代码审查、安全扫描和测试实践可能无法应对 AI 生成代码的数量、复杂性和新风险。这些数据可不意味着 AI 编码不好但确实提醒开发者要悠着点避免犯代价高昂的错误。下面就给大家说说七个需要避免的坏习惯。坏习惯一绕过需求分析ThoughtSpot 首席数据与 AI 策略师 Sonny Rivera 提醒道“我常见的一个错误是团队为 Claude 和 Codex 等助手能快速将想法转化为见解而欢呼却没意识到瓶颈已经转移到了产品管理和语义层面。忽视这种转变你得到的结果将与预期相反交付变慢质量降低。”AI 编码可不能纵容开发者那些已知会导致软件风险和开发返工的过时行为。从想法到代码需要产品负责人遵循基本规范包括明确利益相关者、确定用户需求以及建立用户故事验收标准。那如何避免这个错误呢许多代码生成和 AI 编码工具在支持开发者工作流程时并未提供与利益相关者的正式协作流程。基于规范的开发是解决这一问题的一种方法。团队可以与 AI 协作创建产品需求文档和架构工件进行修改然后将其反馈给 AI 以生成代码。坏习惯二轻信 AI 选择的依赖项Sonatype 首席产品开发官 Mitchell Johnson 提醒 AI 编码者AI 编写的代码只是其中一部分。“如今AI 还会决定你的应用程序依赖哪些开源组件。如果这些决策不是基于最新信息而仅仅是基于模型几个月前学到的内容你可能会在不知不觉中依赖过时、被弃用或有风险的组件。”企业历来都在努力规范其软件开发堆栈。随着时间的推移许多企业在不同开发平台和版本上维护应用程序时积累了技术债务这不仅增加了成本还在扩展应用程序时带来了复杂性。如果没有明确规定 AI 编码工具可用于构建解决方案的框架、组件、库及其版本这种风险会进一步加剧。怎么避免这个错误呢提供架构要求指定可用组件目录并经常更新此文档因为开源和第三方组件的部署可能会引发新的风险。此外审查每个 AI 编码应用程序的软件物料清单和集成的 API。坏习惯三忽视非功能需求受监管行业的公司在安全、可靠性、审计和其他非功能需求方面有开发标准。即使应用程序没有特定的性能和可扩展性要求开发者也具备相关专业知识并且对用户期望有大致了解。但如果没有指导原则AI 编码工具可能会自行做出假设并采取一种无法扩展的开发策略。Southworks 首席技术官 Johnny Halife 表示“编码助手确实能显著提高你的生产力但在处理非功能需求方面比较薄弱。如果跳过设计阶段在处理复杂系统的架构、加固和组件化时往往会显得很粗糙。先由人工完成这些部分确定下来后再让 AI 助手继续工作因为生产力的提升实际上体现在这里而不是简单地让它‘为我构建一个应用程序’。”要避免这个错误就得为开发团队创建一个按类别划分的非功能需求库供他们在任何新项目或概念验证中使用。执行这一步骤确保捕获应用程序和 AI 助手特定的非功能需求并与 AI 编码工具共享。坏习惯四给予过多数据库访问权限团队中的新开发者并不总是清楚开发数据库里有什么。一个 10 年前根据符合规定的生产数据创建的用户注册数据库可能无法满足如今的数据隐私要求。与生产环境相比对开发和测试环境控制较少的企业可能会发现在让 AI 代码生成器访问这些环境之前他们需要解决新的数据治理风险。Redgate Software 集团产品经理 Tim Dalton 指出“在数据库中使用 AI 编码工具会造成严重的数据合规问题因为开发者往往忽略了开发和测试环境中的数据将未脱敏的生产数据暴露给一个能随时提取信息的工具。AI 生成的测试用例可能会将个人身份信息PII直接嵌入到最终进入版本控制的脚本中等到审计发现数据泄露时问题可能已经出现了很多次。在将任何 AI 工具集成到工作流程之前团队需要确保他们的数据得到了适当的脱敏、清理和治理真正适合与 AI 一起使用。”如何避免呢数据治理团队应创建一个测试清单在允许 AI 代码生成器访问任何数据源之前验证其数据并定义数据访问权限。坏习惯五定义功能时未考虑基于角色的访问控制RBAC在设计云原生应用程序时一个关键错误是在开发功能时没有考虑用户访问需求。其中一些应用程序可能需要进行小范围的重构以融入安全需求而更复杂的情况可能需要重新设计。对于那些在功能需求中没有预先定义访问控制的 AI 编码应用程序成本和风险会进一步增加。Kong 的 AI 专家解决方案工程师 Jason Matis 说“问题在于人们在使用 AI 编码时很少在应用程序中添加所有必要的安全和权限功能。通常只是一个简单的构建只考虑了理想情况。虽然这对于最小可行产品来说没问题但对于生产环境来说就不够了。当认证、权限和可观测性由基础设施而非应用程序代码来处理时应用程序的构建方式就无关紧要了因为访问控制已经存在。”避免这个错误的办法是创建基于角色的访问控制RBAC标准和可复用的软件组件来管理这些控制。创建一个按功能记录访问控制的模板并在使用 AI 编码实现时包含这些要求。坏习惯六依赖手动测试根据《全球质量报告》许多组织的自动化测试覆盖率低于 33%。该报告确定了八个生成式 AI 在质量工程中的应用场景如测试用例设计、需求分析和缺陷分析但在生产环境中的应用率均低于 50%。这就引发了一个问题对于积极采用 AI 代码生成和 AI 编码实践的企业来说持续测试是否足够成熟和普及。Marker Collective 首席产品官 Andrew Wyatt 表示“团队在使用 AI 编码时犯的一个错误是仅仅依靠代码审查来发现 AI 生成代码中的问题。更好的做法是将工程标准转化为工作流程中不可跳过的控制措施如测试、类型检查、代码检查、安全检查、评估和可观测性要求这些都应在代码被接受之前执行。AI 运行速度极快但流程应确保明显的错误不会被发布出去。”RSI 工程总监兼 AI 卓越中心负责人 Harshil Shah 表示新的经验法则是评估套件的发展速度应快于代码库的增长速度。“不投资于自动化评估和回归测试框架的团队实际上交付的是模型的置信度而不是其正确性。”对于那些认为 AI 编码可以让他们绕过软件开发生命周期SDLC管理最佳实践尤其是在测试 AI 助手方面的企业来说手动测试或没有正式的测试实践是重大风险。坏习惯七跳过可观测性如今的开发者普遍明白在应用程序、数据操作和 AI 助手中构建可观测性的重要性。在使用 AI 代码生成器和 AI 编码时SDLC 的部分环节实现了自动化AI 会代表开发者做出决策。DevOps 团队应该审查 AI 代码生成器和 AI 编码平台的可观测性能力以便将结果和代码追溯到 AI 的决策步骤。Grafana Labs 人工智能高级总监 Mat Ryer 说“AI 编码使 SDLC 的每个阶段都成为 AI 做出决策的地方除非你刻意关注否则你看不到这些决策。比如当一个提示生成函数的初稿时当测试套件的编写速度比人类审查速度还快时当管道认为部署安全而进行部署时。”安永全球咨询交付服务的杰出技术专家兼 AI 工程负责人 Raghuveer Subodha 表示一个常见的错误是通过模糊的提示让 AI 自己查找错误比如让它修复代码。“以这种方式提示时AI 会添加许多异常处理程序以确保代码能够编译和运行而不是诊断问题。更好的做法是让 AI 生成完整的堆栈跟踪信息并实现结构化日志记录这样就能识别和解决错误。”那如何避免呢Ryer 建议在开发 AI 助手时从始至终全面考虑可观测性理解 AI 为何做出某个决策审查出现问题的地方并评估修复方案。还有啊一个明显且重大的错误是在没有评估购买软件能力的选项的情况下就选择自行构建。仅仅因为 AI 编码让开发应用程序和 AI 助手变得更容易并不意味着企业拥有该解决方案并承担持续维护成本是个好主意。开发者还应考虑无代码的 AI 编码方式即 AI 在 SaaS 基础设施上生成应用程序并利用其平台的安全和治理能力。总之AI 编码为加速软件开发带来了新机遇但 DevOps 团队可不能忽视其速度、风险和新的复杂性哦大家可得多留意这些问题呀