摘要

在自动化养号脚本稳定运行后，项目进入内容运营的闭环阶段——发得出内容，更要管得住评论区。然而，小红书创作者平台的微前端改造（QianKun）直接将发布按钮从 DOM中抹除，习惯了传统选择器定位的脚本瞬间失效。本文完整记录了盲点坐标调试过程，以及如何绕过微前端沙盒实现发布。同时，详细阐述了评论区自动回复技能的架构设计，包括评论分类策略、防重复机制和风控保护 措施。

一、引言

1.1 背景

上阶段结束时，MarkerClaw 已具备以下能力：

- 关键词搜索与内容发现
- 图文/视频内容发布（基于 fill-publish + click-publish 分步流程）
- 账号预热与权重积累

但在实际运营过程中，两个核心需求浮出水面：

1. 发布环节不够稳定——小红书的创作者平台在 2026 年初完成了 QianKun 微前端改造，发布按钮不再以 DOM元素形式存在，click-publish 的 JavaScript 回退策略频频失效；
2. 缺少评论闭环——发布后用户评论无人管理，既浪费了互动机会 ，又降低了账号活跃度。

1.2 解决思路

针对发布问题，放弃 DOM 选择器路线，转向 CDP 原生 dispachMouseEvent 的"盲点点击"方案。针对评论管理，设计一套基于模板匹配 +
持久化去重的自动回复系统。

二、QianKun 沙盒：发布按钮去哪了

2.1 问题发现

在 6 月初的一次测试中，fill-publish 执行成功，表单正常填写，但随后调用的 click-publish 返回了熟悉的错误信息：

```
  PublishError: 未找到发布按钮（小红书创作者平台已更新）
```

直觉告诉我——不是脚本有 bug，是页面变了。

打开浏览器开发者工具，在发布页搜索"发布"两个字，结果如下：

- DOM 树中完全不存在包含"发布"文本的 button 元素；
- 尝试搜索按钮的 CSS 类名（.bg-red、.d-button），返回空集合；
- 甚至 * 通配符遍历无法定位到任何可点击的发布按钮。

2.2 QianKun 微前端简介

QianKun 是蚂蚁金服开源的微前端框架，核心机制包括：

1. 应用隔离——子应用运行在独立的沙盒环境中，主应用 DOM 中只有一个挂载节点；
2. 样式隔离——通过 Shadow DOM 或 Scoped CSS 隔离子应用样式；
3. 通信代理——子应用通过 QianKun 提供的生命周期钩子与主应用通信；

这意味着，发布页面可能运行在一个 Shadow DOM 或 iframe 风格的隔离环境中，主页面的 document.querySelector根本无法穿透到子应用内部。

2.3 DOM 扫描验证

为了验证这个猜想，我在页面加载后执行了以下 JavaScript 进行全量 DOM 扫描：

```javascript
  // 策略1: 扫描所有元素，检查 textContent
  const all = document.querySelectorAll('*');
  for (const el of all) {
    if ((el.textContent || '').trim() === '发布') {
      console.log('Found:', el.tagName, el.className);
    }
  }
  // → 输出为空，全 DOM 无"发布"文本

  // 策略2: 检查 Shadow DOM
  document.querySelectorAll('*').f orEach(el => {
    if (el.shadowRoot) {
      console.log('Shadow DOM found:', el.tagName, el.shadowRoot);
    }
  });
  // → 无 Shadow DOM

  // 策略3: 检查 iframe
  document.querySelectorAll('ifram e').forEach(f => console.log(f.src));
  // → 无发布相关的 iframe
```

结果令人困惑——既没有 Shadow DOM，也没有 iframe，发布按钮使用的是一套完全自定义的渲染机制。

2.4 debugger_click：盲点方案

既然无法找到按钮元素，我需要换一个思路——不找按钮，直接点击 按钮应该在的位置。

通过多轮截图比对和坐标微调，确定发布按钮在视口中的固定坐标为 (850, 780)。这个坐标在不同分辨率的屏幕上略有偏移，但在
1920×1080 的标准窗口下相当稳定。

技术实现利用了 Chrome DevTools Protocol 的 Input.dispatchMouseEvent，生成 isTrusted=true 的鼠标事件：

```python
  def debugger_click(self, x: float, y: float) -> None:
      """通过 chrome.debugger + CDP Input.dispatchMouseEvent 发送真实点击事件。
      与 mouse_click 不同，此方法生成 isTrusted=true 的事件，React 框架才能响应。
      """
      methods = ['Input.dispatchMouseEvent'] * 4
      params = [
          {"type": "mousePressed", "x": x, "y": y, "button": "left", "clickCount": 1},
          {"type": "mouseReleased", "x": x, "y": y, "button": "left", "clickCount": 1},
      ]
      for p in params:
          self._send_cdp("Input.dispatchMo useEvent", p)
```

这个方案的关键优势在于：操作系统级别的鼠标事件会像真实用 户点击一样被浏览器的所有层处理，包括 React 的合成事件系统，也包括
QianKun 的事件代理。

2.5 验证结果

在 3 次实际发布测试中，盲点点击均成功触发了发布：✅

| 测试编号 | 帖子标题 | 发布方式 | 结果 |
|---------|---------|---------|- -----|
| 1 | 大学生自学AI编程，这5个工具就够了 | 盲点 (850,780) | ✅ |
| 2 | 大学生副业做AI代写，月入5000+ | 盲点 (850,780) | ✅ |
| 3 | 大学生靠AI做副业，这个方法太稳了 | 盲点 (850,780) | ✅ |

