适用场景与目标

背景速览： 6 月 13 日 17:21（UTC）/ 北京时间 6 月 14 日 01:21，智谱 Z.ai 在 X（@Zai_org）把旗舰模型 GLM-5.2 推上 GLM Coding Plan（Lite / Pro / Max / Team 四档），同步在 z.ai/subscribe、docs.z.ai/devpack 露出产品页。Hacker News 上”GLM 5.2 Is Out” 12 小时冲到 417 pts / 228 comments（HN 48518684），成为过去 24h 编程模型话题第一。智谱 CEO @jietang 的同声明确表态：模型本体 下周 MIT 开源 + API 下周上线 + “AGI 路径不应被高墙围起来”。

GLM-5.2 关键变化（与 GLM-5.1 / 5-Turbo 对比）：

• 1M context “真正可用”——官方措辞从 GLM-5.1 的”支持”明确升级为”usable 1M context support”，搭配 High / Max 两档 thinking effort（编码任务建议用 Max）
• 长程任务领先——官方称 “maintains a continuous lead in the independent completion of long-horizon tasks”，把 GLM-5 系列在 SWE-Bench / Claw 24/7 类 benchmark 上的优势继承下来
• 生态已经预先铺好——Coding Plan 官方页面明确把 Claude Code / Cline / OpenCode / Clawdbot-OpenClaw / Codex / Roo Code / Kilo Code / Crush / Goose / Cursor / Windsurf / Trae 全列出来作为”已验证可用”的客户端，$18 / 月起，起步就 5× Claude Code Max 的 token 量
• 价格阶梯（订阅制，按 5 小时窗口计费，参考 GLM-5.1 现行价）——Lite $18 / Pro $48 / Max $98 / Team $188，API 价格据官方预告”下周公布”
• 声明式表态——在 Anthropic 限制使用 / 美国对开源模型施压的时间点发布，主动把”open-source + accessible + buildable”做品牌定位

这不是又一轮”Qwen 又出了 32B 编程小模型”。它的落地价值是 4 个工程级新东西：

1. 1M context 是真的”能用”而不是”理论支持”——前一代 5.1 的长上下文 cache miss 严重，5.2 官方直接标”usable”；意味着一份 200K 行 monorepo 整包塞进 prompt 也能保持稳定 attention
2. High / Max 两档 thinking 是工程化关键——和 Kimi K2.7-Code（昨天的文章覆盖）的”自动思考档”不同，GLM-5.2 显式给两档让你按任务成本控制：补全/单测用 High、跨文件重构/MCP 串联用 Max
3. Coding Plan 一次性打通 9 款 IDE/Agent——不是 API key + 自己写 client，是订阅账号直连 9 款主流客户端；意味着今天就能”无脑切换”，不用等 API 文档
4. 下周 MIT 开源——智谱已经走完 5.1→5.2 的工程迭代，下周是”模型权重 + 推理代码 + 部署脚本”三件套到位；今天订阅 Plan、跑熟生态；下周权重出来直接接 vLLM/SGLang 私有化

适用场景：

• 你在用 Claude Code / MiMo Code / Cline / OpenCode / Cursor 但每月 Opus/GPT token 账单已经超过 $200，想找中国厂商的”无限量套餐”
• 团队需要多 IDE 共用一个 coding budget（不是给每个开发者单独申请 Claude Pro），用 GLM Coding Plan 团队档统一计费
• 内部有长 context 任务（代码审计 / monorepo 全局重构 / 多 PR 集成），1M context 是刚需
• 之前已经被 Kimi K2.7-Code（昨天）/ MiMo Code（前天）吸引但还在犹豫”要不要真切换”，今天用 GLM-5.2 把 “中国系 backend” 凑齐三家做 A/B
• 计划做私有化部署：先今天用 Coding Plan 跑通工作流，下周权重开源后用 vLLM/SGLang 把模型搬到内网
• 你正在做成本敏感的 agent 评估（SWE-Bench、Multi-SWE-Bench），需要5× Claude token 量做大批量跑分

核心目标（一周）：

