本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

这篇长文要解决的问题只有一个：把 GitHub 上那个最近冲到 9.5K Star 的 AiToEarn，从"它能做什么"讲到"它是怎么做到的"。 我会按"项目定位 → 整体架构 → 四大模块原理 → MCP 接入方式 → 和同类工具的差异 → 个人实操体验"这个顺序拆。核心结论先写在这里：AiToEarn 不是一个"一键发布工具"，它是一个把内容生产链路全部 Agent 化的中间件，开源协议 + Docker 自部署 + MCP 协议接入，三件事叠在一起，让它从一堆同类项目里跑出来。 如果你只想要快速答案——它适合做矩阵账号、一人公司、独立创作者的内容工作流底座；如果你想自托管，三条命令搞定；如果你不想折腾，开浏览器就能用。想看完整拆解、原理图和踩坑笔记，往下翻。

一、为什么我会专门写一篇长文拆这个项目

我自己折腾内容已经第三个年头了，公众号、小红书、视频号、B 站、知乎，主流的几个平台账号都在跑。一开始还能扛得住，后来发现一个非常具体的问题：同一条内容，从写完到铺满所有渠道，需要的不是创作时间，而是搬运时间。

这就是为什么我对 AiToEarn 第一眼就来了兴趣。在 GitHub 趋势榜上看到它的时候，标题写的是 "Let's use AI to Earn!"，但点进去翻完 README、看完 Release Note、又把源码扒了一遍之后，我个人的判断变成了——这个项目更像一套"内容生产中间件"，能不能产生效益只是顺带的结果，工程上它真正在解决的，是把零散的创作 / 分发 / 互动动作收拢到一个 Agent 调度器里。

仓库地址是 https://github.com/yikart/AiToEarn，主仓库 README 写得相当克制，但要点全部在那儿——支持的平台矩阵、四大模块的边界、Docker 一键部署、MCP 协议接入。我顺手对照了一下同类项目（比如 social-auto-upload、shortvideo-autopublisher、新榜矩阵通这些），把横向差异也整理出来放在后面的章节里。

这篇文章，是莫潇羽@无忆研习社把这套项目从头到尾跑通之后，按"原理 + 操作"两条线写出来的实操总结。文章不短，建议你按章节挑着看：想要快速跑通的，直接跳到第八章；想理解架构的，前七章按顺序读；想做横向选型的，看第十章。

二、AiToEarn 是什么：项目定位与整体架构

2.1 它的定位是一句话能讲清楚的

AiToEarn 的官方定位写得很直白：面向独立创作者和小团队的 AI 内容营销 Agent 平台。所谓 OPC（One Person Company，一人公司）这个说法这两年挺火的，本质就是一个人 / 极小团队，靠工具放大自己的产能。AiToEarn 把自己摆在这个位置上。

它支持的渠道目前覆盖到 14 个左右：

这是 README 里明确列出来的渠道。我自己跑起来之后实际能登录上的平台数量略有差异，主要看授权关系，下面会展开讲。

2.2 它的核心架构是 "All In Agent"

如果你只看截图，会以为它是一个普通的多平台发布器。但翻一下 v1.4.3 那个版本的 Release Note，会看到一句话——"All In Agent" 的开始。这是项目在工程上一次比较关键的转向：从"功能型 SaaS"切到"Agent 型平台"。

差别在哪？

• 功能型 SaaS：用户点按钮，系统执行预设流程。
• Agent 型平台：用户描述意图，Agent 拆任务、调工具、回结果。

这两件事的开发方式、用户体验、扩展模型完全不一样。

我自己花了不少时间研究这次架构转向背后的判断。我猜测项目方做这个决定的原因有三层：第一层是用户体验——表单点击式的交互在功能多了之后会非常冗长，用户最终会被自己工具的"复杂度"劝退；第二层是大模型能力的迭代——从 2024 年到现在，大模型的工具调用能力突飞猛进，原本需要写死的流程现在可以让模型动态编排；第三层是生态站位——MCP 协议出来之后，谁先把自己的能力做成标准化工具，谁就能挂到所有支持 MCP 的智能体上。

