企业官网建设流程全解析

AI 已经能显著缩短代码生产周期，但软件交付真正变慢的环节，正在从“写代码”转向“缺陷可靠闭环”。一个面向缺陷修复的 AutoDebug Agent，不能只停留在能分析、能解释、能生成报告，而要进入真实缺陷现场，拿到真实证据，修改真实仓库，并用反馈持续证明它是否真的修好了问题。

这类 Agent 的建设重点不是一开始设计宏大的系统，而是从一个真实缺陷开始，验证 AI 能否接手一次 Debug。每一轮失败、偏差和修复，都要沉淀为下一轮可复用的输入。

真实缺陷驱动的调试起点

构建 AutoDebug Agent 的起点，不是追求 Agent 形态有多完整，而是验证它能否在真实缺陷场景中完成一次有效 Debug。

AI 缩短了“需求 → 方案 → 代码”的生产周期，但“复现 → 取证 → 修复 → 验证”的缺陷闭环仍然很慢。两条链路的反馈速度不对称，缺陷闭环成为新的交付瓶颈。

主要原因有两个：

• 信息散落在日志、请求、页面状态、代码变更、历史上下文中
• 定位过程依赖经验，难以完全流程化

第一次真实缺陷试验的目标，不是证明 AI 很强，而是暴露下一轮应该改哪里。这个试验通常会出现三类现象：

这说明 AutoDebug 的第一步不是“让 AI 全自动完成所有事”，而是明确它在真实缺陷处理中到底能承担哪一段。

判断执行分离与闭环编排

判断与执行解耦：AI 处理不确定性，程序处理可重复性

AutoDebug Agent 的关键设计，是把“判断”和“执行”拆开。

AI 更适合处理理解、推理、假设和决策；程序更适合处理查询、采集、建分支、推送、发布和通知。两者之间需要清晰的职责边界。

合理边界是：AI 判断方向，程序稳定执行。AI 不应该承担所有执行细节，程序也不应该替代 AI 做开放式判断。

输入质量决定修复上限

更强的模型无法弥补缺失的事实。一句“有问题”的描述，不能替代真实现场。

缺陷输入如果缺少现象、路径、请求和上下文，模型只能在不完整事实上猜测：

缺陷入口应尽量承载现场证据，而不是只保留一句描述。Kapture 的作用，就是把容易消失的现场证据一次固化，把临时状态转成可复用、可分析的输入。

输入质量决定最终修复效果的上限。现场事实缺失时，模型输出再完整，也只能是低置信度推断。

从脚本到可编排系统：让判断、执行、反馈形成闭环

AutoDebug 不能长期停留在单一脚本。脚本能跑通局部动作，但真正的工程价值来自可编排系统：稳定地把 AI 判断送进真实环境，并把真实反馈带回来。

AI 判断链路包括理解症状、定位根因、修改代码和读取反馈；确定性程序链路包括发现、采集、工作区和发布。两条链路都必须进入反馈回流，让真实环境的结果重新影响下一轮判断。

Agent 的价值也要从“说得像”升级为“交得出”。报告只能告诉开发哪里可能有问题，真实修复要求 Agent 能进入仓库、直接修改代码，并形成commit、分支和发布等可追踪工程结果。

反馈驱动能力进化：结果不是终点，而是下一轮输入

真正的进化，不是单次结果变好，而是把每次结果沉淀为下一轮可复用的输入。

每一轮输出都应该产生可复用信息。这些信息会反过来影响下一轮判断、修复和交付。

这里需要区分两个指标：诊断准确率和替代就绪度。

诊断准确率不等于替代就绪度。看对问题只是第一步，要减少开发接手成本，还需要结果足够完整、精准，并能进入工程交付链路。

修复验证与证据链

开发修复归因：不能把候选改动直接当成真实修复

评估 AI Fix 时，必须先确认开发改动是否真的属于当前缺陷。MR、分支、Merge、commit都只是候选线索，不能直接等同于实际修复。

无法确认属于当前缺陷的开发改动，不应进入结果对比，应标记为N/A。

未验证假设持续推进：让 Action 每天靠近结论

不是每天重来，而是每天让未验证假设向结论移动一步。一次无法证实的改进，可以保留在CF中，由Skill每天读取新证据继续推进。

CF Action台账需要记录活跃Action、创建日期、预计完成时间、状态和备注。每日Skill更新会读取会话、commit、Review、Replay和生产结果等新证据，并根据证据推进假设状态。

每日更新推进了 8 个Action，新增了 2 个Action。每个 Action 的目标不是长期停留在“进行中”，而是被证实、否定，或被更好的方案替代。

Replay 双轨验证：一条看能不能修好，一条看能不能判准

Replay 的核心机制是Baseline → Reset → Rerun → Compare。它不是简单重跑，而是保存现场、清理对应记录、重跑主链，再对比新旧证据。

两条链路清理范围不同，是为了避免把原修复和AI Fix误删。

试错环境与生产隔离：给快速试错留出安全空间

快速试错必须与生产交付隔离。开发环境用于快速重跑和验证假设，生产环境用于正式扫描和正式交付。

隔离环境不是平台化炫技，而是为高频试错提供安全空间。

修复证据链：原症状前后回证

修复是否有效，不能只看测试是否通过，还要看原症状是否从失败变为通过。

修前与修后必须保持同一路径、同一环境、同一输入和同一断言。只有在这些条件不变的情况下，FAIL -> PASS才能作为有效修复证据。

失败触发下一轮判断：不要用同一个 Prompt 机械重试

固定 Workflow 的问题在于，它把失败当成“继续改代码”的信号，而不是“重新判断”的信号。

改造前的流程通常是：采集、分析、修复、工程验证。验证失败后，继续使用同一修复 Prompt，最多重试 3 次。这种方式不补新证据，也不调整根因假设。