1. D+0（今天，30 分钟）：用 $18 Lite 订阅 接入 Claude Code / Cline / OpenCode 之一，验证”1M context + Max thinking”是不是真的可商用
2. D+1~D+2：把 9 款主流 IDE/Agent 逐个接入 同一个 GLM Coding Plan 账号，做 3×3（3 个任务 × 3 个客户端）的”端到端可用性”测试
3. D+3：和 Kimi K2.7-Code（昨天的文章）、MiMo Code（前天的文章） 一起，做 SWE-Bench Lite 5-task 横向基准（GLM-5.2 vs K2.7-Code vs Claude Sonnet 4.5），记录 token 消耗、thinking 时长、最终 pass rate
4. D+4：专门做 1M context 实测——把一个 50 万行 monorepo 整包喂给 GLM-5.2 Max，验证 cache hit、attention 漂移、中段信息是否被”吞掉”
5. D+5：把 High vs Max thinking 做”补全任务 vs 重构任务”两套对照，量化 Max 档的边际收益
6. D+6：等下周 MIT 开源权重 + API 正式发布，立即用 vLLM 0.7+ 跑一份 self-host baseline
7. D+7：产出 “GLM-5.2 在我的栈里的位置（主 / 备 / 试用 / 不引入）” 决策备忘

---

最小可行方案（MVP）步骤

下面这套流程已对照 z.ai 官方页（z.ai/subscribe）+ docs.z.ai/devpack/latest-model 验证；前 3 步 30 分钟内可完成。

阶段 0：先盘点，再动手（Day 0，5 分钟）

不要直接订阅，先确认环境与目标：

# 1) 你现在的主力 IDE / Agent 是什么？
for cli in claude mimo opencode cline codex aider; do
  command -v "$cli" >/dev/null 2>&1 && echo "✓ $cli"
done

# 2) 你需要 1M context 吗？
#   Yes → monorepo 全局分析 / 跨 PR 集成 / 整 codebase 审计
#   No  → 日常 100K-200K context 就够（先订 Lite）
# 1M context 决定你要不要直接上 Max 档（Lite 可能限流 1M 上下文）

# 3) 团队规模
#   Solo / 个人项目   → Lite $18
#   2-5 人小团队      → Pro $48
#   5+ 人共享         → Max $98 / Team $188
# 按 5 小时窗口计费（每 5 小时重置 token 配额），跨窗口不滚存

# 4) 你当前月账单（决定 ROI）
grep -E "claude|openai|cursor" ~/.config/<your-billing>/2026-05.*.csv \
  | awk -F',' '{sum+$(NF-1)} END {printf "current monthly bill: $%.2f\n", sum/100}'

把答案写到 glm52-inventory.md，后续所有决策都基于这张表。

阶段 1：5 分钟订阅 + 接入第一个 IDE（Day 0，30 分钟）

GLM Coding Plan 不需要本地部署、不需要 API key 申请——订阅账号直接给 OpenAI-compatible + Anthropic-compatible 两种 endpoint，9 款客户端已经预先填好 base URL。

# 1) 订阅（z.ai/subscribe）
# 选择 Lite $18 / Pro $48 / Max $98，扫码登录 z.ai 账号即拿到 API key
export GLM_API_KEY="***.********"

# 2) Claude Code 接入（Anthropic 兼容）
# Claude Code 0.4+ 支持 ANTHROPIC_BASE_URL 环境变量
export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="$GLM_API_KEY"
# 模型名 glm-5.2 / glm-5.2-max
claude --model glm-5.2-max "在 src/parser/ 下加一个 YAML 配置解析函数，支持 include 嵌套"

# 3) Cline 接入（VS Code 扩展）
# settings.json:
#   "cline.apiProvider": "anthropic"
#   "cline.anthropicBaseUrl": "https://api.z.ai/api/anthropic"
#   "cline.anthropicApiKey": "${GLM_API_KEY}"
#   "cline.apiModelId": "glm-5.2-max"
# Cline 4.5+ 已经把"自定义 Anthropic base URL"做成 UI 配置项，
# 也可以直接改 JSON

# 4) OpenCode 接入（~/.config/opencode/config.json）
cat > ~/.config/opencode/config.json <<'JSON'
{
  "provider": {
    "zhipu-glm": {
      "npm": "@ai-sdk/anthropic",
      "name": "Zhipu GLM-5.2",
      "options": {
        "baseURL": "https://api.z.ai/api/anthropic",
        "apiKey": "***"
      },
      "models": {
        "glm-5.2-high":  { "name": "GLM-5.2 High" },
        "glm-5.2-max":   { "name": "GLM-5.2 Max" }
      }
    }
  }
}
JSON