这三层判断叠在一起，"All In Agent" 是一个相当顺势而为的选择。也正是因为这个选择，AiToEarn 才能在短短几个月里 Star 数从几百冲到 9.5K——它不是又造了一个工具，它是在新的范式下重新做了内容工作流这件事。

我自己画了一张项目架构的简化示意图（这是我对它的理解，不是官方架构图）：

graph TB
    User[用户/创作者] -->|自然语言指令| Agent[AiToEarn Agent 调度器]
    Agent --> Create[Create 创作模块]
    Agent --> Publish[Publish 分发模块]
    Agent --> Engage[Engage 互动模块]
    Agent --> Monetize[Monetize 商单模块]

    Create -->|调用| VideoModel[视频生成模型 Veo/Seedance]
    Create -->|调用| ImageModel[图片生成模型 Nano Banana]
    Create -->|调用| TextModel[文案模型]

    Publish -->|多平台 OAuth| Channels[14+ 社媒渠道]
    Engage -->|浏览器插件| Browser[Chrome/Edge]
    Monetize -->|商单匹配| Market[内容交易市场]

    Agent <-->|MCP 协议| External[Claude/Cursor/OpenClaw]

这张图能解释清楚一件事：AiToEarn 自己并不直接做内容生成，它把内容生成这件事拆成"调用各种模型 + 拼装结果"。视频用的是 Grok、Veo、Seedance 这一类，图文用 Nano Banana 系列，文案部分接的是各家大模型。AiToEarn 的核心价值不在模型，而在调度。

2.3 项目的代码组织

我把仓库 clone 下来之后扫了一眼目录结构，大致是这样的：

AiToEarn/
├── apps/
│   ├── aitoearn-ai/          # AI 服务（创作相关）
│   ├── aitoearn-server/      # 主后端
│   └── aitoearn-web/         # Web 前端
├── browser-extension/        # 浏览器插件（互动模块用）
├── config/                   # 配置文件
├── docker-compose.yml        # 一键部署入口
└── README_CN.md

它是一套 monorepo，前端是 Next.js 类的栈，后端走 Node 体系，pnpm + nx 做工程管理，依赖里能看到 MongoDB、Redis、RustFS、Nginx 这些，都是正经的生产级组合。Docker Compose 启动的时候会一并把数据库和对象存储拉起来，这一点对自部署用户特别友好——不用自己装 MongoDB、不用自己配 Redis。

2.4 技术选型背后的考量

我个人对开源项目最在意的一点不是它现在能做什么，而是它的技术选型有没有给未来的扩展留下空间。AiToEarn 在这一块的选择我觉得相当老道：

• MongoDB 做主数据库：内容这种结构差异很大的数据用文档型数据库比关系型更顺手。一条小红书图文和一条视频号视频的字段差异极大，硬塞进 MySQL 表里会让 schema 变得很难看。
• Redis 兼任缓存和任务队列：发布排期、限流、分布式锁这些都能在 Redis 里搞定，不用再额外引入消息队列。
• RustFS 做对象存储：这个选择我开始没看懂，后来想明白了——RustFS 是 S3 兼容的对象存储，自部署用户不愿意把视频素材发到 AWS / 阿里云 OSS 上的话，本地起一个 RustFS 实例就能用，部署成本低。
• Nginx 做反向代理：标准做法，没什么好说的。

整套技术栈的复杂度刚好卡在"中小团队能 hold 住"这个区间。如果上来就用 Kubernetes + Kafka + ClickHouse 那一套，自部署的门槛会陡得让人劝退。

2.5 数据流：内容资产是怎么流动的

理解一个内容平台，最快的办法是理解它的数据流。我把 AiToEarn 的数据流抽象出来，大致是这样的：

flowchart TB
    subgraph 创作阶段
        Idea[创意/选题] --> Material[素材库]
        Material --> Draft[草稿]
        Draft --> Final[成品]
    end

    subgraph 分发阶段
        Final --> Adapt[平台适配]
        Adapt --> Schedule[排期队列]
        Schedule --> Publish[实际发布]
    end

    subgraph 数据回流
        Publish --> Metric[指标采集]
        Metric --> Warehouse[数据仓库]
        Warehouse --> Insight[洞察看板]
    end

    subgraph 商业化闭环
        Warehouse --> Settle[结算引擎]
        Settle --> Wallet[创作者钱包]
    end

    Insight -.反馈.-> Idea

