Diffsmith

想要一个并排模式，同时显示原文件与 diff，因为现在要在单行上留评论前，我得频繁切回编辑器回忆上下文。

对于这样一个处在智能体编码热循环中的工具，一次性买断真是清新的做法。我想弄明白的机制是：当智能体通过重写整个代码块来回复评论时，锚点去了哪里？评论是跟着移动后的逻辑走，还是随旧行一起消失？这个解决步骤决定了第三轮之后 review 回合是否还读得下去。

这在那些频繁 commit 的智能体循环里会很麻烦。我们的智能体每完成一个有意义的步骤就会 commit，所以一次 40 分钟的会话会产生 10-15 个 commit，每个 commit 都会把整个 review 状态扫进 Past。有没有可能让评论在它锚定的行保持不变并存在于 HEAD 中时继续存活？提交通常意味着我认可了代码，不是说我聊完了。

上面提到的“重写时归档”机制覆盖了智能体编辑被评论行的情况。不过我好奇另一个触发条件：如果智能体在会话中直接运行了 `git commit`，Diffsmith 是和新的 HEAD 做 diff 然后以相同方式归档所有内容，还是因为锚点指向之前未提交的状态而丢失追踪？

终于有一种方式可以逐行与我的 AI 智能体对话，而不是把 diff 片段复制粘贴到聊天框里。MCP 回复查看器精准定位在代码行上，确实非常有用。

MCP路径让这个过程变成了一个循环而非单向审查，因为智能体的回复会直接落回到它们所属的那一行。这些评论状态实际存放在哪里：是放在repo里作为我gitignore的东西，还是在工作树之外的应用程序本地存储中？我问这个问题是因为想知道，当我在审查中切换分支或stash时，锚定评论会怎样，以及MCP服务器是智能体轮询新笔记，还是我完成一轮审查后主动推送给你的？