我一天要丢二三十条反馈：预览环境里截图、圈一块、打一句“第三个卡片，空态，文案顶出来了”。然后等它改。改完一看，它动的是第二个卡片。
它手里只有我那句口语描述，剩下全靠猜。
猜错的代价不是改错那一次，是我得回去重新描述一遍，而第二遍通常还没第一遍说得清楚。烦的是这个！
所以那些“AI 代码评审”工具我一直提不起劲。发现问题从来不慢，我自己一眼就看得见。慢的是把“我看见了什么”变成“它该改哪一行”。翻译成本，这才是贵的部分。
Nitzan Kletter 10 月 6 号发在 dev.to 上的 Maple 盯的就是这一段。开源，前端评审工具箱，拆成八个小包。他文章里标了 AI 辅助写作，我不太在乎，我在乎的是它把评论锚在哪。
构建期给每个 JSX 元素打上源文件、行号、列号，评论提交时定位到 file:line。⚡评论从“一段描述”变成了一个坐标。
不是我夸这个实现多优雅。是因为不这么干的方案我见得太多了：锚 CSS 选择器。听着挺聪明，可类名一改、结构一动、下次部署一过，评论就成了孤儿——它说的那个东西还在页面上，只是它已经不知道自己在说谁。file:line 至少是智能体能直接跳过去的坐标。
这一条我想说重一点：评论的价值不在于写得多详细，在于它落地的时候还指得准。
第二个让我停下来看的是 mock 状态。
评审这活儿有一半是在非正常路径上干的：打开空列表、打开 403、打开加载中，然后说这儿文案不对、这儿骨架屏抖了一下。这套上下文以前全在我脑子里。agent 拿到的是“空态文案太长”，它去正常路径里找空态，找不着，或者找一个不相干的。来回三轮，我火了，它也不知道错在哪。
Maple 让评审者用自然语言说想要什么状态——空列表、报错、没权限、加载中、一条数据、上千条——页面按对应的模拟响应刷一遍，评论把这个状态记在自己身上。智能体处理的时候能重新打开评审者当时抱怨的那个页面版本。
作者在评论区回了一个挺关键的细节：存的是 mock 指令，不是数据快照。empty、error、forbidden、loading 这类不随真实数据漂；“一条”、“上千条”这种基于真实数据构造的，会漂。截图是给人看的，状态是给 agent 的，这两件事他分开了。
这条我认。数据快照塞进评论里，评论迟早变成几兆的垃圾，而没人会为了修一个 padding 去下载几兆。
MCP 那边除了列评论、取单条上下文、标记已处理，还有一个是阻塞等新评论的。说白了就是让 agent 蹲在那儿，你评论一条它醒一次，不用每次手动去敲“我写完了，你看一下”。这个设计我喜欢，省掉的又是一个高频小动作。
装的时候不用注册，不用先申请 key。默认存储就是 PR 里那条 Maple 评论，更新时重发一条新的而不是编辑旧的，所以全新安装不需要任何额外基础设施。这是我这几年判断一个工具值不值得试的第一道筛子：装之前要先填两张表的，我基本就关掉了。Apache-2.0，链路上不依赖托管服务，MCP 服务器在官方 registry 里注册过，这些是加分项，不是决定项。
坑也得说。
0.18，公开开发中，0.x 阶段不承诺兼容，破坏性变更记在 changeset 里——意味着你现在把它塞进团队工作流，是要跟着改的。作者自己的待办里还有一条挺要命的：预览 Pod 里的文件存储会随 Pod 消失，评论跟着没。本地跑没事，评论以文件形式落在 .maple/ 目录下；上了预览环境就是隐患。
门禁我感情复杂。有未处理评论就阻止合并，这是让工具真被用起来的那个钩子，没有它，评审意见就是一条没人看的评论。可哪天赶上热修，你被自己的工具卡在门外，你会想砸键盘。评论区已经有人提了要留跳过通道，我看还没做。
想试的话就一行：
npx @maple-kit/cli review --port 5173
端口填你自己的本地 dev server。三分钟能跑起来，这条我保证。
花的成本老实说不好看：为了省下“是第三个卡片”那二十秒，我研究了一个下午怎么把评论锚到源码行，这比例听着挺傻的。但那个动作我一天做二三十次。一天二三十次乘以二十秒是十分钟，十分钟不多，丢的是注意力——每重新描述一遍“哪个卡片”，我都得在脑子里把刚才看见的东西再拼一次。
省下来的是这个。装完一天，回本。你要是也在天天给 agent 当人肉翻译，试试。有更快的写法，教教我。