gpc-vitals-monitoring

GPC 生命体征监控

适用场景

在以下任务中使用此技能：

• 使用 gpc watch 进行实时发布监控（多项指标、自动执行操作）
• 监控崩溃率、ANR 率和其他 Android Vitals 指标
• 为 CI/CD 设置基于阈值的告警
• 跟踪应用启动时间、帧率、电池和内存
• 查看并回复用户评价
• 使用 GPC 输出构建监控流水线
• 比较不同时期的生命体征数据
• 调查错误问题和异常情况
• 下载 Play 批量报告（安装量、崩溃、评分、收入、订阅）为 CSV

所需输入

• 软件包名称（或已配置的默认值）
• 要监控的指标类型（崩溃、ANR、启动、渲染、电池、内存）
• 版本代码（可选，用于按版本筛选）
• 阈值（用于 CI 告警）

操作步骤

0) 统一健康快照——从这里开始

最快速地全面了解发布、生命体征和评价的方法：运行一条命令。

gpc status

输出：

App: com.example.myapp · My App  (fetched 10:42:01 AM)

RELEASES
  production   v1.4.2   completed    —
  beta         v1.5.0   inProgress  10%

VITALS  (last 7 days)
  crashes     0.80%  ✓    anr         0.20%  ✓
  slow starts 2.10%  ✓    slow render 4.30%  ⚠

REVIEWS  (last 30 days)
  ★ 4.6   142 new   89% positive   ↑ from 4.4

并行调用 6 次 API，结果在 3 秒内返回。缓存 1 小时。

gpc status --days 14          # Wider vitals window
gpc status --cached           # Instant — no API calls (uses last fetch)
gpc status --refresh          # Force live fetch, ignore cache
gpc status --output json      # Full structured output for scripts

若任何生命体征指标超过阈值，则退出代码为 6——可将其用作部署门禁。

1) 单项指标生命体征仪表板

如需查看 gpc status 未提供的单项指标详情：

gpc vitals overview

2) 崩溃监控

# Crash rate and top clusters
gpc vitals crashes

# Group by version code
gpc vitals crashes --dim versionCode

# CI threshold alerting — exit code 6 if crash rate exceeds threshold
gpc vitals crashes --threshold 0.02

退出代码 6 表示超过阈值——可用它来限制部署。

比率阈值是小数，与 Google 的报告方式一致：2% 为 0.02，1.09% 为 0.0109，0.47% 为 0.0047。比率不可能超过 1，因此值为 1 或更大时会被拒绝，并返回 THRESHOLD_INVALID（退出代码 2），而不是导致告警始终无法触发。error-count 是计数，因此应传入计数值。

3) ANR 监控

gpc vitals anr
gpc vitals anr --dim versionCode
gpc vitals anr --threshold 0.0047  # Google's bad behavior threshold

4) 性能指标

# Cold/warm startup times (auto-includes startType as a required dimension)
gpc vitals startup

# Frame rate / rendering
gpc vitals rendering

# Battery usage
gpc vitals battery

# Stuck background wakelocks (despite the name, not a memory-usage metric)
gpc vitals memory

# Excessive wakeup rate
gpc vitals wakeup

# Low memory killer rate (LMK)
gpc vitals lmk

# Memory usage percentiles (v0.9.97+)
gpc vitals memory-rss
gpc vitals memory-bitmap

gpc vitals memory 是卡死唤醒锁指标集（为兼容性而沿用此名称），gpc vitals wakeup 是过度唤醒率。要查看实际内存用量，请使用下方的 memory-rss / memory-bitmap。它们都支持与其他生命体征子命令相同的标志：--days <n>、--threshold <value>、--json。

内存用量百分位数（gpc vitals memory-rss / memory-bitmap，v0.9.97+）

Google Play 于 2027 年 2 月发布的质量要求以 P90 评估动态内存。这两个命令会查询 Play Developer Reporting 内存指标集在 P50、P75、P90、P95 和 P99 的数据：

• gpc vitals memory-rss —— 匿名 RSS 加交换空间用量
• gpc vitals memory-bitmap —— 位图内存用量

gpc vitals memory-rss --app com.example.app --days 30
gpc vitals memory-rss --app com.example.app --dim deviceRamBucket   # hardware dimension
gpc vitals memory-rss --app com.example.app --dim appState          # foreground vs background
gpc vitals memory-bitmap --app com.example.app --dim deviceModel
gpc vitals memory-rss --app com.example.app --threshold <value>     # gates on P90, exit 6 on breach