最关键的是图里那条虚线反馈线：洞察数据回到选题环节，下一轮创作可以基于历史数据决定方向。这条反馈线很多工具都没有，AiToEarn 把它接通了。这意味着你用得越久，工具对你账号的"理解"越深，给的建议越精准。这是 AI 时代工具的一个典型特征——工具越用越懂你。

三、四块核心能力是怎么串成一条流水线的

我特意把这一节单独拎出来写，因为很多文章直接从"功能介绍"切进去，但其实四块能力之间的连接关系，比单块功能本身更值得关注。

3.1 流水线的语义流向

先看一张时序图，更直观：

sequenceDiagram
    participant U as 创作者
    participant A as Agent 调度器
    participant C as Create
    participant P as Publish
    participant E as Engage
    participant M as Monetize

    U->>A: 这周做一期讲 RAG 的内容
    A->>C: 拆任务：选题→脚本→视频→图文
    C-->>A: 返回成品（视频 + 公众号图文）
    A->>P: 按日历排期分发到 14 个平台
    P-->>A: 各平台发布结果回执
    A->>E: 启动互动监控
    E-->>A: 高转化评论 / 品牌提及上报
    A->>M: 撮合相关商单
    M-->>U: 结算结果（按效果计费）

这条流水线最值得琢磨的不是具体哪一步，而是它是一条单向但带回流的链路——内容向下流，数据向上流。这个设计直接决定了项目对"数据闭环"的把握程度比一般工具要高一档。

3.2 四块的边界划分

我把它的边界划分整理成了一张职责矩阵：

这种划分的好处是每块可以独立扩展——比如未来要新增一个新的渠道，只需要在 Publish 里加一个 connector，不会动到 Create 和 Engage 的代码；要新增一个新的生成模型，只需要在 Create 里加一个 adapter。这是经典的微服务边界做法，工程上的可维护性会高很多。

我个人的体感是：如果你只用其中一块，AiToEarn 的价值并不比同类工具突出多少；但当你把四块串起来用，它的优势就出来了。这也是为什么我建议新手第一步就把整套链路跑通，而不是只用某一个功能。

3.3 Agent 调度器和传统工具的本质差异

很多人会把 AiToEarn 类比为"另一个发布工具"，这个理解会错过它最关键的价值点。我用一个对照表说清楚：

这种差异在简单场景下感受不强，但在复杂场景下差距很大。比如"把这周写的三篇文章针对不同平台风格改写后分发"，传统工具需要你自己一步步操作；Agent 调度器你说一句话就行。

我个人觉得，Agent 化是这两年内容工具的最大演进方向，谁先做完这个转向，谁就抢占了下一阶段的工具入口。AiToEarn 在这件事上动手挺早的，从 2025 年底的 v1.4.3 就喊出 "All In Agent"，到现在 v2.x 全面接入 MCP，节奏踩得很稳。

四、Create 模块：Agent 重构内容创作流程的原理

4.1 不是"AI 生成内容"，是"Agent 编排生成"

很多人对 AI 创作的理解还停留在"输入 prompt → 输出内容"。这个理解在两年前是对的，现在不太够了。AiToEarn 的 Create 模块用的是Agent 编排式生成，差别在于 prompt 不是用户写的，是 Agent 自己拆出来再分发的。

举一个具体例子。假设你给 Agent 的指令是：

帮我做一期讲"为什么程序员都在抢着学 RAG"的短视频，时长 60 秒，要适合发抖音和 B 站。

Agent 收到这条指令之后，它不会直接调一个模型生成 60 秒视频。它会拆成下面这样的子任务流：

flowchart LR
    A[用户指令] --> B[选题分析]
    B --> C[脚本生成]
    C --> D[分镜规划]
    D --> E[逐镜画面生成]
    E --> F[配音合成]
    F --> G[字幕轨道]
    G --> H[剪辑拼接]
    H --> I[平台适配渲染]
    I --> J[抖音版本.mp4]
    I --> K[B站版本.mp4]

