AI代码生成的计划-实施-检查-改进框架

本文介绍了一个基于PDCA循环的结构化框架,用于指导AI代码生成过程。该框架通过工作协议、结构化提示和持续改进,帮助开发者在利用AI能力的同时保持代码质量,包含具体的技术实践和实验数据。

关键要点

  • 应用结构化目标设定周期到AI编码会话:使用计划-实施-检查-改进原则为每个会话设定清晰、可观察的成功标准,并根据结果调整方向。
  • 使用结构化任务级规划与AI:让代理分析代码库,将大型功能分解为可在短迭代中完成的小型可测试块,防止范围蔓延。
  • 对AI代码生成应用红绿单元测试周期:让代理先编写失败的测试,然后编写生产代码使其通过,创建结构化反馈循环,减少回归和意外后果。
  • 建立验证检查点:在执行下一个迭代之前,执行"完成分析"时刻,要求代理根据计划审查结果。
  • 实施每日微回顾:每次编码会话后,花五到十分钟与AI代理分析有效的方法以及如何改进提示和交互。

AI代码生成未充分发挥潜力

AI代码生成的快速采用正在提高产出,但尚未在交付和结果上实现可衡量的改进。Google的DORA 2024年DevOps状况报告得出结论,AI采用率每增加25%,交付稳定性就会下降7.2%。这种差距可能是由于增加的批处理大小超出了组织定义、审查、测试、部署和维护输出的能力。

更令人担忧的是质量问题的迹象。GitClear对2.11亿行代码的分析显示,重复代码块增加了十倍,重复代码首次超过了移动代码。除了膨胀了要维护的代码量外,克隆代码有17%的缺陷率,并且18.42%的这些错误会传播到其他副本中。

为什么需要结构化的计划-实施-检查-改进周期?

行业未能实现生产力提升和质量改进,因为AI工具及其使用都需要发展。工程师需要可重复的实践,利用他们的经验来指导代理进行测试验证的更改,同时利用现有的代码模式。这种代理使用涉及引入结构化提示技术。

  • 结构化提示在方法和任务复杂性上比临时方法表现好1%到74%
  • PDCA通过经过验证的软件工程实践提供结构,融入了持续改进和迭代交付
  • 一项对照研究发现,PDCA将软件缺陷减少了61%

PDCA框架概述

以下是我为与编码代理交互组装的结枃化PDCA周期。我在团队用于规划、跟踪和接受工作的项目管理流程中单独使用此过程。计划和检查步骤产生的工件被添加到我们用于跟踪工作的Jira故事中。

该PDCA周期最适合一到三小时的编码任务,但我也用它将更大的工作范围分解为此大小的单元。这种努力长度既符合我的注意力跨度,也符合我使用模型的上下文大小。

该框架包括一个工作协议和结构化提示,引导人/AI协作完成周期的各个步骤。每个步骤都建立在先前步骤的基础上,行动步骤(回顾)将持续改进强制纳入周期。

工作协议

这些协议是开发人员为按照质量标准参与和指导代理所做的承诺。此步骤应花费一分钟供人类阅读。

规划分析

指示代理对要实现的业务目标、代码中的现有模式以及解决问题的替代方法进行项目范围分析。对于此步骤,允许两到十分钟的人/AI交换,为项目跟踪提供工件。

规划任务分解

指示代理制定实现业务目标将遵循的步骤。为代理设定路径,使输出更好地专注于即时目标。此步骤应花费约两分钟。

实施

在测试驱动的迭代周期中实施计划。提供实施指南,形成严格的护栏,指导代理如何构建专注于期望行为并通过单元测试验证的代码。指示代理向开发人员展示其推理,提供干预和指导代理的访问点。此步骤的持续时间取决于工作范围,最好控制在三小时以内。

检查

要求代理根据初始目标和实施指南验证代码实现、内部文档和自述文本。此步骤为开发人员审查工作提供帮助,并为回顾提供数据。此步骤应花费五分钟的人/AI交互,并为项目跟踪提供工件。

行动

进行回顾,通过从会话中学习并改进提示和人/AI交互来持续改进。此步骤应花费两到十分钟的人/AI交互。

工作协议:人AI协作中的人类责任

工作协议是帮助团队提高一致性和维持代码质量的成熟实践,这些关注点直接适用于个体工程师单独工作、为共享代码库做出贡献的情况。我将这种基于团队的方法适应于人AI协作,使用结构化协议在交互中锚定人类责任。

在与不同的生成式AI代码工具和演进模型合作的两年中,我的工作协议声明了我认为在AI协助下维持代码质量必不可少的最小规范集。我的意图是通过指导代理进行耦合更少、内聚更好和代码重复减少的更改来创建小批处理大小、连贯的提交和隔离的拉取请求。

这些协议包括原则(测试驱动开发、增量更改和尊重既定架构)和示例干预问题:“失败测试在哪里?“或"你在修复多个问题,专注于一个失败测试?“这些协议强化了我认为需要保持对AI产生代码负责的习惯。

计划

计划由两个活动组成:高层分析和详细规划。

高层分析:解决业务问题

前期分析在开始代码生成之前强制明确明确的业务问题和技术方法。这种做法对抗了AI在没有足够上下文的情况下实现的倾向,这会导致实现尝试失败、代码重复和不必要的回归。通过代理自己建议的迭代周期,我扩展了分析提示,明确强制执行项目范围的代码搜索,以查找类似的实现以及集成和配置模式。

我的分析提示强制进行代码库搜索,以识别类似的代码模式、系统依赖关系和现有数据结构。它要求提供解决业务问题的替代方法。该提示将输出限制在人类可读的分析上,专注于"什么"和"为什么"而不是实现细节。

