Crit - 给 AI agent 输出加一个本地浏览器评审回路
AI coding agent 让修改速度变快了，但评审方式往往还停留在终端里。Agent 一口气改了十几个文件，人类在 diff 里滚动、复制路径、描述哪一行有问题，再把意见粘回聊天窗口。这个流程能用，但很容易漏掉视觉问题、上下文问题和细小的状态回归。
今天推荐的 tomasz-tomczyk/crit 试图把这个反馈回路做成一个本地浏览器界面。它可以打开代码 diff、Markdown 计划、运行中的 localhost 页面或静态 HTML 文件，让你像在 PR review 里一样点选行号、框选范围、给页面元素打点批注，然后把这些评论交给 agent 继续修。GitHub 页面当前显示项目约有 352 stars、29 forks，主要语言是 Go，许可为 MIT。仓库创建于 2026 年 2 月 16 日，最近仍在 2026 年 5 月 27 日更新；最新 release 为 v0.15.3，发布时间是 2026 年 5 月 20 日。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | tomasz-tomczyk/crit |
| Stars | 约 352 |
| Forks | 29 |
| 主要语言 | Go |
| 许可 | MIT |
| 创建时间 | 2026 年 2 月 16 日 |
| 最近更新 | 2026 年 5 月 27 日 |
| 最新 release | v0.15.3 |
把“看 diff”变成可操作的 review
Crit 的核心价值不是替你判断代码对错，而是让人类的反馈更精确。它运行后会在本地启动浏览器界面，展示 agent 的输出，并把评论挂到具体位置上。对代码来说，这就是熟悉的逐行 review；对文档来说，可以直接指向某个段落；对网页来说，可以在渲染后的按钮、表单或布局区域上打点。
这比在聊天里说“上面那个函数有问题”要可靠。Agent 收到的反馈不再是模糊描述，而是带有文件、行号、选中文本或页面坐标的评论。人也不需要在终端、浏览器、编辑器和聊天窗口之间反复复制上下文。
README 里把它概括成一句很朴素的话：指向那一行，告诉 agent。这正是很多 agent 工作流缺的那一层人机接口。
四种评审模式覆盖不同产物
Crit 没有只把自己做成代码 diff viewer。它提供四种入口：
crit自动检测当前分支的改动，展示语法高亮 diff；crit plan.md评审 Markdown、计划、规格或多份文档；crit http://localhost:3000代理运行中的本地页面，在 live 页面上添加 pin comment；crit landing.html直接渲染静态 HTML artifact，不需要 dev server。
这个分类很贴近 AI agent 的真实产物。Agent 不只是写代码，还会写计划、改页面、生成一次性的预览文件。传统 terminal diff 对这些产物并不友好，尤其是 UI 工作：CSS 改动是否让按钮偏移、移动端元素是否遮挡、文案是否挤出容器，只看 diff 很难判断。
Live 和 Preview 模式把视觉反馈也纳入同一套评论系统，让“这个按钮太靠右”这种意见可以落到具体元素上。
评论文件留在本地，回路不绑定云服务
Crit 默认是本地工具。它启动本机服务，绑定 127.0.0.1，评论数据保存在 ~/.crit/reviews/。这意味着评审回路不一定要经过外部 SaaS，也不需要把工作区内容上传出去。对于处理私有代码、内部计划或还没公开的页面，这个默认边界很重要。
它也提供分享能力，可以把 review 上传到 crit.md 或自托管的 crit-web，适合异步评审。但 README 里把 sharing 做成显式动作，并说明可以通过配置关闭。这种默认本地、按需分享的设计，比默认把所有上下文发到远端更适合开发者工具。
如果只是单人让 agent 迭代代码，完全可以只使用本地 review 文件。多人协作时，再打开 share 或 GitHub PR sync。
Agent 集成是它的重点
Crit 明确面向 AI agent，而不是只面向人类 reviewer。它支持 Claude Code、Cursor、GitHub Copilot、OpenCode、Codex、Gemini、Qwen、Hermes、Windsurf、Cline、Grok、Aider 等工具，只要 agent 能读文件、运行命令，就能接入这个回路。
常见用法是在 agent 工作完成后调用 /crit 或运行 crit。人类在浏览器里添加评论，agent 再读取评论文件继续修。Crit 还提供 crit comment，让 agent 可以用命令行创建结构化评论，而不必手写 JSON。
更进一步的实验能力是 agent_cmd。配置后，浏览器评论线程可以把某条评论直接发送给 agent，agent 的响应会回到 thread 里；如果 agent 修改了文件，Crit 通过文件监听更新 UI。这个功能仍然应该谨慎使用，因为它涉及让本地 agent 执行命令，但设计上已经把 agent_cmd 限定为全局配置，避免项目级配置劫持命令。
Round-to-round diff 适合反复打磨
Agent 工作不是一次性提交，而是多轮迭代。你指出一个问题，agent 修改；你再看修改是否引入新问题。Crit 的 round-to-round diff 正是为了这个节奏设计的。每轮修改后，它可以展示上一轮到当前轮的变化，并支持 split / unified diff 切换。
这对批量改动特别有用。直接看最终 diff 时，很难分清哪些是第一轮生成的，哪些是根据评论补的。Round-to-round diff 把反馈后的变化单独显出来，reviewer 更容易判断 agent 是否真正处理了问题，还是只是绕开了表面描述。
评论也支持单行和范围选择，形式上接近 GitHub PR review。熟悉代码评审的人不需要学习一套新的批注语言。
v0.15.3 关注细节体验
最新 release v0.15.3 的变化不算激进，但能看出项目正在打磨真实使用中的摩擦点。发布说明提到新增 heading anchor link 和复制能力，用于更容易指向文档中的章节；也修复了 daemon 连接失败时日志不够可见、配置 host 没有在启动信息和内部请求中正确使用、pin highlight 影响滚动页面等问题。
这些都是 review tool 会很快遇到的边角问题。一个评审界面如果自己抢滚动、报错不清楚、host 配置表现不一致，人会很快回到原来的终端 diff。Crit 近期版本把这些交互细节列入 release，说明作者关注的不是单纯能跑，而是能不能在多轮 agent 工作里少打断人。
适合什么场景
Crit 适合已经把 AI agent 放进日常开发流程，但仍然想保留人类把关的人。
典型场景包括：
- agent 一次改动很多文件，需要像 PR 一样逐行评审；
- agent 先写计划或规格，人类想直接在 Markdown 段落上批注；
- 前端页面由 agent 调整，需要在真实渲染界面上指出视觉问题；
- 想把本地 review 评论同步到 GitHub PR，或者从 PR 拉回评论；
- 团队想给 AI 生成代码建立“先评审，再继续”的节奏；
- 不想为了内部评审把私有代码和草稿默认上传到云端。
如果你只是偶尔让 agent 改一行脚本，Crit 可能显得多余。它真正解决的是多文件、多轮、人类反馈密集的场景。
需要注意的边界
Crit 不是静态分析器，也不是自动代码审查模型。它不会替你发现所有 bug，而是改善人类把问题反馈给 agent 的界面。因此最终质量仍然取决于 reviewer 是否认真看、测试是否覆盖关键路径、agent 是否正确理解评论。
Live mode 代理本地页面时，也要理解安全边界。默认绑定 loopback 是合理的；如果你把 host 改成 0.0.0.0 暴露到局域网，就要自行承担访问控制风险。
另外，agent_cmd 让评论能直接触发 agent 行动，这在可信项目中很方便，但不应该随意在陌生仓库里开启高权限命令。Crit 把这个配置限制在全局文件，是一个好的防护点，但用户仍然要决定权限模式。
总结
tomasz-tomczyk/crit 的方向很清楚：让 AI agent 的输出进入一个更像代码评审、更适合视觉反馈、更容易多轮迭代的本地界面。它没有假设 agent 会自动写对一切，而是认真承认人类仍然需要指出问题，并把“指出问题”这件事做得更精确。
如果你的 agent 工作流已经从“写一个函数”发展到“改一组文件、生成页面、维护计划、反复修正”，Crit 是一个值得试用的小众工具。它把人类 review 从聊天文本里拉回具体位置，也让 agent 更容易收到可执行的反馈。