Flunes什么时候选 Marker.io: 所有反馈都发生在一个你能掌控的网页上。 你想要钉在页面上的可视化标注和技术元数据（浏览器、操作系统、控制台）。 可视化截图标注是你评审流程的核心。
Flunes vs Marker.io
- 是，原生支持
- 部分，靠增购项
- 否，并非其职责
「部分」指可通过集成或付费增购实现，并非核心模式。
迁移到 Flunes 你能得到什么
你团队的反馈不只局限于某个你能往里加脚本的网站。
你希望提反馈的队友零安装、零账号。
纯文字报告（不需要可视化标注）就够用了。
你不想按内部席位付费。
你团队的反馈很少只待在一个站点上
来自你自己人的真实 bug 报告，往往出现在离某个已埋点网页很远的地方。测试在一个 TestFlight 构建里撞上崩溃，PM 在审阅一个 staging 链接时看到一处毛病，支持转述了某位队友在通话里提到的问题，设计师指出他在手机上看到的一处布局 bug。一个钉在单个生产站点上的 widget 永远看不到这些。作为 Marker.io 替代方案，Flunes 会从问题真正发生的地方接收一份纯文字报告，可选附一张截图，再把它送进正确的仓库，变成一条你的团队可以动手处理的干净 GitHub issue。
跳过 widget 的代价
拿掉页面内的 widget，意味着放弃它自动采集的元数据：浏览器版本、操作系统、视口、控制台日志。这是一笔实打实的取舍，对某些团队来说很重要。换来的好处是，你的队友什么都不用装，也不用建账号。PM、测试或设计师打开一条私密链接，写下哪里出了问题，提交就行。没有要嵌进你代码的东西，没有 script 标签，也不用给每个人开通登录。如果你对这些环境元数据的需要，胜过对团队里任何人随处都能无摩擦报告的需要，那 Marker.io 更贴合。
Flunes 不会做的事
保持诚实能让事情简单。Flunes 不会在线上页面上盖一层钉点标注，也不抓控制台或网络日志。它不是公开 roadmap，也不是投票看板，更不替代 GitHub 里的分流。它做的事很窄，而且是刻意的：接过一位非技术队友用大白话写的描述，再产出一条结构化、带标签的 GitHub issue。如果在网站上做像素级标注就是你评审流程的核心，那是 Marker.io 的活，不是它的。
常见问题
不能。Flunes 采集的是纯文字报告（可选附截图），不做钉在页面上的可视化标注，也不抓控制台。如果在网站上做可视化标注是核心需求，那 Marker.io 更合适。