我经常在进入"计划"步骤的下一部分之前提出澄清问题并建议额外的上下文。我将分析响应包含在我的Jira故事中,以记录我的方法。

详细规划:创建可观察和可测试的增量

一旦我同意了方法,详细规划提示要求代理准备初始执行计划。该计划将工作分解为一组原子化、可测试的检查表项目,具有明确的停止/继续标准和透明度要求,以便我可以跟踪代理正在做什么。

大型语言模型在扩展交互中难以保持连贯方向,特别是在具有需要架构一致性既定模式的大型代码库中。详细规划提供了路线图和人与AI之间的合同,促进更投入和负责任的编码会话。

我的提示通过要求在任何代码更改之前进行失败测试来强制执行TDD纪律,并将尝试限制在三次迭代,然后停止请求帮助。它强制要求具有明确接受标准和过程检查点的编号实施步骤。

实施:具有人类监督的测试驱动实现

实施提示在执行TDD纪律的同时,允许将相关功能分组为并行更改批次并同时进行测试验证。红绿重构纪律解决了AI创建过于复杂场景或完全跳过测试优先的倾向。批处理减少了推理成本,同时适应了AI产生完整工作代码块的优势,而不是真正的红绿测试驱动所需的刚刚足够的更改。研究表明,使用AI的结构化TDD比非结构化编码方法获得更好的成功率,但在整个过程中需要大量的人类指导。

我的实施提示包括代理和我都可以跟踪的检查表,强调行为测试失败而不是语法错误,以及真实组件而不是模拟。逐步过程可能比非结构化方法在前期使用更多令牌,但允许更积极的人类监督和隔离且连贯的提交。我遵循代理的推理,并在看到我可以纠正的推理错误、我可以补充的上下文差距或上下文漂移时进行干预。上下文漂移的迹象包括偏离主题、重复代码或忽略既定模式。

检查:完成分析

完成分析要求代理审查聊天会话记录和生成的代码,以确认更改产生预期输出,并标记与原始计划和实施指南的偏差。此审查创建了超越功能测试的明确完成定义,包括过程遵守和架构一致性。

具体来说,审查确认所有测试都已通过,并且通过端到端测试验证了复杂输出(如有必要)。代理审查新代码的准确内部文档和良好的测试覆盖率。然后它会审计会话,查看我们是否处理了原始计划中的所有待办事项,以及我们是否始终遵循测试优先方法。这些结果以叙述性和检查表形式总结,以及任何未完成项目的列表,以及工作是否准备好关闭的结论。

此输出加速了人类代码审查,并提供了开发人员可以审查、纠正、补充并添加到工作跟踪系统的工件。结果还为最后一步(回顾)提供数据。

行动:为持续改进进行回顾

回顾步骤分析会话,以突出协作模式,识别成功的人类干预,并建议改进提示和开发人员使用工具。通过回顾的持续改进通过系统地识别哪些人类干预和提示模式产生更好的结果来缓解AI的不一致性能。

回顾提示要求代理总结发生的情况,标记浪费的努力或错误的路径,提出本可以更好的事情,并建议下一次我可以做出的最有价值的更改,以改进编码会话。我专注于我可以在提示语言、过程和我的行为中更改的内容,因为这些是我可以控制以改进结果的唯一杠杆。

衡量成功

持续改进超越了单个PDCA周期,并受益于独立的质量度量。GitHub的API为创建早期预警系统提供了一个钩子。我有git操作来测量五个质量代理:

  • 大提交百分比:包含超过100行更改的提交,目标低于20%
  • 蔓延提交百分比:触及超过五个文件的提交,目标低于10%
  • 测试优先纪律率:修改测试和生产文件的提交百分比,目标大于50%
  • 每次提交的平均文件更改数:目标少于五个文件
  • 每次提交的平均行更改数:目标少于100行

实验结果

为了比较PDCA与非结构化方法,我使用Cursor和Anthropic模型使用不同方法实现了相同的用户故事。我收集了定量数据和定性指标:令牌消耗、代码行数、主观开发人员体验和代码质量评估。

非结构化会话的令牌使用情况

活动 使用的令牌
代码 264,767
故障排除 1,221,217
总计 1,485,984

PDCA会话的令牌使用情况

活动 使用的令牌
分析 106,587
详细计划 20,068
实施 1,191,521
检查 6,079
行动 7,383
总计 1,331,638

代码输出指标

指标 非结构化 PDCA
生产代码行数 534 350
测试代码行数 759 984
实现的方法数 16 9
创建的类数 1 1
修改/创建的文件数 5 14

PDCA方法导致更少的生产代码行、更全面的测试覆盖率和更原子化的提交。PDCA中较高的文件数反映了其对更小、专注的更改的强调,而不是在离散代码和测试文件中反映的广泛修改。

进一步发展的领域

我的协议、提示模板和成功度量相对较新,并且随着AI工具本身的能力而发展。以下是我当前改进和实验学习的重点领域:

  • 使过程形式与任务复杂性匹配
  • 包括模型选择策略

结论

研究表明,由于质量下降和集成挑战,AI代码生成未能实现其生产力潜力。PDCA框架通过对人AI协作应用结构来缩小这一差距,在利用AI能力的同时更好地维护代码质量。

该框架提供了五个关键实践:通过分析和规划阶段进行结构化目标设定,任务级规划以产生原子提交,及早发现问题的红绿测试周期,完整性的验证检查点,以及持续改进的微回顾。实验结果表明了核心权衡;PDCA需要更多的前期规划投资,以减少故障排除和维护,并改善开发人员体验。

采用AI代码生成的组织需要系统化的实践,这些实践可以扩展但允许个人偏好。PDCA框架提供结构,同时保持适应不同上下文的能力。随着AI能力的快速发展,人AI协作的纪律方法对于可持续软件开发至关重要。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计