Reporting API 仅提供每日聚合的数据，GPC 会强制采用此粒度。--threshold 会针对 P90（anonRssAndSwapMemoryUsageP90 / bitmapMemoryUsageP90）进行评估，这是 Google 要求采用的相同百分位数。gpc verify checklist 会跟踪此要求本身；在 Google 发布阈值之前，不会提供预检规则。

低内存杀手率（gpc vitals lmk，v0.9.58+，已在 v0.9.59 中修正）

背景：v0.9.58 发布了一个名称错误的资源（lowMemoryKillerRateMetricSet），导致 404。v0.9.59 是可正常使用的版本——Google 的实际资源为 lmkRateMetricSet，包含指标 userPerceivedLmkRate、userPerceivedLmkRate7dUserWeighted、userPerceivedLmkRate28dUserWeighted 和 distinctUsers。查询 LMK 时请使用 v0.9.59+。

gpc vitals lmk --app com.example.app --days 7

支持与其他生命体征子命令相同的标志：--days <n>、--threshold <value>、--json。

注意： v0.9.41 提升了生命体征内存数据的准确性（Bug H：指标字段名称从 stuckBackground 修正为 stuckBg）。

错误发生次数（gpc vitals error-count，v0.9.57+）

gpc vitals error-count 从 Play Developer Reporting API 返回指定时间窗口内的错误问题发生次数。如果 CI 门禁需要绝对计数而非比率，请使用此命令。

gpc vitals error-count --app com.example.app --days 7
gpc vitals error-count --app com.example.app --days 7 --threshold 100

若计数超过 --threshold，则退出代码为 6（与其他生命体征命令使用相同的 CI 约定）。

4a) 比较不同版本的指标

并排比较两个版本代码的所有关键指标：

gpc vitals compare-versions <v1> <v2>

# Example
gpc vitals compare-versions 141 142

# Wider time window
gpc vitals compare-versions 141 142 --days 14

# JSON output for scripting
gpc vitals compare-versions 141 142 --json

# Markdown table (for GitHub comments, Slack, etc.)
gpc vitals compare-versions 141 142 --format markdown

比较：崩溃率、ANR 率、启动时间、渲染、电池和内存。每个版本使用互不重叠的 7 天时间窗口。终端输出中会用红色突出显示退化情况。

注意： gpc vitals compare-versions 使用互不重叠的 7 天时间窗口，两个窗口的结束时间都设在今天之前 2 天，以适应 API 数据延迟。

新鲜度校准（v0.9.70+）： Google 的 vitals 数据通常比实时数据延迟 3-4 天。GPC 现在会在运行任何 vitals 查询前，查询每组指标的新鲜度端点，并自动校准日期范围。这可防止请求的日期范围超出 Google 可用的数据窗口时出现此前发生的 400 INVALID_ARGUMENT 错误。无需配置。

4b) 实时发布监控（gpc watch，v0.9.67+）

gpc watch 是统一的发布监控命令。它会按间隔轮询发布状态（近实时）和 vitals 数据（延迟 2-4 天），检查阈值，并在超出阈值时采取行动。

# Basic: monitor crashes + ANR on production, poll every 15 minutes
gpc watch

# Watch a beta rollout with tighter thresholds
gpc watch --track beta --crash-threshold 0.015 --anr-threshold 0.005

# Auto-halt the rollout on any threshold breach
gpc watch --on-breach halt

# Notify + halt + send webhook on breach
gpc watch --on-breach notify,halt,webhook \
  --webhook-url https://hooks.slack.com/services/XXX

# CI mode: 3 rounds, 5-minute interval, NDJSON output
gpc watch --rounds 3 --interval 300 --json

# Monitor all 6 metrics
gpc watch --metrics crashes,anr,lmk,slowStarts,slowRender,errorCount

六项指标： crashes、anr、lmk、slowStarts、slowRender、errorCount。

三种超限操作（可通过 --on-breach 组合使用）：

• notify — OS 通知（macOS、Linux、Windows）
• halt — 通过 Google Play API 停止当前发布
• webhook — 将超限事件作为 JSON POST 到 --webhook-url