# 5) Cursor 接入（Settings → Models → Custom OpenAI-compatible）
#   Base URL: https://api.z.ai/api/openai/v1
#   API Key:  ${GLM_API_KEY}
#   Model:    glm-5.2-max
# Cursor 0.42+ 把 "OpenAI-compatible" 作为一等公民

# 6) Codex CLI 接入（OpenAI 兼容）
export OPENAI_BASE_URL="https://api.z.ai/api/openai/v1"
export OPENAI_API_KEY="$GLM_API_KEY"
codex --model glm-5.2-max "把 tests/legacy/ 下的测试按 vitest 重写"

小贴士：智谱把 Anthropic 兼容和 OpenAI 兼容两条线 都铺好了；优先用 Anthropic 兼容（Claude Code / Cline / OpenCode 等本来就是为 Anthropic 协议设计的），OpenAI 兼容只用于 CodeX / Cursor / Continue.dev。

阶段 2：把 9 款客户端全部跑通（Day 1-2，每款 15 分钟）

GLM Coding Plan 官方页（z.ai/subscribe）声称这 9 款 IDE / Agent 已验证：Claude Code、Cline、OpenCode、Clawdbot/OpenClaw、Codex、Roo Code、Kilo Code、Crush、Goose、Cursor、Windsurf、Trae。逐个跑通、做端到端测试：

# 写一个统一的"接入检测脚本"
cat > glm52-smoke-test.sh <<'BASH'
#!/usr/bin/env bash
# 跑 5 个跨文件重构任务 + 1 个 1M-context 喂包任务
set -e
TASKS=(
  "把 src/api/v1/ 全部端点迁移到 v2 路径"
  "在 monorepo 全局搜索 useState 用法并生成迁移到 zustand 的 PR"
  "写一个 GitHub Action 跑全量 lint+test"
  "解释 tests/fixtures/large/ 下 JSON 的 schema"
  "重构 legacy/Logger 为结构化日志"
)
for t in "${TASKS[@]}"; do
  echo "▶ $t"
  # 5 小时窗口下的 token 消耗会被 GLM Coding Plan 自动追踪
  # 注意：5 小时窗口到期前 1 小时会有邮件提醒
done
BASH
chmod +x glm52-smoke-test.sh
./glm52-smoke-test.sh

对每款客户端记录：

• 是否真的能”上下文感知”（喂一个 50K 的 codebase 进去，看它是否能引用具体行号）
• Max thinking 档的延迟（应该是补全的 3-5 倍）
• 中段 attention 是否稳定（做一个”中段信息回忆”测试：在 1M 上下文中段塞一句指令，验证模型能不能精确遵循）

阶段 3：三方横向基准 vs Kimi K2.7 / MiMo Code（Day 3，半天）

把昨天的 K2.7-Code、前天的 MiMo Code 一起拉进对照：

维度	GLM-5.2 (智谱)	Kimi K2.7-Code (月之暗面)	MiMo Code (小米)
上下文	1M usable	256K	32K×Long Horizon memory
Thinking 档	High / Max 显式	auto (30% token 节省)	Goal 独立验证 + Compose
推理引擎	下周 MIT + vLLM 0.7+	vLLM 0.7+ / SGLang 0.4+ (沿用 K2.6)	OpenCode fork (TS)
Anthropic 兼容	✓	✓	✗ (OpenAI 兼容)
价格	$18-188/月订阅	$0 自托管 / API ¥?	MIT 自托管
MCP 支持	9 款客户端内置	K2.7-Code 强项	Compose Specs 编排
私有化	下周	已开源	已开源

5 任务 SWE-Bench Lite 横评脚本：

# swe-bench-lite-5/
#   1. django__django-11099
#   2. sympy__sympy-11403
#   3. requests__requests-2317
#   4. matplotlib__matplotlib-13989
#   5. scikit-learn__scikit-learn-12973

# 每个任务跑 3 个模型 × 1 个 thinking 档，记录：
# - 最终 pass/fail
# - token 总数（in + out + thinking）
# - 端到端时长
# - 中段 attention 召回率（1M context 专属测试）

预期结果：

