最开始没打算做一个"批注工具"。当时手上的原型都是直接导出成静态 HTML，放到 Vercel 上给团队看，唯一的问题是：怎么让大家一起在上面留反馈。
先试了几个现成的路子：Vercel 自带的团队评论功能要升级到 Pro；把原型嵌进文档用评论功能；或者接一个第三方反馈工具的嵌入脚本，一行代码就能加上悬浮的反馈按钮。选了最后一种，图省事，很快就跑起来了。
用起来之后才发现问题：这类工具的流程是"进工具截图、写反馈、再退出来"，看一页原型来回切好几次。留言这件事本身没有变简单，只是换了个地方做。
这句话之后，方向变了。不再是"接一个现成的反馈工具"，而是做一个常驻在页面上的批注层：点哪写哪，能连续标很多条，不用离开当前页面。多人写、一个人看，中间需要一个后端做同步。
批注最初的形式是"坐标打点"——记录点击位置的 x/y。后来意识到这样不够：如果这些反馈最终是要交给 AI 编程助手去改代码，AI 需要知道的是"改哪个元素"，而不是"页面上哪个坐标"。坐标带不了这个信息，于是批注升级成"点选具体元素"，自动记录下 CSS 选择器、元素文本和周边结构。
做到这一步，又出现一个新问题：这层批注逻辑是嵌进每个原型里的一段脚本，如果以后要分享给团队里其他人用，每次更新都要重新塞一遍脚本、重新部署。当时想的是——不如做成一个独立的浏览器插件，批注记在页面右侧的列表里，点哪条就跳到对应位置。
做成插件之后，随之而来的是一个更实际的问题：如果以后要把这个插件发给别人用，本地更新了是不是还要重新打包发一次？这个疑问后来直接变成了要不要上架 Chrome 应用商店的理由——上架之后，更新是自动推送的，不用再手动分发安装包。
中间当然踩了不少实际的坑：登录用的邮箱链接一度失效过；域名和另一个完全不相关的项目撞得很像，排查了好一阵才发现看错了地址；申请上架时因为权限声明得太宽，被要求走更严格的审核，收窄到"用户点击时才生效"之后才通过。这些不是这篇记录的重点，但都是真实发生过的。
回过头看，最后要解决的还是最开始那个问题：团队怎么一起在原型上批注、怎么把这些反馈变成能真正被执行的修改。只是路径拐了几次——从嵌入脚本到独立插件，从坐标打点到点选元素，从"发给别人要手动分发"到"上架商店自动更新"。每一次拐弯，都是被具体的麻烦逼出来的，不是提前规划好的。