阈值按以下优先级解析：CLI 标志 > .gpcrc.json 中的 vitals.thresholds.* > 默认值（崩溃率 2% / 0.02、ANR 率 1% / 0.01、LMK 3% / 0.03、启动缓慢 5% / 0.05、渲染缓慢 10% / 0.1）。标志和配置值均使用小数表示。

**自动停止：**发布达到 100%、超限触发停止操作、达到 --rounds 限制或按下 Ctrl+C 时，监控循环会停止。

**退出码：**0 = 正常，6 = 至少有一项指标超出阈值。

Webhook 负载：

{
  "type": "breach",
  "round": 3,
  "rollout": { "track": "production", "versionCode": "142", "userFraction": 0.1 },
  "vitals": { "crashes": { "value": 0.025, "threshold": 0.02, "breached": true } },
  "breaches": ["crashes"],
  "halted": true
}

在配置中设置 Webhook URL，避免每次都传入：

{
  "webhooks": { "watch": "https://hooks.slack.com/services/XXX" }
}

注意： gpc vitals watch（单指标监控器）仍可使用，但从 v0.9.67 起，建议使用 gpc watch 监控发布。

5) 错误跟踪和异常

# Detected anomalies
gpc vitals anomalies

# Error issues and reports
gpc vitals errors search

**v1.0.0-rc.1 中的变更：**如果项目未启用 Play Developer Reporting API，或服务账号无法读取此应用的 vitals，gpc vitals 和 gpc anomalies list 会以退出码 4 失败。人类可读输出仍会说明原因，并在 stderr 中打印启用 URL；--json 会包含错误代码和 Google 返回的消息。在 v0.9.47 到 v0.9.99 期间，这些命令会打印该消息并以退出码 0 退出，这意味着 CI 中的 --threshold 检查可能在从未读取任何指标的情况下通过。其他命令不受影响。

6) 评论情感分析

基于本地 NLP 的评论情感分析——无需外部 API：

gpc reviews analyze

# Filter by date range
gpc reviews analyze --since 2026-01-01
gpc reviews analyze --days 30

# Filter by language
gpc reviews analyze --lang en

# JSON output
gpc reviews analyze --json

# Markdown report (for GitHub, Confluence, etc.)
gpc reviews analyze --format markdown

输出包括：

• 情感趋势随时间的变化（正面/中性/负面）
• 主题聚类（用户最常讨论的内容）
• 关键词频率表
• 按版本细分的评分分布

所有处理均在本地进行——不会调用第三方 NLP 服务。

7) 评论监控

# Recent reviews
gpc reviews list

# Filter by rating
gpc reviews list --stars 1-2

# Filter by language
gpc reviews list --lang en

# Filter by time
gpc reviews list --since 7d

# Full text of truncated reviews (v0.9.83+)
gpc reviews list --full-text

# Single review details
gpc reviews get <review-id>

# Reply to a review (max 350 chars — validated before sending)
gpc reviews reply <review-id> --text "Thank you for your feedback"

# Auto-paginate all reviews (API returns max 10 per page by default)
gpc reviews list --all

# Start from a specific index (for manual pagination)
gpc reviews list --start-index 20

# Export reviews
gpc reviews export --format csv --output-file reviews.csv

v0.9.47 新增：--all 会自动翻页遍历所有评论页面。发送前会根据 Google Play 的 350 个字符限制校验回复文本——超出限制会立即以退出码 2 退出。注意：Reviews API 只会返回过去 7 天内的生产环境评论。

v0.9.83 新增：reviews list 会为每条评论添加 hasReply、lang 和明确的 [truncated] 标记，并提供 --full-text 标志以获取完整的未截断文本。reviews list --json 使用统一的 { reviews, nextPageToken, meta.count } 封装（会破坏读取裸数组的脚本）。

阅读：

• references/review-management.md

8）基于阈值的 CI 门控

使用 --threshold，根据核心指标质量控制发布：

# Gate on crash rate (exits with code 6 if breached)
gpc vitals crashes --threshold 0.02

# Gate on ANR rate
gpc vitals anr --threshold 0.0047

# Combine in a script
gpc vitals crashes --threshold 0.02 && \
gpc vitals anr --threshold 0.0047 && \
echo "Vitals OK — safe to promote"

门控不会盲目通过（v1.0.0-rc.1+）。 如果 --threshold 运行没有返回指标值，程序会以退出码 6 退出，并报告 THRESHOLD_NO_DATA，而不是以 0 退出。常见原因包括 --app 错误、Play 数据延迟 2-4 天，以及应用流量过少。请检查 --app、扩大 --days，或在该次运行中移除 --threshold。同一命令遇到 403 时会以退出码 4 退出。

