seendiff：把“看过”和“审过”拆开，AI 大 diff 才能真正被接管

seendiff 是一款给大规模代码变更做审查的本地工具。它面向的不是“怎么写代码”，而是 AI coding agent 一次改了很多文件之后，人怎么知道自己究竟看过了什么、真正审过了什么。seendiff 会把分支相对基准分支的完整变更放进浏览器界面，并保留审查进度；产品定位本身就写明，它针对的是 AI coding agent 产生的大型 diff。1

使用门槛也很明确：本机需要 Python 3.10 或更高版本和 Git，安装 CLI 后，在 Git 仓库里运行 seendiff 即可启动本地服务。seendiff 不是合并工具，不负责编辑、解决冲突或发表评论；它把自己限定成一个阅读和审查界面。2

真正值得拆的，不是它把 diff 画得多漂亮，而是它把“审查”从一次性滚动阅读，改成了两个可以分别追踪的状态。

普通 diff 阅读很容易制造一种错觉：代码从屏幕上经过了，审查就完成了。seendiff 故意把这两件事拆开。代码块经过视口时，系统自动记为 Seen；只有用户按 R，或按 f 把整个文件标为已审，才会进入 Reviewed。快捷键 n / N 还可以直接跳到下一个或上一个未审查块。1

这个设计解决的不是记忆问题，而是责任边界问题。自动记录 Seen，降低了“我刚才滚到哪里”的操作成本；把 Reviewed 留给明确按键，则阻止系统把“出现在视线里”误判成“人已经做过判断”。V 进一步把两者接起来：用户可以一次性把当前文件里所有“看过但未审”的块标为已审，但这个动作仍然是一次明确的确认，而不是滚动带来的副作用。2

seendiff 还没有把审查进度绑定在会变掉的提交 SHA 上。产品把相邻改动组织成带内容标识的 blocks；超过 48 行的 block 会在代码结构的接缝处分段，分段至少 12 行。审查状态按仓库、基准引用和分支保存，因此 amend、rebase 或改写提交信息后，用户仍能回到原来的审查位置。2

这里的取舍很具体：状态要足够稳定，才能承接真实开发中的 rebase；状态又不能直接等于批准，因为代码内容变化后，用户仍需检查那些重新出现或未完成的块。对产品设计来说，值得迁移的做法是：把“被系统带到过”和“由用户作出判断”建成两个状态，不要用一个绿色勾选替代整条责任链。

AI coding agent 可以解释自己做了什么，但单独的聊天记录通常不是好的审查界面。读者还得在解释、文件树和代码之间来回寻找，才能确认 agent 说的内容对应哪几行。seendiff 的 walkthrough 模式把解释直接放回 diff：agent 用脚本把一次大改动拆成 acts 和 steps，当前步骤在代码窗格中指向自己的行号，底部再显示这一步的说明。1

关键不在“AI 写了一段摘要”，而在解释必须携带可检查的对象。仓库说明要求 walkthrough 中的每个行号引用都对照真实 diff 校验；引用过时，脚本会在加载时失败，而不是把用户带到一个看似相关的位置。用户也可以 dismiss walkthrough，回到普通 diff。2

这个设计把 agent 的说明从“陪你读一遍”变成“给出一组可回跳的审查线索”。用户先读一个步骤，再看它指向的增删行，最后决定是否把相关 block 标为 Reviewed。解释因此不再是另一个需要相信的文本对象，而是审查现场里的导航层。导航层能减少寻找成本，却不能替用户判断代码是否正确；seendiff 也没有把 walkthrough 设计成自动批准入口。

seendiff 把数据留在本机：产品页面声明没有账号、遥测或 localhost 之外的网络调用；仓库还说明服务绑定 127.0.0.1，Git 拉取只有显式传入 --fetch 时才会发生。对不希望源代码离开开发机的用户，这个边界很有价值；对需要团队评论、在线协作或直接修改代码的人，seendiff 的只读定位则意味着仍要回到其他工具。12

所以，seendiff 的巧思不是再加一个 AI 审查按钮，而是先把监督对象定义清楚：滚动产生的是“看过”证据，按键产生的是“审过”判断，walkthrough 提供的是带行号的解释线索。AI 改码越多，产品越需要把这些状态和证据放在同一个可继续、可退出、可复核的路径里，而不是把全部责任压缩成一句“已完成”。