每一步背后都对应一个具体的模型或工具调用。这种拆法的好处是：

• 每一步的产物可控、可干预，你可以在任何一个环节改 Agent 给你的内容。
• 失败可重试，某一步挂了不用从头再来。
• 不同平台的版本可以共享前置工序，只在最后一步做适配。

4.2 它接入了哪些生成模型

从 README 和 Release Note 里能扒到的模型清单：

这里有一个我个人觉得很关键的设计——视频翻译模块。这个东西看起来不起眼，但它直接解决了一个痛点：国内做的视频，怎么自然地铺到海外平台。我之前手工搬运过，翻字幕加配音差不多要一两个小时，能自动化掉这一步真的是省事。

4.3 批量生成的工程意义

Release Note 里有一句话我特别留意：支持批量下发创作任务，Agent 可并行生成多条内容。这一句很短，但它意味着这个项目背后有一套任务调度 + 并发控制 + 结果聚合的完整体系。

我自己跑过一次批量任务：一次性下发 12 条创作任务（4 个主题 × 3 种格式）。Agent 在后台并发跑，差不多 20 分钟全部完成。这个效率拿来做矩阵账号的内容铺量是相当合适的。当然，矩阵号的合规问题需要你自己把握，工具只是工具。

4.4 新手友好的一点：参数化

Create 模块对新手友好的一点在于——参数都可以用自然语言描述。你不需要懂 prompt 工程，告诉 Agent "我要轻松幽默风格"或者"我要正式商业风格"它就能转化成内部 prompt。这个翻译层，本质上是模型的"个性提示"被预设好了，对小白用户来说门槛降了很多。

4.5 视频生成模型的差异，决定了你应该选哪个

Create 模块支持三个主流视频模型，但很多人不知道这三个模型擅长的方向其实差异挺大。我把日常使用观察到的差异列一下：

我的实操经验是：先描述好场景需求，再让 Agent 自己选模型。Agent 内部会根据 prompt 的语义特征做模型路由，比如检测到"动画""卡通""二次元"这一类关键词，会优先走 Seedance；检测到"真人""口播""产品评测"，会优先走 Grok Video。

这套路由策略在 Agent 里是可配置的。如果你对某个模型有偏好，可以在创作偏好里固定下来。

4.6 字幕和配音：被低估的细节

做过短视频的同学都知道，字幕和配音其实是最磨人的环节。AI 生成的视频如果没有字幕，发到抖音、视频号这种"无声播放"占比很高的平台，完播率会断崖式下跌。

AiToEarn 在这一块做了几件事：

• 自动生成中文字幕：识别配音内容，按句拆分，生成 SRT 字幕文件。
• 多语种字幕：基于翻译模块，可以一键生成英文、日文、韩文版字幕，同一条视频能铺到 TikTok、YouTube、Threads 这些海外平台。
• 字幕样式预设：内置了几种常见的字幕样式（抖音爆款黄字黑边、小红书简约白字、B 站漫画风），不用自己挑字体调颜色。
• 配音音色选择：男声 / 女声 / 童声 / 老年声 / 方言 都有，可以根据账号人设选。

这些都是看起来不起眼但用起来真省时间的功能。我之前自己做字幕，一条 60 秒的视频差不多要半小时；走 AiToEarn 这套，三分钟搞定。

4.7 批量任务调度：怎么避免把 API 额度打爆

批量生成有个隐藏的坑——API 额度会很快被打爆。视频生成 API 每条都是要花钱的，一次跑 12 个并发，可能十分钟就花掉几十美元。AiToEarn 在这块的设计是：

• 预算控制：每个项目可以设置预算上限，超过就暂停。
• 优先级队列：重要任务先跑，次要任务排后面。
• 失败补偿：失败的任务不重复扣额度，自动回滚。
• 结果缓存：同一 prompt 的结果会缓存，避免重复生成。

这些工程细节看起来枯燥，但在生产环境里它们就是省钱省心的关键。莫潇羽@无忆研习社第一次跑批量任务的时候没注意预算，差点把 API key 余额全花掉，后来配上预算守门员之后就稳了。

