x-surfing

name	x-surfing
description	Drive x.com (Twitter) through pocket-browser's real-device WKWebView — follow, like, reply, post, and verify every write. Use when an agent needs to operate a logged-in X account via the pocket /pocket/cmd API instead of a headless browser. Includes hard-won pitfalls: React synthetic-click immunity, newline-swallowing composer, UserCell targeting, and verification discipline.

X 冲浪 skill（pocket-browser 版）

用 pocket-browser 的真机 WKWebView 操作 x.com。所有工艺都在真实账号上实战验证过，所有"⚠️"都是翻过的车。

前提：手机端 WebView 已登录目标 X 账号，/pocket/status 返回 phone_connected: true。

基本功

# 指令一律"写 JSON 文件 → curl -d @file"，内联转义引号是地狱
curl -s -X POST http://127.0.0.1:3897/pocket/cmd \
  -H "Authorization: Bearer $POCKET_TOKEN" \
  -H "Content-Type: application/json" -d @/tmp/cmd.json

• goto 大站要 "timeout_ms": 30000 起步；返回 "loading..." 只代表开始加载，不代表加载完。goto 后等 8–10 秒再动手。
• 读页面优先 js（[...document.querySelectorAll('article')].map(a=>a.textContent)），比 screenshot 快且稳；x.com/home 这类重页面截图经常直接 timeout。
• 页面状态是流沙：每次操作前确认目标元素真的存在（articles.length > 0），不要信上一秒的 DOM。

⚠️ 四条铁律（每条都是事故换的）

1. React 无视合成 click()。btn.click() 返回正常、页面纹丝不动。必须 dispatch 完整事件链：

['pointerdown','mousedown','pointerup','mouseup','click'].forEach(t =>
  btn.dispatchEvent(new MouseEvent(t, {bubbles: true, cancelable: true, view: window})));

2. 发推正文一律单段、无换行。composer 里 insertText 带 \n 会吞内容——只发出最后一段，而且 sent 返回 true、字数看起来正常，全是假象。要分段感就用句号和破折号。

3. UserCell 内精确定位，永不批量点击。回关/点赞先找到目标 cell 再在 cell 内找按钮：

const cell = [...document.querySelectorAll('[data-testid=UserCell]')]
  .find(c => c.textContent.includes('@TargetHandle'));
const btn = [...cell.querySelectorAll('button')].find(b => /follow back/i.test(b.textContent));

批量点击的事件冒泡会点进别人主页、误关推荐位的路人。非 ASCII 显示名（韩文、日文）在传输链路可能碎掉——匹配一律用 ASCII 的 @handle。

4. js 返回值 ≠ 实际生效。每个写操作后必须独立验证：回关后重读按钮文本是否变 "Following"；发推后 goto 回主页读第一条 article 确认正文上墙。"CLICKED"/"sent" 都不算数，DOM 状态才算。

5. 验证必须刷新页面（重新 goto）再读 DOM，读旧 DOM 会误判失败。详情页不会实时插入你刚发的回复——原地读 DOM 看不到 ≠ 没发出去。误判失败后盲目重试也不会堆出重复内容：X 对同文重复会提示"已发过"并拦截（天然防双发保险丝）。反过来说，重试一直"失败"时，第一次很可能已经成功了——先 goto 刷新验证，再决定要不要重试。

发推

1. 字数预检：X 对中文按 2 字符计权，280 上限 ≈ 140 个中文字。sum(2 if ord(c)>127 else 1 for c in text)
2. goto 自己的主页再开 composer——在别人主页或推文详情页开 composer 会自动 @ 对方，推变成回复，进不了自己的 Posts 流。
3. 开 composer：a[href='/compose/post'] 或 [data-testid='SideNav_NewTweet_Button']（事件链点击）。
4. 填正文：ta.focus() 后 document.execCommand('insertText', false, text) 到 [data-testid='tweetTextarea_0']。单段，见铁律 2。
5. 发送：[data-testid='tweetButton']（事件链点击）。
6. 验证：回主页读第一条 article，关键词在墙上才算发出去了。发完跳到限流提示页属正常现象，不影响已发内容。

回复

1. 从 timeline 或对方主页点击目标推文进入详情——不要直接 goto status URL，受限账号会被重定向，回复变成独立发推。
2. 点击前确认目标 article 真的找到了（find 返回非 null）。页面没加载完时 reply 按钮会命中残留 DOM，回复会错楼。
3. 在目标 article 内找 [data-testid='reply']——详情页第一个 article 是主帖，不要用页面第一个 reply 按钮。
4. insertText 单段正文 → tweetButton → 验证。

点赞 / 回关

• 点赞：目标 article 内 [data-testid='like']，事件链点击，读 [data-testid='unlike'] 出现验证。
• 回关：铁律 3 的 cell 内定位，点击后重读按钮文本变 "Following" 才算成功。

删推

目标 article 内 [data-testid='caret'] → menuitem 含 Delete → [data-testid='confirmationSheetConfirm']。

⚠️ 永不按文本内容匹配做删除——同文的新旧两条会误中先渲染的那条。删除前确认候选唯一，或用时间戳/位置区分。

维护本地关注名册

不要每次都开 followers/following 页现场找人——页面是虚拟列表，加载慢、滚动不可靠，还容易在匆忙中误点。在本地文件里维护一份名册：

• 记什么：@handle（ASCII，用于 cell 匹配）、显示名、互关/单向状态、一句话备注、快照日期。
• 纪律：每次回关、取关、发现新粉丝后立即更新名册，让它始终可信；写操作前先查名册再上页面，目标明确才动手。
• 单向关注单独列出并注明原因（等回关中/疑似平台抽风取关/观察截止日），避免下次盘点时又变成"不知道是谁"。
• 名册是账号的私人数据，放在你自己的工作目录，不要提交进公开仓库。

行为纪律

• timeline 是算法流，刷新即换内容。要找特定推文去对方主页找；主页虚拟列表 scrollBy 不一定触发加载，翻不到就止损，改天再来。
• 发推频率一天 2–4 条是人，再多像嗑药。
• 写操作失败先截图看现场，不要盲重试——上一次的"失败"可能已经生效了一半。

为什么用真机而不是 headless

X 对数据中心 IP 和 headless 特征降权甚至阉割 DOM。pocket-browser 的执行端是真 iPhone、真 WebKit、真移动 UA、真家宽网络，登录态就在手机里——这条链路发出的每个动作，和主人亲手点的没有区别。区别只有一个：是谁的手。