2026 年 9 月 18 日早上，我收到了 GitHub Support 的邮件：
We've cleared the restrictions from your account, so you have full access to GitHub again.
账号恢复了。整个过程没有所谓“秒解”技巧：从 GitHub 要求我补充账号用途，到最终解除限制，我等了大约九天。我写清楚了自己怎样使用 GitHub 和 AI 编程工具，等了一周后在原邮件里跟进了一次。
下面只写邮件和公开活动能够证实的过程。GitHub 没有说明哪一次操作触发检测，因此不能把原因归到 AI 编程工具、GitHub Actions、IP 变化或某个 API 请求。
九天时间线
9 月 8 日，GitHub Support 告诉我，账号的一些活动被 abuse detection system 标记，需要人工审核，因为相关活动可能与服务条款冲突。对方没有列出具体操作，只问了一个问题：我打算怎样使用 GitHub？
9 月 9 日，我在原邮件线程里回复。我说明自己是个人开发者，GitHub 主要用于正常的软件开发和版本管理。我的工作流里确实有 AI 编程工具，这些工具可能在本机或我授权的云环境里调用 Git、GitHub CLI 和 GitHub API，用来修改自己的代码、提交分支、运行测试、触发 Actions，以及把自己的应用部署到阿里云。
我也写明，这些自动化都由我发起，用于自己的开发工作。我不会用 GitHub 或 AI 工具做垃圾信息、钓鱼、恶意软件传播、未授权访问、批量注册、刷星、刷关注、挖矿或盗用凭据。最后，我请对方在可能的情况下指出触发审核的活动；如果某个自动化模式有问题，我愿意停用或调整，并检查相关凭据。
9 月 16 日，回复已经过去一周，我仍然没有收到新消息。账号处于暂停状态，我也无法登录 Support portal 查看工单。我一度打开了新的 reinstatement request 表单，但页面明确提醒不要重复提交，否则可能增加处理延迟。我没有继续创建新申请，而是回复原来的邮件，询问三件事：9 月 9 日的说明是否收到、恢复申请是否仍在审核、是否还需要我补充材料。
9 月 17 日 23:31 UTC，也就是北京时间 9 月 18 日 07:31，GitHub 发来解除限制的邮件。邮件只解释说，滥用检测系统有时会标记需要人工审核的账号，没有说明这次具体由什么触发。
恢复后，我重新登录并检查了仓库。GitHub 的公开事件也显示，我在 9 月 19 日重新向 gpt_oracle_web 推送了代码，随后又在 first_myself_site 创建和合并了多次 Pull Request。邮件里的“full access”确实落到了实际操作上。
申诉邮件写了什么
Support 问的是“你准备怎样使用 GitHub”，我的回复就集中在真实工作流上：
- 我是谁，账号由谁使用；
- 仓库和代码是否属于自己，或是否得到授权；
- 自动化工具会执行哪些 GitHub 操作；
- 这些操作由谁发起，用来完成什么工作；
- 我明确不会做哪些违反条款的事情；
- 如果 GitHub 指出具体问题，我准备怎样整改。
下面是根据我当时邮件整理的短版。不要原样复制，工具、云环境和用途都应该换成自己的真实情况。
Hello GitHub Support,
I am an individual developer, and I use GitHub for legitimate software development and source control. Some parts of my workflow are assisted by AI coding tools running locally or in cloud environments that I authorize.
These tools may use Git, GitHub CLI, GitHub APIs, and GitHub Actions to work on repositories that I own or am authorized to access. The automated operations are initiated for my own software-development work, and I understand that I am responsible for activity performed through my account and credentials.
I do not intend to use GitHub or AI tools for spam, phishing, malware distribution, unauthorized access, bulk account creation, artificial stars or followers, cryptocurrency mining, credential abuse, or other activity that violates GitHub's Terms of Service.
I do not know which specific activity triggered the review. If possible, please identify the relevant activity or request pattern. I will disable or adjust it, review the relevant credentials if necessary, and make sure future automation follows GitHub's policies and rate limits.
I respectfully request a manual review and reinstatement of my account. Please let me know if you need any additional information or action from me.
Thank you.
写这封信时，我刻意没有猜测触发原因。把“可能是某个 AI Agent 请求太多”写进去，看起来配合，实际却会把没有证据的推测写成事实。我只列出真实用途和边界，再请 Support 指出需要调整的活动。
一周没有回复：继续跟进原工单
账号暂停后，我无法登录 Support portal。GitHub 的收件回执写明，可以直接回复邮件补充信息。原线程已经有账号、问题和历史说明，继续回复也更方便审核人员看到上下文。
我的跟进邮件很短：
Hello GitHub Support,
I'm following up on my existing ticket regarding the suspension of my account.
I replied on September 9 with details about how I use GitHub, but I have not received a further update. Because my account is suspended, I cannot sign in to the Support portal to check the ticket.
Could you please confirm by email that my reply was received and let me know whether my reinstatement request is still pending review?
Please also let me know if you need any additional information or action from me.
Thank you for your time and assistance.
我没有同时提交新的恢复申请，也没有去 GitHub Community 求加速。GitHub 的回执明确说，Community 不能处理账号恢复，也不能让工单更快进入审核。
能确认的事实，以及不能确认的原因
9 月 17 日的邮件只确认了三件事：风控系统曾把账号标记并交给人工复核，复核后限制被解除，GitHub 没有披露具体事件、时间或命中的规则。
这封邮件不能证明 GitHub 禁止 AI coding tools、GitHub CLI、API、Actions 或自动部署。我后来继续正常使用这些工具。需要控制的是多个自动化叠加后的行为模式，例如短时间大量写操作、高并发、失败后密集重试、无人值守持续运行，以及同一份长期凭据被多个环境共同使用。这些是防范方向，仍然不能用来反推本次封禁原因。
我按下面的顺序处理风险：
| 优先级 | 行为模式 | 处理方式 |
|---|---|---|
| P0 | 遇到 403/429 或网络错误后持续重试 | 读取 Retry-After 和 rate-limit headers；交互式 Agent 立即停止并报告 |
| P0 | 多个 Agent 或脚本并行 push、开 PR、评论、改标签、重跑 Actions | 同一账号的远端写操作串行，集中到任务或里程碑结束时执行 |
| P0 | 本地、CI、云主机和部署平台共用一个长期高权限 token | Actions 使用仓库自带的 GITHUB_TOKEN；外部自动化按用途拆分 GitHub App 或 fine-grained PAT |
| P1 | CI 或部署产生文件变化，再次触发同一工作流 | 检查递归触发、限制路径、部署串行，并跳过已经过期的提交 |
| P1 | 高频轮询状态，或 Agent 无人监督地连续写入远端 | 优先 webhook；必须轮询时降低频率并使用条件请求 |
| P2 | VPN、云主机和本地电脑频繁切换出口并共用凭据 | 减少不必要的出口漂移，检查安全日志；目前没有证据证明它触发了这次审核 |
| P3 | 正常使用 Coding Agent、git push、gh pr、Actions 和自动部署 | 继续使用，不因为这次事件停掉正常开发 |
GitHub 的 REST API 限流说明 写明，REST 和 GraphQL API 合计最多允许 100 个并发请求；内容创建请求通常不超过每分钟 80 个、每小时 500 个，部分 endpoint 的限制更低。超过次级限流后，如果响应有 Retry-After，就等到指定时间；如果 x-ratelimit-remaining 为 0，就等到 x-ratelimit-reset；两者都没有时，至少等一分钟再试。持续请求可能让 integration 被禁用。
这些数字只是平台的通用上限，个人自动化应该远低于它们。GitHub 的 REST API 最佳实践 还建议把请求串行化，并在 POST、PATCH、PUT、DELETE 之间至少等待一秒。
账号恢复后，我收紧了哪些自动化
我先给本机所有 Codex 任务加了一条统一边界：本地读取、改代码、测试、构建和 commit 可以正常进行；远端写操作必须串行。遇到 rate-limit 相关的 403/429，当前交互任务停止 GitHub 写入，不允许在 git push、gh api、REST、workflow rerun 和重新认证之间来回切换。无人值守的 integration 即使采用退避，也要限制重试次数。
gpt_oracle_web 原来的 CI 同时监听所有分支的 push 和 pull_request。一个 PR 分支 push 后可能重复跑两套离线测试。我在 PR #1 中把 push CI 限制到 main，保留 PR 检查，并让同一 PR 的新提交取消旧 CI。离线测试通过后，这项改动已经合入。
个人站点的部署原本已经串行，但快速连续合并时，过期提交仍可能排队完成构建和部署。我在 PR #49 中把 workflow token 收窄到只读，并在部署前读取远端 main 的最新 SHA。当前运行的 GITHUB_SHA 已经过期时，打包、上传和 SSH 部署都会跳过；最新提交仍按原流程自动部署。
我也检查了 video-factory。它已经按 ref 设置 concurrency，同一 PR 的新运行会取消旧运行，部署只接受 main push 或人工触发。这次先保持现状，没有为了追求形式统一再改一遍。
凭据检查只看了类型、权限、workflow 引用和 secret 名称，没有读取 secret 值。两个仓库的 Actions 配置中没有出现个人 PAT；本机 GitHub CLI 使用 Keychain 中的 OAuth 登录。后续仍要定期撤销不用的 token，为长期外部自动化使用 GitHub App 或最小权限的 fine-grained PAT，并避免多个并发 Agent 共用一份高权限长期凭据。
GitHub 的 Acceptable Use Policies 禁止 excessive automated bulk activity、垃圾信息和通过自动化给服务器造成不合理负担。正常开发自动化可以继续跑，前提是给并发、重试、凭据和触发链路加上边界。
如果再次遇到，我会这样处理
先保存暂停页面、GitHub 邮件、工单号和发送时间。然后从与账号绑定的邮箱回复，事实性地说明账号用途和自动化边界。收件回执只确认消息已经进入队列；Support 要求补充用途，说明申请仍在人工审核中。
接着检查已发送邮件、垃圾邮件和退信。进不了 Support portal 时，继续回复原邮件；如果连原邮件都没有，可以走 GitHub 官方的 Can't sign in 入口，并注明是在跟进已有申请。不要同时开多张恢复申请。
等待期间，我会备份本地仓库，尤其是 .git 和未提交修改，并暂停可能持续重试 GitHub 请求的自动化。这些措施用来保护开发现场，无法证明自动化就是封禁原因。
恢复邮件到了以后，还要实际验证登录、拉取、推送、Pull Request 和 Actions。GitHub 的 Appeal and Reinstatement 政策说明，恢复请求会由工作人员审核，但没有承诺固定处理天数。我的经历是大约九天，其中一次人工补充说明、一次同线程跟进；别人的等待时间可能完全不同。