夜雨聆风这次做 Visual RFC Runner，不是因为想再造一个评审系统，而是因为我越来越明显地感到：现在很多方案文档正在失去“被认真看完”的机会。
以前方案主要是人写，虽然也长，但长得有取舍。现在大量内容都是 AI 生成的，动不动就是几千字、几十个小标题。看起来完整，实际上人很难持续读进去；读完以后，也很难判断哪一段是真的有用，哪一段只是“生成得很像方案”。
所以我想换一种表达方式。
HTML 比纯文本更适合表达复杂信息：可以有结构、有布局、有状态、有图、有交互。一个流程图、一个原型页面、一个可点击的说明页，往往比一大段文字更容易让人进入问题。
但 HTML 带来另一个问题：评审时很容易说不清楚。
你看到页面上某个地方不对，需要让 AI 改。正常对话里只能说：
“这里不太对” “右边那个卡片太重了” “这块逻辑应该往前放” “刚才那个框里的文案换一下”
人知道“这里”是哪儿，AI 不一定知道。下一轮修改时，我还要重新描述位置、回忆上下文、解释大概想改什么。描述不准，就可能改错；改错了，再继续解释。这个过程很消耗。
所以我做了一个很轻的本地批注工具：让反馈直接落在页面上。
它解决的问题
Visual RFC Runner 想解决的不是“AI 能不能写 HTML”，而是“人看完 HTML 以后，怎么把意见准确交还给 AI”。
它把评审拆成三个动作：
这样一来，反馈就不是一句悬空的自然语言，而是带着位置、类型、状态和原文上下文的结构化输入。
我希望它保持轻量。它不接管项目，不变成一个新平台，也不把工作流搬到云端。真正理解上下文的还是 Claude Code / Codex 当前会话；浏览器只是一个 companion，负责把人的视觉反馈采回来。
现在能做什么
目前这版主要有几类能力。
第一，可以注入到真实页面。如果本地已经跑着一个前端页面，或者打开了一个 HTML 原型，工具可以通过 CDP 把批注脚本注入进去。用户看到的还是原来的页面，只是右上角多了批注工具。
第二，可以按元素、文字、区域写意见。有时候问题是某个按钮，有时候是一段文案，有时候只是视觉区域不舒服。批注不应该只支持一种粒度，所以它支持点元素、选中文字、框选区域。
第三，批注会落到项目里。每条意见会写成本地 JSONL，而不是只存在浏览器里：
.visual-rfc/sessions//comments.jsonl这点很关键。因为 Agent 下一轮真正要读的不是截图，而是一组可以定位、可以过滤、可以标记状态的批注记录。
第四，它支持状态流转。批注可以区分 open、resolved、question 这类状态。这样不是所有意见都挤在一起，而是能逐步形成一轮评审闭环。
大概怎么做的
实现上，我刻意把它拆成两半。
一半在浏览器里。这部分负责展示工具栏、监听点击/选区/框选、记录 DOM 线索、把批注发给本地 companion API。它不负责理解项目，也不负责改代码。
另一半在当前项目里。CLI 负责启动本地服务、注入脚本、保存批注、导出上下文。Agent 读取这些批注，再结合项目代码、文档和当前任务来决定怎么改。
它的核心边界是：
浏览器只采集反馈，Agent 负责理解和修改。这个边界对我来说很重要。因为如果把浏览器 companion 做得太重，它就会变成另一个“需要维护上下文”的地方。那反而增加了协作成本。
一次评审闭环
一次典型使用大概是这样：
这件事看起来很小，但体验差别很明显。
以前我要把“看到的问题”翻译成一段文字，再让 AI 根据文字去猜页面位置。现在我只要在页面上点一下，把意见写在那个地方。它更像是把设计评审里的红线批注，搬到了本地 Agent 工作流里。
我为什么觉得它有必要
现在 AI 很擅长生成内容，但生成内容太容易以后，真正稀缺的反而变成了人的注意力。
如果方案还是大段大段文字，人看不过来，AI 也不知道人到底在哪一段失去了耐心。最后就会变成一种假工作量：内容很多，沟通很长，但有效反馈很少。
可视化评审想把这个问题往前推一步：
先用 HTML 把方案表达得更直观。 再让人的反馈直接绑定在视觉对象上。 最后让 Agent 拿到结构化批注，而不是猜一句“这里”。
这不是要替代文档。恰好相反，它是希望文档变得更可读、更可评审、更容易被修改。
对我来说，Visual RFC Runner 的价值就在这里：它不是让 AI 生成更多东西，而是让人更容易指出“哪些东西真的需要改”。
下载体验
visual-rfc-runner-0.1.0.zip （阅读原文）
解压以后里面有安装说明和版本说明。Claude Code / Codex / Code X 这类 Agent 拿到包以后，也能通过 AGENTS.md、CLAUDE.md、INSTALL.md 判断怎么安装和验证。