门控如何读取核心指标（v1.0.0-rc.2+）。 速率阈值使用小数（0.02 = 2%）；1 或更大的值会被拒绝，并报告 THRESHOLD_INVALID（退出码 2）。门控会比较最近一天的最差值：启动指标每种启动类型对应一行，错误计数每种报告类型对应一行；使用 --dim 时，每个维度值各自对应一行，因此 --dim deviceModel --threshold 0.02 会在任一设备型号的值超过 2% 时失败。gpc watch 会评估最近一天的数据；如果无法读取带有阈值的受监控指标，则以退出码 4 退出。releases rollout increase --vitals-gate 和 gpc train advance 在数据缺失时会阻止操作，而不是继续推进。在 rc.2 之前，gpc watch 始终收不到值（它错误解析了 Google 的响应），因此依赖 --on-breach halt 前请先升级。

在 CI 中，使用退出码 6 阻止晋级：

- name: Check vitals before promotion
  run: |
    gpc vitals crashes --threshold 0.02
    gpc vitals anr --threshold 0.0047
- name: Promote to production
  if: success()
  run: gpc releases promote --from beta --to production --rollout 10

阅读：

• references/ci-gating.md

8a）发布比例提升时的核心指标门控（--vitals-gate，v0.9.74+）

发布命令中的 --vitals-gate 标志会在提升发布比例之前检查崩溃和 ANR 阈值。如果任一阈值超标，则完全跳过此次提升，GPC 以退出码 6 退出。在指标异常期间，不会有用户受到更高发布比例的影响。

此前的行为（v0.9.74 之前）： GPC 先提升发布比例，然后检查核心指标；如果阈值超标，再停止发布。这会导致用户在异常期间仍处于新的、更高的发布比例。

新的行为（v0.9.74+）： GPC 会先检查核心指标。如果阈值超标，则不会提升发布比例。

# Increase rollout only if the crash rate is within the configured threshold
gpc releases rollout increase --track production --to 50 --vitals-gate

# Use in a staged rollout script
gpc releases rollout increase --track production --to 10 --vitals-gate
gpc releases rollout increase --track production --to 25 --vitals-gate
gpc releases rollout increase --track production --to 50 --vitals-gate
gpc releases rollout increase --track production --to 100 --vitals-gate

--vitals-gate 本身不带阈值标志：它会从 .gpcrc.json 读取 vitals.thresholds.crashRate，该值为小数（0.02 即 2%）。如果没有此键，则会发出警告并跳过门控。

退出码 6 表示核心指标阈值超标，发布比例提升未执行。退出码 0 表示核心指标检查通过，发布比例已提升。

在 CI 中，使用 if: success() 守卫，让流水线在第一个门控失败时停止：

- name: Ramp to 25%
  run: gpc releases rollout increase --track production --to 25 --vitals-gate

- name: Ramp to 50%
  if: success()
  run: gpc releases rollout increase --track production --to 50 --vitals-gate

- name: Full rollout
  if: success()
  run: gpc releases rollout increase --track production --to 100 --vitals-gate

在 .gpcrc.json 的 vitals.thresholds.crashRate 下设置门控阈值，使用小数（0.02 即 2%）。

阅读：

• references/ci-gating.md

8b）核心指标门控崩溃率修复（v0.9.82）

早期版本中，rollout increase 的核心指标门控崩溃率检查（--vitals-gate 标志）会被静默跳过。根本原因是：GPC 访问了 Reporting API 返回的 MetricSetResponse 结构中的 .data 字段，但该字段并不存在。因此，无论崩溃率如何，门控都会通过。

v0.9.82 中的修复读取 rows[last].metrics[firstMetric].decimalValue.value，与 gpc train 从同一 API 读取崩溃率的方式一致。要让 --vitals-gate 的崩溃率检查正常工作，必须升级到 v0.9.82+。

8c）配置中的 VitalsThresholds（v0.9.82）

VitalsThresholds 现在是 @gpc-cli/config 中 GpcConfig 和 ResolvedConfig 的正式类型化字段。在项目级别的 .gpcrc.json 中设置阈值：

{
  "vitals": {
    "thresholds": {
      "crashRate": 0.02,
      "anrRate": 0.005
    }
  }
}

