企业官网建设流程全解析

策划一个网站策划书,医疗门户网站模板,网站建设引言,dw网页代码模板关键要点 将结构化目标设定循环应用于AI编码会话#xff1a;运用计划-执行-检查-行动原则为每次会话设定明确、可观察的成功标准#xff0c;并根据结果调整方向。对AI使用结构化任务级规划#xff1a;让代理分析代码库#xff0c;并将大型功能分解为可在短迭代内完成的小型…关键要点将结构化目标设定循环应用于AI编码会话运用计划-执行-检查-行动原则为每次会话设定明确、可观察的成功标准并根据结果调整方向。对AI使用结构化任务级规划让代理分析代码库并将大型功能分解为可在短迭代内完成的小型、可测试的代码块以防止范围蔓延。对AI代码生成应用红绿单元测试循环让代理先编写失败的测试然后编写通过测试的生产代码创建一个结构化的反馈循环以减少回归和意外后果。建立验证检查点执行“完成度分析”环节在进入下一次迭代前要求代理根据计划审查结果。实施每日微型回顾每次编码会话后花五到十分钟与AI代理分析哪些做法有效以及如何改进提示和互动。AI代码生成工具承诺更快的开发速度但常常带来质量问题、集成问题和交付延迟。在本文中描述了一种结构化的人机协作计划-执行-检查-行动框架。在使用代理进行了一年多的非结构化过程后在过去的六个月中一直在完善这个框架。通过使用这个PDCA循环相信可以更好地在利用AI能力的同时保持代码质量。通过工作协议、结构化提示和持续回顾使用这种实践来确保对提交代码的责任同时指导AI生成经过测试、可维护的软件。代码生成尚未发挥其潜力AI代码生成的快速采用正在增加产出但尚未持续实现交付和成果方面的可衡量改进。某中心的DORA《2024年DevOps状况报告》得出结论AI采用率每增加百分之二十五交付稳定性就会下降7.2%。这种差距可能是由于增加的批处理规模超出了组织定义、审查、测试、部署和维护输出的能力。更令人担忧的是质量问题的迹象。某机构对2.11亿行代码的分析显示重复代码块增加了十倍重复代码量首次超过了移动代码量。除了导致需要维护的代码量膨胀之外克隆代码有百分之十七的缺陷率并且其中18.42%的错误会传播到其他副本中。为什么需要结构化的计划-执行-检查-行动循环行业尚未实现生产力和质量改进因为AI工具及其使用方式都需要发展。工程师需要可重复的实践利用他们的经验来指导代理进行经过测试验证的更改同时利用现有的代码模式。这涉及引入结构化提示技术。结构化提示在方法上优于临时方法根据方法和任务复杂度的不同优势在百分之一到百分之七十四之间。PDCA通过一种经过验证的、包含持续改进和迭代交付原则的软件工程实践提供了结构这些原则是过去二十年所追求的敏捷实践的基础。一项对照研究发现PDCA的应用使软件缺陷减少了百分之六十一。PDCA框架概述接下来是为与编码代理互动而制定的结构化PDCA循环。在团队用于规划、跟踪和接受工作的项目管理流程中个人使用此流程。“计划”和“检查”步骤产生的工件会添加到用于跟踪工作的Jira故事中。这种做法以较低的开销创造了透明度和可解释性。这个PDCA循环最适合一至三小时的编码任务但也用它来将更大的工作范围分解为此类大小的单元。这种工作量既符合注意力持续时间也符合所用模型的上下文长度。该框架包括一个工作协议和结构化提示引导人机协作完成循环的各个步骤。每个步骤都建立在前面的步骤之上而“行动”步骤将持续改进融入循环。工作协议这些协议是开发者为按照质量标准参与和指导代理所做的承诺。人类阅读应只需一分钟。规划分析指示代理对要实现业务目标、代码中的现有模式以及解决问题的替代方法进行项目范围的分析。此步骤允许两到十分钟的人机交流为项目跟踪提供一个工件。规划任务分解指示代理列出为实现业务目标将遵循的步骤。为代理设定路径使其输出更专注于当前目标。此步骤应耗时约两分钟。执行以测试驱动的迭代周期实施计划。提供实施指南为代理构建专注于期望行为并由单元测试验证的代码形成严格的约束。指示代理向开发者展示其推理过程提供干预和指导代理的切入点。此步骤的持续时间取决于工作范围最好控制在三小时以内。检查要求代理根据初始目标和实施指南验证代码实现、内部文档和自述文本。此步骤有助于开发者审查工作并为回顾提供数据。此步骤应进行五分钟的人机交互并为项目跟踪提供一个工件。行动进行回顾通过从会话中学习并改进提示和人机互动来持续改进。此步骤应进行两到十分钟的人机交互。此框架中包含的具体提示是通过使用所述回顾过程的实际编码会话开发和完善的。它们反映了一组特定的质量关注点并在与某模型的互动中不断发展。它们是他人适应自身开发优先级和偏好AI工具的起点。当前的工作协议和PDCA提示已共享在一个代码仓库中。工作协议人机协作中的人类责任工作协议是帮助团队提高一致性和维持代码质量的成熟实践这些关注点即使是在个体工程师单独工作、贡献于共享代码库的情况下也直接适用。已将这种基于团队的方法适应于人机协作使用结构化协议来锚定互动中的人类责任。在使用不同的生成式AI代码工具和不断演变的模型的两年中工作协议声明了认为对于在AI辅助下保持代码质量至关重要的最低规范。其目的是通过指导代理进行耦合更少、内聚性更好、代码重复更少的更改来创建小批处理量、连贯的提交和独立的拉取请求。协议包括原则测试驱动开发、增量更改和尊重既定架构和示例干预问题“先写失败测试在哪”或“你在修复多个问题专注于一个失败测试好吗”。这些协议强化了认为需要保持对AI生成代码负责的习惯。以下是分析提示的摘录用于强制执行代码仓库范围的检查分析前的要求交付物识别[两到三个]遵循类似模式的现有实现记录已建立的架构层哪些命名空间哪些接口映射集成接触点哪些现有方法需要修改列出已有的抽象文件提供程序、接口、基类计划规划由两个活动组成高层分析和详细规划。高层分析解决业务问题前期分析强制在开始代码生成之前明确具体的业务问题和技术方法。这种做法对抗了AI倾向于在没有足够上下文的情况下进行实施从而导致实施尝试失败、代码重复和不必要的回归。通过在代理自身建议下的迭代循环扩展了分析提示明确强制执行项目范围的代码搜索以查找类似的实现、集成和配置模式。分析提示强制进行代码库搜索以识别类似的代码模式、系统依赖项和现有数据结构。它要求提供解决业务问题的替代方法。该提示将输出限制为专注于“什么”和“为什么”而非实现细节的人类可读分析。在进入“计划”步骤的下一部分之前通常会提出澄清问题并提供额外的上下文。将分析响应包含在Jira故事中以记录方法。以下是规划提示的介绍规划阶段。基于我们的分析提供一个连贯的计划纳入我们的改进并针对您作为实施上下文的使用进行优化。执行上下文。该计划将按照TDD规范分步骤实施并在人工监督下进行。每个步骤都标记了在同一线程上下文内的最佳模型选择。详细规划创建可观察和可测试的增量一旦就方法达成一致详细规划提示会要求代理准备一个初始执行计划。该计划将工作分解为一组原子化、可测试的清单项目具有明确的停止/继续标准以及透明度要求以便能够遵循代理的操作。大语言模型在长时间互动中难以保持连贯的方向特别是在具有既定模式、需要架构一致性的大型代码库中。详细规划提供了路线图和人机之间的契约促进更投入和负责任的编码会话。提示通过要求在任何代码更改之前进行失败测试来强制执行TDD规范并将尝试限制在三次迭代然后停止请求帮助。它强制要求带有明确验收标准和过程检查点的编号实施步骤。与代理的互动鼓励它按计划逐步进行。如果工作足够复杂现实将迫使我们偏离计划步骤。例如可能需要解决回归测试失败或者意识到误解或遗漏了某些内容或者在工作过程中了解到改变方法的信息。此时通常会要求代理从当前所在位置重新规划或者处理完附带任务然后要求代理从其完成的最后一步回到计划。执行具有人工监督的测试驱动实现实施提示在允许将相关功能分组为并行更改批次并进行测试验证的同时强制执行TDD规范。红绿重构规范解决了AI倾向于创建过于复杂的场景或完全跳过测试优先的问题。批处理降低了推理成本同时适应了AI在生成完整的工作代码块而非真正的红绿测试驱动所需的最小更改方面的优势。研究表明使用AI的结构化TDD比非结构化编码方法能获得更好的成功率但需要在整个过程中大量的人工指导。实施提示包括代理和都可以跟踪的清单强调行为测试失败而非语法错误以及真实组件而非模拟。逐步过程可能比非结构化方法在一开始使用更多的标记但允许更积极的人工监督和独立且连贯的提交。遵循代理的推理并在看到可以纠正的推理错误、可以补充的上下文差距或上下文漂移时进行干预。上下文漂移的迹象包括偏离主题、重复代码或忽略既定模式。以下是实施提示中TDD规则的示例TDD实施❌ 不要测试接口 - 测试具体实现❌ 不要使用编译错误作为红阶段 - 使用行为失败✅ 要创建能够编译但行为上失败的存根实现✅ 尽可能使用真实组件而非模拟编译错误不是有效的红。红测试发生在调用不符合预期时。因此这意味着项目可以编译且方法存根存在但行为未完全实现。检查完成度分析完成度分析要求代理同时审查聊天会话记录和生成的代码以确认更改产生了预期的输出并标记与原始计划和实施指南的偏差。此审查创建了一个明确的“完成”定义超越了功能测试包括过程遵从性和架构一致性。具体而言审查确认所有测试都已通过并且必要时通过端到端测试验证了复杂输出。代理审查新代码的准确内部文档和良好的测试覆盖率。然后它审计会话以查看是否解决了原始计划中的所有待办事项以及是否始终遵循了测试优先的方法。这些结果以叙述和清单形式总结并附上任何未完成项目的列表以及关于工作是否准备关闭的结论。此输出加快了人工代码审查的速度并提供了一个开发者可以审查、纠正、补充并添加到工作跟踪系统中的工件。结果也为最后一步——回顾——提供了数据。以下是完整性提示完整性检查根据我们的执行情况审查我们最初的目标结果和计划。验证所有测试通过手动测试完成如需要文档已更新未引入回归没有由此测试驱动创建的剩余待办实现过程审计测试方法得到一致遵循TDD规范得以保持测试覆盖率充分且适当没有未经测试的实现被提交简单的测试场景有效状态[完成/需要工作]未完成项目[任何剩余任务]准备关闭[是/否附理由]行动为持续改进而回顾回顾步骤分析会话以突出协作模式识别成功的人工干预并建议改进提示和开发者对工具的使用。通过回顾进行持续改进系统地识别哪些人工干预和提示模式能产生更好的结果从而减轻AI性能不一致的问题。回顾提示要求代理总结发生的情况标记浪费的努力或错误的路径提出可以做得更好的地方并建议下一次可以做出的最有价值的一项改变以改进编码会话。专注于提示语言、过程和行为中可以改变的内容因为这是可以控制以改善结果的唯一杠杆。以下是回顾提示中的评估点示例关键时刻分析哪两到三个时刻中我们的方法对成功/失败影响最大哪些具体决策或干预是改变游戏规则的技术和过程洞察我们的协作模式中哪些对效率影响最大什么可以加速进展哪些过程要素运作良好哪些需要改进衡量成功持续改进不仅限于单个PDCA循环还能从独立的质量衡量中受益。某中心的API为创建早期预警系统提供了钩子。使用git操作来测量五个质量代理指标大型提交百分比包含超过一百行更改的提交目标低于百分之二十蔓延提交百分比涉及超过五个文件的提交目标低于百分之十测试优先规范率同时修改测试和生产文件的提交百分比目标大于百分之五十每次提交平均更改文件数目标少于五个文件每次提交平均更改行数目标少于一百行git操作可在github上获取在拉取请求和每三十天对整个代码仓库运行一次操作。插图PR分析github操作的部分输出对于有兴趣使用更复杂指标的企业有商业解决方案可用例如某机构、某中心和某机构。没有直接使用过任何这些工具的经验但正在试用某机构的免费层级来评估结果。实验结果为了比较PDCA与非结构化方法使用某中心的模型以不同方法实现了同一个故事。收集了定量数据和定性指标标记消耗、代码行数、主观开发者体验和代码质量评估。对一个需要复杂系统交互的故事使用了这种方法总体目标是使Tracer.cs能够接受类、方法或文件作为入口点并根据在设置json中配置的TracerOption.cs而不是运行基于Rosalyn的代码路径跟踪来检查某数据库以确定包含的dll是否已被分析然后使用现有的KuzuDepedencyGraphReader.cs和DatabaseDependencyGraphBuilder.cs从某数据库中检索子图作为ScoredOutputNodeGraph.cs并使生成的地图在功能上等同于通过方法和类跟踪创建的地图。按活动划分的标记使用量非结构化活动标记使用量代码264767故障排除1221217总计1485984按活动划分的标记使用量PDCA活动标记使用量分析106587详细计划20068执行1191521检查6079行动7383总计1331638结果表明了前期规划成本与故障排除效率之间的权衡。在非结构化会话中百分之八十的标记是在代理宣布任务完成后花费的。这部分额外工作涉及对实现的故障排除调试失败、解决不完整的实现以及纠正关于现有代码模式的假设。虽然不会将这种级别的故障排除描述为典型情况但在处理复杂集成时并不少见。代码输出指标指标非结构化PDCA生产代码行数534350测试代码行数759984实现的方法数169创建的类数11修改/创建的文件数514PDCA方法导致了更少的的生产代码行数、更全面的测试覆盖率和更原子化的提交。PDCA中较高的文件数量反映了其强调更小、更集中的更改而不是体现在独立代码和测试文件中的广泛修改。虽然两种方法都实现了可行的解决方案但非结构化方法在初始实施后需要进行更广泛的调试而PDCA的测试驱动增量更早地发现了问题。在定性上PDCA创造了更好的开发者体验。在PDCA中人工互动贯穿规划和编码过程而在非结构化方法中互动集中在最后且主要集中在审查和故障排除上。意识到这些结果基于单个实验。展示它们不是作为证据而是作为方向性数据支持继续在自己的实践中发展和改进这种方法。有待进一步发展的领域协议、提示模板和成功衡量标准相对较新并且与AI工具本身的能力一样在不断演变。以下是当前细化和实验学习的重点领域使流程规范性与任务复杂度相匹配PDCA框架的结构化方法提供了价值但需要根据所执行工作的复杂性和风险进行调整。规划提示需要大量的标记使用并正在寻求为隔离良好的更改例如在已存在具体示例的情况下实现接口尝试更轻量级的分析和规划步骤。在这种情况下以及其他潜在情况下现有代码为AI遵循提供了足够的上下文和模式无需广泛的前期分析。在敏捷方法发展的早期有人提出了某方法即流程严格程度应随项目关键性和团队规模而扩展。这表明应为低复杂度场景制定不太正式的规划和实施提示版本同时仍进行模式分析、强制执行足够的透明度和进行回顾。涉及架构决策、跨系统集成或新颖问题领域的复杂更改受益于更结构化的PDCA循环。前期对分析和详细规划的投资可以防止AI工具在没有足够上下文的情况下操作时产生的返工、回归和技术债务的复合成本。纳入模型选择策略结构化的分析和规划为基于任务复杂度优化执行成本提供了机会通过切换模型选择来实现。已经开始在分析和规划中纳入复杂度评估并要求AI估计实施难度、模式清晰度和每个提议解决方案的范围。然后要求它就执行过程中的每个点例如在某中心内使用某模型和某模型推荐使用哪个模型。它形成推荐的标准是有用的但推荐并非基于经验证据而且模型的实际行为比其训练数据更新。在这种情况下也在等待某中心发布更新的小模型并将试验其他系列的小模型。初始分析和规划阶段需要能力更强的模型来处理模糊的需求和架构推理。然而在遵循明确规范的实施阶段特别是在代码库包含强模式且更改范围明确的情况下使用成本较低的模型可能同样有效。在人工参与的过程中解决这个问题的优势在于人类能够主动降级模型并在模型遇到困难时迅速干预。结论研究表明由于质量下降和集成挑战AI代码生成尚未发挥其生产力潜力。PDCA框架通过对人机协作应用结构来弥补这一差距在更好地保持代码质量的同时利用AI能力。该框架提供了五个关键实践通过分析和规划阶段进行结构化目标设定、任务级规划以产生原子化提交、及早发现问题的红绿测试循环、用于完整性的验证检查点以及用于持续改进的微型回顾。实验结果表明了核心的权衡PDCA需要更多的前期规划投资以减少故障排除和维护并改善开发者体验。采用AI代码生成的组织需要可扩展但又允许个人偏好的系统化实践。PDCA框架提供了结构同时保持适应不同上下文的能力。随着AI能力的快速发展对于可持续的软件开发而言对人机协作的规范方法是至关重要的。AI披露根据InfoQ对贡献者的AI政策在保持人类专业知识作为内容主导的前提下使用生成式AI工具作为支持工具。具体来说使用某模型进行头脑风暴和构思以制定初始大纲进行反馈和提出反对意见以识别论点中的不足以及通过起草辅助来改善多次修订中的清晰度、流畅度和语法。本文中包含的提示示例是与某模型共同创作的代表了实际工作中的真实提示。亲自检索和审查了所有研究来源撰写了分析和框架并做出了所有最终内容决策。对所有内容的准确性、原创性和质量承担全部责任并在采纳任何AI生成的建议前进行了严格核实。更多精彩内容 请关注我的个人公众号 公众号办公AI智能小助手或者 我的个人博客 https://blog.qife122.com/对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号网络安全技术点滴分享