最近清理微博主页翻到十年前发的那些转发、打卡、半夜emo真是想找个地缝钻进去。删掉吧舍不得留着吧又不想让新关注的人看到唯一能两全的办法就是设置成“仅自己可见”——微博用户的黑话叫“自见”。手动一条条设置点开更多、找菜单、确认每条至少四五次点击我手里还有三百多条要处理想想都绝望。刚好那阵子一直在玩 Vibe Coding就是用自然语言怼着AI让它写代码的玩法索性花了一个小时让AI帮我写了个批量隐藏微博自见的脚本几分钟把历史微博全部处理完。这篇不是教程文档记录一下这个真实的 Vibe Coding 项目怎么做下来需求怎么拆、方案怎么选、和AI怎么一来一回把它“Vibe”出来以及过程中的翻车和补救。如果你也对这种新玩法感兴趣或者单纯想解决和我一样的“历史微博社死”问题这篇应该能帮上忙。1. 这个Vibe Coding项目到底在解决什么问题1.1 “自见”是什么批量隐藏的场景有多常见先给不混微博黑话的朋友解释一下“自见”就是“仅自己可见”的简称。把一条微博设成自见之后除了你自己谁都看不到。它和删除的区别在于内容还在、数据还在只是从公开主页上消失了。很多早年微博不适合直接删——比如记录、回忆、碎碎念——但也不想继续公开那自见就是唯一能两全的操作。手动设置有多麻烦一条微博的完整流程是鼠标悬停微博右上角点开“更多”按钮等菜单弹出来找到“仅自己可见”选项点击再在弹窗里点确认。快的话四五秒慢的话十秒以上。微博网页版又没有“全选批量设为自见”这种功能所以几百条下来半小时到一个小时就没了而且特别容易漏。这时候很自然会想到写个自动化脚本。但这种脚本的恶心之处在于它不复杂但琐碎。要管登录态、页面滚动、DOM元素定位、弹窗、限速……人肉写的话光调试选择器就能耗掉一下午。而这正是 Vibe Coding 最擅长的领域任务清楚、边界明确、容错率高AI生成初版、你负责提要求和纠偏。1.2 为什么“1小时Vibe出来”是可信的Vibe Coding 的核心状态是“人给方向、AI给实现”不是一次成型而是快速循环。正常流程是我先用两三句话描述需求AI吐出第一版脚本我丢进终端跑把报错扔回给AIAI改完再跑遇到新问题再继续反馈。这中间每次循环大概5-10分钟跑通核心流程用不了一小时。我觉得这个项目特别适合 Vibe。它不需要高性能逻辑不需要复杂算法都是“点击、等待、判断”这种AI训练数据里见过一万遍的模式。调好之后AI写出来的代码甚至能直接打包给朋友用。这也是为什么我一直把“嵌入式 vibe coding”挂在嘴边——Vibe 应该被嵌入到日常提效里而不是当噱头玩两天就扔了。真正把需求说清楚、把边界写明白AI 的产出速度是肉眼可见的快。2. 方案选型官方API、油猴脚本还是浏览器自动化2.1 为什么第一时间排除了官方API一开始我确实想过走微博官方接口。但凡接触过微博开发的都知道第三方接口早就收得很紧了大量写操作接口不对个人开发者开放即使拿到了调用频率和权限也卡得很死。想用API批量改可见性光应用审核那一关就够呛而且官方风控逻辑不透明说不定哪天接口就悄悄失效了。对“一小时搞定”的目标来说这条路直接否决。2.2 油猴脚本和Playwright之间怎么选UI自动化有两条主流路线我在这之间犹豫了一阵子。方案优点缺点油猴脚本Tampermonkey轻量打开页面就自动执行需要处理跨域、页面重渲染调试麻烦选择器一旦失效很难定位问题Playwright Python完全模拟真人操作能控制滚动、等待、点击可复用登录状态环境稍微重一些但对个人小工具无所谓我最后选了 Playwright。理由很简单这次任务有三个绕不开的硬需求——长页面滚动加载、登录状态复用、稳定等待弹窗和按钮。这三个需求在油猴脚本里都得写一堆 hacky 代码而在 Playwright 里是现成能力。选择器问题两边都有但 Playwright 能方便地把当前页面 DOM dump 出来给 AI 调这个优势在 Vibe Coding 的工作流里特别值钱。2.3 核心工作量其实就三块整个项目的技术点拆开无非三块第一定位并点击“更多”菜单与“仅自己可见”选项第二循环遍历当前已加载的微博再滚动加载旧的微博直到全部处理完第三操作之间加随机延迟规避风控同时打印日志方便断点续跑。把这三块描述给 AI让它往下展开就行。其余什么登录态、等待策略、运行参数都是可以后补的细节。我当时没有在框架上纠结太久因为 Vibe Coding 的玩法本来就允许“先跑起来再说”框架问题在反馈循环里自然会暴露和修正。3. 现场记录我如何一步步把脚本Vibe出来3.1 第一轮需求扔给AI拿到能跑的骨架当时我给的 prompt 大意是这样用Python和Playwright写一个批量操作微博可见性的脚本打开微博网页版复用登录状态滚动遍历我主页所有微博对每条公开微博点击“更多”选“仅自己可见”已经有“仅自己可见”标签的跳过操作之间随机延迟2-5秒每20条暂停20秒打印日志并输出CSV备份AI 很快给了一版能跑的骨架核心逻辑没问题本地一跑就暴露了第一个大问题浏览器直接弹出登录页因为登录态没带上。初版代码大致长这样结构很标准但实际运行需要反复调from playwright.sync_api import sync_playwright import random, time with sync_playwright() as p: browser p.chromium.launch_persistent_context( user_data_dir./weibo_session, headlessFalse, localezh-CN ) page browser.pages[0] if browser.pages else browser.new_page() page.goto(https://weibo.com) # 之后的遍历、点击和确认逻辑需要逐轮完善我当时没指望它一次就对直接把运行结果扔回给 AI进入第二轮。3.2 第二轮复用登录态解决反复登录我把现象贴回去“每次启动都要求登录怎么复用已经登录的浏览器”AI 让我用launch_persistent_context指定一个本地用户数据目录第一次手动登录之后所有运行都复用这个登录态。这个改动是整个项目里最关键的一步解决了“脚本能用但每次都要你扫码”这种最劝退的问题。顺带我还让 AI 加了显式等待逻辑。微博页面是动态渲染的不等待直接点元素基本会扑空。AI 改成在关键操作前等待某个节点出现或者等待网络空闲操作就稳了很多。这一轮改动不大但直接把“能跑”变成了“能稳定跑”。3.3 第三轮搞定无限滚动加载第二个坑是脚本只处理到当前可见的微博就停了没办法继续加载历史微博。原因是微博主页是往下滚着加载的脚本必须先滚到底部等新内容渲染再接着处理下一批。AI 给的做法很直接last_count -1 while True: count page.locator(article).count() # 按实际DOM结构调整 if count last_count: break # 没有新内容说明到底了 last_count count page.mouse.wheel(0, 20000) # 滚动到底 page.wait_for_timeout(random.randint(2000, 3000))这逻辑听着简单实际调试时也要折腾几轮但 AI 很快就改对了。这种“滚动-等待-统计比较”的模式基本是所有无限流页面自动化的万能药以后处理别的平台也能直接复用。3.4 第四轮区分已隐藏微博避免重复操作再往后就是细化有些微博本来就设了自见脚本没必要再点一遍。AI 的思路是处理之前先检查这条微博上是否已经带有“仅自己可见”的标签或菜单文案有就跳过。我跑了一遍日志里出现了一堆“跳过已自见”的记录说明判断逻辑生效了。最终跑起来很顺。三百多条微博十几分钟跑完中间还故意每处理20条暂停20秒假装一个手速比较慢的人类。跑完后我去主页抽查公开区干净了历史微博全在个人可见列表里一条没漏。日志大概长这样[12:31:07] #12 已处理https://weibo.com/xxx - 仅自己可见 [12:31:12] #13 跳过已经是仅自己可见 [12:31:16] #14 已处理https://weibo.com/xxx - 仅自己可见4. 踩坑实录这些坑你大概率也会遇到4.1 微博改版导致选择器失效怎么让AI重新定位前端项目最喜欢改 class 名微博尤其勤快。我有一版脚本早上还跑得好好的晚上直接全军覆没所有元素都找不到了。后来我让 AI 改成“文本定位优先”的方式——通过可读文本“仅自己可见”“更多”来找按钮而不是死等 class。这一改抗改版能力强了很多。真到万不得已要用 class 的时候正确姿势也不是自己盯着 DevTools 猜而是复制当前页面 DOM把一小段带上下文的结构丢给 AI让它重新推理选择器。比自己埋头查快得多而且 AI 对常见的 DOM 结构理解很到位。4.2 触发风控不要硬刚降频才是正解跑第二轮的时候脚本连续点了两三百下新浪开始不给好脸色各种验证码弹出来。这时候千万别想着怎么绕过验证码那是跟平台规则硬碰硬。正确做法是把操作频率降下来。我实测有效的组合是每条随机延迟2-5秒每处理20条休息20秒整个运行控制在一小时以内。这样跑完基本不会再触发。这里得说句实在话这种自动化脚本本质上是游走在规则边缘的所以更要自觉控制强度和频次只处理自己的账号别动批量注册、刷量这类黑产心思。合规这事靠别人提醒不如自己心里有根弦。4.3 误操作了怎么办先备份再动手有一回脚本在定位“更多”菜单时点错了入口把一个本来准备保留公开的微博设置成了自见。想恢复并不麻烦进入该微博的编辑界面或者从账号管理入口里找到可见性设置改回公开就行。但这事提醒我一个道理批量自动化最怕的不是慢是干错了还不知道错在哪儿。所以我在启动脚本前让 AI 加了一个步骤先把全部微博链接和当前可见状态存成 CSV。万一误操作照着 CSV 反向恢复就行。这个习惯现在被我带到了所有自动化项目里——操作前备份操作中打日志操作后能追溯。5. 这趟Vibe Coding下来我总结的通用心法5.1 写Prompt时把“不要做”也写清楚人脑对“不做什么”的注意力远低于“要做什么”AI 也一样。在让 AI 写自动化脚本时尤其要把边界写死不要点转发、不要动置顶、不要修改已经自见的微博、不要点广告流里面的更多。AI 对 prompt 里的负面约束记忆其实很强这一步花30秒能在后面省下30分钟。我那次误操作就是因为只说了“把公开微博设成自见”没说“绝不能碰非目标内容”。5.2 把报错、截图、DOM喂给AI别让它凭空猜很多人在 Vibe Coding 时喜欢问“应该怎么写”但更高效的是直接把运行日志、报错堆栈、甚至页面截图丢给 AI让它在真实上下文里改代码。我在这个项目里大概有五六轮循环每一轮都是“跑出来 - 报错 - 贴回去 - 改”。这比让人工分析快得多也准得多。有一轮改选择器时我把页面 DOM 压缩成几十行关键片段发过去AI 立刻定位到新的按钮结构。上下文越真实AI 产出越准。Vibe Coding 不是许愿是喂料。5.3 什么项目适合Vibe什么不适合不是所有项目都适合 Vibe。这次能成是因为逻辑是线性的遍历-点击-确认、失败可接受点错了能改回来、用户只有一个我自己、操作频率不至于触发风控。反过来凡是涉及高性能、高并发、资金安全、强一致性、或者要给别人线上系统做生产开发的我建议老实写代码、看文档、做测试。Vibe Coding 是提效工具不是甩锅工具。AI 写的代码你自己要能读得懂、改得动、负得起责——这是底线。毕竟脚本跑起来是按你的要求去干活的出了问题第一个被找的还是你。我在这个项目里最大的收获不是那个脚本本身——它很糙也无所谓。真正有用的是把“让 AI 干活”变成了一种肌肉记忆。需求说清楚、边界写明白、跑挂了就把现场信息发给 AI每一轮循环都在把抽象需求变成具体可用的脚本。现在再碰到那种“简单、重复、让人崩溃”的批量操作我第一反应已经不是咬牙手动做了而是打开终端对着 AI 说给爷 Vibe 一个。如果你家也藏着几百条历史微博不用再手动一条条点了按这个思路试一次大概率也能在一小时内拥有自己的批量隐藏工具。
最近清理微博主页翻到十年前发的那些转发、打卡、半夜emo真是想找个地缝钻进去。删掉吧舍不得留着吧又不想让新关注的人看到唯一能两全的办法就是设置成“仅自己可见”——微博用户的黑话叫“自见”。手动一条条设置点开更多、找菜单、确认每条至少四五次点击我手里还有三百多条要处理想想都绝望。刚好那阵子一直在玩 Vibe Coding就是用自然语言怼着AI让它写代码的玩法索性花了一个小时让AI帮我写了个批量隐藏微博自见的脚本几分钟把历史微博全部处理完。这篇不是教程文档记录一下这个真实的 Vibe Coding 项目怎么做下来需求怎么拆、方案怎么选、和AI怎么一来一回把它“Vibe”出来以及过程中的翻车和补救。如果你也对这种新玩法感兴趣或者单纯想解决和我一样的“历史微博社死”问题这篇应该能帮上忙。1. 这个Vibe Coding项目到底在解决什么问题1.1 “自见”是什么批量隐藏的场景有多常见先给不混微博黑话的朋友解释一下“自见”就是“仅自己可见”的简称。把一条微博设成自见之后除了你自己谁都看不到。它和删除的区别在于内容还在、数据还在只是从公开主页上消失了。很多早年微博不适合直接删——比如记录、回忆、碎碎念——但也不想继续公开那自见就是唯一能两全的操作。手动设置有多麻烦一条微博的完整流程是鼠标悬停微博右上角点开“更多”按钮等菜单弹出来找到“仅自己可见”选项点击再在弹窗里点确认。快的话四五秒慢的话十秒以上。微博网页版又没有“全选批量设为自见”这种功能所以几百条下来半小时到一个小时就没了而且特别容易漏。这时候很自然会想到写个自动化脚本。但这种脚本的恶心之处在于它不复杂但琐碎。要管登录态、页面滚动、DOM元素定位、弹窗、限速……人肉写的话光调试选择器就能耗掉一下午。而这正是 Vibe Coding 最擅长的领域任务清楚、边界明确、容错率高AI生成初版、你负责提要求和纠偏。1.2 为什么“1小时Vibe出来”是可信的Vibe Coding 的核心状态是“人给方向、AI给实现”不是一次成型而是快速循环。正常流程是我先用两三句话描述需求AI吐出第一版脚本我丢进终端跑把报错扔回给AIAI改完再跑遇到新问题再继续反馈。这中间每次循环大概5-10分钟跑通核心流程用不了一小时。我觉得这个项目特别适合 Vibe。它不需要高性能逻辑不需要复杂算法都是“点击、等待、判断”这种AI训练数据里见过一万遍的模式。调好之后AI写出来的代码甚至能直接打包给朋友用。这也是为什么我一直把“嵌入式 vibe coding”挂在嘴边——Vibe 应该被嵌入到日常提效里而不是当噱头玩两天就扔了。真正把需求说清楚、把边界写明白AI 的产出速度是肉眼可见的快。2. 方案选型官方API、油猴脚本还是浏览器自动化2.1 为什么第一时间排除了官方API一开始我确实想过走微博官方接口。但凡接触过微博开发的都知道第三方接口早就收得很紧了大量写操作接口不对个人开发者开放即使拿到了调用频率和权限也卡得很死。想用API批量改可见性光应用审核那一关就够呛而且官方风控逻辑不透明说不定哪天接口就悄悄失效了。对“一小时搞定”的目标来说这条路直接否决。2.2 油猴脚本和Playwright之间怎么选UI自动化有两条主流路线我在这之间犹豫了一阵子。方案优点缺点油猴脚本Tampermonkey轻量打开页面就自动执行需要处理跨域、页面重渲染调试麻烦选择器一旦失效很难定位问题Playwright Python完全模拟真人操作能控制滚动、等待、点击可复用登录状态环境稍微重一些但对个人小工具无所谓我最后选了 Playwright。理由很简单这次任务有三个绕不开的硬需求——长页面滚动加载、登录状态复用、稳定等待弹窗和按钮。这三个需求在油猴脚本里都得写一堆 hacky 代码而在 Playwright 里是现成能力。选择器问题两边都有但 Playwright 能方便地把当前页面 DOM dump 出来给 AI 调这个优势在 Vibe Coding 的工作流里特别值钱。2.3 核心工作量其实就三块整个项目的技术点拆开无非三块第一定位并点击“更多”菜单与“仅自己可见”选项第二循环遍历当前已加载的微博再滚动加载旧的微博直到全部处理完第三操作之间加随机延迟规避风控同时打印日志方便断点续跑。把这三块描述给 AI让它往下展开就行。其余什么登录态、等待策略、运行参数都是可以后补的细节。我当时没有在框架上纠结太久因为 Vibe Coding 的玩法本来就允许“先跑起来再说”框架问题在反馈循环里自然会暴露和修正。3. 现场记录我如何一步步把脚本Vibe出来3.1 第一轮需求扔给AI拿到能跑的骨架当时我给的 prompt 大意是这样用Python和Playwright写一个批量操作微博可见性的脚本打开微博网页版复用登录状态滚动遍历我主页所有微博对每条公开微博点击“更多”选“仅自己可见”已经有“仅自己可见”标签的跳过操作之间随机延迟2-5秒每20条暂停20秒打印日志并输出CSV备份AI 很快给了一版能跑的骨架核心逻辑没问题本地一跑就暴露了第一个大问题浏览器直接弹出登录页因为登录态没带上。初版代码大致长这样结构很标准但实际运行需要反复调from playwright.sync_api import sync_playwright import random, time with sync_playwright() as p: browser p.chromium.launch_persistent_context( user_data_dir./weibo_session, headlessFalse, localezh-CN ) page browser.pages[0] if browser.pages else browser.new_page() page.goto(https://weibo.com) # 之后的遍历、点击和确认逻辑需要逐轮完善我当时没指望它一次就对直接把运行结果扔回给 AI进入第二轮。3.2 第二轮复用登录态解决反复登录我把现象贴回去“每次启动都要求登录怎么复用已经登录的浏览器”AI 让我用launch_persistent_context指定一个本地用户数据目录第一次手动登录之后所有运行都复用这个登录态。这个改动是整个项目里最关键的一步解决了“脚本能用但每次都要你扫码”这种最劝退的问题。顺带我还让 AI 加了显式等待逻辑。微博页面是动态渲染的不等待直接点元素基本会扑空。AI 改成在关键操作前等待某个节点出现或者等待网络空闲操作就稳了很多。这一轮改动不大但直接把“能跑”变成了“能稳定跑”。3.3 第三轮搞定无限滚动加载第二个坑是脚本只处理到当前可见的微博就停了没办法继续加载历史微博。原因是微博主页是往下滚着加载的脚本必须先滚到底部等新内容渲染再接着处理下一批。AI 给的做法很直接last_count -1 while True: count page.locator(article).count() # 按实际DOM结构调整 if count last_count: break # 没有新内容说明到底了 last_count count page.mouse.wheel(0, 20000) # 滚动到底 page.wait_for_timeout(random.randint(2000, 3000))这逻辑听着简单实际调试时也要折腾几轮但 AI 很快就改对了。这种“滚动-等待-统计比较”的模式基本是所有无限流页面自动化的万能药以后处理别的平台也能直接复用。3.4 第四轮区分已隐藏微博避免重复操作再往后就是细化有些微博本来就设了自见脚本没必要再点一遍。AI 的思路是处理之前先检查这条微博上是否已经带有“仅自己可见”的标签或菜单文案有就跳过。我跑了一遍日志里出现了一堆“跳过已自见”的记录说明判断逻辑生效了。最终跑起来很顺。三百多条微博十几分钟跑完中间还故意每处理20条暂停20秒假装一个手速比较慢的人类。跑完后我去主页抽查公开区干净了历史微博全在个人可见列表里一条没漏。日志大概长这样[12:31:07] #12 已处理https://weibo.com/xxx - 仅自己可见 [12:31:12] #13 跳过已经是仅自己可见 [12:31:16] #14 已处理https://weibo.com/xxx - 仅自己可见4. 踩坑实录这些坑你大概率也会遇到4.1 微博改版导致选择器失效怎么让AI重新定位前端项目最喜欢改 class 名微博尤其勤快。我有一版脚本早上还跑得好好的晚上直接全军覆没所有元素都找不到了。后来我让 AI 改成“文本定位优先”的方式——通过可读文本“仅自己可见”“更多”来找按钮而不是死等 class。这一改抗改版能力强了很多。真到万不得已要用 class 的时候正确姿势也不是自己盯着 DevTools 猜而是复制当前页面 DOM把一小段带上下文的结构丢给 AI让它重新推理选择器。比自己埋头查快得多而且 AI 对常见的 DOM 结构理解很到位。4.2 触发风控不要硬刚降频才是正解跑第二轮的时候脚本连续点了两三百下新浪开始不给好脸色各种验证码弹出来。这时候千万别想着怎么绕过验证码那是跟平台规则硬碰硬。正确做法是把操作频率降下来。我实测有效的组合是每条随机延迟2-5秒每处理20条休息20秒整个运行控制在一小时以内。这样跑完基本不会再触发。这里得说句实在话这种自动化脚本本质上是游走在规则边缘的所以更要自觉控制强度和频次只处理自己的账号别动批量注册、刷量这类黑产心思。合规这事靠别人提醒不如自己心里有根弦。4.3 误操作了怎么办先备份再动手有一回脚本在定位“更多”菜单时点错了入口把一个本来准备保留公开的微博设置成了自见。想恢复并不麻烦进入该微博的编辑界面或者从账号管理入口里找到可见性设置改回公开就行。但这事提醒我一个道理批量自动化最怕的不是慢是干错了还不知道错在哪儿。所以我在启动脚本前让 AI 加了一个步骤先把全部微博链接和当前可见状态存成 CSV。万一误操作照着 CSV 反向恢复就行。这个习惯现在被我带到了所有自动化项目里——操作前备份操作中打日志操作后能追溯。5. 这趟Vibe Coding下来我总结的通用心法5.1 写Prompt时把“不要做”也写清楚人脑对“不做什么”的注意力远低于“要做什么”AI 也一样。在让 AI 写自动化脚本时尤其要把边界写死不要点转发、不要动置顶、不要修改已经自见的微博、不要点广告流里面的更多。AI 对 prompt 里的负面约束记忆其实很强这一步花30秒能在后面省下30分钟。我那次误操作就是因为只说了“把公开微博设成自见”没说“绝不能碰非目标内容”。5.2 把报错、截图、DOM喂给AI别让它凭空猜很多人在 Vibe Coding 时喜欢问“应该怎么写”但更高效的是直接把运行日志、报错堆栈、甚至页面截图丢给 AI让它在真实上下文里改代码。我在这个项目里大概有五六轮循环每一轮都是“跑出来 - 报错 - 贴回去 - 改”。这比让人工分析快得多也准得多。有一轮改选择器时我把页面 DOM 压缩成几十行关键片段发过去AI 立刻定位到新的按钮结构。上下文越真实AI 产出越准。Vibe Coding 不是许愿是喂料。5.3 什么项目适合Vibe什么不适合不是所有项目都适合 Vibe。这次能成是因为逻辑是线性的遍历-点击-确认、失败可接受点错了能改回来、用户只有一个我自己、操作频率不至于触发风控。反过来凡是涉及高性能、高并发、资金安全、强一致性、或者要给别人线上系统做生产开发的我建议老实写代码、看文档、做测试。Vibe Coding 是提效工具不是甩锅工具。AI 写的代码你自己要能读得懂、改得动、负得起责——这是底线。毕竟脚本跑起来是按你的要求去干活的出了问题第一个被找的还是你。我在这个项目里最大的收获不是那个脚本本身——它很糙也无所谓。真正有用的是把“让 AI 干活”变成了一种肌肉记忆。需求说清楚、边界写明白、跑挂了就把现场信息发给 AI每一轮循环都在把抽象需求变成具体可用的脚本。现在再碰到那种“简单、重复、让人崩溃”的批量操作我第一反应已经不是咬牙手动做了而是打开终端对着 AI 说给爷 Vibe 一个。如果你家也藏着几百条历史微博不用再手动一条条点了按这个思路试一次大概率也能在一小时内拥有自己的批量隐藏工具。
