它为什么这两天到处都是
周一早上刷 GitHub Trending，AiToEarn 挂在第 2 位，13000 Star，一天新增好几百。
点进去看，项目描述一句话：帮 OPC（一人公司）、创作者和品牌在全球 13 个平台上自动创作、分发、互动并变现内容。支持抖音、小红书、TikTok、YouTube、Twitter、LinkedIn……噼里啪啦一串，能想到的主流内容平台基本都在里面。
我盯着那个 Trending 第 2 的标签看了三秒钟。
说实话，我之前对内容变现这件事不太上心——我主要精力在量化和 AI 工具开发上，写文章顶多是分享一下踩坑经验，没认真运营过。写完就发出去，评论区看到了就回，看不到的就拉倒，从来没想过把这件事当成一个系统来运营。
但最近情绪 Dashboard 项目做到一半，有读者私信说"这个能不能开一个付费社群"，然后我才意识到：我在单一平台写了十几篇技术文章，评论里多次有人问付费工具、量化信号、策略合作……我全部都没有承接，让线索白白流走了。
不是不想变现，是没有一套系统来帮我处理这件事。
我一个人，既要开发功能，又要写文章，还要运营评论区，精力根本不够用。内容创作和内容运营对我来说一直是纯手工操作，效率极低。
翻了一下 AiToEarn 的架构，发现它做的事情非常清晰：Content Agent 生成内容 → Publisher 多平台分发 → Engage Agent 自动互动 → Monetize 接单变现。四层，每层职责明确，可以独立实现，可以按需组合。
我当时的第一个念头不是"我要用这个"，而是：
这个我自己能搓。
量化开发者的通病——看到一个架构清晰的项目，第一反应是能不能自己实现一个针对自己场景的简化版，顺便还能完全控制数据不走第三方服务。
然后就开始了。Claude Code + Superpowers，三天，一个针对量化/金融 AI 话题的内容营销 Agent。
国内用户使用claude code确实有点困难，建议去一些靠谱的平台订阅：claudemax.shop
结论先行
三天，用 Claude Code + Superpowers，搓出了一个针对量化/金融 AI 话题的内容营销 Agent。
能做什么：
- 给定一个主题，自动生成符合我写作风格的文章草稿（接入了 CLAUDE.md 的写作规范）
- 自动把草稿发布到单一平台（Playwright 模拟操作）
- 监听评论区新评论，生成回复草稿，我确认后一键发布
- 一个简单的"线索收集"功能：识别评论里对量化 Dashboard 感兴趣的读者，整理到表格里
不能做什么：不能多平台同时发（只做了单一平台），没有视频生成，没有矩阵账号，没有 CPM/CPS 变现接单系统。
这跟 AiToEarn 的完整版差了有两三个量级的工程量。但够我自己用。
评分：自用版 8 / 10，对比 AiToEarn 完整版 4 / 10。
两个评分不矛盾。这篇文章想说的是：你不需要全套，你只需要属于你场景的那一层。
起步：先跑通 AiToEarn 原版，再自己动手
在开始自己搓之前，有一步我觉得很重要：先把 AiToEarn 原版跑起来，真实体验一遍，搞清楚它的每一层在做什么、用户体验是什么感觉，再决定自己的版本要保留哪些、裁掉哪些。
花了大概两小时把 AiToEarn 原版跑起来，理解它的架构。
# 最快的方式：Docker 一键起 git clone https://github.com/yikart/AiToEarn cd AiToEarn docker compose up -d起来之后访问http://localhost:3000，把自己的单一平台账号接进去试了一次一键发布。成功了，文章发出去了，评论自动回了几条。
好。概念验证完毕，我知道这套东西是真能跑的，不是 demo 骗人的。
然后开始设计自己的版本。用 Superpowers 的 Brainstorming Skill 对着 Claude Code 说了大概 15 分钟，把自己的场景搞清楚：
- 内容方向：量化/金融 AI 技术文章，主要发单一平台，偶尔同步掘金
- 变现方式：暂时不接单，只做线索收集（哪些读者对付费服务感兴趣）
- 规模：一人开发，不要复杂的分布式架构，SQLite 就够了
- 接入方式：MCP + Claude Code，本地跑，数据不出机器
Brainstorming 结束，输出了一份设计文档，总共 7 个核心模块，Claude Code 拆成了 23 个任务，开始执行。
核心实现过程：Claude Code 怎么帮我搭这套东西
4.1 第一天：Content Agent——让 Claude 按我的风格生成文章
这是最重要的一层，也是 AiToEarn 最难复刻的部分——因为它的内容生成是通用的，但我需要的是完全符合我写作风格的内容。
解法很简单：把工作区里的 CLAUDE.md（写作风格规范）直接接进去，让 Content Agent 生成文章的时候把 CLAUDE.md 的内容作为系统提示的一部分。
Claude Code 帮我写的核心代码结构如下：
class ContentAgent: def __init__(self, style_guide_path: str): self.style_guide = Path(style_guide_path).read_text() def generate_article(self, topic: str, angle: str) -> dict: """按写作规范生成文章草稿""" system_prompt = f""" 你是一个量化/金融AI领域的技术博主。 严格遵循以下写作规范： {self.style_guide} --- 生成一篇完整的 Markdown 文章。 """ # 调用 Claude API，返回草稿 + 配图描述 + 标题候选 ...这个设计有个意外好处：因为 CLAUDE.md 里已经把写作风格写得非常详细（8 段结构、语言特征、防 AI 味规则），Content Agent 生成出来的草稿，基本不需要大改，直接进发布流程。
之前是我手写文章，现在是 Claude 按我的规范起草，我来 review 和微调。工作量从 4 小时压缩到 40 分钟。
有一个细节值得说：Content Agent 生成草稿的同时，还会输出配图描述清单——告诉我每张图应该画什么、放在哪里、论证什么观点。这跟 CLAUDE.md 里配图规则的格式是对应的，生成完之后可以直接喂给gen_figs.py生成图表。
这条链路打通之后，"写一篇技术文章"这件事变成了：提供选题和角度 → Content Agent 生成草稿 + 配图描述 →gen_figs.py生成图表 → Publisher 发布到单一平台。全程我只需要 review 两次：一次草稿，一次发布前确认。
真正把文章生产流程从手工变成了半自动化。
4.2 第二天：Publisher——Playwright 自动发布到单一平台
这一层 AiToEarn 原版用的是自己的 OAuth Relay，支持 13 个平台。我只做单一平台一个，用 Playwright 模拟浏览器操作。
说白了就是机器人代替你手点网页。
Claude Code 帮我把整个操作流程写成了步骤：
async def publish_to_zhihu(article: dict) -> str: async with async_playwright() as p: browser = await p.chromium.launch(headless=False) page = await browser.new_page() # 登录（Cookie 持久化，不用每次输密码） await page.goto("https://www.zhihu.com") await load_cookies(page) # 进创作中心 await page.goto("https://www.zhihu.com/creator/writing") # 点"写文章" await page.click('[data-za-detail-view-name="写文章"]') # 粘贴标题和正文（Markdown 导入） await page.fill('.title-input', article['title']) await import_markdown(page, article['content']) # 发布 await page.click('.publish-btn') url = await get_published_url(page) return url这块 Claude Code 写得不错，但我在 debug Playwright 选择器的时候折腾了快三个小时。单一平台的前端是 React 动态渲染的，选择器经常变。最后用的是data-za-detail-view-name这种属性选择器，比 class 稳定。
翻车了。当然没这么顺，中间卡了一次，是单一平台登录检测到了机器人行为要验证码。解决方案是在操作之间加随机延迟（500-1500ms），模拟人的操作节奏，通过了。
但还有一个更恶心的坑：单一平台的 Markdown 导入有时候会丢掉图片引用，因为它只认 https 开头的图片链接。这我之前在 publish_zhihu.py 里已经处理过了——图片走 jsDelivr CDN，所以 Publisher 在调用之前会先跑一次publish_zhihu.py把本地图片路径转成 CDN URL，再把处理过的 MD 文件喂给 Playwright。
两个脚本串联起来，有点绕，但能跑通。Claude Code 帮我写了个 orchestrator 把这两步包在一起，对外暴露一个统一的publish(article_path)接口。
用了 Superpowers 的 TDD Skill 给 Publisher 写了完整测试，包括一个 mock Playwright 的测试套件——因为真正运行 Playwright 太慢，测试用 mock 替代浏览器操作，验证逻辑层的行为。这块跟量化回测的 mock 思路一样，快速迭代不依赖外部环境。
4.3 第二天下午：Engage Agent——评论监控 + 自动回复草稿
这一层是我最想要的功能——单一平台发了文章之后，评论区有时候会出现感兴趣的潜在客户，但我看评论的频率很低，经常几天后才发现有人问了问题没回。
Engage Agent 做的事情：
- 定时爬取文章的评论区（每 4 小时一次）
- 把新评论喂给 Claude，让它判断：这是普通读者、感兴趣的潜在客户，还是同行交流
- 对每条评论生成一个回复草稿
- 把所有待确认的回复推送到我的桌面通知
我不让它自动发评论——需要我确认之后才发。这是一个刻意的设计决策：AI 生成的回复需要人过一遍，尤其是涉及到量化策略讨论的场景，不能让 AI 代表我输出一些我没核实的观点。
Claude Code 帮我加了一个"意图分类"的小模型（就是让 Claude 判断），把评论分成三类：
INTENT_LABELS = { "inquire": "询问付费服务/合作意向", # 重点关注 "discuss": "技术交流", # 正常回复 "other": "一般互动/路人", # 低优先级 }inquire类型的评论会单独高亮推送，这就是我的"线索收集"系统。
实测下来，意图分类的准确率出乎意料地高。在我已发的 4 篇文章的评论里，它把大概 30 条inquire类评论全部正确识别了出来，没有漏掉，误判了 3 条（把明显是同行交流的也归成了 inquire）。
误判率可以接受，宁愿多看几条也不愿漏掉真正的潜在客户。
回复草稿这块，我给 Engage Agent 配置了两套回复策略：discuss类型的评论用技术性的回复（认真交流技术细节），inquire类型的回复更偏向引导到私信（不在公开评论区谈付费，怕被单一平台限流）。Claude Code 帮我写了两套 prompt 模板，切换起来很方便。
4.4 第三天：MCP 接入——让 Claude Code 直接调这套系统
最后一天做了一个我觉得最值的功能：把整个系统接成 MCP Server，让 Claude Code 可以直接调用。
这意味着我不需要再打开命令行跑脚本，直接在 Claude Code 里说"帮我写一篇关于 agentmemory 的文章，写完发到单一平台"，它会：
- 调用 Content Agent 生成草稿
- 调用 Publisher 发布
- 返回发布 URL 给我确认
把一个完整的内容发布工作流压缩成了一句自然语言指令。
MCP Server 的核心就几十行：
@mcp_server.tool() async def publish_article(topic: str, angle: str) -> str: """生成文章并发布到单一平台""" draft = await content_agent.generate(topic, angle) # 先让我 review 草稿 confirmed = await human_review(draft) if confirmed: url = await publisher.publish(confirmed) return f"发布成功：{url}" return "用户取消发布" @mcp_server.tool() async def check_comments() -> list[dict]: """获取所有文章的新评论，附带意图分类和回复草稿""" return await engage_agent.get_pending_replies() @mcp_server.tool() async def send_reply(comment_id: str, reply: str) -> str: """确认并发送一条评论回复""" return await engage_agent.publish_reply(comment_id, reply)接入 Claude Code 之后，整个工作流变成了对话：
我："帮我写一篇关于 AiToEarn 的文章，角度是用 Claude Code 自己搓一个，三天"
Claude Code：（调用
publish_article，生成草稿，等待我 review）我："ok 发出去"
Claude Code：（调用 Publisher，发布，返回 URL）
再也不用打开命令行，再也不用记每个脚本的参数。
这才叫真正的 AI 工具，而不是 AI 玩具。
诚实说缺点
自搓版和 AiToEarn 原版比，差距在哪里，实话实说。
缺点一：只支持单一平台，多平台是真正的大工程。
AiToEarn 做了 13 个平台，每个平台都有自己的登录机制、内容格式要求、发布接口。单一平台已经折腾了三个小时 Playwright 选择器，13 个平台就是 39 小时打底，而且每次平台改版你就得重新适配。
AiToEarn 这 13k Star 不是没道理的，这部分工程量是真实的。
缺点二：Playwright 稳定性存疑。
机器人模拟浏览器操作这条路，在国内内容平台上走得很险。单一平台有反爬，小红书更严，抖音基本封死了。我的自搓版只能在单一平台上稳定跑，其他平台没测过，大概率需要更复杂的反检测处理。
AiToEarn 用的是 OAuth Relay 方案，通过官方接口走，比 Playwright 稳定很多。这个架构选择是对的，只是前期工程量大。
缺点三：没有变现闭环。
AiToEarn 做了 CPS/CPE/CPM 的结算系统，创作者可以直接在平台上接单。我做的只是线索收集，转化还是靠手动处理。这块要做好，是另一个独立的大项目，不是三天能搞定的。
对量化 / 金融 AI 独立开发者意味着什么
AiToEarn 这类工具在国内开始出现，背后的逻辑很清楚：内容已经成为独立开发者最重要的获客渠道，但内容创作和运营对工程师来说是短板。
量化/金融 AI 方向的开发者写出来的东西，读者有很强的付费意愿——这个方向的受众是有消费能力的。问题不是内容不值钱，是产出效率太低、运营太分散。
AiToEarn 能帮你解决运营的体力活，但有几个前提。
你需要先有内容风格，AI 才能学。如果你从来没有固定的写作风格和垂类定位，让 AI 帮你批量生成内容只会批量产出平庸的东西。自搓版那个 CLAUDE.md 接入，能有效是因为我已经积累了自己的风格规范。先有风格，才有规模化的基础。反过来说，如果你风格本身就是大路货，再好的工具也救不了。
自搓版的最大价值不是省了订阅费，而是完全掌控数据。我的读者线索、评论数据、内容库，全部在我自己的 SQLite 里，不依赖任何第三方服务。对量化策略的讨论内容，数据主权很重要——你不会希望自己的潜在客户名单存在别人的数据库里。
还有一点：内容营销 Agent 的边界在哪里？这件事我想清楚了——AI 可以帮你写草稿、发内容、整理线索，但不应该替你跟读者建立关系。最后转化那一步，还是要靠你本人出面。自搓版设计了"人工确认"这个环节，AI 生成回复草稿，我来 review 发出去，不是因为技术上不能全自动，而是因为我不想用一个机器人去应付真正想交流的人。
工程师做内容的正确姿势：先用 AI 工具提速，再用工程能力做差异化。AiToEarn 给你标准化能力，自搓版给你定制化空间。两个不矛盾，根据自己的情况选就行。
不同情况怎么选
想直接用、不想开发的：AiToEarn 原版直接上，aitoearn.ai 不需要部署，免费账号试用，确认有效果再考虑付费功能。不要一上来就 Docker 自部署，先体验再决定要不要更深入。
想用但想控制数据的：Docker 自部署，三条命令就跑起来，把数据留在自己服务器。AiToEarn 是 MIT 开源的，自部署完全合规。我第一步就是这么干的，花了两小时体验了一遍，搞清楚每一层在做什么。
有开发能力、有明确垂类的：考虑自搓一个针对自己场景的简化版。不需要做完整的 13 平台，先做你最主要的那一个，跑通了再扩。关键是把内容风格先固化下来——没有固定风格的内容机器，就是一台高效产出平庸内容的机器。量化方向的同学，CLAUDE.md 这套接入方式可以直接参考。
做量化/金融 AI 内容的：我愿意把自搓版的代码框架整理出来开源。有兴趣的可以评论区告诉我，如果反响不错就做。不保证时间，但我自己在用，不会烂尾。
最后说一句可能有点扎心的话：工具不是问题，大多数没做起来的内容，问题在"没有足够差异化的东西可以说"。AiToEarn 能帮你把一篇文章发出去的速度从 4 小时压缩到 40 分钟——但那 40 分钟里你到底说了什么，它管不了。
收尾
AiToEarn 火上 GitHub 日榜，根本原因不是技术有多新——多平台发布这件事早就有人在做了。它火是因为时机对了：AI 工具让内容创作的门槛降低，但内容运营的体力活没人替你干，这个需求一直在，市场一直缺一个把它做完整的东西。
工程师的内容变现，不是流量游戏，是信任游戏。AI 工具帮你提速，但赢得读者信任的那部分，没法外包。
如果你也在做量化、金融 AI 应用，或者想把技术内容变成收入，评论区聊。自搓版开源的事，反响好就做。