技能介绍

要解决的问题

AI 编码代理能很快产出补丁，但生成的变更经常混在大量上下文里：改了哪几个文件、哪段逻辑真正被修改、边界条件是否覆盖，光看 git diff 或文件列表并不直观。尤其当代理连续多轮修改后，审查者很难判断这一轮到底动了什么、为什么动、有没有引入回归。另一个问题是反馈通常散落在聊天窗口或截图里，代理拿到的是一段自然语言，缺少稳定的“评论到修复”输入。

它如何工作

这个技能把本地代码审查包装成一个 PR 风格循环：在 Git 仓库里启动 diffx，在浏览器 UI 中查看变更；以类似 pull request 的方式浏览差异，而不是直接面对终端输出。审查者可以针对具体行留下行内评论，把问题定位到代码位置。完成检查后，技能把评论整理成结构化反馈，交给编码代理执行修复。代理修改后再回到同一套流程审查，直到变更通过。

PR 风格浏览：将本地 git 变更放进浏览器界面，便于按文件和 diff 块阅读。
行内评论：评论锚定到具体行，减少“改一下这里”这种无法执行的反馈。
结构化回传：把审查意见转成代理可消费的修复输入，形成审查-修复循环。

适用边界与注意点

它适合本地开发中的未提交变更、分支比较和代理迭代修复，不替代 GitHub/GitLab 上的最终 review、权限控制或 CI 门禁。前置条件包括 git、diffx CLI 和可用浏览器。审查质量仍然依赖人是否真的看 diff，结构化反馈的格式也取决于代理如何接收上下文；如果代理无法理解评论粒度，循环会退化成反复试错。对于超大差异、二进制文件或需要运行测试/构建验证的场景，应结合自动化测试单独判断。