写个缺陷修复的skill,提高AI的缺陷修复效率
发布于 2026-06-13
603
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
文章主旨:通过制定并遵循一个严格、结构化的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 篇文章
浏览 921.1K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
高成熟度实践点睛之QPM
SP 1.1 建立项目的目标:建立并维护项目的质量目标和过程性能目标(1)项目的QPPO要根据项目的特点、组织级的QPPO、组织级的基线来确定。不应该所有项目的目标都是相同的,因为项目的特点是不同的。(2)项目的QPPO要满足SMART原则。(3)项目的QPPO要和历史的过程性能基线进行对比,判断目标达成的概率。(4)项目的QPPO达成概率也可以通过过程性能模型进行预测。(5)难以达成的目标,要制
别用计算器写诗,也别让诗人算账 —— 论 Skill 与程序的边界与共生
摘要:AI开发中程序与Skill的本质区别在于确定性与经验性的管辖权划分。程序是确定性逻辑的忠实执行者,确保输入输出关系固定;而Skill是经验型逻辑的动态调度者,依赖LLM进行灵活决策。架构设计必须遵循"确定性交给程序,经验型交给LLM"原则:若让LLM执行精确运算会产生幻觉,用代码处理语义则会导致维护灾难。最佳实践是构建"脑-手"协作模型,LLM负责意图理解与决策,程序负责具体执行,通过结构化接口确保AI的创造性不逾越确定性边界。
CMMI之怪相分析
90年代中期,CMM开始传入中国。1999年清华鼎新成为首家通过CMM评估的国内企业,截止2006年底,中国通过CMMI正式评估的组织的数量仅次于美国和印度,位居全球第三。CMM在中国推广近10年以来,对于中国软件企业的发展起到了巨大的推动作用。但是,最近几年,CMMI在中国的推广却表现出了一些令人担忧的现象,社会上对于CMMI的评价日趋下滑。笔者试图透析企业通过评估后所表现出的种种怪现象,对中国
敏捷的过程改进方法:从经验教训中学习
每次去客户现场做差距分析或者运行检查,总是习惯于找他们的缺点,但是每次也总能从客户那里发现他们的优点,时间久了,慢慢地对缺陷麻木了,审丑疲劳了,只有发现他们的优点时,我才会精神一振,心情愉快。 今年1-2月份期间我去给一个客户做运行检查,整理完发现报告后,我查阅了那6个项目组的阶段总结报告与项目总结报告中的经验教训部分,我发现的60%的缺陷他们自己也感觉到了,只是没有人去提取、去系统的归纳整理、
对需求变更的定量分析
很多公司头疼需求变更,如果我们采用定量的技术该如何分析需求的变更呢?首先定义什么叫需求变更?在客户方与开发方共同认可需求之后的需求修改、增加、删除都是需求变更。需求变更对象可以从多个维度划分: 维度一: 功能需求、非功能性需求、接口需求、界面需求、技术约束等; 维度二:业务逻辑、数据对象、控制逻辑等;其次,可以从3个层次分析需求变更:层次1: 需求变更率分析。需求变更率有多种定义方法。 方法一:需求变更率=需求变更的个数/交付的需求个数;...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线