夜雨聆风我花了差不多一周时间，写了一套用Playwright来自动化公众号文章的发布。
脚本要做的事情包括，打开微信公众号后台，填标题，填摘要，把排好版的HTML正文粘贴到编辑器里，然后找到文章中的图片占位符，把配图一张一张替换进去。
看着简单，但真正的痛苦在于，微信编辑器用的是ProseMirror，不是普通的文本框。你不能直接Ctrl+A选中一个占位符然后替换，因为ProseMirror会把你的整个正文全选中。你得用Selection API精确选中那个特定的节点，先删掉，再粘贴图片进去。光这一步，我前后调了三天。
然后DOM结构一变，选择器全崩。微信后台哪天心血来潮改了个class名，我的脚本就得跟着改。
然后5月7号，OpenAI在Chrome商店里上架了一个插件。
它做的事情说起来很简单也很疯狂，让Codex直接操作你浏览器里所有已登录的网站。不是打开一个新窗口，不是启动一个无头浏览器，就是用你正在用的那个Chrome，带着你所有的登录状态，直接上手干活。
我一开始看到这个消息的时候，反应比较平淡。因为Codex四月份那次大更新已经加了Computer Use，能操控整个电脑了，Chrome插件听着像是那次的延伸版本。
但我仔细研究完之后发现，这俩完全不是一回事。而且这个差异，恰恰是让我这个Playwright老用户有点破防的地方。
先说说这个插件到底是什么。
核心逻辑特别简单。你在Chrome里装上这个插件之后，在Codex里用 @Chrome 命令告诉它你要干嘛就行。比如「帮我打开Salesforce，把刚才会议记录里的客户信息更新进去」，或者「帮我在Workday里提交一个请假申请」。
Codex就会去你的Chrome里干活。它能导航，能看页面内容，能点击按钮，能输入文字，能截图。基本上你手动在浏览器里能做的操作它都能做。
最关键的是，它是在你真实的浏览器环境里干的。你的cookie，你的登录状态，你的session，全都现成的。所以它完全不需要像Playwright那样先走一遍登录流程、存cookie、管理session。你本来就是登录着的，它直接用。
而且Codex会为每个任务创建独立的tab group，所以你正在看的东西不会被搞乱，任务的页面都归拢在一个组里。做完了还留着给你检查，不像有些自动化工具跑完就把窗口全关了，你都不知道它到底干了啥。
安全这块OpenAI做了个权限模型，每次Codex要操作一个新网站，都会先问你允不允许。你可以选只允许这一次，也可以选「以后这个网站别再问了直接用」。还有白名单和黑名单，在设置里可以管理。
不过我得说实话，这个插件申请的权限是真的多。读取所有网站的数据，访问页面调试器，读取浏览历史，管理下载，管理标签页。看着挺吓人的。但想想它要做的事情，确实需要这些权限才能操控浏览器。反正每次操作新网站它都会问你，不至于背着你去干坏事。
说到这块有个细节我觉得挺有意思。OpenAI在设计这个的时候，其实是把浏览器能力分了三层。第一层是Codex自带的in-app browser，用来做本地开发服务器预览和公共页面访问，不需要你的登录状态。第二层就是这个Chrome插件，专门用来操作你已经登录的网站。第三层是Computer Use，直接操控整个操作系统。
三层各有分工，不是谁替代谁，而是根据任务自动选择最合适的工具。你在Codex里说一句话，它自己判断该用哪一层。
好，到重点了。这也是我自己最关心的部分。
我做公众号自动化发布的流程已经快两个月了，用的就是Playwright。整个流水线从选题扫描到排版到发布，Playwright负责最后一步。所以我对Playwright的优缺点，是真的有切肤之痛。
两种方案的核心差异，我一个个聊。
先说登录状态。这是最直观的区别。
Playwright启动的是一个全新的浏览器实例，坦率的讲就是一个什么都没登录过的空白浏览器。你要让它操作需要登录的网站，就得自己处理整个登录流程。保存cookie，管理session，处理验证码，全得你自己写代码。
我做公众号发布的时候是怎么搞的呢。先让Playwright启动一个浏览器实例，手动登录微信公众号，登录完了把session保存下来，下次运行的时候复用这个session。但session会过期啊，过一阵子又得重新登录。这种感觉很蛋疼，你明明自己打开Chrome就能看到已经登录的公众号后台，但Playwright就是用不了那个登录状态。。。
花了那么多时间处理登录态管理，结果打开Chrome一看，它就在那儿。
Codex Chrome插件呢。你Chrome里本来就是登录着的。它直接用你现有的浏览器状态。不需要额外处理登录，不需要管理session，不需要担心cookie过期。
这一项就省了不知道多少麻烦。
再说适应性。这个差异更致命。
Playwright是确定性工具，你写了一个脚本，它严格按照你写的逻辑执行。点击ID为submit-btn的按钮，填写class为title-input的输入框。选择器写对了，每次完美执行。选择器写错了，或者目标网站改了DOM结构，换了个class名，加了一层嵌套div，脚本直接崩。
我上个月就碰到了。微信后台悄悄更新了一版编辑器，我的CSS选择器一半失效了。排查加修复花了一整个下午。那种感觉特别无奈，你的脚本逻辑完全没问题，就是因为别人的页面结构变了，你就得重新适配。
Codex Chrome插件走的是完全不同的路。它不是靠选择器定位元素的，它是用AI理解页面内容。它能「看懂」这个页面上哪个是标题输入框，哪个是提交按钮，哪个是文章编辑区域。即使页面结构变了，只要功能还在那个位置，它大概率还是能找到正确的元素。
怎么说呢，Playwright是按地图走的，地图一变就迷路。Codex是看路牌走的，路牌挪了个位置它也能认出来。
然后是开发门槛。这个差异太直观了。
Playwright你得会写代码。Python也好TypeScript也好，你得理解选择器、等待策略、异步编程、错误处理。写一个靠谱的自动化脚本，光是把各种边界情况处理完，代码量就不小。我这个公众号发布脚本，光是发布那一个环节就写了三四百行。
Chrome插件呢。你告诉它你要干嘛就行。自然语言，一句话，不需要写一行代码。
说到这个我得坦率的讲，这个门槛差异真的不是一点点。我是个非技术背景转行做AI产品经理的人，学Playwright的时候是硬啃的，DOM、CSS选择器、异步这些概念对我来说全是新东西。如果当时就有这个Chrome插件，我大概率根本不需要花那么多时间去学Playwright。
但也得说句公道话，Playwright有它不可替代的地方。
速度，Playwright脚本跑起来是真的快。它直接跟浏览器通信，走CDP协议，每一步操作都是确定性的，不需要AI去理解页面再判断该干什么。对于一个稳定的、不变的目标网站，Playwright的速度和可靠性远超AI方案。
Chrome插件每次操作都需要AI去理解页面内容，判断下一步该干什么，这个过程天生比执行预定义脚本慢。而且AI有判断失误的可能，它可能点错按钮，可能理解错页面内容。
还有调试。Playwright脚本出了问题，你去看日志，看报错信息，定位到具体哪一行代码出错了，排查逻辑很清晰。Chrome插件出了问题，你说一句「刚才那个操作好像不对，重新来一遍」就行了。不需要改代码，不需要看日志，就是再跟它说一遍。维护成本几乎为零，但排查过程没那么精确。
所以如果要用一句话总结的话，Playwright是「快但脆弱」，Chrome插件是「慢但皮实」。
那我自己到底怎么选呢。
固定、高频、已经稳定的流程，继续用Playwright。比如我这个公众号发布，流程是固定的，代码已经写好了，跑得也稳定，没有理由换。
但那些临时性的、需要登录状态的、目标网站可能变化的任务，以后我大概率会直接用Chrome插件。比如帮我在某个后台查个数据导出来，比如帮我对比几个网站的信息做个汇总，比如帮我在一个不常用的系统里填个表单。这些任务以前我得写一次性的脚本，写完了可能就用那一次，投入产出比太低了。
我觉得很多人的情况应该跟我差不多。你手头有一堆「如果能自动化就好了但又懒得写脚本」的事情，现在有个工具能让你直接说一句话就搞定，这个体验差别是很大的。
浏览器自动化这件事，正在经历同样的变化。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章，我们，下次再见。
/ 作者：夏尔AI
/ 邮箱：435452239@qq.com