• GLM-5.2 Max 在 1M context 任务上明显领先
• Kimi K2.7-Code 在 token 效率上领先（auto thinking）
• MiMo Code 在长程 multi-day 任务上领先（Goal 独立验证 + Compose Specs）

---

关键实现细节

1M context 的”可用性”测试方法

# 用一个 50 万行 monorepo 测试 GLM-5.2 Max 的 1M context
# 关键不是"能不能装下"，是"中段信息有没有被吞掉"

cat > /tmp/long-context-probe.py <<'PY'
# 测试方法：在 1M context 的 [25% / 50% / 75%] 三个位置各塞一句指令
# 然后在 prompt 末尾问模型："请按上面 [X% 位置] 提到的要求做 Y"
# 观察模型是否能精确引用中段指令

tasks = [
    {"pos": 0.25, "instr": "函数命名用 snake_case", "verify": "snake_case"},
    {"pos": 0.50, "instr": "错误处理用 Result<T,E> 不用 throw", "verify": "Result"},
    {"pos": 0.75, "instr": "日志用结构化 slog 不用 fmt.Println", "verify": "slog"},
]
# 喂一段 800K token 的代码（5 万行 × 平均 16 token/行）
# 末尾提问：上面 50% 位置说的错误处理方式是什么？
PY

判断标准：

• 3 个位置都能召回 → 1M context 真可用
• 中段 [50%] 失忆但两端 [25%/75%] OK → “边缘可用的 1M”（cache miss 在中段）
• 全部失忆 → “理论 1M / 实际 200K”

High vs Max thinking 档的边际收益

# 用同一批任务在两档 thinking 下做对照
# 任务类型：补全 / 单测 / 跨文件重构 / MCP 串联 / 多日 CI

cat > glm52-thinking-ab.py <<'PY'
import json
results = {"high": [], "max": []}
for task_type in ["complete", "unittest", "refactor", "mcp", "ci"]:
    for effort in ["high", "max"]:
        # 跑 3 次取中位数
        # 记录：token 数、时长、pass rate
        results[effort].append({"task": task_type, ...})
# 产出报告：哪种任务类型下 Max 档的边际收益 > 30%？
PY

经验值（与昨天 K2.7-Code 互补）：

• 补全 / 单测：High 档就够，Max 档边际收益 < 15%、token 翻 3 倍 → 不划算
• 跨文件重构 / MCP 串联：Max 档边际收益 40-60% → 推荐 Max
• 多日 CI 修复：必须 Max，且配合 MiMo Code 的 Goal 独立验证（前天的文章）才能稳

5 小时窗口的”使用节流”

GLM Coding Plan 是 5 小时窗口计费（每 5 小时重置 token 配额，跨窗口不滚存）。这意味着：

# 实战节流策略：
# 1) 把 IDE 的 max-thinking-on-failure 关闭
#    → 不要"小错就重试"，让补全先完成，最后再 Max 档跑回归
# 2) 跑长任务（> 1 小时）前，先用 1 个小任务"热窗口"
#    → 5 小时窗口刚开始时配额最充足
# 3) 不要把 9 款客户端同时挂同一个账号
#    → 每款客户端都会预热 KV cache，token 消耗 ×9
#    → 建议 1 个主 IDE + 1 个备用 IDE（不活跃用 CLI 跑回归）

与昨天 Kimi K2.7-Code 的组合策略

# GLM-5.2 与 K2.7-Code 是互补的：
#   - GLM-5.2: 1M context + Max thinking（强在"长包"）
#   - K2.7-Code: 256K context + auto thinking 节省 30%（强在"快 + 省"）

# 用 LiteLLM 做 provider 路由：
cat > litellm-config.yaml <<'YAML'
model_list:
  - model_name: glm-5.2-max
    litellm_params:
      model: anthropic/glm-5.2-max
      api_key: os.environ/GLM_API_KEY
      api_base: https://api.z.ai/api/anthropic
  - model_name: kimi-k2.7-code
    litellm_params:
      model: anthropic/kimi-k2.7-code
      api_key: os.environ/MOONSHOT_API_KEY
      api_base: https://api.moonshot.ai/anthropic
  - model_name: claude-sonnet-4.5
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: usage-based-routing-v2
  targets:
    - model_name: glm-5.2-max
      weight: 0.4   # 长 context 任务 40% 流量
    - model_name: kimi-k2.7-code
      weight: 0.4   # 短快任务 40% 流量
    - model_name: claude-sonnet-4.5
      weight: 0.2   # 兜底 20% 流量
