账号更新订阅追踪
跟 douyin-viral-breakdown 不一样：那个是"给一条链接，深挖为什么火"，这个是"持续盯着
几个账号，谁发新东西第一时间告诉你"。两个是互补关系，不是二选一。
这个 skill 是做什么的
用户在这管理一批"订阅"，每条订阅绑定一个账号 + 一个飞书群机器人地址 + 一个自己设置的
检测间隔。真正的检测在服务端跑（后台有一个全局轮询job每30分钟检查一次"有没有订阅
到期该跑了"，具体多久检测一次是每条订阅自己的 check_interval_minutes 决定的），不
依赖当前对话或 Agent 环境本身的定时任务能力——哪怕这次对话关掉、用户电脑关机，服务端
该检测还是检测，该推送还是推送。这个 skill 只是让用户能用自然语言管理订阅（新增/暂停/
恢复/删除/查日志/改间隔），本身不负责"盯梢"这件事。
务必把这个"服务端持续跑，不是这次对话在跑"的事实讲清楚，避免用户以为要一直开着这个对话
才有效，或者以为是这个 skill 自己在后台定时执行。
目前后端只接入了抖音，架构上是按平台适配器设计的（每个平台一个抓取模块），后续会
陆续接入更多平台。用户问起"支持哪些平台"或"检测间隔能设多短/多长"时，先跑一次 config
命令给出实时答案，不要凭记忆回答——这份文档写的时候的范围以后可能会调整。
前置条件
订阅前必须凑齐两样东西，缺一样都不要硬跑：
- 账号主页链接——分享链接（短链或长链都行），不是某条内容的链接
- 飞书群机器人 webhook 地址——
https://open.feishu.cn/open-apis/bot/v2/hook/开头
如果用户只给了账号名字或模糊描述，没有链接，先请对方去账号主页点"分享"拿链接。如果
用户没有飞书群机器人，主动引导获取步骤（这个操作很快，几十秒能搞定）：
1. 打开飞书，进一个群（没有合适的群就新建一个，哪怕是只有自己的群）
2. 群设置 → 群机器人 → 添加机器人 → 自定义机器人
3. 起个名字（比如"账号更新提醒"），创建后复制那个 webhook 地址
也需要一把 zyunaigc API Key（服务端检测时调用平台接口要用），没有的话引导去
getting-api-key.md。
常用操作
所有操作都是 scripts/manage_subscription.py 的子命令，纯本地 CLI 调后端接口，
没有中间状态，每次都是实时结果：
# 查看目前支持哪些平台、检测间隔的可选范围
python3 scripts/manage_subscription.py config
# 新增订阅（--platform 不传默认是 douyin，--interval-minutes 不传默认120分钟）
python3 scripts/manage_subscription.py add \
--link "https://www.douyin.com/user/MS4wLjABAAAA..." \
--webhook "https://open.feishu.cn/open-apis/bot/v2/hook/xxxx" \
--remark "竞品A" \
--interval-minutes 120
# 查看我的所有订阅
python3 scripts/manage_subscription.py list
# 修改webhook/备注/单次最多推送条数/检测间隔
python3 scripts/manage_subscription.py update --id 3 --interval-minutes 30
# 暂停 / 恢复
python3 scripts/manage_subscription.py pause --id 3
python3 scripts/manage_subscription.py resume --id 3
# 删除
python3 scripts/manage_subscription.py remove --id 3
# 立即触发一次检测（不等下一轮自动轮询，常用来验证 webhook 配对没配对）
python3 scripts/manage_subscription.py run --id 3
# 查看某条订阅的执行日志
python3 scripts/manage_subscription.py logs --id 3
新增订阅时，--remark、--max-notify（默认5，单次检测最多推送几条新内容，防止账号
突然爆发式发布把飞书群刷屏）都是可选的，用户没提就用默认值，不用反问一句"要不要设置
推送上限"这种细节，除非用户自己关心这个。--platform 目前不用主动问用户——只有抖音一个
选项时不需要让用户做这个选择，除非以后 config 返回了多个平台、且从用户的链接文本
判断不出是哪个平台，才需要反问。
--interval-minutes 也不用没事就问——默认120分钟(2小时)对大多数场景够用，只有用户
明确表达"要更快知道"或者"没必要查那么勤"这类意图时才需要跟他确认具体数字，并且要提前
说清楚换算关系："间隔越短，一天检测次数越多，消耗的积分也越多"，让用户自己权衡，不要
替他做这个决定。
关键行为，必须提前告诉用户
首次订阅不会推送任何历史内容——add 命令背后会先拉一次账号当前的内容列表用来
"建立基线"，不推送，只从这一刻起，检测到比基线更新的内容才会推送。这是刻意设计，避免
把账号过去发过的几十条内容一次性炸到飞书群里。创建成功后一定要主动说明这一点，不要让
用户以为"订阅了怎么什么都没收到"。
检测间隔是每条订阅自己设置的，不是全局统一的——创建/修改订阅时可以用
--interval-minutes 指定，具体允许的范围（下限防止刷屏式消耗积分、上限对应"一天一次"）
以 config 命令的实时结果为准，不要凭这份文档里的数字硬编。间隔越短，服务端调用平台
接口的频次越高，消耗的积分也越多——每次检测无论有没有发现新内容都会产生一次调用和一次
计费，这是必须提前跟用户说清楚的关键点，不要等用户自己发现余额掉得快才补充说明。
引导话术：几种常见情况
用户想订阅但没给飞书webhook：
> 好的，还差一个飞书群机器人地址才能推送通知。步骤很快：进一个飞书群 → 群设置 → 群机器人
> → 添加自定义机器人，创建后把那个 webhook 链接发我就行。
用户给的链接不是账号主页链接（比如是某条具体内容的链接）：
> 这个像是某条具体内容的链接，我需要的是这个账号的主页链接——打开这个账号的主页，
> 点分享，把链接发我。
用户想订阅的平台目前不支持（add 返回"暂不支持平台"）：
> 这个平台目前还没接入，现在支持的是：<跑一次 config 命令拿到的列表>。有其它平台的
> 需求可以先记下来，等接入了再帮你订阅。
创建成功：
> 已经订阅「XXX」了。因为是刚订阅，这次只是记录了对方现有的内容作为基线，不会有历史
> 推送；从现在起，这个账号发新内容，我们这边最多<检测间隔>内就能检测到，检测到会直接
> 推到你那个飞书群。（把"检测间隔"换成这条订阅实际设置的值，比如"2小时"）
创建失败：把 add 命令输出的失败原因原样转述给用户，不要自己编一个更笼统的说法
（比如接口说"账号不存在"就别说成"网络问题"）。
看到某条订阅状态是"已暂停"且伴随连续失败次数：主动说明——"这条订阅因为连续检测
失败被系统自动暂停了，原因是：<日志里的error_detail>，需要我帮你恢复吗？"，不要
默默地把它当正常状态展示。
余额不足：接口返回体里会带充值链接，原样发给用户，不要自己编一个，也不要用同一把
报错的 Key 反复重试。
发现 → 拆解，两个 skill 连起来用
收到"某抖音账号发新作品了"的飞书推送后，用户如果想知道"这条为什么火"，直接把作品链接
接给 douyin-viral-breakdown 那个 skill 做深度拆解就行——这两个 skill 是设计成配套
使用的：一个负责"发现"，一个负责"分析"（目前只有抖音这条链路打通，其它平台接入拆解
skill 之前，只能帮用户"发现"，还不能一键接深度拆解）。可以在用户对某条推送表现出兴趣
时主动提一句这个联动，不用每次都提。
常见问题
跑之前遇到不确定的情况，先查 troubleshooting.md：
API Key 缺失、webhook 格式错误、账号链接解析失败、重复订阅、创建后被判定失败并回滚、
自动暂停、立即检测后群里没收到消息等，都在里面有对应的判断和处理方式。
相关文件
scripts/manage_subscription.py— 订阅管理 CLI（config/add/list/update/pause/resume/remove/logs/run）references/getting-api-key.md— 怎么注册 zyunaigc.com 拿到 API Keyreferences/troubleshooting.md— 常见错误与排查- 服务端实现：
coze_plugin_website/backend/routers/plugin_routers/account_subscription.py、
services/account_subscription_service.py（通用的定时检测/比对/推送逻辑）、
services/subscription_platforms/（按平台拆分的适配器，抖音的实现在douyin.py）
