AI 已经能显著缩短代码生产周期但软件交付真正变慢的环节正在从“写代码”转向“缺陷可靠闭环”。一个面向缺陷修复的 AutoDebug Agent不能只停留在能分析、能解释、能生成报告而要进入真实缺陷现场拿到真实证据修改真实仓库并用反馈持续证明它是否真的修好了问题。这类 Agent 的建设重点不是一开始设计宏大的系统而是从一个真实缺陷开始验证 AI 能否接手一次 Debug。每一轮失败、偏差和修复都要沉淀为下一轮可复用的输入。真实缺陷驱动的调试起点构建 AutoDebug Agent 的起点不是追求 Agent 形态有多完整而是验证它能否在真实缺陷场景中完成一次有效 Debug。AI 缩短了“需求 → 方案 → 代码”的生产周期但“复现 → 取证 → 修复 → 验证”的缺陷闭环仍然很慢。两条链路的反馈速度不对称缺陷闭环成为新的交付瓶颈。主要原因有两个信息散落在日志、请求、页面状态、代码变更、历史上下文中定位过程依赖经验难以完全流程化第一次真实缺陷试验的目标不是证明 AI 很强而是暴露下一轮应该改哪里。这个试验通常会出现三类现象阶段动作暴露的问题命中读缺陷、搜代码、提出根因假设AI 可以进入真实现场并尝试分析偏差输入信息不完整结论容易漂移失焦判断和执行混在一起动作不稳定这说明 AutoDebug 的第一步不是“让 AI 全自动完成所有事”而是明确它在真实缺陷处理中到底能承担哪一段。判断执行分离与闭环编排判断与执行解耦AI 处理不确定性程序处理可重复性AutoDebug Agent 的关键设计是把“判断”和“执行”拆开。AI 更适合处理理解、推理、假设和决策程序更适合处理查询、采集、建分支、推送、发布和通知。两者之间需要清晰的职责边界。模块负责内容特点判断理解缺陷、搜索代码、形成假设、决定下一步面向不确定性需要推理和选择执行查询、采集、建分支、推送、发布、通知面向可重复性适合程序自动化合理边界是AI 判断方向程序稳定执行。AI 不应该承担所有执行细节程序也不应该替代 AI 做开放式判断。输入质量决定修复上限更强的模型无法弥补缺失的事实。一句“有问题”的描述不能替代真实现场。缺陷输入如果缺少现象、路径、请求和上下文模型只能在不完整事实上猜测缺失项影响现象无法确认问题的完整表现路径无法稳定复现用户如何触发问题请求缺少接口行为、请求响应等线索上下文缺少页面状态、环境、前后操作背景缺陷入口应尽量承载现场证据而不是只保留一句描述。Kapture 的作用就是把容易消失的现场证据一次固化把临时状态转成可复用、可分析的输入。证据类型作用操作路径记录用户如何触发问题网络请求保留接口请求和响应线索页面状态保留问题发生时的界面和状态录屏保留连续操作和可视化过程输入质量决定最终修复效果的上限。现场事实缺失时模型输出再完整也只能是低置信度推断。从脚本到可编排系统让判断、执行、反馈形成闭环AutoDebug 不能长期停留在单一脚本。脚本能跑通局部动作但真正的工程价值来自可编排系统稳定地把 AI 判断送进真实环境并把真实反馈带回来。AI 判断链路包括理解症状、定位根因、修改代码和读取反馈确定性程序链路包括发现、采集、工作区和发布。两条链路都必须进入反馈回流让真实环境的结果重新影响下一轮判断。Agent 的价值也要从“说得像”升级为“交得出”。报告只能告诉开发哪里可能有问题真实修复要求 Agent 能进入仓库、直接修改代码并形成commit、分支和发布等可追踪工程结果。反馈驱动能力进化结果不是终点而是下一轮输入真正的进化不是单次结果变好而是把每次结果沉淀为下一轮可复用的输入。每一轮输出都应该产生可复用信息。这些信息会反过来影响下一轮判断、修复和交付。这里需要区分两个指标诊断准确率和替代就绪度。指标关注问题组成项诊断准确率它有没有看对根因60%、定位30%、证据10%替代就绪度它能不能减少开发接手成本根因25%、定位20%、完整性35%、精准度20%诊断准确率不等于替代就绪度。看对问题只是第一步要减少开发接手成本还需要结果足够完整、精准并能进入工程交付链路。修复验证与证据链开发修复归因不能把候选改动直接当成真实修复评估 AI Fix 时必须先确认开发改动是否真的属于当前缺陷。MR、分支、Merge、commit都只是候选线索不能直接等同于实际修复。判断项说明明确关联KP改动需要能关联当前缺陷对应的KP分支 /MR/Merge/commit只能作为候选线索语义确认要确认改动语义上确实修复当前缺陷核心修复只有被确认的改动才可作为对照与AI Fix比较无法确认属于当前缺陷的开发改动不应进入结果对比应标记为N/A。未验证假设持续推进让 Action 每天靠近结论不是每天重来而是每天让未验证假设向结论移动一步。一次无法证实的改进可以保留在CF中由Skill每天读取新证据继续推进。CF Action台账需要记录活跃Action、创建日期、预计完成时间、状态和备注。每日Skill更新会读取会话、commit、Review、Replay和生产结果等新证据并根据证据推进假设状态。每日更新推进了 8 个Action新增了 2 个Action。每个 Action 的目标不是长期停留在“进行中”而是被证实、否定或被更好的方案替代。Replay 双轨验证一条看能不能修好一条看能不能判准Replay 的核心机制是Baseline → Reset → Rerun → Compare。它不是简单重跑而是保存现场、清理对应记录、重跑主链再对比新旧证据。轨道核心问题流程证据清理 / 保留规则AUTO DEBUG REPLAYAgent 能不能修好采集 → 诊断/修复 → 前后回证 → 推送/发布复现、修复、验证、AI分支清理Auto Debug 关联Review迁移AI FixREVIEW REPLAYReviewer 能不能判准修复归因 →Diff→ 语义对比 → 指标/发布Compare、Accuracy、Reviewed只清理Review保留原修复与AI Fix两条链路清理范围不同是为了避免把原修复和AI Fix误删。试错环境与生产隔离给快速试错留出安全空间快速试错必须与生产交付隔离。开发环境用于快速重跑和验证假设生产环境用于正式扫描和正式交付。维度DevelopmentProduction运行目标快速试错、快速重跑正式扫描、正式交付账本关系独立账本正式账本标识机制开发 CF 标识Kaptain / CF / 通知Kaptain 写入不写 Kaptain只接受经过门禁的版本重置与回放允许频繁reset/replay使用版本化release版本控制通过版本门禁与生产隔离只接收已过门禁的版本隔离环境不是平台化炫技而是为高频试错提供安全空间。修复证据链原症状前后回证修复是否有效不能只看测试是否通过还要看原症状是否从失败变为通过。阶段状态凭证要求关键判断修前失败凭证FAIL同一业务路径、真实触发原问题、记录失败证据证明问题确实存在最小修复1 个断点从失败到通过之间只做最小必要修改用最小变更验证修复有效性修后通过凭证PASS相同环境、输入、断言再次执行原问题消失才通过修前与修后必须保持同一路径、同一环境、同一输入和同一断言。只有在这些条件不变的情况下FAIL - PASS才能作为有效修复证据。失败触发下一轮判断不要用同一个 Prompt 机械重试固定 Workflow 的问题在于它把失败当成“继续改代码”的信号而不是“重新判断”的信号。改造前的流程通常是采集、分析、修复、工程验证。验证失败后继续使用同一修复 Prompt最多重试 3 次。这种方式不补新证据也不调整根因假设。一个典型风险是即使出现“273 个 Maven 测试通过”也不能直接等于“原始缺陷已修复”。失败后需要进入新一轮判断而不是重复同一种重试。AI 负责判断做什么、下一步做什么程序负责检查能否执行并决定是否可以毕业。失败后的下一轮要读取失败证据更新事实与假设再决定补证、修复、反馈、工程验证或停止。闭环体系与阶段度量Loop从复盘到自我改进AutoDebug 的进化依赖真实反馈而不是主观判断。迭代策略是共规划五轮迭代每轮只解决上一轮暴露的一个断点当前已驱动 2 轮完整迭代。阶段作用当前问题或目标脚本复盘复盘执行过程问题仍靠人解释AI 归因按需取证与分析由 AI 辅助定位原因候选失控生成候选方案7样本 →17候选0决策结果优先以结果筛选方案以“可替代”为目标效果闭环形成持续改进闭环发现、排序、回证候选失控是一个关键断点。候选数量从 7 个样本扩展到 17 个候选但最终决策数为 0说明候选变多不等于质量变好。如果没有排序、验证和回证机制AI 分析会停留在“生成很多可能性”。缺陷闭环全景发现、修复、评审、回放完整的缺陷闭环不是单次修复而是持续跟踪 Action 的系统。每次replay、review、live结果都要回流到 Action。外层治理流程是每天记录真实进展更新已有 Action补充新的 Action再驱动下一轮优化。AutoDebug、Review、Replay 分别解决不同问题阶段定位解决的问题Auto Debug执行链路缺陷是否真的被处理Review复盘链路AI 当时判断是否准确Replay验证链路优化是否可以被数据重复证明Auto Debug 从 Kaptain 缺陷出发让 AI 进入真实仓库修改代码、验证、推送、发布。Review 在开发真实修完后用真实MR、diff和分母规则评估 AI 分析质量。Replay 只重放关键阶段用历史KP证明优化是否真的稳定。编号Replay 类型重放范围证明内容3AReplay Auto Debug只重放第 1 阶段采集、AI 修复、验证、推送、发布是否更可得3BReplay Review只重放第 2 阶段diff 拉取、分母过滤、语义评分、CF Review 是否稳定产出工程质量门禁包括fixture-first、tsc、unit test、coverage、dry-run。真实验收证据包括日志、lock、processed、CF、Kaptain、replay-run。用数据证明阶段结果没有真实样本、真实修复和真实回证“Agent 很强”只是一句口号。依据含义作用真实样本来自实际缺陷、真实KP或真实任务避免只在演示样例中证明能力真实修复AI 或开发在真实仓库中完成可验证修改证明问题确实被处理而不是只给出解释真实回证通过日志、对比、评审、Replay 等方式回流证据证明修复有效并支撑下一轮改进阶段性结果必须能被数据证明不能只靠主观描述。规模化验证与交付指标真实缺陷规模化交付从 268 个缺陷进入系统到 89 个以上完成验证真实交付漏斗体现了 AutoDebug 从分析到交付的实际落地情况阶段数量含义真实缺陷进入系统268真实缺陷被纳入系统处理产出 AI 分析报告197系统完成缺陷分析并生成报告生成并交付代码修复133形成可交付的代码修复结果完成编译或测试≥ 89修复结果至少完成编译或测试验证这不是 Demo而是真实仓库交付过程覆盖修改、构建和测试。准确率与替代就绪度92.5% 不等于 81.3%已完成缺陷中诊断准确率为 92.5%替代就绪度为 81.3%。指标数值关注点判断含义诊断准确率92.5%根因、定位与证据是否判断正确是否看对问题替代就绪度81.3%信息是否完整、精准能否减少开发接手看对问题不等于已经准备好替代人工。替代就绪度更接近工程交付视角因为它关心开发接手成本是否真的下降。Replay 规模化验证436 次重放让改进可比较Replay 用于规模化验证让改进可重复、可比较。Replay 类型数量内容Auto Debug Replay131重跑诊断、修复、验证Review Replay305重跑对比、评分、解释累计 Replay436其中 389 次形成完整基线对比验证流程是重跑正式主链保存前后现场再比较结果变化。瓶颈向上游迁移真实失败会推动边界外移当系统内部链路逐步稳定后瓶颈会自然迁移到系统之外。真实失败会推动边界外移从手工触发逐步迁移到上游输入质量。阶段主要瓶颈解决方向Skill → 系统手工触发不可持续动作脚本化报告 → Git开发仍承担结果真实分支与commitWorkflow → Loop跑通不等于改对观察后重规划内部 → 上游输入成为主瓶颈缺陷提交Skill报告不等于真实改动Workflow 跑通也不代表改对。当内部链路成熟后输入质量会成为主瓶颈缺陷提交本身也需要被 Skill 化。Agent 工程化迭代方法单兵小步快走用最短反馈环推动 Agent 成长单兵推进 AutoDebug 的核心不是一次把系统想完而是让每一轮最小改动都尽快遇到真实反馈。这套方法强调本地优先、先定边界、先写验收标准、小步闭环、抓住真实数据窗口以及用高质量反馈校准 AI 的执行方向。本地优先是为了让反馈尽快发生。每轮改动在独立worktree中进行修改后立即验证、Replay、Compare。如果结果符合预期保留本轮结果如果不符合预期带失败证据重新修改。链路稳定后再搬到云端。维度做法目的执行位置本地优先快速获得反馈工作方式独立worktree隔离每轮改动反馈节奏当天进入下一轮缩短迭代周期上云时机链路稳定后再搬到云端避免过早放大不稳定问题先定边界再让 Agent 开工Agent 开工前要先把任务边界和判真方式写清楚否则它容易在模糊目标下自行扩散。阶段作用关键内容Trellis问题结构化把问题拆清楚明确要解决什么讨论对齐整体方案对齐方案方向减少理解偏差Grill挑战关键细节提前拷问风险点和模糊点验收标准样本、边界、上限明确怎么判真、测试样本、边界条件、重跑限制/goal/tdd带着清晰合同开工用目标和测试驱动 Agent 执行开工前必须回答三个问题改什么、如何判真、最多重跑几次。边界不清时Agent 容易把任务做宽判真方式不清时Agent 很难判断自己是否完成重跑次数不清时容易陷入无效 Replay。验收标准早于实现可验证的 Done 才是真完成先写Done再开始实现可以避免 Agent 把“做过”误当成“完成”。目标结果 样本设计 停止条件 可验证的 Done组成部分要回答的问题具体内容目标结果最终要改善什么明确目标产出以及哪些证据算完成样本设计如何保证可比较设计正向样本、负向样本、边界样本停止条件什么情况交给人工设置 Replay 上限规定停止和人工介入条件Done必须可验证不能只靠 Agent 自述“已经做过”。小步闭环胜过大改一次只改一个系统断点小步快跑优于一次性大改版。最小改动的价值是让因果关系仍然可见。维度大改版小步快跑改动方式多个环节一起改一次只改一个系统断点观察难度因果关系混在一起因果关系更清楚运行结果连续运行一周仍可能毫无进展每轮都可解释处理方式输入、协议、流程、发布、验证互相牵连选一个真实样本保留或撤回假设Replay没有明确小闭环当天 Replay每轮都要能解释改了什么为什么有效或无效是否保留。抓住真实数据窗口动态证据会过期缺陷刚出现时日志、现场、版本都在是最稳定、最容易还原问题的时间段。这个时间段适合建立最短反馈环。阶段状态证据价值风险缺陷刚出现日志、现场、版本都在最容易形成完整输入应立即抓取真实数据等待处理上下文开始变化证据开始变弱可迭代窗口在缩短事后回看动态证据已经消失难以还原真实现场只能依赖残缺信息判断不要等到问题过去后再回看。越早抓住真实数据越容易形成完整输入。AI 放大执行力也放大错误方向AI 是执行放大器。它可以放大执行力也会放大错误方向。AI 只负责把执行变快方向必须由真实反馈持续校准。反馈类型前提条件结果影响高质量反馈目标清晰、证据可比迭代越来越快执行效率被正向放大错误反馈方向错误、输入缺失更快放大偏差错误方向被加速推进判断标准要外部化至少包括结果、样本和停止条件。不要只追求 AI 执行速度先保证反馈方向正确再让 AI 放大执行。真实反馈的核心价值AutoDebug Agent 的核心经验可以浓缩为一句话真实反馈决定优先级证据决定下一步最小改动换取新的反馈。单兵迭代不是一次性大改而是每次只围绕一个真实失败点行动。把失败变成假设再用证据判真一次只改一个断点立即用真实样本回证。持续缩短“反馈 → 改动 → 验证 → 新反馈”的周期才是 AutoDebug Agent 从能分析走向能交付的关键。