我用 Muse 搭建了一套 X 账号自动化运营系统：从选题、写作到发布
图：X 账号自动化运营系统——Agent 生产，人确认，规则约束行为。
2026 年 10 月 11 日，我开始用 Muse 运营一个 X 账号。
账号名是 Mango.ETF，定位 AI、美股、加密资产和 ETF 中文内容。启动时只有 29 个粉丝，第一阶段目标是增长到 500 个。
我不打算每天花几个小时找新闻、改写文案、制作配图、发布帖子，再逐条检查评论区。更想尝试的是：把这些重复工作拆解成一套可以持续运行的自动化流程。
于是，我把 Muse、定时任务、规则文件、浏览器操作和运行状态管理组合起来，搭建了一套账号运营系统。
系统每天按计划收集信息、生成草稿、检查内容、记录运行状态，并把待发布内容发给我确认。评论巡查、突发新闻监控和粉丝数据追踪也被拆成独立任务。
整个系统的核心思路是：
让 Agent 负责重复执行，让规则负责约束行为，让人负责方向、关键决策和结果验收。
这篇文章记录实际采用的架构、内容生产流程、风控设计、踩过的坑，以及如何从零搭建类似的系统。
需要说明的是，本文记录的是截至 2026 年 10 月 13 日的早期实战。系统已经开始运行，但增长效果、各项规则的有效性以及长期稳定性仍需要持续验证。
一、先把运营工作拆成一条流水线
一个人运营 X 账号，真正耗时的往往不是写某一条帖子，而是每天重复完成整条工作链。
选题需要寻找信息源，写作需要核实事实，发布需要检查格式，评论需要判断是否值得回复，运营还需要追踪数据并调整策略。
如果每一步都依赖人工操作，工作就很难持续。
我的做法是把整个系统拆成四层。
规则层：x-ops/*.md
定义选题、写作、风控、回复和验收标准
↓
调度层：cron 定时任务
按计划触发不同运营任务
↓
执行层：Muse Agent + 浏览器
收集信息、生成草稿、执行获准的操作
↓
状态层：state.json + logs/
记录运行状态、执行结果、异常和熔断状态四层各自解决不同的问题。
规则层决定任务应该怎么做；调度层决定什么时候做；执行层负责实际工作；状态层负责记录发生了什么，以及系统是否应该继续运行。
这样设计的好处是，修改写作规则不必重写定时任务，增加一个监控任务也不必推翻原来的内容生产流程。
更重要的是，任务失败时可以定位问题究竟出在规则、调度、执行还是状态管理。
图：四层架构——规则层、调度层、执行层、状态层各司其职。
二、把运营方法写进文件，而不是只写进提示词
这套系统最重要的设计，是把运营经验沉淀为独立的 Markdown 文件。
我使用的工作区结构如下：
x-ops/
├── rewrite-rules.md
├── risk-control.md
├── sources-manual.md
├── reply-templates.md
├── follow-list.md
├── viral-playbook.md
├── algorithm-report.md
├── forab-style.md
├── state.json
├── follower-tracker.md
└── logs/每个文件负责一类规则。
| 文件 | 主要职责 |
|---|---|
| rewrite-rules.md | 选题标准、文案结构、事实核验和发布前检查 |
| risk-control.md | 发布频率、内容红线、权限控制、暂停和恢复机制 |
| sources-manual.md | 信息源分级、抓取路径、可用性与降级方案 |
| reply-templates.md | 评论回复原则、常见场景与人工介入条件 |
| follow-list.md | 记录值得研究的创作者及其内容方法 |
| viral-playbook.md | 记录经过观察和测试的内容策略 |
| algorithm-report.md | 记录推荐算法的代码出处、版本和分析结论 |
| forab-style.md | 配图原则与文字、图片之间的分工 |
| state.json | 暂停状态、登录检查结果、发帖记录和运行状态 |
| follower-tracker.md | 每日粉丝数、净增长与阶段性目标 |
| logs/ | 保存草稿、信源、执行结果和异常记录 |
这相当于给 Agent 建立了一套外部工作手册。
如果只把所有要求写在一次对话里，随着任务增加，规则容易遗漏，也难以追踪修改历史。把规则保存为文件后，就可以单独迭代、复核和版本管理。
不过，规则文件不是安全边界本身。Agent 仍然可能误解规则，甚至忽略规则。因此，关键约束必须尽可能通过程序校验、权限设置和任务执行前检查来落实。
例如，文案长度可以通过代码检查；重复内容可以通过文本相似度检测；暂停状态可以由调度器直接判断；涉及高风险操作的任务则可以要求人工确认。
自然语言负责描述意图，程序负责落实可以明确验证的约束。
三、内容生产线：从新闻到可发布的草稿
这条流水线分为选题、核验、重写、配图和发布前检查五个环节。
1. 选题：只处理有事实依据的信息
账号的主要方向是 AI、美股、加密资产和 ETF。
目前优先关注 NVDA、AVGO、MU、NBIS、TSLA、AMD、META、MSFT 和 TSM 等公司，同时跟踪 AI 基础设施、稳定币、ETF、宏观经济与政策变化。
信息源分为三个层级：
- 核心来源：公司公告、财报、监管机构文件、官方发布，以及经过验证的现有信息管线。
- 辅助来源：财经媒体、分析师评级变化和专业研究机构的公开材料。
- 降级来源：当原始来源暂时无法访问时，使用可追溯的搜索结果寻找替代来源，并明确标注信息的不确定性。
每个新信息源都需要先验证抓取路径，至少能够稳定获得标题、链接和发布时间，才能进入正式流程。
选题主要关注过去 24 小时发生的事件，例如财报、产品发布、评级变化、政策调整和重要市场波动。
但这里有一个重要区别：24 小时是选题优先级，不是事实有效期。涉及长期影响的事件，即使发生时间较早，也可能值得重新分析。
同样，搜索结果中出现一条新闻，不代表新闻内容已经得到证实。重要数字应尽可能回到原始公告、财报或数据发布机构核对。
2. 重写：把信息压缩成一个明确观点
目前的短帖规则是：
- 默认控制在 100—140 个中文字左右，根据内容复杂度调整。
- 开头直接呈现数字、事实反差或核心判断。
- 一段只表达一个主要观点。
- 关键数字必须能够追溯到来源。
- 区分已知事实、媒体报道和个人推论。
- 不使用没有证据支撑的夸张形容词。
- 不把市场观察包装成确定的投资结论。
例如，一条财报新闻可以采用这样的结构：
核心事实：公司公布了什么数据？关键变化：与上一季度、去年同期或市场预期相比，发生了什么变化？分析意义：这个变化可能说明什么？信息来源：原始公告或可靠报道链接。
这套结构的目的，是避免 Agent 把一条新闻扩写成一段看似专业、实际上没有增加信息量的文字。
钩子可以使用数字、时间反差、反直觉结论等形式，但不能为了吸引注意力而改变事实的含义。
3. 配图：让图片承担证据功能
图文内容采用一个简单原则：文字负责解释为什么值得关注，图片负责提供可核实的依据。
配图优先级为：
- 公司公告、财报或官方数据截图。
- 可以追溯来源的数据图表。
- 与事件直接相关的公开图片。
- 在确有必要时使用原创示意图。
图片需要检查来源、时间、上下文和版权许可。截图应尽量保留足够的信息，避免截掉关键限定条件，造成误读。
图片数量由内容决定，不必为了提高视觉丰富度而强行添加图片。
4. 发布前检查：把错误拦在发布之前
每条草稿需要通过以下检查：
- 信源链接可访问，且确实支持文案中的主要结论。
- 数字、时间、公司名称和单位正确。
- 事实、报道和推论没有混淆。
- 与近期内容不存在明显重复。
- 文字清楚，没有模板化的空话。
- 草稿、信源和检查结果已经写入日志。
如果任何一项未通过，草稿就退回修改；涉及关键事实但无法核实的内容，直接放弃。
这一步看起来会增加工作量，但它的作用是减少错误发布后再补救的成本。
图：内容生产线——选题、核验、重写、配图、发布前检查五个环节。
四、定时任务：让每种工作独立运行
目前使用 cron 调度不同任务，时间均按北京时间计算。
| 任务 | 计划时间 | 职责 |
|---|---|---|
| x-post-noon | 每天 12:15 | 生成午间内容草稿 |
| x-post-evening | 每天 21:00 | 生成晚间内容草稿 |
| x-comments-evening | 每天 21:30 | 整理近期评论和提及 |
| x-breaking-watch | 每小时 | 监控重要突发事件 |
| x-follower-daily | 每天 08:18 | 记录粉丝数据 |
| x-health-check | 每周日 21:00 | 检查系统健康状态 |
| x-musk-watch | 每天早间 | 整理马斯克近期公开动态 |
| x-musk-digest | 每天 22:18 | 汇总当天收集的素材 |
这些时间是当前的调度配置，并不代表它们已经被证明是最佳运营时段。
冷启动阶段，评论量较少，因此可以先降低巡查频率，把资源投入内容生产和事实核验。随着真实互动增加，再根据需要调整任务。
突发监控也不应仅仅因为某个关键词突然热门就自动发布。系统需要检查事件是否足够重要、信息是否可靠、是否与账号定位相关，以及是否已经发布过相同内容。
定时任务的价值，是让流程可以稳定触发；内容是否值得发布，仍然需要经过独立判断。
五、从草稿到发布：人类保留最后确认权
当前采用的发布流程如下：
定时任务触发
↓
检查系统是否处于暂停状态
↓
读取规则文件和近期发布记录
↓
收集信息并生成草稿
↓
执行事实核验和发布前检查
↓
发送草稿、信源和检查结果
↓
人工确认
↓
通过合规的发布方式完成发布
↓
核对实际发布结果并记录日志草稿发给我时，会附带四项内容：完整文案、选题摘要、信源链接，以及选择这个角度的理由。
这样我不必重新检查所有原始材料，只需重点判断事实是否可靠、观点是否值得发布，以及是否符合账号定位。
确认后才进入发布环节。
这里有一个需要特别说明的平台限制：X 当前的自动化规则明确警告，不应使用通过脚本操作 X 网站的非 API 自动化方式，这可能导致账号被永久停用。
因此，复用浏览器登录态虽然是这套系统早期探索过的执行路径，却不能因为它技术上可行，就认定它符合平台规则。正式长期运行时，应优先采用 X 允许的发布方式；如果没有可用且合规的接口，就保留人工发布步骤。
这也解释了为什么我不把"零人工操作"作为系统的最高目标。
真正重要的是减少重复劳动，同时保留账号控制权、操作可追溯性和可接受的风险水平。
图：人类保留最后确认权——草稿先发人审核，确认后才发布。
六、评论区巡查：先判断，再决定是否回复
评论处理分成发现、分类、核实和回复四个步骤。
系统首先读取近期帖子、评论和账号提及，再根据上次巡查记录识别新内容。
这里使用评论 ID 作为检查水位线，比只记录最后一次巡查时间更可靠。时间可能相同，也可能受到排序变化影响，而稳定的内容 ID 更适合用来判断是否处理过某条评论。
评论大致分为以下几类：
| 类型 | 处理原则 |
|---|---|
| 数据补充 | 核实后补充来源和事实 |
| 指出错误 | 重新核对，确认有误就更正 |
| 观点讨论 | 结合具体论据回应 |
| 无法核实的问题 | 标记并交由人工判断 |
| 广告、骚扰或纯引战内容 | 通常不参与讨论 |
评论模板只用于辅助表达，不应让所有回复看起来像同一个程序生成的标准答案。
还要注意，评论自动化有单独的平台限制。X 对自动回复、主动提及和 AI 回复机器人设有具体规则，其中 AI 回复机器人需要事先取得 X 的明确书面批准。
因此，这套系统目前更适合自动整理评论、生成候选回复并交给人审核。不能把"发现一条评论"直接等同于"自动向对方发送回复"。
七、突发事件监控：只在值得关注时打断人
突发监控每小时执行一次，主要关注：
- 重点公司的重大公告。
- 重要政策变化。
- 重大并购和行业级事件。
- 关注股票出现显著价格异动。
- 信息足够新鲜，并且有可靠来源支持。
例如，重点股票出现约 8% 的价格变化，可以作为内部检查阈值。但这个数字只是当前的候选规则，不是经过验证的最优阈值，也不意味着达到阈值就应该自动发帖。
价格异动还需要结合市场整体表现、交易时段、消息来源和事件背景判断。
如果只是普通波动，系统保持静默；如果事件重要且信息可靠，则生成一份包含事实、来源、发布时间和潜在影响的候选草稿。
夜间不推送普通提醒，紧急事件则可以根据严重程度另行设置通知策略。
突发监控的核心不是尽可能多地提醒，而是提高提醒的有效信息密度。
八、风控：不要把算法猜测当成确定规律
这是整套系统中最需要谨慎对待的部分。
X 已经公开了部分推荐算法相关代码，涵盖候选内容获取、用户互动信号、内容排序以及安全相关模型。可以从中研究推荐系统的组成和部分技术机制。
但公开代码并不意味着外部研究者掌握了线上系统的全部实现，也不意味着可以从某个模型参数直接推导某条帖子的实际曝光量。
因此，我把风控规则分为三类。
第一类：明确的平台规则。
例如，不发布垃圾信息，不重复发布实质相同的内容，不进行误导性操作，不以自动化方式批量发送未经请求的回复。违反平台规则可能造成搜索可见性受限或账号被停用。
这些约束应该优先落实。
第二类：工程层面的风险控制。
包括限制单日任务数量、记录发布结果、设置暂停开关、检查登录状态、避免重复执行，以及在连续失败时停止任务。
这些规则不需要知道推荐算法的具体权重，也能显著改善系统的可控性。
第三类：需要实验验证的增长假设。
例如，不同发帖时间是否影响曝光，长文是否比短文更适合账号定位，数据图表是否提高收藏率，某类开头是否能带来更多有效互动。
这些都可以测试，但不能预先当成确定规律。
1. 发布频率
当前设计为每天两条固定内容，突发事件内容另行判断。
每天最多发布多少条，应当结合内容质量、实际互动和平台规则确定，而不是认为某个固定数量天然安全。
也没有足够依据证明每周停更半天会向算法发送某种"休息信号"。如果安排休息，理由应当是运营资源、内容质量或工作节奏，而不是未经证实的算法机制。
2. 内容重复检测
系统记录近期发帖的正文、主题和来源，发布前检查是否重复。
这里需要同时检查文字相似度和信息重复度。一条帖子即使换了措辞，如果仍然是在重复发布同一个观点，也可能缺乏价值。
反过来，同一个主题也可以从新的证据、时间变化或不同分析角度重新讨论。
3. 异常行为和权限控制
系统应当避免未经授权的自动点赞、批量关注、主动骚扰式回复等行为。
我也不把模拟真人浏览、随机化点击或刻意掩饰自动化身份作为风控方案。它们不能保证账号安全，反而可能把系统设计引向规避平台检测。
更可靠的做法是减少不必要的操作，遵守平台允许的交互方式，并让每项自动化行为都能解释其目的。
4. 熔断机制
每周检查以下指标：
- 最近 7 天的曝光和互动变化。
- 粉丝净增长。
- 来自非关注者的有效互动。
- 任务失败次数。
- 数据抓取和发布状态是否一致。
- 内容核验失败或纠错情况。
早期账号的数据波动很大，不能仅凭一两条低曝光帖子就断定账号遭到降权。
因此，冷启动阶段以观察和记录为主。只有出现连续异常、任务状态不一致或明确的平台风险时，才触发暂停。
例如，可以把连续两条帖子曝光低于粉丝数的 5% 设为内部预警条件，但它只是一个待验证的阈值，不能当作"隐形降权"的证据。
一旦触发熔断，系统应停止后续发布任务，保留日志并通知人工检查。恢复运行前，需要确认问题已经解决，而不是简单等待 24—48 小时后自动恢复。
图：风控三类——明确的平台规则、工程层风险控制、待验证的增长假设。
九、增长方法论：把经验变成可验证的假设
我会持续研究表现出色的创作者，记录他们的内容结构、开头、论据组织和视觉表达。
但模仿的对象是方法，不是直接复制内容。
目前重点研究几类策略：
- 用明确结论或具体数字开头。
- 用真实数据支撑判断。
- 让一条帖子只承担一个主要观点。
- 发布可供读者收藏和复用的指南。
- 适当使用图表、截图和原始来源。
- 在相关讨论中提供真正有价值的补充。
其中一些方法可能提高内容表现，但具体效果需要通过账号自己的数据验证。
例如，"干货帖应该追求收藏而不是点赞"并不是普遍成立的规律。对于投资研究类内容，收藏可能说明读者希望日后查阅；对于突发新闻，转发和点击可能更有参考价值。
不同内容应该有不同的评价指标。
同样，争议并不自动等于增长。刻意留下错误、制造冲突或引导无意义争吵，可能损害账号信誉，也可能违反平台规则。
真正值得争论的内容，应该来自事实解释、不同假设和有依据的判断分歧。
建立自己的实验记录
每条帖子至少记录：
post_id、发布时间、主题与内容类型、信源、正文版本、配图类型、曝光量、点赞数、回复数、转发数、收藏数（若可获取）、新增粉丝、采集时间。
后续可以比较不同内容类型的表现，例如：
- 数据分析与突发新闻，哪一种更容易获得有效互动？
- 原始数据截图与原创图表，哪一种更适合当前账号？
- 不同开头方式，是否带来更高的阅读和互动表现？
- 哪些主题带来短期曝光，哪些主题更有助于持续涨粉？
实验时尽量一次只改变一个主要因素，并记录样本量和时间窗口。
由于账号仍处于冷启动阶段，样本不足时应该承认结果不确定，不要因为一条帖子表现突出，就立即把它总结为固定方法。
十、素材库：把零散信息变成可复用资产
除了发帖，我还安排了一个素材收集任务，整理马斯克近期的公开动态。
每天收集值得关注的帖子，保存中文摘要、原文链接、发布时间以及必要的互动数据，随后生成晚间汇总。
素材格式尽量统一：主题、原文链接、发布时间、中文摘要、关键事实、值得进一步研究的问题。
纯表情回复、缺乏实质内容的互动和重复信息可以跳过。
收集素材的目的，是为后续分析和长文写作建立资料库，而不是把别人的帖子简单翻译后重新发布。
涉及原文截图、图片和大段文字时，还需要考虑版权、平台规则和引用范围。素材被收录，并不意味着可以不受限制地公开转载。
如果后续要将这些资料整理为公众号文章，可以先按主题分类，再核对原始来源、补充独立分析，形成有自己观点的内容。
十一、状态管理与成本控制
早期运行中，我已经遇到三个值得记录的问题。
问题一：粉丝数误报。
第一次数据抓取曾经把其他账号的数字错误地记到自己的账号上，系统一度报告 9.3 万粉丝，实际只有 29 个。
解决方式是重新核对目标账号身份，并把关键指标与实际页面数据交叉验证。
教训很简单：数据抓取成功，不代表抓到的数据属于正确对象。
问题二：登录状态误报。
评论巡查任务曾多次报告登录失效，但人工检查发现账号仍然正常登录。
这说明登录状态检测本身也可能出错。以后不能只依赖一个简单信号判断登录是否有效，应当记录具体错误信息，并区分网络异常、页面加载失败和真正的身份验证问题。
问题三：发帖数量漂移。
状态文件曾记录当天发布 8 条，但实际发布了 9 条。
原因在于状态记录和真实发布结果没有做到可靠对账。
解决方案是将每次发布的执行过程设计成有状态的任务，并使用实际帖子 ID 作为成功发布的重要依据。
pending
↓
draft_validated
↓
awaiting_approval
↓
publishing
↓
published如果发布过程中断，不能直接假定任务失败并立即重试。应先检查平台上是否已经生成帖子，避免重复发布。
每天还需要将任务日志、实际帖子 ID 和状态文件进行对账。
成本控制方面，我会优先保留对决策最有帮助的任务，减少重复检查和无意义的通知。对于同一任务反复返工的情况，也应设置重试上限；超过限制后停止自动执行，交由人工判断。
一套成熟的自动化系统，不应该只记录成功，还应该能够解释失败、识别不确定状态，并避免错误不断累积。
十二、从零搭建：建议按这个顺序实施
如果要复现类似系统，我不建议一开始就部署所有任务。更稳妥的顺序是：
- 明确账号定位、目标读者和内容边界。
- 建立工作区，先编写选题、写作和事实核验规则。
- 建立信息源清单，逐个验证来源和抓取路径。
- 实现草稿生成、事实检查和日志记录。
- 加入人工审核，先以手动发布验证内容质量。
- 建立粉丝和帖子数据追踪，确认数据归属与采集口径。
- 增加评论整理、素材收集和突发事件监控。
- 建立状态机、失败重试限制、任务对账和熔断机制。
- 在确认平台规则允许的前提下，再逐步增加自动执行能力。
这里有一个容易被忽视的原则：先证明每个环节可靠，再把它们连接起来。
如果信息源不可靠，自动化只会更快地生产错误；如果状态管理不可靠，定时任务越多，问题越难定位；如果没有发布前检查，执行效率越高，错误传播也可能越快。
图：从零搭建的九个步骤——先证明每个环节可靠，再连接起来。
最后：真正值得自动化的，是重复劳动
这套系统目前仍处于早期阶段。它已经把选题、草稿生成、信息整理、定时调度和状态记录组织成了一套可以持续迭代的工作流，但是否能够稳定增长粉丝，还需要时间和数据来验证。
我更关心的不是一天能够生成多少条帖子，而是能否持续找到有价值的信息，准确地表达观点，并通过真实反馈不断改进内容。
AI Agent 的优势，在于它可以反复执行明确的流程，并把规则、记录和任务连接起来。
但目标选择、事实判断、风险承担和结果评价，仍然需要清晰的责任边界。
当执行成本越来越低，真正稀缺的可能是三种能力：知道什么值得做，能够判断结果是否可信，以及愿意为最终结果负责。
这也是我搭建这套系统最想验证的事情：
如果把一个人的运营经验写成规则，再交给 Agent 持续执行，这套系统能否逐渐成为一个可复用、可衡量、可持续改进的内容运营流程？
答案不应该靠想象得出。
接下来，我会继续记录实际运行数据、失败案例和迭代结果，用真实表现检验这套方法。