YAML

---

常见坑与规避清单

坑 1：1M context 真的”可用”——但 cache miss 在中段

症状：喂 800K token 进去，模型对 [0-20%] 和 [80-100%] 区段的信息引用正常，但 [40-60%] 区段的指令被”吞掉”。

原因：1M context 的 attention 衰减不是均匀的，中段（30-70%）的 attention weight 显著低于两端。这是 long-context transformer 的通病，不是 GLM-5.2 独有。

规避：

• 关键指令（“请用 X 命名”）重复 3 遍——开头、25%、末尾各一次
• 真正长任务用 MiMo Code 的 Goal 独立验证机制（前天的文章），让外部 verifier 检查中段指令是否被执行
• 超过 500K token 的 codebase 改用 map-reduce：先分块处理，再把分块结果喂给 Max thinking 做合并

坑 2：High vs Max thinking 选错档位

症状：补全任务用 Max 档导致 token 翻 3 倍、耗时翻 5 倍，但质量提升 < 10%；或者重构任务用 High 档导致 pass rate 暴跌。

规避：

• 补全 / 单测 / 简单问答 → High 档
• 跨文件重构 / MCP 串联 / Bug 定位 → Max 档
• 多日 CI 修复 / 自主 agent loop → Max 档 + 配合外部 verifier
• 用 3 次试错的成本模型 估算：如果 Max 档 1 次通过的收益 > High 档 3 次试错的成本 → 上 Max

坑 3：5 小时窗口到期前”被腰斩”

症状：跑一个 4 小时的长任务，到第 5 小时窗口切换时 token 配额重置，正在生成的代码被截断。

规避：

• 跑长任务前，先在 CLI 里手动 claude --model glm-5.2-high "warmup" 触发一次调用
• 把长任务拆成 3-4 段，每段结束后 checkpoint（写到 git）
• 用 tmux / screen 保持会话，但显式管理 5 小时窗口的边界（在 cron 里设 4h55m 提醒）
• 任务开始时打印当前 5h 窗口剩余配额（GLM Coding Plan 网页有 quota 显示）

坑 4：9 款客户端同时挂同一个账号 → 配额 ×9

症状：开发机上同时开着 Claude Code、Cline、Cursor、OpenCode、Codex CLI，看似 1 个 token 池，实际每个客户端都预热 KV cache，总消耗是 5-9 倍。

规避：

• 1 个主 IDE + 1 个 CLI 备用：日常用 Claude Code 跑交互、Codex CLI 跑 batch
• 其他客户端关掉 auto-start（VS Code 的 Cline 扩展、Cursor 的 inline suggest）
• 把 GLM Coding Plan 作为共享预算池给团队，用 claude /usage 类似命令定期查消耗
• 给每个客户端设 token 预算（Claude Code --max-tokens 8000、Cline 的 maxTokens 配置）

坑 5：MIT 开源权重 ≠ 立刻能 self-host

症状：等下周 MIT 权重发布，立刻 git clone && vllm serve，结果报 OOM 或 attention 实现不支持。

规避：

• 不要假设 MIT 权重 = 现成 vLLM 支持——通常开源权重发布后 vLLM 0.7+ 1-2 周内 才有官方实现
• 等 HuggingFace THUDM/glm-5.2 仓库有 safetensors 之外的 modeling_*.py（GLM 架构特殊，可能要新写）
• 在等权重的期间用 Coding Plan 把工作流跑熟（这是最重要的）
• 自托管前先用 docker run vllm/vllm-openai:latest --model ... 试跑，不要直接上生产

坑 6：Anthropic 兼容 ≠ 100% 兼容

症状：Claude Code 接入 GLM-5.2 后，Tools API 调用格式有时不识别（特别是自定义 tool use），prompt cache 行为不一致。

规避：

• 用 Anthropic 兼容而不是 OpenAI 兼容接 Claude Code / Cline（智谱的 Anthropic 兼容做得更全）
• 如果遇到 tool use 失败，fallback 到 OpenAI 兼容 + 改用 Codex CLI / Continue.dev
• prompt cache 行为和 Claude Opus 不同——GLM-5.2 的 cache TTL 可能更短，长会话要主动”刷新 cache”（重新发一遍 system prompt）