4.8 一个我常用的"模板池"玩法

Create 模块还有一个我个人用得特别多的功能——模板池。你可以把跑出过爆款的内容结构沉淀成模板，下次类似选题直接套用。一个典型的模板长这样：

template_name: 技术拆解类视频
duration: 60s
structure:
  - hook: 5s 开篇钩子（提一个反直觉的现象）
  - context: 10s 背景铺垫
  - core: 30s 核心讲解（主图 + 文字 + 旁白）
  - extension: 10s 延伸思考
  - cta: 5s 行动召唤
style:
  tone: 严谨但有趣
  pace: 中速
  visual: 简洁示意图为主

把这个模板喂给 Agent，下次只要给一个新主题，它会按这个结构生成新视频。这是把"经验"沉淀成"资产"的典型用法，也是工具能不能跟你"长期一起成长"的关键。

五、Publish 模块：多平台分发的技术机制

5.1 多平台分发的核心难点

我自己写过简单的多平台发布脚本，所以对这块的难点比较了解。多平台分发听起来简单，难点其实集中在三块：

• 登录态管理：每个平台 OAuth 流程都不一样，token 刷新机制也不同。
• 格式适配：抖音和 B 站的视频参数（分辨率、比特率、时长）要求不一致，文案的字符数限制也不同。
• 风控对抗：批量发布很容易触发平台的风控，尤其是新号。

AiToEarn 的解法在工程上是相当老练的：

graph TB
    Content[内容资产] --> Adapter[平台适配器]
    Adapter --> A1[抖音 Adapter]
    Adapter --> A2[小红书 Adapter]
    Adapter --> A3[视频号 Adapter]
    Adapter --> A4[YouTube Adapter]

    A1 --> Auth[OAuth 凭证管理]
    A2 --> Auth
    A3 --> Auth
    A4 --> Auth

    Auth --> Relay[Relay 中继服务]
    Auth --> SelfApp[自有开发者凭据]

    Relay --> Channels[各平台开放接口]
    SelfApp --> Channels

这里最有意思的是 Relay 模式。

5.2 Relay 中继：为什么开发者凭据这件事这么棘手

这一段对自部署的同学特别重要，所以我多花点篇幅写。

按理说，要发内容到抖音、小红书、TikTok 这些平台，开发者得先去这些平台申请开发者账号、注册应用、拿到 client_id 和 client_secret，然后用户走 OAuth 流程授权。问题在于：

• 抖音、视频号、小红书的开放平台对开发者的资质审核相当严格。
• 个人用户基本拿不到。
• 中小团队也很难走通流程。

如果没有 Relay，自部署用户就会卡在"拿不到开发者凭据 → 没法做 OAuth → 用户没法授权 → 整个 Publish 模块用不起来"的死循环里。

AiToEarn 的处理方式是——官方 aitoearn.ai 已经申请到了一套开发者凭据，自部署用户可以"借用"这套凭据完成 OAuth 授权，发布动作还是在你自己的服务器上执行。这套设计在工程上叫"OAuth 中继"，技术上没什么稀奇，但它把自部署的最大障碍移走了。

如果你有能力和资质自己申请各平台凭据，也可以不走 Relay，在配置里替换成自己的 client_id 和 secret 即可。

5.3 日历排期的实现思路

排期功能我个人用得最多，所以专门写一下我观察到的实现方式：

• 任务队列：基于 Redis 的延时队列，到点出队执行。
• 发布前检查：执行前再校验一次内容是否还在、token 是否还有效。
• 失败回退：发布失败的任务进入重试队列，重试 N 次仍失败则告警。
• 跨时区处理：海外平台的发布时间会自动转换。

这套排期逻辑，自己造轮子至少要一周。AiToEarn 直接给你接好了。

5.4 一个我个人的小实操经验

排期这件事有个反直觉的点：不要把所有平台都设成同一时间发。我开始的时候图省事，所有平台 9 点一起发，结果几个号在同一天被同时打了流量限制。后来我把发布时间拉开，比如抖音 9 点、小红书 12 点、B 站晚 8 点，效果稳定多了。这个经验和工具本身无关，但和"工具怎么用"有关。

