AI驱动的缺陷全自动修复

一、背景AI提效带来的新问题核心矛盾天平失衡环节AI带来的影响编码加速产出工程师掌控度下降测试/评审/治理压力被反向放大形成「造得快、修得慢」的瓶颈本质缺陷存在复利效应用户量越大未修复缺陷的影响呈指数级放大核心命题AI让「造」变快的同时必须通过缺陷修复全链路自动化让「修」跟上节奏Prompt是战术体系化建设才是根本。二、端到端自动修复体系设计5阶段闭环流程阶段核心动作关键规则上报收集描述截图日志产物明确Hook检测兜底分析推导根因依据结论必须标注「依据上下文」断链则触发补全子流程修复决策树代码Diff根因明确直接修复不明确则进入「加日志→验证复现→补上下文→再分析」循环测试金字塔E2E验证单测底层快速反馈→集测中层链路验证→E2E顶层含Computer-Use复现优先修了没复现没修​评审三依据看板不依赖人脑记忆依赖可引用证据链• 根因依据分析报告、推理链• 修复决策代码Diff、决策说明、规范引用• 测试证据截图、录屏、用例结果两大贯穿原则原则具体做法检测强驱动​拒绝纯模型驱动采用「模型Hook检测」兜底模型遗漏由Hook在阶段3拦截避免缺陷流出明确分阶段​拒绝「一锅端」采用分阶段流水线质量门控单点出错仅回退对应阶段不推翻整体流程自进化机制用户反馈、测试用例自动沉淀回流每一次修复都成为下一次的训练材料实现「越用越聪明」。三、实践经验难点与重点核心认知工程算法水面之上可见的是算法/Prompt技巧水面之下决定持续价值的是上下文工程、Hook兜底、评审证据链、知识库治理、反馈回流等工程体系。模型「猜」的问题根源现象原因典型失败模式模型倾向「给答案承认不知」用通用知识填补输入缺失模型能力≠项目知识• 缺少项目架构/团队约定/历史决策上下文• 隐性边界条件无文档记录• 遗漏单点修复导致回归新问题• 治标不治本try-catch吞异常/硬编码偏移根因未解决反而加深隐患两大解决重点1上下文分层递进加载层级适用场景包含内容L1 Bug Knowledge始终加载日志规范、注释规范、错误码定义L2 Repository Knowledge简单缺陷无法修复时启用结构索引、接口契约、提交历史、测试语义L3 Project Knowledge复杂/跨模块缺陷启用Wiki、模块故障诊断树、模式库、判断边界L4 Dynamic Instrumentation根因不明时启用插装策略、运行时中间态捕获规则上下文断链立即标记「信息不足」进入下一层补全禁止硬猜2分阶段产物Hook检测通过工程规则兜底不依赖模型自觉每个阶段输出标准化产物Hook校验不通过则阻断流程。四、趋势与扩展思考长期价值排序项目知识沉淀工程化体系模型能力前两者可长期沉淀进化是抗模型迭代风险的「地基」。两类应用场景策略应用类型策略核心动作新应用无历史包袱AI友好化前置从Day-1内建修复体系结构化文档标准注释高覆盖测试治理动作前置到设计开发阶段存量应用最小闭环切入→双轨并行• 轨道一用例驱动开发补齐review、日志规范、注释、知识库、测试覆盖• 轨道二定时扫描7×24主动发现问题多次交叉review避免遗漏通用规律日志是跨项目最稳定的「通用语言」缺陷上下文提供方式、复现/验证方式因端/技术栈而异但链路分析均可基于日志实现。Hook规则写法详解Hook本质是流水线中的每个质量门禁通过「规则引擎脚本校验」实现不依赖模型自觉强制拦截不符合规范的产物。通用Hook框架所有阶段通用# hook定义模板以分析阶段为例 hook: id: analyze_root_cause_check name: 根因结论依据校验 stage: analyze # 生效阶段report/analyze/fix/test/review trigger: post # 触发时机pre阶段前/post阶段后 condition: # 触发条件逻辑表达式 - type: output_field_check field: root_cause_report operator: exists # 必须存在根因报告 - type: regex_match field: root_cause_report pattern: 依据上下文:. # 必须包含依据声明 action: # 拦截动作 type: block # block阻断流程warn警告不阻断 message: 根因结论未标注依据来源请补充上下文引用后重试 fallback: # 失败兜底 type: trigger_sub_flow sub_flow: context_completion # 触发上下文补全子流程各阶段具体Hook规则示例阶段Hook名称核心校验逻辑拦截场景示例兜底动作上报阶段​日志完整性校验trace_id ! null log.contains(export_task_start) log.contains(export_task_end)上报日志缺失TraceID或任务起止标记触发日志插装子流程分析阶段​根因依据校验root_cause_report.matches(依据上下文:.) evidence_list.length 1模型输出可能是索引问题但无日志/提交记录支撑触发调试增强子循环修复阶段​SQL变更规范校验code_diff.type sql sql.parse(diff).contains(INDEX) rule_engine.check(index_naming_rule)模型添加的索引名不符合idx_表名_字段名规范返回修复建议阻断合并测试阶段​E2E用例强制校验test_result.e2e_pass true test_data.volume 1000000仅通过单测未复现百万数据超时场景触发E2E用例生成子流程评审阶段​三依据完整性校验evidence_board.root_cause_ref ! null evidence_board.fix_decision_ref ! null evidence_board.test_evidence_ref ! null缺少测试证据或根因依据上下文分层实现逻辑详解上下文分层的核心是按需加载断链即停避免一次性喂入过多无关信息导致模型幻觉同时降低推理成本。上下文存储架构context-store/ ├── L1_bug_knowledge/ # 全局通用规则 │ ├── log_spec.yaml # 日志规范 │ ├── error_code.yaml # 错误码定义 │ └── common_patterns.json # 常见缺陷模式 ├── L2_repo_knowledge/ # 仓库级知识 │ ├── schema/ # 表结构索引 │ │ └── order_table.yaml # 订单表字段索引定义 │ ├── commit_history/ # 提交记录索引 │ │ └── index.json # 按文件/功能索引的提交记录 │ └── api_contract/ # API契约 ├── L3_project_knowledge/ # 项目级知识 │ ├── module_diagnosis_tree/ # 模块故障诊断树 │ │ └── export_timeout.yaml │ ├── team_conventions/ # 团队约定 │ └── boundary_conditions/ # 隐性边界条件 └── L4_dynamic_instrumentation/ # 动态插装策略 ├── sql_profiler.yaml # SQL执行计划插装规则 └── runtime_capture.yaml # 运行时变量捕获规则分层加载逻辑伪代码def load_context(defect, current_layerL1): # 1. 始终加载L1基础上下文 context load_L1_context() # 2. 判断是否需要加载更高层级 if is_simple_defect(defect): # 简单缺陷如空指针异常L1足够 return context # 3. 尝试L2仓库知识 if current_layer L2: repo_context load_L2_repo_context(defect.module) context.merge(repo_context) # 检查上下文是否充足 if check_context_sufficiency(context, defect): return context # 断链标记信息不足准备升级层级 mark_insufficient_context(defect, missing_fields[sql_execution_plan]) # 4. 尝试L3项目知识复杂/跨模块缺陷 if current_layer L3: project_context load_L3_project_context(defect.project) context.merge(project_context) if check_context_sufficiency(context, defect): return context # 5. 最后尝试L4动态插装根因不明时 if current_layer L4: dynamic_context trigger_dynamic_instrumentation(defect) context.merge(dynamic_context) return context def check_context_sufficiency(context, defect): # 校验上下文是否覆盖缺陷分析所需的最小字段集 required_fields get_required_fields(defect.type) for field in required_fields: if field not in context: return False return True场景落地示例订单导出超时缺陷步骤加载层级加载内容判断是否充足下一步动作1L1日志规范export_前缀、错误码EXPORT_TIMEOUT5001不足缺SQL相关信息升级到L22L2订单表结构字段定义、提交记录#1234删除索引不足缺SQL执行计划升级到L33L3导出超时诊断树、团队约定「大数据查询必加索引」不足缺实际执行计划升级到L44L4动态插装的SQL执行计划日志充足找到全表扫描证据开始根因分析