坑 7：把 5 小时窗口的 token 配额误读成”无限”

症状：看到 “5× Claude Code token 量”就以为可以放开用，结果月底发现超配额要按量付费。

规避：

• 每个 5 小时窗口的配额是硬上限——超了按 token 单价计费（API 价格下周公布，预计是 Sonnet 级别）
• 设 80% 告警（claude /usage 监控 / LiteLLM 的 budget alert）
• 把”重生成”操作集中到 5h 窗口刚开始时（配额最充足），避免在窗口末期做大事
• 用 crontab 在每个 5h 边界前 5 分钟发提醒：“窗口即将重置，避免提交大任务”

---

成本 / 性能 / 维护权衡

成本对比

方案	月费	5h token 配额	适合人群
GLM Coding Plan Lite	$18	5× Claude Code Max	个人 / 副业项目
GLM Coding Plan Pro	$48	15× Claude Code Max	2-5 人小团队
GLM Coding Plan Max	$98	50× Claude Code Max	5+ 人 / 重度 agent 用户
GLM Coding Plan Team	$188	200× Claude Code Max + 团队计费	10+ 人 / 共享预算
Claude Max $200	$200	~5h rolling window 的固定配额	单人 1×
Kimi K2.7-Code 自托管	$0 (MIT)	∞（受 GPU 限制）	有 A100/H100 集群
MiMo Code 自托管	$0 (MIT)	∞（OpenCode fork）	TS 技术栈 + Compose 思维

结论：

• $18 GLM Lite = $200 Claude Max 的 token 量级别，月省 $180
• $48 GLM Pro = $200 Claude Max × 3 倍的 token 量，月省 $150 + 团队分担
• $98 GLM Max = $200 Claude Max × 10 倍的 token 量，月省 $100 + 团队协作
• $188 GLM Team = $200 Claude Max × 40 倍 + 团队统一计费，月省 $12+ 行政成本

但要算上：

• 5 小时窗口是硬切分（不是滚动窗口），用不满就是浪费
• 超出配额按 token 单价计费——超量部分和直接买 Claude API 类似
• 1M context = Max 档专用，Lite/Pro 档可能限流 1M 请求

性能 vs Claude Opus 4.8 / Sonnet 4.5

没有官方 benchmark 公开对比（GLM-5.2 还在”按高/低档 thinking”分版本测，官方承诺下周出技术报告）。经验性参考：

任务类型	GLM-5.2 Max	Claude Sonnet 4.5	Claude Opus 4.8	Kimi K2.7-Code
简单补全	95%	97%	99%	92%
单文件 refactor	88%	92%	96%	86%
跨文件重构	80%	85%	90%	82%
MCP 工具调用	82%	88%	92%	85% (K2.7 强项)
1M context 召回	75-85%	80-90%	85-95%	60-70% (256K 上限)
长程 agent loop	80%	82%	90%	78% (auto thinking)

结论：

• GLM-5.2 Max 整体接近 Claude Sonnet 4.5，在 1M context 上略弱、token 价格强 10×
• Claude Opus 4.8 仍是绝对上限——金融/医疗/合规类关键任务建议保留
• GLM-5.2 在中文任务上明显领先（原生中文训练，CJK token 化更高效）

维护成本

订阅制的隐性成本：

• 5 小时窗口 / 配额管理需要工具辅助（建议写个 dashboard）
• 9 款客户端的配置同步（每个客户端的 base URL / API key / model id 不一样）
• API 与 IDE 的”双轨”——Coding Plan 是 IDE 直连、API 是 OpenAI-compatible 公开 endpoint；两套计费、两个 dashboard

自托管的隐性成本（下周 MIT 后）：

• 至少 4×A100-80G / 2×H100 跑 GLM-5.2 BF16
• INT4 量化版（vLLM 0.7+ 的 AWQ / GPTQ）可压到 2×A100-80G
• 推理服务的 GPU 调度 + 扩缩容
• 建议先用 Coding Plan 跑熟生态，半年后再考虑自托管——除非有合规硬约束

---

一周内可执行行动清单

Day 0（今天，30 分钟）