配置中的阈值与标志一样，均使用小数：0.02 为 2%，0.005 为 0.5%。这些值会作为 --vitals-gate、gpc watch 和 gpc vitals crashes/anr --threshold 的默认值。命令行标志仍优先于配置。

9）Reporting API 速率限制

Play Developer Reporting API 的速率限制为 每秒 10 次查询。GPC 会自动处理此情况——如果达到限制，请求会进入队列，并在退避后重试。无需配置。

10）监控流水线

将 JSON 输出传送到你的监控技术栈：

# Send crash data to your monitoring tool
gpc vitals crashes --output json | jq '.data' | curl -X POST ...

# Periodic check (cron)
gpc vitals overview --output json >> /var/log/gpc-vitals.jsonl

11) 报告：批量 CSV 下载（自 v0.9.93 起可用）

Play 会将月度批量报告作为 CSV 文件存放在与开发者账号关联的 Google Cloud Storage 存储桶中，而不是通过 Publisher API 提供。自 GPC v0.9.93 起，gpc reports 会使用同一服务账号直接读取该存储桶；在 v0.9.93 之前，这些命令只会说明数据所在位置。

一次性授权。 Play 不会自动向服务账号授予报告存储桶的访问权限：该存储桶仅会授权给你自己的用户登录账号。在 Play Console -> Users and permissions -> the service account -> Account permissions 中，启用 "View app information and download bulk reports (read-only)"，然后等待几分钟，让权限生效。如果没有该权限，所有报告命令都会因 REPORT_ACCESS_DENIED（退出码 4）而失败。可通过 gpc doctor 检查；其中的 reports-bucket 探测会在缺少授权时发出警告。

存储桶解析。 默认值为 pubsite_prod_<developerId>，根据 developerId 配置项或 GPC_DEVELOPER_ID 推导。如果账号的存储桶名称不同，请从 Play Console -> Download reports 复制准确的 Cloud Storage URI 并覆盖默认值：

设置	设置方式
标志（优先级最高）	--bucket pubsite_prod_1234567890
环境变量	GPC_REPORTS_BUCKET=pubsite_prod_1234567890
配置	"reports": { "bucket": "pubsite_prod_1234567890" }
推导出的默认值	developerId / GPC_DEVELOPER_ID

# List report files for a type, optionally narrowed to one month
gpc reports list installs --app com.example.myapp --month 2026-02
gpc reports list earnings --month 2026-02
gpc reports list crashes --app com.example.myapp --limit 20 --next-page <token>

# Stats reports (per app), decoded UTF-8 CSV on stdout
gpc reports download stats --app com.example.myapp --month 2026-02 --type installs
gpc reports download stats --app com.example.myapp --month 2026-02 --type crashes \
  --dimension country --output-file crashes-2026-02.csv

# Financial reports (account-level, no --app)
gpc reports download financial --month 2026-02 --type earnings
gpc reports download financial --month 2026-02 --type play_balance \
  --output-file balance-2026-02.csv

reports list <report-type> 接受单个报告类型（而非 stats / financial），并返回与其他 list 命令相同的 --json 封装：{ reports, nextPageToken, meta.count, message? }。Stats 类型会限定为已配置的应用；financial 类型则是账号级别。

报告类型。Financial：earnings、sales、estimated_sales、play_balance。Stats：installs、crashes、ratings、reviews、store_performance、subscriptions。sales 和 estimated_sales 是同一 Play 报告的两种名称，返回的数据相同。

维度（仅限 stats 的 --dimension，默认为 overview）：overview、country、language、os_version、device、app_version、carrier、traffic_source。Play 会按每个维度、每个月发布一个 CSV；评论报告没有维度。如果所请求的维度在该月不存在，错误信息会列出实际存在的维度。

编码和归档：Play 会以 gzip 压缩和 UTF-16 编码存储这些对象。GPC 会解压并重新编码为 UTF-8 文本，因此输出可以直接通过管道传给标准 CSV 工具。Financial 报告以 ZIP 归档形式提供：如果归档中只有一个 CSV，会自动解包；如果归档中有多个 CSV，则需使用 --output-file report.zip（保存原始归档）或 --json（内联所有条目）。

使用 --json 时，下载命令会输出以下三种封装之一：

