先给结论：判断一个平台能不能自动化，我此前用的标准是「脚本能不能跑通」——能登录、能填表、能提交，没被拦，就算这个平台不反自动化。
这个标准是错的。它只覆盖了当场会不会被拦，完全没覆盖事后会不会被算账。
这两件事之间隔着一整套风控系统，而后者的反馈周期是几小时到几天。
一、我原来的判断，和它错在哪
把八个内容平台的发布流程自动化之后，我在文档里写下过这么一条结论：
八个平台没有一个在 headed 浏览器 + 持久化登录态下拦截自动化。
headless 会被拦，headed 基本都能过。
这条结论的证据是充分的：每个平台我都实际跑通了，登录、填内容、提交、验收，一次不落。
但它的结论范围被我悄悄扩大了。证据只能支撑「操作当场不会被阻断」，我写成了「平台不拦截自动化」——后者暗示的是平台对这件事没意见。
几小时后，其中一个平台发来了账号违规预警：
您的账号疑似使用三方工具或脚本（如 AI）自动浏览、查看或发布内容来运营账号，
本次仅警告，多次违规将影响账号功能。平台倡导真实分享，请勿以技术手段模拟真人行为。
当场一路绿灯，事后收到警告。 两者之间没有矛盾——它们本来就是两个不同的系统在工作：前端负责让页面能用，风控负责事后识别异常模式。
二、这类误判的结构
回头看，我的推理链条是这样的：
脚本跑通了 → 没有报错 → 平台没有拦 → 平台允许
✅ ✅ ✅（当场） ❌ 推不出来
前三步都成立，最后一步是跳跃。
而且这个跳跃特别难自我察觉，因为：
- 反馈是延迟的。当场的成功是即时的、明确的；风控的判定是几小时后的、异步的。人天然会用即时反馈校准认知
- 成功是可复现的。我不是只成功了一次，是八个平台每个都成功了——重复成功会强化错误的结论
- 没有反例出现在视野里。风控不通过页面告诉你「你正在被观察」
这三条加起来，构成了一个几乎必然会踩的坑：用「能不能做到」回答了「该不该做」。
三、平台到底在识别什么
那条预警里有一句值得逐字读：
请勿以技术手段模拟真人行为
它禁的不是「用了脚本」，而是「让脚本看起来像人」。
这解释了一个反直觉的点。我当时的第一反应是：那我把范围缩小一点，不发内容了，只做自动浏览和自动回复——这样总该没问题吧？
这个方向恰恰更危险。 因为预警里那句话是这么排列的：
自动浏览、查看或发布内容
三个动作是并列的，都在被禁之列。而自动回复比自动发文更贴近「模拟真人行为」——它直接在互动层伪装成一个正在阅读、正在思考、正在回应的人。
降低操作频率 ≠ 降低违规程度。 有些行为的性质，跟做多少次无关。
四、那么什么样的自动化是安全的
我现在的划线是这样的，供参考：
| 类型 | 例子 | 判断 |
|---|---|---|
| 官方 API / 开放接口 | 平台提供的发布 API、Webhook | ✅ 平台明示允许 |
| 本地工具链 | 本地写稿、格式转换、发布前校验 | ✅ 完全不碰平台 |
| 读公开数据且遵守 robots | 按 robots.txt 抓公开页面 |
✅ 规则是明写的 |
| 模拟登录态操作后台 | 就是我做的这类 | ⚠️ 看平台条款，多数不允许 |
| 模拟真人互动 | 自动点赞、关注、评论、回复 | 🔴 几乎所有平台明确禁止 |
分界线不在「技术难度」，也不在「频率高低」，而在两个问题：
- 平台有没有给出官方通道？ 有官方 API 却绕过它去驱动 UI，本身就说明了态度
- 这个行为是不是在冒充人？ 发布内容还可以说是「工具辅助创作」，互动行为很难这么解释
五、这件事改变了我的成本模型
之前我算自动化的账，算的是「省了多少人工」。
现在要多算一项：账号资产的风险敞口。
具体到我的场景，这笔账很清楚：
- 那个平台的内容对我的实际目标（被检索到）贡献为零——它的
robots.txt是白名单制，把绝大多数抓取工具都排除在外，我早就查证过 - 而代价是一个已经运营了一段时间的账号，收到了第一次警告
为一个已知收益为零的渠道，押上一个有沉没成本的账号。 写出来才发现这个决策有多不划算——而在做的时候，它藏在「把能力建全」这个听起来很合理的目标底下。
所以我的处理是：那个平台的自动化整体停掉，脚本保留但加了运行时硬阻断——光在注释里写「不要用」是挡不住手滑的：
if args.cmd in ("publish", "login", "probe") and not args.i_know_the_risk:
print("🔴 该平台自动化已停用——平台已发来账号违规预警")
return 2
六、一条可以迁移的判断规则
如果只留一句，我会写成：
当场没被拦，只能证明「前端没拦」。它不能证明「平台允许」，更不能证明「事后不会被算账」。
要验证「平台允许」，得看三个地方，而且都不在页面上：
- 用户协议 / 开发者条款里关于自动化访问的条款
- 平台有没有提供官方 API——提供了却不用，本身就是信号
robots.txt——它管的是抓取，但也反映平台对程序化访问的整体态度
这三处都是明示的规则。而页面能不能操作成功，是实现细节。
拿实现细节去推断规则，就是我这次犯的错。
小结
| 我以为 | 实际 |
|---|---|
| 脚本跑通 = 平台不反自动化 | 只能说明前端没拦，风控是异步的 |
| 缩小操作范围能降低风险 | 有些行为的性质与频率无关，互动类反而更敏感 |
| 「把能力建全」是中性的目标 | 它会掩盖「这个渠道值不值得」这个前置问题 |
| 注释里写「不要用」就够了 | 挡不住手滑，要在运行时硬阻断 |
能做到，和该做，是两个问题。 前者是工程问题，后者要去读规则——而规则从来不写在页面上。