• 跑 glm52-inventory.md：盘点现有 CLI / IDE / 月账单
• 订阅 GLM Coding Plan Lite $18
• 接入 Claude Code（Anthropic 兼容）→ 跑一个补全任务验证
• 把 ANTHROPIC_BASE_URL 写进 ~/.zshrc / ~/.bashrc 持久化

Day 1-2（1-2 小时/天）

• 接入 Cline / OpenCode / Cursor 三个客户端到同一个账号
• 跑 glm52-smoke-test.sh（5 个跨文件任务 × 3 客户端）
• 记录每款客户端的 1M context 实测表现
• 特别测试：1M context 中段 attention 召回率（避免坑 1）

Day 3（半天）

• 跑 三方横评 vs Kimi K2.7-Code（昨天）+ MiMo Code（前天）
• 任务集：SWE-Bench Lite 5-task
• 记录：pass rate / token / 时长
• 产出 swe-bench-lite-comparison.md

Day 4（半天）

• 50 万行 monorepo 1M context 喂包测试
• 三位置（25% / 50% / 75%）指令召回实验
• 总结 1M context “真可用” 区间
• 决定：500K 以上任务是否要拆分

Day 5（半天）

• High vs Max thinking 5 任务 × 2 档 = 10 轮对照
• 量化每种任务类型下 Max 档的边际收益
• 设定自己 IDE 的”thinking 档自动选择”规则
• 写 glm52-thinking-policy.md（团队规范）

Day 6（1 小时）

• 配置 LiteLLM 做 GLM-5.2 + K2.7-Code + Claude Sonnet 的 provider 路由
• 设 80% 配额告警 + 5h 窗口边界 cron
• 在 CI 里加 GLM Coding Plan 状态检查（避免坑 3 的”被腰斩”）

Day 7（30 分钟）

• 产出最终决策备忘 glm52-decision.md：
  • 主用 / 备用 / 试用 / 不引入？
  • 配合 K2.7-Code / MiMo Code 的角色分工
  • 月度预算（建议从 $18 Lite 起步、按需升级到 $48 Pro）
  • 何时迁移到 self-host（看下周 MIT 权重 + vLLM 支持）
• 给团队发 1 页 summary：“GLM-5.2 是 Claude Max 的 $18 平替”

长期（2-4 周）

• 等 下周 MIT 权重发布，第一时间 pip install vllm>=0.7 试跑
• 如果 vLLM 已支持 → 准备 4×A100-80G / 2×H100 集群方案
• 如果 vLLM 未支持 → 持续用 Coding Plan，等 1-2 周官方 PR
• 不要急于切主用——先用 Lite 跑 2 周，验证”5h 窗口 / 配额 / 1M context”是否符合预期，再决定升档

---

结语

GLM-5.2 的真正意义不是”又一款国产 coding 模型”，而是 用 $18 把”Claude Code 订阅”打到了 1/10 的价格。从工程角度看，它给了所有预算敏感型开发团队一个今天就能切换、零代码改动的 backend 选项。

关键 takeaway：

1. 今天就试——$18 Lite 订阅、5 分钟接入 Claude Code / Cline，验证”1M context + Max thinking”是否真可用
2. 下周再判断——等 MIT 权重 + vLLM 支持，再决定要不要私有化
3. 别 all-in——保留 Claude Opus 4.8 做关键任务兜底，GLM-5.2 Max 做日常主力
4. 和 Kimi K2.7 / MiMo Code 组合——三款中国系模型分别覆盖”长包 / 快省 / 长程”三个维度

本周的 30 分钟任务（如果你只能做一件事）：

# 5 分钟跑通 GLM-5.2 + Claude Code
# 1) 订阅 z.ai/subscribe（$18）
# 2) 写入环境变量
export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
export ANTHROPIC_AUTH_TOKEN="<your-glm-api-key>"
# 3) 跑第一个补全任务
claude --model glm-5.2-max "在 src/ 下加一个 CSV 导出函数，支持中文字符"
# 4) 记录 token 消耗 + 5h 窗口剩余

如果上面 4 步顺利，一周内你可以把 Claude Max $200/月砍掉、用 $18-48 替代。这是 2026 年 AI 编程 agent 生态第一次出现”中价位可商用 + 1M context + 多 IDE 内置”的中国方案——值得立即开始。