两年前我说自己是AI时代的纺织工，今天我把这活开源交出去了！|命令提示符|快照|浏览器|纺织工|调用

两年前我发过一条动态，说我在给自己的网站做i18n翻译，明明早就可以用AI翻译了，但一大堆文章要通过对话方式跟AI沟通还是很烦人，长文本得自己截断，复制黏贴几次之后就觉得自己是AI时代的纺织工，不想干这种体力活了。

那会儿的解法是用Cursor快速做个小工具。现在回头看，那个解法大概只解决了一半，工具是做出来了，可打开网页、找到那个框、把东西粘进去、点提交、再看看它有没有真的提交上去，这一串还是我自己在做。体力活最重的那一段其实压在浏览器里。

昨天开源了huashu-mac-use，操控没有API的Mac原生app的那个。今天说另一个，huashu-chrome，操控浏览器的那个。这俩在我这儿的定位是一双眼和一只手，昨天讲的是眼，今天讲手。

先坦白一句，这个仓库其实上个月底就推到GitHub了，npm包也发了，只是一直没正经介绍过，所以今天算是补一篇正式的说明书。

https://github.com/alchaincyf/huashu-chrome

装法就一条命令，它会自己认出这台机器上装了哪些agent、把各自的配置写好，然后弹个引导页带你装扩展（装扩展这一下得你自己点，浏览器不允许脚本代劳）：

npx huashu-chrome install

Claude Code、Codex、Cursor、Gemini CLI这些都通用。装完你可以先拿一件小事试它，比如打开你自己的某个创作者后台，让它把最近十条内容的数据拉成一张表。这件事最能立刻看出它跟别的工具的区别，因为那个页面没有你的登录态压根打不开。

顺便回答昨天B站评论区那位朋友，他说我好多东西都是Windows用户没法用的。mac-use确实只能在Mac上跑，但这个chrome的是三个平台都适配过的，Windows和Linux的配置路径都写好了。

为什么是浏览器

我先说个可能有点反常识的判断：浏览器对agent来说不是一个信息源，是一个身份。

你让agent去拿网上的东西，它有一堆办法可以用，搜索、fetch、爬虫、各家的API，这些办法解决的都是同一个问题，怎么拿到数据。但你在工作里真正卡住的那些地方，卡住你的往往是另一件事：你得证明你是你。

公司的OA、内网的审批流、甲方给你开的那个后台账号、你自己的创作者中心，这些地方的东西谈不上难爬，它们是没有你的身份就根本不存在。你没法通过常规的fetch穿透进去，而能穿透的东西你其实早就有了，就是你此刻这个已经登录好的浏览器。

这是我的公众号后台，agent直接就进去了，没让我登录，也没问我要任何密钥。它用的就是我此刻这个身份。

创作者后台也一样。这类页面对任何不带登录态的工具来说都是一堵墙，而对你自己的浏览器来说它就是首页。

所以这个东西的独特价值不在于能打开网页，在于带着你此刻的登录态打开网页。不用API key，不用重新登录，用的就是你正在用的那个身份。

纺织工的活到底长什么样

说抽象的没意思，说几件我真拿它干过的事。

第一件是填法签的申请表。

办过签证的应该都懂这个痛苦。先注册账号，人机验证转半天，勾了个盒子发现状态又被切回去了，再点一次；注册成功，激活邮件到邮箱，去点激活链接；然后开始填表，填到一半发现因为前面选了「采过指纹」，表单又多长出来两个字段；好不容易填完点提交，提交触发了页面重渲染，出行目的那一栏被清空了，重选一次再提交；提交成功回到申请人列表，好，还有第二个申请人，整套再来一遍。

这是agent干这件事时的样子，一共53分钟，我在旁边干别的。

这就是纺织工活最标准的形态：每一步都不难，难的是它有四十步，而且第八步会悄悄出错。

中间有一下它没自己做，是那个图片选择题的验证码。它把账号密码填好，然后在页面右下角浮出来一条，告诉我验证码归我，我点完它继续。

这个设计我自己挺满意的。能不能识别验证码其实是个很次要的问题，要紧的是它知道自己该在哪一步停下来问人。经验库里关于某个签证中心的记录里有一条结论，写的是：这个站的号源、登录页、注册字段，agent拿不到，必须让真人自己点一下那个复选框，别再浪费回合重试。一个知道自己边界在哪的工具，用起来比一个什么都硬试的工具省心得多。

第二件是花录上架App Store。

花录是我前段时间上架的第一个macOS App，那次提审的元数据全是agent在App Store Connect的网页上填的。这活的形状是这样的：7种语言，每种语言5个字段（描述、新增内容、关键词、名称、副标题），一共35处，字段还分在两个不同的页面上，漏一处就是某个语言的商店页残缺。

