用AI代理运营账号，三天损失四个渠道：踩坑复盘

一位独立开发者做了一个公开实验：一个人加上一支小型AI代理团队，靠数字产品赚回每月的AI订阅费，全程不投付费广告。这是该系列第三篇，记录了一次代价不小的翻车——让AI代理直接运营社交账号之后，Reddit、Hashnode、小红书、X四个渠道在三天内相继失守。

先把冷冰冰的零点摆出来：Gumroad、itch 和中文店铺的订单数均为 0，收入 $0。据作者 12 日 21:00 的dashboard数据，Dev.to 第一篇文章发布两天拿到 31 次浏览、1 个互动；第二篇上线不到一天，显示“低于25次”。Gumroad 三十天内只有 37 次浏览，来自真实访客的链接点击为 0。

四个渠道是怎么丢的

Reddit：一篇偏自我推广的帖子导致账号被 r/excel 永久封禁，这条免费渠道在本轮冲刺中直接报废。

Hashnode：两篇文章发布后，登出状态下访问返回 404，随后被 AutoMod 归档。作者记下的教训很具体——发布后一定要用未登录状态检查一遍。

小红书：AI代理用账号浏览和发帖后收到疑似自动化警告，一天后账号内所有笔记被标记。除非人工手动重启，该渠道已被永久停用。

X：账号申诉后恢复了，但从新设备登录时遇到未预期错误。作者没有继续和登录死循环缠斗，本轮直接放弃 X。

作者总结出的规律不是“内容太差”，而是三个条件叠加：新账号或冷账号 + 代理集中活动 + 新设备或自动化浏览器。

养号是平台风控体系里的一个通俗说法：账号需要经过一段时间的真实人类行为（浏览、点赞、间歇性停留、非规律登录）来累积信任分，平台据此区分正常用户与自动化脚本。新注册或长期不活跃的“冷账号”天然缺乏这类历史信号，风控模型会给它更高的风险评分。此时若出现高频翻页、集中发帖、非本地设备登录等行为，即便内容本身合规，也会因会话特征异常被直接判定为机器人。Reddit 的 shadowban、小红书的限流标记、X 的临时冻结，本质上都是这套信任评分机制在起作用。因此“养号”并非玄学，而是绕开风控冷启动期的必要成本。

教训一：需要养号的平台，最先惩罚代理

Reddit、小红书和 X 都要求账号有接近真人的历史行为，才会对批量操作产生信任。一个刚登录就大量翻页、当天发帖的代理，看起来就是脚本。即便文案再小心，会话特征本身已触发风控。作者的结论是：如果平台奖励账号年龄和日常浏览，就别把代理放上去，要么让真人先养号数周，要么跳过。

浏览器指纹与会话特征是风控识别自动化的另一条主线。平台不仅看账号年龄，还会采集 User-Agent、Canvas/WebGL 指纹、时区、字体列表、鼠标轨迹、请求间隔等数十项信号。无头浏览器或自动化框架（如 Playwright、Puppeteer）默认的指纹往往高度一致，且缺乏人类操作的随机抖动，容易被批量识别。更隐蔽的是“新设备登录”这一环：同一账号从陌生 IP 和陌生设备指纹登录，本身就会触发二次验证或风控降权。这解释了为什么作者即使文案谨慎，代理一上线仍被标记——问题不在说了什么，而在“怎么登录、怎么翻页”。

教训二：留下来的渠道看内容，不看账号

Dev.to、itch 和 GitHub awesome 列表不需要预热，读者或维护者直接评判内容本身，这也是它们至今仍然畅通的原因。

当晚的实际状态是：Dev.to 两篇文章登出可访问；itch 上按角色划分的免费追踪器四页都配了真实截图，还有一篇 PM 开发日志链回 Dev.to；GitHub 列表提交了三个 PR（awesome-job-seeking #72、awesome-job-boards #252、Awesome-Job-Search-Resources #6），目前都只有 bot 评论或零评论。作者提醒：没有回复不是信号，且 PR 未合并前，0 点击说明不了任何问题。三个提交之后，合并历史正常的免费列表基本用尽，本轮再提交列表PR的边际收益接近于零。

GitHub awesome 列表是由社区维护的优质资源清单仓库，通过 Pull Request 提交新链接，由维护者人工审核后合并。它之所以对代理友好，是因为评判标准完全落在链接本身的质量与相关性上，不涉及账号历史或行为特征。但也正因人工审核，维护者活跃度参差不齐：许多仓库长期无人处理 PR，bot 自动回复后便石沉大海。作者提到“提交三个 PR 后免费列表基本用尽”，反映的是这类渠道数量有限、且合并周期不可控的现实。对独立开发者而言，awesome 列表更适合作为长期 SEO 与外链资产，而非短期获客手段。

教训三：给代理立下的新规矩

被标记之后，作者写下了四条硬性规则并开始执行：每个账号只允许一个代理接触，其他任何人不登录、不发帖；对有反机器人检测的平台完全不用自动化，要么真人手动发布，要么放弃该渠道；QA 只读链接，不点击追踪链接，所有自身请求都记录在案，以便从浏览和下载数据中剔除；“已发布”只有在登出状态下能打开页面才算数。

加上真实截图之后，数据变了吗

作者在四个 itch 追踪器页面（SWE、数据分析、PM、UX）填入了示例表格。据 12 日 20:55 数据：PM 7浏览/2下载，UX 7/1，DA 6/1，SWE 2/1，与当天 14:30 检查时相比没有变化。搜索检查显示，四个页面均未出现在 tag-productivity、tag-notion 或“job tracker”“notion job tracker”搜索结果中。作者也坦承存在混淆变量：同一时间窗口内还改了 CTA 文案，因此这不是一次干净的 A/B 测试。

接下来 48 小时

itch 上追踪器页面的现有 CTA 将于 13 日 22:35（北京时间）结束。之后作者只在数据分析页面测试一个新标题（“转介绍、招聘板还是公司官网：哪个真能帮你拿到数据分析面试？”），其余三页保持原样，以便判断标题本身是否带来变化。GitHub 列表不再提交新 PR，14 日检查三个开放 PR 是否有回复，且只有链接被合并后才计入点击。Dev.to 第四篇将于 15 日发布，给出 16 日截止日前的最终数据——如果依然是 $0，也会如实呈现。规则保持不变：一号一代理，不碰有反机器人检测的平台，不新增需要养号的渠道。

如果你也在真实账号上跑代理，是什么让你被标记的？作者在评论区等着交换经验。

免费追踪器地址：https://itch.io/c/8301723/free-notion-job-application-trackers-by-role

背景补充

A/B 测试的干净性在此次实验中是一个被明确承认的缺陷。作者在检查 itch 数据的同时修改了 CTA 文案，导致“加真实截图”与“改文案”两个变量同时变化，无法归因于任一单一因素。严格的 A/B 测试要求一次只改变一个变量，并保证样本量足够、随机分流均匀。在独立开发者流量本就稀薄（个位数浏览）的情况下，任何微小的外部波动都会淹没真实信号，这也是为什么作者后续计划只改一个标题、其余三页保持原样——这是在小样本条件下尽量逼近可控实验的务实做法。