写个缺陷修复的skill,提高AI的缺陷修复效率
发布于 2026-06-13
1126
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章主旨:通过制定并遵循一个严格、结构化的Bug修复流程,可以显著提高缺陷定位与修复的效率和质量,避免来回试错的低效循环。
关键要点:
- 缺陷修复的核心瓶颈在于与AI反复沟通定位问题原因。
- 修复流程必须根除根本原因,不能只解决表面现象。
- 用户确认是连接分析阶段与修复阶段的关键决策环节。
- 修复完成后需进行知识存档,以避免同类问题再次发生。
- 所有步骤均需有检查清单进行最终确认,确保流程完整落实。
内容结构:
一、动机与背景:作者在实际开发中发现,使用AI(TRAE)进行缺陷修复时,最耗时的是反复沟通而无法准确定位原因。为此,作者设计了一套规范化的Bug修复Skill,以提升修复效率。
二、修复流程(核心主体部分):
- 前置判断:明确区分“Bug修复”与“需求调整”。Bug修复指代码行为与预期不符;需求调整指新功能或行为变更,两者走不同流程。
-
步骤1:故障定位(深入分析):
- 确定问题模块和出错层面(前端/后端/交互)。
- 如果多次修改未果,需扩大分析范围(层次、范围、交叉、换角度)。
- 编写复现测试:必须编写用于稳定重现Bug的测试(单元/集成),或提供详细手动复现步骤。无法复现的问题无法精准修复。
- 识别根本原因:明确区分“出错点(A)”与“根本原因(B)”,并使用“5个为什么”深挖。必须同时修复A和B。 - 步骤2:用户确认:在完成故障定位后,必须向用户汇报分析结果(出错模块、出错点A、根本原因B、修复建议),并获得用户同意后才能继续修复。
- 步骤3:修复影响分析:评估修复的有效性、影响范围、关联改动点及潜在的连锁修改。
- 步骤4:方案设计:通常提供两种方案,并选择更能预防问题复发的方案。强调设计优于临时补丁。
- 步骤5:方案评审:对选定方案进行自我批判,检查是否有遗漏、是否破坏其他功能、是否存在性能/安全风险。
- 步骤6:虚拟修改:在思维中进行修改的静态推演,确保修改完整、无语法错误、保持代码可读性。
- 步骤7:单元测试:修正步骤1编写的复现测试以使其通过,编写/更新其他相关单元测试,并执行回归测试确保无新问题。
- 步骤8:全局扫描:在代码库中搜索是否存在相同或类似的潜在问题模式,并在获用户同意后统一修复。
-
步骤9:经验总结:将本次修复记录追加到项目文档
docs/bug-fixes.md中,格式包括问题描述、严重程度、出错点、根本原因、修复方案、预防措施、影响范围。
三、修复检查清单:列出所有流程步骤,确保最终没有遗漏。最终输出要求以diff或前后对比形式展示修改,并需用户确认关键决策后才能修改代码。
文章总结: 这是一套高度结构化、强调根本原因分析与用户确认机制的Bug修复SOP,适合用于提升AI辅助开发场景下的问题修复效率与质量。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1083.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
AI编程要小步快跑,步步为营
文章浏览阅读417次,点赞8次,收藏6次。《AI编程的正确打开方式:小步快跑,步步为营》 文章揭示了AI编程中常见的误区:用户往往期待AI能一次性完成复杂任务,结果却陷入调试困境。核心问题在于错误的使用方式——把AI当作"许愿池"而非"结对编程伙伴"。 文章通过对比两种开发方式,指出成功关键在于"小步快跑"方法论: 将复杂需求拆分为可验证的小任务 每个步骤保持简单明确(10秒可验证) 步步为营,确保每一步正确后再继续。
CMMI 2.0维持性评估13问
从2018年3月28日正式发布CMMI 2.0以来,已经有组织在2018年做的评估可以做复评了,复评时可以考虑继续做基准评估,也可以考虑做维持性评估。维持性评估是在CMMI2.0中新增的评估,很多组织并不了解这种评估方式,我把关于维持性评估常见的13个疑问梳理澄清如下:1 满足什么条件才可以做维持性评估?答:进入维持性评估的准则如下:1)维持性评估的级别不能超过上一次评估的级别。原来是3级,则维持性评估只能评估3级或3级以下的等级,不能评估为4级,5级。2)相关的抽样因素...
需求还是bug?
文章浏览阅读525次,点赞3次,收藏7次。如何区分"需求"和"Bug"?核心判断标准在于是否存在"白纸黑字"的约定:Bug是违反已有规范的行为(如功能异常或与设计不符),需求则是提出新的期望或变更。可通过三个问题来辨别:是否写进文档?产品经理是否认可该功能?用户认为是"坏了"还是"想要更多"?常见模糊地带如性能问题和体验优化需具体情况具体分析。建议建立三方裁决机制,由产品经理最终判定,并分别走Bug修复或需求变更流程,以高效解决争议。关键在于明确基准
过程改进方法重于CMMI模型
过程改进方法重于CMMI模型在实施CMMI的过程,理解CMMI模型的难点之一是理解模型,模型理解不深不透,就无法正确地判断是否达到了模型的要求,可能做了很多投入产出不成比例的活动,造成资源的浪费。在理解了模型之后,更大的困难在于如何在企业里推广CMMI模型。举个很简单的例子,按CMMI模型的要求,项目组应该进行估算:估算任务和工作产品的属性以及工作量等,对于软件开发,任务和工作产品的属性就是规模、
CMMI 3.0究竟有哪些变化?
4月6日,CMMI 研究院发布了CMMI 3.0版本,和2.0相比,有哪些变化呢?本文做了系统梳理。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线