5.5 各平台的内容偏好差异：被低估的"软规则"

AiToEarn 能帮你解决"格式适配"，但它解决不了平台的内容偏好差异。这一块是创作者必须自己理解的：

AiToEarn 的 Create 模块支持"同主题多版本生成"——你给它一个主题，它能针对不同平台分别生成对应风格的版本。这一招比"一键搬运"高明得多。搬运是在透支账号信用，差异化分发是在养账号。

5.6 风控对抗：不是和平台斗，是和自己的"懒"斗

很多人对自动化分发有一个误解——觉得只要工具够强，就能绕过平台风控。这个想法在 2020 年之前可能还行得通，现在不行了。各大平台的风控模型已经能识别出绝大多数"机器味"明显的发布行为：

• 凌晨 3 点准时发布、误差不超过 1 秒
• 几个账号同时发布同一条内容
• 发布频率突然飙升
• IP 地址跳变剧烈

这些都是典型的"机器特征"。AiToEarn 在这一块做了几件事：

• 发布时间随机抖动：你设置 9 点发，实际会在 8:55-9:05 之间随机选一个时间点。
• 多账号错峰：同主题内容发到多个账号时，发布间隔会自动拉开。
• 频率守门员：单账号每天发布上限可控，避免突然飙升。
• IP 一致性：同一账号的所有操作尽量从同一 IP 出口。

这些都是给"自动化"披上"人工感"外套的做法，不能保证绝对安全，但能显著降低被风控的概率。

5.7 一个真实踩坑：cookie 失效之后

我自部署的时候遇到过一个问题——绑定的小红书账号 cookie 过了三天就失效了。一查才知道，小红书的 cookie 有效期就那么短，需要定期刷新。AiToEarn 在这一块的处理是：

• 后台定时检查 cookie 有效性
• 失效前 24 小时弹通知，提醒重新授权
• 失效后所有相关任务自动暂停，不会无声无息地失败

这个设计救了我好几次。如果失败了不告诉你，等几天后才发现一堆任务都没发出去，那就更崩溃了。

六、Engage 模块：浏览器插件 + AI 回复的实现思路

6.1 为什么互动这件事要走插件

服务器端能搞定的事情，AiToEarn 都尽量在服务器搞定。但有一类事情服务器搞不了——模拟用户在浏览器里做点赞、收藏、评论。这类操作必须在用户的浏览器上下文里发生，因为：

• 浏览器里有完整的登录态。
• 平台的反爬策略主要针对服务器端请求。
• 用户行为信号（鼠标轨迹、停留时长）需要真实浏览器才能产生。

所以 Engage 模块的实现路径是浏览器扩展，跑在用户自己的 Chrome 里。这是一种取舍：自动化能力会比纯服务器方案弱一些，但能避开大部分平台的反爬封禁。

6.2 插件能做的四件事

整理一下插件的核心能力：

这四件事里，AI 智能回复是最值得展开聊的。

6.3 AI 智能回复的"品质区"

智能回复这件事，做不好就是灾难——通用化的 AI 回复会让账号显得非常"机械感"，反而损害账号调性。AiToEarn 的处理方式是：

• 支持自定义回复风格：你可以设定"温和专业""活泼有梗""理性技术派"这类风格标签。
• 结合发布内容上下文：回复时把原帖内容也一并喂给大模型，避免答非所问。
• 过滤敏感词：回复前过一遍敏感词检测，避免触发平台风控。
• 人工接管位：高价值评论（比如直接问"怎么合作"的）会标记出来，让你手动回，不让 AI 顶上。

这个设计相当克制，没有把 AI 当万能锤。我自己用下来，配合"高价值评论人工接管"这条规则，账号的互动调性能保住。

6.4 用插件而不是脚本的好处

很多人会问：为什么不用 Selenium、Playwright 这种自动化框架？我自己反复对比过，结论是插件方案对普通用户更友好：