一个典型风险是：即使出现“273 个 Maven 测试通过”，也不能直接等于“原始缺陷已修复”。失败后需要进入新一轮判断，而不是重复同一种重试。

AI 负责判断做什么、下一步做什么；程序负责检查能否执行，并决定是否可以毕业。失败后的下一轮要读取失败证据，更新事实与假设，再决定补证、修复、反馈、工程验证或停止。

闭环体系与阶段度量

Loop：从复盘到自我改进

AutoDebug 的进化依赖真实反馈，而不是主观判断。迭代策略是共规划五轮迭代，每轮只解决上一轮暴露的一个断点，当前已驱动 2 轮完整迭代。

候选失控是一个关键断点。候选数量从 7 个样本扩展到 17 个候选，但最终决策数为 0，说明候选变多不等于质量变好。如果没有排序、验证和回证机制，AI 分析会停留在“生成很多可能性”。

缺陷闭环全景：发现、修复、评审、回放

完整的缺陷闭环，不是单次修复，而是持续跟踪 Action 的系统。每次replay、review、live结果都要回流到 Action。

外层治理流程是：每天记录真实进展，更新已有 Action，补充新的 Action，再驱动下一轮优化。

AutoDebug、Review、Replay 分别解决不同问题：

Auto Debug 从 Kaptain 缺陷出发，让 AI 进入真实仓库，修改代码、验证、推送、发布。Review 在开发真实修完后，用真实MR、diff和分母规则评估 AI 分析质量。Replay 只重放关键阶段，用历史KP证明优化是否真的稳定。

工程质量门禁包括fixture-first、tsc、unit test、coverage、dry-run。真实验收证据包括日志、lock、processed、CF、Kaptain、replay-run。

用数据证明阶段结果

没有真实样本、真实修复和真实回证，“Agent 很强”只是一句口号。

阶段性结果必须能被数据证明，不能只靠主观描述。

规模化验证与交付指标

真实缺陷规模化交付：从 268 个缺陷进入系统到 89 个以上完成验证

真实交付漏斗体现了 AutoDebug 从分析到交付的实际落地情况：

这不是 Demo，而是真实仓库交付，过程覆盖修改、构建和测试。

准确率与替代就绪度：92.5% 不等于 81.3%

已完成缺陷中，诊断准确率为 92.5%，替代就绪度为 81.3%。

看对问题，不等于已经准备好替代人工。替代就绪度更接近工程交付视角，因为它关心开发接手成本是否真的下降。

Replay 规模化验证：436 次重放让改进可比较

Replay 用于规模化验证，让改进可重复、可比较。

验证流程是重跑正式主链，保存前后现场，再比较结果变化。

瓶颈向上游迁移：真实失败会推动边界外移

当系统内部链路逐步稳定后，瓶颈会自然迁移到系统之外。真实失败会推动边界外移，从手工触发逐步迁移到上游输入质量。

报告不等于真实改动，Workflow 跑通也不代表改对。当内部链路成熟后，输入质量会成为主瓶颈，缺陷提交本身也需要被 Skill 化。

Agent 工程化迭代方法

单兵小步快走：用最短反馈环推动 Agent 成长

单兵推进 AutoDebug 的核心，不是一次把系统想完，而是让每一轮最小改动都尽快遇到真实反馈。这套方法强调本地优先、先定边界、先写验收标准、小步闭环、抓住真实数据窗口，以及用高质量反馈校准 AI 的执行方向。

本地优先是为了让反馈尽快发生。每轮改动在独立worktree中进行，修改后立即验证、Replay、Compare。如果结果符合预期，保留本轮结果；如果不符合预期，带失败证据重新修改。链路稳定后，再搬到云端。

先定边界，再让 Agent 开工

Agent 开工前要先把任务边界和判真方式写清楚，否则它容易在模糊目标下自行扩散。

开工前必须回答三个问题：改什么、如何判真、最多重跑几次。

边界不清时，Agent 容易把任务做宽；判真方式不清时，Agent 很难判断自己是否完成；重跑次数不清时，容易陷入无效 Replay。

验收标准早于实现：可验证的 Done 才是真完成

先写Done，再开始实现，可以避免 Agent 把“做过”误当成“完成”。

目标结果 + 样本设计 + 停止条件 = 可验证的 Done

Done必须可验证，不能只靠 Agent 自述“已经做过”。

小步闭环胜过大改：一次只改一个系统断点

小步快跑优于一次性大改版。最小改动的价值，是让因果关系仍然可见。

每轮都要能解释：改了什么，为什么有效或无效，是否保留。

抓住真实数据窗口：动态证据会过期

缺陷刚出现时，日志、现场、版本都在，是最稳定、最容易还原问题的时间段。这个时间段适合建立最短反馈环。

不要等到问题过去后再回看。越早抓住真实数据，越容易形成完整输入。

AI 放大执行力，也放大错误方向

AI 是执行放大器。它可以放大执行力，也会放大错误方向。AI 只负责把执行变快，方向必须由真实反馈持续校准。

判断标准要外部化，至少包括结果、样本和停止条件。不要只追求 AI 执行速度，先保证反馈方向正确，再让 AI 放大执行。

真实反馈的核心价值

AutoDebug Agent 的核心经验可以浓缩为一句话：真实反馈决定优先级，证据决定下一步，最小改动换取新的反馈。

单兵迭代不是一次性大改，而是每次只围绕一个真实失败点行动。把失败变成假设，再用证据判真；一次只改一个断点，立即用真实样本回证。持续缩短“反馈 → 改动 → 验证 → 新反馈”的周期，才是 AutoDebug Agent 从能分析走向能交付的关键。