这里有个坑挺值得说的。那个后台的表单，你把字填进去了，页面上也显示出来了，工具那边还报了「已设置」，但它其实一个字都没存住。所以真正可靠的做法是每填一项就刷新页面重新读一遍，不信任何写入时的返回值。

顺着这条往下说，就到了我做这个东西时真正在处理的核心问题。

核心问题一：它说做完了，其实没做

浏览器agent最大的问题很少是点不准，基本都是工具返回成功、页面其实没动。

一个三十步的任务，第八步悄悄失效了，后面二十二步全是在垃圾上继续操作，而没有任何人知道。上面那个填了却没存住是一例，法签表单里提交一次就把选项清空是另一例，一个是写进去了没生效，一个是生效了又被吃掉。

所以这里每一个动作做完，都不允许只回一句「已点击」，必须交待页面到底有什么反应：状态从关变成了开、正文多了29个字、还是整块内容被换掉了。没反应也要明说没反应，并且告诉agent可能是哪几种原因。

这里有个我想了挺久才想明白的地方：这个判定只回答页面动没动这一个确定性问题。至于这一步算成功还是算失败，那得理解意图，是模型该干的事。工具一旦越界去猜成功失败，agent反而会被它误导，这个亏我吃过。

还有一个容易被忽略的。表单流程最常见的失败其实是校验错误，而校验提示常常出现在长页面的下方，agent根本翻不到那儿。所以页面上所有的报错提示会被单独拎出来放在最前面。没有这一段，「已提交」和「被校验拦下」在它眼里长得一模一样。

核心问题二：慢

这个问题的起点是我自己的抱怨。今年三月我发过一条，说视频评论太多回不过来，想让agent去自动回复，不管是Claude Code还是别的，基本上都是太慢太笨了，最后还是让它给我开发了个浏览器插件来干这事。

慢在哪呢？我翻了翻本机最近七天的日志，agent一共调用了四千多次，而两次调用之间的空档中位数是6秒多，那6秒里浏览器其实是闲着的，忙的是模型，它在想下一步该干嘛。

一个点开始、填手机号、勾同意、下一步的流程，逐个调用就是四次思考、四份页面快照，而中间那三份快照压根没有任何人读，agent在发出第一个点击之前，就已经知道后面三步要干什么了。

所以这里有个批处理，让它一次说完。它跟一个盲目执行的宏还是有区别的，每一步都验过效果才走下一步，任何一步没反应就当场停下来，把做到哪、为什么停、还剩什么讲清楚。另外提交、支付、删除、发布这类动作它永远不代做，一串动作里夹一个它，跑完了中间没有任何人看得见。

从日志上看，写操作里有四成走了批处理这条路。

核心问题三：它得越用越快

陌生网站上试错是这类工具最大的时间成本。同一个飞书多维表格的任务，第一次从零摸索用了281次调用、54分钟；把摸清的规律记下来之后，第二次不到10次。

所以它每干完一个站，就把学到的东西存回本机：这个站的数据在哪个接口里、字段叫什么名、哪堵墙翻不过去、哪个坑必踩。下一个agent进来先读它。我这台机器上现在攒了39个站的记录。

举几条真实的，都是撞出来的。某个跨租户的协作文档，在后台标签页里读永远只能读到第一屏，必须先把它调到前台；12306查余票不需要登录，可你必须在浏览器里发请求，命令行直连拿不到；X的用户时间线接口不叫你以为的那个名字，而且它的搜索索引只覆盖最近三十天，早于三十天的查询返回的是空，不是结果少。

这些东西的共同特点是查文档查不到，只能撞，而撞一次记下来，就再也不用撞第二次了。

不过经验这东西有个前提，我把它写进了每一条记录的开头：经验是提示，不是规则。站点会改版，接口会失效，与页面实际不符时一律以实际为准，然后顺手把记录改对。

巧的是就在写这篇文章的时候，我顺手验了一条自己记过的经验，那条写着某个政府网站封了常规的抓取工具、只能走浏览器，结果一测，人家早就不封了，用最普通的方式就能读到。那条记录曾经是对的，可站方改了策略之后它就变成了误导，会让后面的会话白开一次浏览器，所以我当场把它改掉了。

顺序也是设计出来的

还有一条挺重要但容易被忽略的，是agent面对一个陌生网页时该按什么顺序出牌。

一个网页把信息放在三个地方：网站自己的数据接口里、页面的结构里、和最终渲染出来的画面里。正确的顺序是先看接口，要动手才看结构，看画面放到最后。

为什么呢？因为接口里的字段名是网站自己写的，不用猜。屏幕上五个数字糊在一起，你照常识猜哪个是播放量哪个是收藏量，大概率三个是错的，而接口返回里它自己标着名字。我在经验库里记过一条更极端的，某个电商的搜索结果里有个字段是「近30天多少人看过」，agent要是照常识去猜，很容易把它当成销量报给你。这是一个不会报错的错。