GLM 5.2 抢购脚本指南
一个面向 GLM Coding Plan 的本地工具火了。先看清它能做什么、怎么本地研究，以及哪些账号和合规风险不要碰。
GLM 5.2 出来后，Coding Plan 变成了抢购现场。有人整理了一个开源工具 VitoHowe/glm-coding，仓库名叫 AegisFlow，定位是本地运行的 GLM Coding 支付运营后台。
它做的事情很直接：多账号导入、套餐同步、验证码链路、预览下单、签单出二维码、定时启动任务。 X 上那条转发把重点概括成了几项：OCR 验证识别、 ticket 池预加载、并发请求、定时触发和抢购提醒。
先看边界
这个项目不适合当成“无限抢购神器”。它会接触账号 Token 、验证码、支付二维码和购买链路，任何一步处理不好，都可能带来账号风控、支付异常或平台规则风险。
更稳妥的用法，是把它当成本地研究样例：看它怎么组织多账号状态、怎么做任务调度、怎么把验证码链路拆成后端服务，而不是拿真实主力账号直接开冲。
本地研究怎么跑
仓库 README 写得比较清楚，环境要求是 Windows 、 Python 3.12+、 Node.js 。先在 PowerShell 里确认：
py -3 --version
node --version
npm --version
然后下载仓库，双击根目录的 start.bat。第一次启动会创建 .venv、安装 Python 依赖、构建 Vue 前端，并启动 FastAPI 服务。页面默认在：
http://127.0.0.1:8787
本地配置一般不用改。端口冲突时，再把 .env 里的 APP_PORT 改成 8788 这类新端口。
使用前做三件事
第一，用测试账号研究，不要把主力账号 Token 直接丢进去。这个工具会保存本地会话和任务缓存，数据目录默认是 data。
第二，先读 README 里的“不包含”部分。项目没有做账号密码登录自动化，也不包含 deviceToken 和浏览器支付跳转逻辑。别把它想象成完整官方客户端。
第三，不建议调大并发硬抢。 README 里提到 OCR worker 、 ticket 池、定时启动和代理池配置，这些能力越激进，越容易撞上风控。只是研究代码，保持默认本地模式就够了。
适合学什么
这类仓库最值得看的不是抢购动作本身，而是几个工程拆法：
- 本地 Web 后台怎么管理多账号状态；
- 定时任务怎么和支付链路串起来；
- OCR 这种重 CPU 环节怎么放进 worker 池；
- 二维码和任务日志怎么做本地缓存；
- 失败重试、状态展示、账号删除怎么收口。
如果只是想买 Coding Plan，优先走官方页面。这个项目更适合开发者拆解自动化后台的结构。真要尝试，也先用测试账号、本机网络、低并发，并确认自己能承担账号和支付风险。