{ "objectName": "...", "csv": "..." }
{ "objectName": "...", "outputFile": "...", "bytes": 1234 }
{ "objectName": "...", "entries": [{ "name": "...", "csv": "..." }] }

最小权限：只有报告命令（以及对应的 gpc doctor 探测）会请求 devstorage.read_only 作用域，并且存储作用域的令牌会单独缓存，因此其他命令的令牌不会包含存储访问权限。如果新授予的权限尚未生效，gpc auth clear-cache 会清除缓存令牌，但不会移除凭据。

此路径特有的错误代码：REPORT_ACCESS_DENIED（4，缺少授权）、REPORT_BUCKET_UNKNOWN / REPORT_BUCKET_INVALID（2）、REPORT_BUCKET_NOT_FOUND（4）、REPORT_OBJECT_NOT_FOUND（4）、REPORT_AUTH_REJECTED（3）。完整列表见 gpc-troubleshooting。

验证

• gpc status 显示全部三个部分（发布、运行状况、评论），且无错误
• gpc watch --rounds 1 完成一轮轮询，且无错误
• gpc vitals overview 返回数据（需要足够的安装量）
• 阈值命令返回退出代码 0（正常）或 6（超出阈值）
• gpc reviews list 返回近期评论
• JSON 输出可解析：gpc vitals crashes --output json | jq .
• gpc doctor 将 reports-bucket 显示为通过（已授予 bulk-reports 权限）
• gpc reports list installs --month <last full month> 至少返回一个对象

故障模式 / 调试

症状	可能原因	修复方法
没有运行状况数据	应用安装量不足	运行状况数据需要大量安装量；小型应用可能没有数据
THRESHOLD_INVALID（退出代码 2）	速率阈值写成了百分比（例如 2.0）	使用小数：2% 写作 0.02（v1.0.0-rc.2+）
API_METRIC_GAMES_ONLY（退出代码 4）	在非游戏应用上运行 vitals rendering	这是预期行为：Google 仅为游戏提供慢速渲染数据（v1.0.0-rc.2+）
THRESHOLD_NO_DATA（退出代码 6）	设置了 --threshold，但没有返回指标值	--app 错误、数据延迟或没有流量。检查 --app，扩大 --days 范围，或在本次运行中移除 --threshold（v1.0.0-rc.1+）
退出代码 4，并显示 Reporting API 启用链接	Reporting API 未启用，或服务账号无法读取此应用	为项目启用 Play Developer Reporting API，并授予服务账号访问权限。在 v1.0.0-rc.1 之前，退出代码为 0
--threshold 始终通过	阈值过高，或在 rc.2 之前的版本中写成了百分比	阈值使用小数（0.02 = 2%）。先用 gpc vitals crashes 检查当前速率
Reviews API 速率限制	请求过多	Reviews API：每小时 200 次 GET，每天 2,000 次 POST。请错开请求。
找不到报告	月份格式错误	使用 YYYY-MM 格式（例如 2026-02）
任何报告命令都出现 REPORT_ACCESS_DENIED	服务账号缺少 bulk-reports 权限	Play Console -> Users and permissions -> 服务账号 -> Account permissions -> 启用“View app information and download bulk reports (read-only)”，等待几分钟，然后运行 gpc auth clear-cache 并重试
REPORT_BUCKET_UNKNOWN	没有 developerId，也没有显式指定存储桶	设置 developerId / GPC_DEVELOPER_ID，或传入 --bucket / GPC_REPORTS_BUCKET / reports.bucket
REPORT_BUCKET_NOT_FOUND	账号的存储桶不是 pubsite_prod_<developerId>	从 Play Console -> Download reports 复制准确的 Cloud Storage URI，并通过 --bucket 设置
带有维度的报告出现 REPORT_OBJECT_NOT_FOUND	该维度在此月份未发布	错误信息会列出实际存在的维度；评论报告没有维度
报告月份没有返回任何内容	该月份尚未结束	Play 会在月份结束后发布该月的报告；请使用上一个完整月份
多 CSV 财务归档无法打印	REPORT_MULTIPLE_ENTRIES	使用 --output-file report.zip 保存归档，或使用 --json 内联所有条目
崩溃集群为空	新版本	崩溃数据需要时间汇总；请在 2-4 天后再次检查

相关技能

• gpc-setup：身份验证和配置
• gpc-release-flow：上传和发布管理
• gpc-ci-integration：在 CI 中自动检查运行状况