ruttl允许您编辑正在审核的页面。
Snag打开了修复此问题的拉取请求。

ruttl 是一款网站评审工具，而且字面得少见：评论钉在实时页面的像素上，文字、对齐和图片都能在你注视着页面时于浏览器里改掉。Snag 站在这条线的另一端。实时页面上的任何东西都不会被动到：被记录下来的是浏览器做了什么——DOM 被回放出来，旁边是控制台和失败的请求——再归档成 Jira 或 GitHub 里的一张工单。个人数据在上传之前就已在浏览器中屏蔽——输入内容绝不会被记录。改动本身出现在代码仓库里，形式是一个带着复现测试的拉取请求，该测试在修复前失败、修复后通过。

他们确实很好

在实时页面编辑这件事上，ruttl 确实领先于 Snag：内容、对齐方式和图像都直接在浏览器里改动，而 Snag 的修复运行只会生成一份供人审阅的差异。ruttl 的移动 SDK 可以在你自己的应用内部报告缺陷，并一并记录操作系统和应用版本，而 Snag 只记录浏览器会话。ruttl 的集成列表包含 Jira、Slack、Trello、ClickUp、Zapier、Asana 和 Unsplash，而 Snag 连接的是 Jira 和 GitHub。如果你收集到的反馈是关于文案和排版而不是关于代码的，那么 ruttl 做的是 Snag 并不尝试去做的事。

Snag不同之处在于

在浏览器里做出的改动，仍然要由某个人写进源码，别人才看得到。Snag 直接从源码这一端开始。填满工单的捕获内容，正是编码代理读的东西：它在你代码仓库的一次性副本里重现故障，加上一个在今天这份代码上失败、改动进去之后通过的测试，然后把这一整套作为拉取请求提交评审。没有人点头就不会合并，沙箱在运行结束时销毁。走不到拉取请求的运行按一半计费——让尝试比成果便宜是有意为之——而每个套餐的前 5 次修复都免费。

该选哪一个呢？

如果反馈说的是客户正看着的那个页面上的文案、排版和图片，而且能就地改掉它比代码仓库里发生什么更值钱，那就选 ruttl。如果报告的是缺陷而不是改稿，如果接手的人接下来读的是调用栈而不是评论，而且不该因为多来了两个人账单就动，那就选 Snag。

Snag和ruttl，并排

每个ruttl单元格都链接到我们阅读它的页面。

人们实际会问的问题

Snag可以完全替代ruttl吗？

不太算，因为它们瞄准的是这份工作的不同一半。在 ruttl 里，主角是实时页面：评论钉在像素上，内容、对齐和图片都能在你注视着页面时于浏览器里改掉。Snag 从不碰你正在看的这个页面。它记录的是浏览器做了什么——DOM、控制台、失败的请求——然后把这些归档成 Jira 或 GitHub 里的一张工单。个人数据在上传之前就已在浏览器中屏蔽——输入内容绝不会被记录。它提出的改动改为落在代码仓库里，形式是一个需要有人接受的拉取请求。如果你收集的反馈是关于文案和排版的，这两者并不互为替代。

Snag的定价与ruttl的定价相比如何？

这是性质上的差别，不是数量上的差别。ruttl Pro 套餐按人计价：按月计费时每人每月 18 美元，按年计费时每人每月 15 美元，所以账单跟着人头走。Snag 根本没有按人计费这一项：计价单位是工作区，加进来一名设计师、一位测试负责人，或者一个只待两周的外包，账单纹丝不动。套餐计量的是修复运行次数，以每月额度的形式出售。今天的具体数字在首页的定价部分。

ruttl 把 MCP 放在 Pro 套餐上。Snag 把它放在哪里？

差别在层级，也在分工。ruttl 的常见问题把 MCP 连接和令牌生成放在它的 Pro 套餐上，他们的 MCP 页面描述了由此打开的闭环：你自己的编码代理接走一张工单，并在你的代码里把它修好。Snag 这边，服务器从 Capture 套餐起就随附，而且只读：它把捕获内容交出去，不写回任何东西，因为“写”是修复运行做的事，而修复运行本来就在你买的东西里。两条路在这里都受支持。把你自己的代理指向服务器，或者让内置的运行接手。

修复运行拿不出拉取请求时会怎样？

按一半计费，而且它一路上收集到的证据仍然归你。真正走到终点的运行会给你三样东西：差异、一个在当前这份代码上失败、改动进去之后通过的复现测试，以及代理据以推理的捕获内容。全过程都在你代码仓库的一次性副本里进行，运行结束时销毁，结果随后等着有人来读——没有人点头就不会合并。任何套餐的前 5 次修复都免费，所以头几次无论如何都不花钱。

这些细节的来源

本页上的每个ruttl详情都链接到我们最初阅读该ruttl页面，并附有阅读日期。如果某些内容已过时，请发送电子邮件至 admin@dvcllc.io，我们将予以更正。