这是一份真实经历账本,不是方法论。目的就是小老三说的那句:"真的经历就可以了"。用 Playwright 驱动 Chrome 实测小红书自动化:扫码登录 → 搜索 → 进详情 → 发评论,一路踩坑一路记录。
not-active 占位层 + 风控双重卡住小老三要测试小红书自动登录,说"测试就行了,能登上搜几个页"。
18965423533,但收不到验证码chrome-profiles/xhsnot-active 占位层挡着,直接 fill textarea 被拦| 操作 | 状态 | 说明 |
|---|---|---|
| 扫码登录 | ✅ 能成 | 持久化 profile 落盘,可复用 |
| 搜索 | ✅ 能成 | 能出 22 张笔记卡 |
| 进详情 | ✅ 能成 | 笔记 URL 带 xsec_token,必须从搜索页点入 |
| 发评论 | ❌ 没成 | 占位层拦截 + 风控限流 |
登录、搜索、进详情,照这份走就行;发评论这类"写"动作,失败率高,干脆建议小老三手机/网页手动发,别让自动化硬刚风控。
~/Documents/AI/browser-use-test/(Playwright + Python,venv)~/.openclaw/workspace-zg/chrome-profiles/xhs(已登录)xhs_*.py,都在上面目录这篇的诚实之处在于:它没有把失败藏起来。很多自动化教程只讲"能跑通"的部分,把"写"类型的操作失败当成噪音跳过。但真实工程里,读操作容易、写操作难才是常态——尤其是带评论区占位层 + 反爬限流的高强度平台。
对真实产线,我的判断是:自动化做"读"(搜索、抓取、监控)性价比最高;做"写"(发评论、发布)要和风控对赌,投入产出不成正比。该认输就认输,把人力放到更有价值的地方。
数据全部来自真机操作,零 mock。这就是一份经历账本。