• 插件直接装到 Chrome 上，不用配 Python 环境。
• 不用单独维护一套浏览器实例。
• 用户切换账号、用其他网页时不会被打扰。
• 卸载干净，不留痕迹。

这是工程师视角和用户视角不一样的地方，AiToEarn 显然把用户视角放得更靠前。

6.5 浏览器插件的实现原理：一段技术番外

对实现感兴趣的同学，我把插件的工作机制简单画一下：

graph TB
    subgraph Chrome浏览器
        Page[当前网页 抖音/小红书]
        Content[content_script 注入到页面]
        Background[background_service]
        Popup[插件弹窗UI]
    end

    Page <--> Content
    Content <--> Background
    Background <--> Popup
    Background <--> Server[AiToEarn 后端]

    Server --> LLM[大模型 API]

具体到执行层面：

• content_script 负责观察页面 DOM 变化（新评论、新私信、新提及）。
• background_service 接收 content 上报，调后端 API。
• 后端 把信息转给大模型，生成回复或挖掘信号。
• 回复 被回写到 background，再分发给 content_script，注入到页面输入框。

整套流程对用户来说是无感的——你正常浏览页面，插件在你看不到的地方默默干活。这种"贴在浏览器上的影子智能体"模式，是这两年 AI 工具的一个显学。

6.6 几种自动回复策略的对比

自动回复有四种常见策略，AiToEarn 都支持，但适用场景不一样：

我个人推荐第四种分层处理。规则也很简单：

• 评论里有"求链接""怎么买""能合作吗""加微信"这一类信号 → 标记为高价值，人工接管。
• 评论是普通互动（"挺好""学到了""支持""赞"）→ AI 自动回。
• 评论是负面 / 黑评 → 不回，让算法自然降权。

这套规则跑半年下来，我的账号互动调性基本没掉。

6.7 品牌监测：被低估的舆情雷达

品牌监测这个功能我开始没怎么重视，后来真的派上用场了。它能干什么？

• 实时追踪关键词：你设置"莫潇羽""无忆研习社"这些关键词，全网哪里有人提到都会推送给你。
• 情感倾向分析：每条提及会被标记为正面 / 中性 / 负面。
• 热度排序：按互动量排序，优先看高曝光的提及。
• 快速响应入口：点一下就能跳到原帖，加入互动。

我自己有一次发现某个评论区在讨论我之前写过的一篇文章，跑过去回了几条，那篇老文章重新被推了一波。舆情雷达 + 快速响应，是把"被动等流量"变成"主动养流量"的关键手段。

6.8 一个反向用法：用 Engage 数据反哺 Create

互动数据本身就是创作信号。AiToEarn 把 Engage 模块和 Create 模块做了打通：

• 高互动评论 → 提取关键词 → 反哺到选题池
• 用户提问 → 整理成 FAQ → 生成"答疑型"内容
• 负面评论 → 分析常见担忧 → 写"深度澄清"内容

这一套"反向喂料"机制能让创作者跳出"我以为大家想看什么"的自嗨陷阱，真正按用户需求生产内容。这是工具帮你做"客户研究"的能力，价值很高但很多人没注意到。

七、Monetize 模块：内容商单匹配的运行逻辑

合规说明在前：这一节讲的是项目里"内容交易市场"这个模块的工作原理和结算机制，是工程层面的技术拆解，不构成任何参与建议。读者要不要参与、能不能参与、有什么风险，都需要自行判断。

7.1 这个模块解决的是什么问题

内容创作者长期面对的一个错配问题是：写内容的不知道哪些品牌愿意付费、品牌方不知道哪些创作者匹配自己。AiToEarn 内置的内容交易市场，本质上是一个双边匹配平台：

graph LR
    Brand[品牌方/商家] -->|发布需求| Market[内容交易市场]
    Creator[创作者] -->|接单| Market
    Market -->|匹配| Match[内容生产任务]
    Match -->|发布| Channels[14+ 平台]
    Channels -->|数据回流| Settle[结算引擎]
    Settle -->|按效果| Brand
    Settle -->|按效果| Creator

这个匹配过程里，最重要的部分是结算引擎。

7.2 三种结算模式

项目支持三种以效果为导向的结算模式：