Web Device 评审模式：所见即所得，当场 review

本地 Web Device 浮层，arc#4525 之后 · 本篇文章加 ?review=1 · 1440×900 · 2026-08-21。没选文字、没开 Page note 时，整页 chrome 就是这一块岛。状态条空着就被藏起来。

先讲一个你会遇到的下午

你在改一页产品 landing。lint、validate、check、build 全绿，PR 也过了。打开本地渲染出来的页面，还是觉得 hero 太空、某段在真实导航下面显得怪、中文版某一句突然太长。

问题不在「文件有没有写对」，而在读者会看到的那一屏。你脑子里的修改意见是 on the spot 的：「这里写长一点」「删掉这句」「换一个更具体的例子」。

以往这些话往往进了 PR 评论、Slack，或记在自己本子上。agent 看不到选区，也接不上「改哪一段」。

页面内评审模式做的就是这件事： 在所见即所得的成品页上，当场点选、当场写 review 建议；建议变成内容旁边的可执行指令，人和 agent 可以一起改，而不是你看页面、agent 只看源码，两边对不上。

它不是访客留言板，也不是又一套独立评论产品。本地给 URL 加上 ?review=1 才出现，给写作期用。

2026 年 8 月浮层换过一版。最早对外的那版是左下角 Page note 加一条一直挂着的状态栏，合同是对的，看起来像调试条扣在页面上。现在的玻璃岛还是同一份合同，只是不再抢戏。

完整操作合同见文档：页面内评审模式。下面用真实截图走一遍这个场景。

为什么必须对着「渲染后的页面」评

写 Web Device 站点时，自动化关卡擅长抓结构问题：DSL 错了、source 绑错了、链接断了、预渲染失败。

但有一类判断，关卡再绿也替不了你：

评审对象是浏览器里的成品页。页面内评审把「我看到了什么」和「我要它变成什么」写在同一处，并留给 agent 一条可执行的路径。

打开之后长什么样

本地跑起 blocklet（例如 arc blocklet run 或已有 arc service），在任意已渲染页面的 URL 后面加上：

?review=1

必须是字面量 review=1。写成 true 或 yes 都不会开。

右下角会出现一块磨砂玻璃岛，三个图标，不再分两个角落：

左下角那颗 Page note 没有了。状态条（Review: open · N planned / N done、语言勾、Approve page）还在浮层里；空的时候不显示，登录会话读到 .review/.actions/state 之后才填。匿名 ?review=1 仍然可以选字、开 Page note、写指令。

Point 默认是关的。这是故意的：评审一张活页面时，你得还能点页面上的真链接。

场景一：对某段文字写意见（锚定反馈）

同一环境。选中 “what-you-see-is-what-you-get page, leave” 之后，面板带上选中原文；类型是可执行动作，不是聊天标签。

选中时系统还会记下选区前后约 50 个字符，用 {selected} 标出位置。以后正文改了，仍可用这段上下文找回去，而不是只靠「整页第一次出现的同一句话」。

Point 是第二种动作，不是用来取代选字。先打开指针，再点带 data-aup-id 的节点（AUP 渲染出来的节点）。Shift / meta 连点可以加节点；拖框可以罩住多个，也可以罩住空白。2026-08-21 在这篇文章的 markdown 正文上数到 零个 data-aup-id，所以 Point 没有可悬停的目标；选字仍然可用。不要把 Point 理解成「任何页面随处一点」。

场景二：整页写一句（Page note）

有些意见不落在某一句上：「这一整页太长」「和上一张 landing 的骨架撞车了」。点岛上的气泡，不选文字也能提交。

Page note 不绑定选区。适合整体节奏、结构、跨页比较这类反馈。

画面只存在一瞬间时，用 Freeze

CSS 动画和视频不好评：你要写的那一帧，话还没写完就没了。Freeze 会暂停动画、transition 和 <video>。岛本身还活着，所以仍可以打开输入框。

Freeze 是评审辅助，不是 design mode，不会改 CSS。再点一次同一图标关闭（标签变成 Unfreeze）。

意见必须落在内容旁边

浮层只是循环的一半。Slack 里一张截图、复制出来的 selector、PR 上一条评论，都还是你看着页面、agent 看着文件。

Web Device 把意见写成文件，放在内容项旁边，agent 用的还是同一棵 AFS 树。你留下的是 instruction / delete / replace / insert-after / page-note，位置就是站点源码所在的位置。一段文字的身份是读者看见的那串字，加上前后大约五十个字符的 {selected} 上下文，不是指望下次改版还能对上的 CSS selector。

第一版浮层是对的，也吵。玻璃岛还是同一份合同，只是更安静：Point 要先打开，输入框贴在目标旁，Freeze 能按住一帧，空的状态条直接藏起来。这是 chrome 的变化，不是新产品。

提交之后：两级状态

登录会话能读 .review/.actions/state 之后，状态条会列出 open 项和摘要。你可以：

两级状态不要混：

新提交一条反馈时，若页面已经是 approved，会自动降回 open：签过字的页面不能在还有新意见时静默保持通过。

这次 2026-08-21 的截取是匿名的。上面的岛和输入框是活的；填满的状态条不在这些图里，因为空条会被藏起来，而且没有会话上下文就不会去拉条目。这是 chrome 事实，不是产品缺了一块。

意见存在哪里（为什么 agent 用得上）

反馈不进全站评论库，也不另起一套 HTTP API。它跟内容项同目录：

content/docs/web-device/overview/
  content.md
  content.zh.md
  .review/
    a1b2c3d4.md      # 一条反馈
    .status.md       # 页面级 open / approved

单条文件大致是：

---
status: open
type: page-note
locale: en
author: anonymous
created: 2026-08-21T…
---
Hero feels thin under the real header: add one concrete example.

锚定反馈还会多 anchor 与 context 字段。Point 出去的条目还可能带 aupId、bbox 或附近文本。locale 记录你提交时看的是哪个语言版本的 URL（多语言站点上很重要）。

本地可用 AFS 列出或读回（路径按你的站点名替换）：

arc afs ls /web/content-sites/<site>/collections/docs/web-device/overview/.review
arc afs exec /web/content-sites/<site>/collections/docs/web-device/overview/.review/.actions/state

agent 的工作流可以是：读 .review/ → 按 type 改 content.md → set-item-status 标 done → 人再 Approve page。

发布时 .review/ 不会进公开产物。 评审数据留在写作树；deploy 快照会排除名为 .review 的目录。公开访客也不会因为 URL 上碰巧带了参数就看到一整套可写评论面（可写内容面只在本地/开发工作流里）。

建议工作流（所见即所得 → 当场意见 → 一起改）

什么时候不该用

继续阅读