AI智能体调试的是当前代码,但生产错误存在于过去。以下是修复方案。
摘要
一项新的开源技能强制AI编程助手通过使用git worktree隔离确切的历史提交来调试生产错误,同时保持本地工作空间不被影响。
生产错误发生在过去,但AI编程助手只分析当前代码。当3小时前的生产错误追踪被输入到Cursor或Claude Code时,智能体几乎总是最终在追捕一个幽灵。等到调试开始时,主分支通常已经前进了。智能体查看文件的当前状态,由于代码行已移动,完全错过了原始错误,并自信地幻想着对无辜代码进行修复。常见的解决方法是告诉智能体执行 git checkout 到旧提交。但智能体很混乱。它们经常忘记切换回来,使仓库处于分离的HEAD状态,或者意外覆盖未提交的本地工作。
为了解决这种摩擦,我编写了一个开源技能,强制执行严格的调试流程——
当智能体获得旧崩溃日志时,它会:
- 从git log解析出历史哈希
- 使用git worktree在那一刻创建一个隔离的临时仓库文件夹
- 分析旧代码以找到实际根本原因
- 完成后销毁临时文件夹(git worktree remove --force)
实际本地工作空间完全不受影响。未提交的工作非常安全。
您可以通过开放注册表使用一条命令将其放入任何兼容技能的智能体(Claude Code、Cursor、Windsurf)中:
Bash npx skills add MeherBhaskar/temporal-debug-skill
很想知道您的看法……欢迎提出想法和反馈。
相似文章
你究竟如何调试AI代理?
开发者分享了在生产环境中调试AI代理的困境,指出了幻觉问题、提示词更改导致的回归以及高昂的API成本,并向社区征求策略。
我分析了 50 多个 AI 团队如何调试生产环境中的智能体故障,结果令人意外
基于对 50 多个 AI 团队的访谈,作者指出生产环境中的智能体故障往往源于细微的提示词或配置问题,而非深层模型缺陷。文章主张采用版本控制、A/B 测试和实验跟踪等软件工程实践以提高可靠性。
如何为你的AI代理进行版本控制和回滚?git让我失望,我感觉自己遗漏了什么。
一位开发者分享了使用git进行AI代理版本控制和回滚的困境,强调了提示词编辑导致的静默行为变化以及缺乏回归信号的问题。他们向社区寻求更好的工作流程。
@RayFernando1337: 导致用户流失的错误几乎从不出现在差异对比中,只有当你停止审查代码时才能真正捕捉到它们……
一位开发者分享了在Cursor中使用Opus 4.8 Max Thinking模型与子代理框架的工作流,并介绍了一个包含可安装技能文件的GitHub仓库,其中包含一个名为'running-bug-review-board'的技能,可进行实时QA测试。
今天如何为AI编码代理提供真实的生产上下文?
本文讨论了为AI编码代理提供真实生产上下文(如日志、指标和追踪)以改进其调试和修复建议的挑战,并向社区征求实用解决方案。