三次发布间隔均在 5 分钟以上，未触发任何风控验证。

三、评论区自动回复 Skill

3.1 系统架构

评论区自动回复模块设计为 OpenClaw 技能，遵循 xiaohongshu-skills 项目的统一架构：

│ 用户交互层 │ OpenClaw Skill (xhs-comment-reply) │ 意图识别、流程编排     │

│ 执行层     │ Python CLI → comment.py            │ CDP 操作、评论发送     │

│ 持久化层   │ ~/.xhs/replied_comments.json       │ 已回复评论 ID 去重     │

│ AI 层      │ copywriting-zh-pro skill (外部)    │ 评论内容分析与回复生成 │
 

3.2 评论分类策略

评论自动回复的核心挑战是根据评论内容选择合适的回复方式。 我设计了一套基于关键词匹配的六分类系统：

```python
  def classify_comment(text: str) -> str:
      text = text.strip()
      if any(kw in text for kw in ("真能", "靠谱", "有用吗", "假的", "怀疑")):
          return "质疑类"
      if any(kw in text for kw in ("怎么", "如何", "步骤", "哪里", "什么工具")):
          return "询问方法"
      if any(kw in text for kw in ("多少", "价格", "钱")):
          return "价格咨询"
      if any(kw in text for kw in ("666", "厉害", "赞", "不错", "👍", "❤")):
          return "赞扬类"
      if any(kw in text for kw in ("求带", "带带我", "想学", "收徒")):
          return "求带类"
      return "一般评论"
```

六类评论对应不同的回复模板和引导策略：

| 评论类型 | 示例 | 回复风格 | 转化意图 |
|---------|------|---------|---- -----|
| 质疑类 | "真能行吗" | 个人经验+鼓励尝试 | 建立信任 |
| 询问方法 | "怎么做的" | 具体步骤+私信引导 | 引流私信 |
| 价格咨询 | "多少钱" | 价格区间+定制说明 | 筛选客户 |
| 赞扬类 | "太厉害了" | 感谢+持续互动 | 维护关系 |
| 求带类 | "求带" | 入门引导+教程推荐 | 直接转化 |
| 一般评论 | "不错" | 互动引导 | 增加活跃 |

3.3 回复持久化去重

为避免对同一评论重复回复，设计了基于 JSON 文件的持久化方案：

```python
  REPLIED_COMMENTS_PATH = Path.home() / ".xhs" / "replied_comments.json"

  def _load_replied_comments() -> set[str]:
      if REPLIED_COMMENTS_PATH.exists():
          data = json.loads(REPLIED_COMMENTS_PATH.read_text(encoding="utf-8"))
          return set(data.get("replied", []))
      return set()

  def _save_replied_comment(comment_id : str) -> None:
      REPLIED_COMMENTS_PATH.parent.mkd ir(parents=True, exist_ok=True)
      replied = _load_replied_comments()
      replied.add(comment_id)
      REPLIED_COMMENTS_PATH.write_text (
          json.dumps({"replied": list(replied)}, ensure_ascii=False, indent=2),
          encoding="utf-8",
      )
```

每次回复成功后，评论 ID 被持久化到文件中。下次运行时自动跳过已回复的评论，无论脚本是否重 启或间隔多久。

3.4 防风控导航策略

评论回复的风控关键在于导航次数控制：

```
  传统流程：导航到搜索页 → 搜索 → 打开详情页(navigate) → 回复 → 后退
  导航次数：1            + 1    + 1               + 1    + 1   = 5次

  优化流程：主页盲点进入详情页(navigate) → 回复 → 后退
  导航次数：1                              + 1    + 1   = 3次
```

核心优化：从用户主页盲点直接进入详情页，仅需 1 次 navigate。单篇帖子的评论回复流程共消耗 3
次导航（进入、回复操作中的页面刷新、退出），在风控阈值内。

3.5 验证结果

对已发布的 3 篇帖子执行自动回复测试：

- 检测到 3 条新评论（含 1 条质疑类、2 条询问方法类）
- AI 自动生成对应回复并发送 ✅
- 评论 ID 已持久化，下次运行不会重复回复 ✅
- 操作间隔 3–5 秒，未触发风控 ✅

四、技术总结

4.1 本阶段关键产出

- 盲点发布方案——突破了 QianKun 微前端沙盒限制，使用 CDP Input.dispatchMouseEvent 盲点点击 (850,780)，3 次实测全部成功
- 评论区自动回复 Skill——完成了从评论检测、分类、AI 生成回复到持久化去重的完整闭环
- 持久化去重机制——基于 JSON 文件的评论 ID 持久化，确保跨会话不重复回复

4.2 经验教训

1. 浏览器自动化不能迷信 DOM——微前端、Shadow DOM 等技术让传统选择器失效，CDP 原生的坐标事件是最底层的保底方案
2. 评论管理比发布更敏感——回复操作涉及用户个人通知，频率控 制需要比发布更严格
3. 持久化是自动化的基石——任何有状态的操作（如"已回复"） 都必须有可靠的持久化机制，内存记录在进程重启后毫无价值

4.3 后续计划

- 整合发布 + 自动回复为一键全流程脚本（见下篇）
- 引入定时发布调度（基于 OpenClaw cron）
- 接入 WeCom 实现微信端管理评论区