AI Agent 看不懂线上崩溃？xcrashlytics 把 Crashlytics 证据送进终端
AI 编程 Agent 能读代码，却不一定能看到线上事故的完整上下文：某个崩溃影响了多少用户？从哪个版本开始？堆栈里哪些帧属于自己的代码？如果工程师还要手动打开 Crashlytics、复制错误信息，再把内容粘贴给 Agent，调查过程很容易丢失关键证据。
xcrashlytics 是一个面向 macOS 的命令行工具，连接 Firebase Crashlytics 和本地 Xcode Organizer 报告。它的定位不是替你诊断或修复代码，而是把崩溃消息、堆栈、版本范围和影响数据变成终端中可查询、可导出的证据，让人和编码 Agent 在同一份材料上工作。
先把它装起来
项目 README 当前标注支持 macOS 15+、Swift 6.0，并提供安装脚本。安装脚本会把程序放到 ~/.local/bin，同时校验 SHA-256；使用 Firebase 数据还需要 Firebase CLI。
curl -fsSL https://raw.githubusercontent.com/0xfirattamur/xcrashlytics/main/scripts/install.sh | sh brew install firebase-cli firebase login xcrashlytics init --scan
init --scan 会扫描可用应用并写入 .xcrashlytics.json。如果一个 Firebase 账号下有多个应用，可以用 xcrashlytics use 选择配置。认证复用 Firebase CLI 登录，不需要额外的 gcloud 登录流程。
如果不想执行安装脚本，也可以从源码构建：
git clone https://github.com/0xfirattamur/xcrashlytics.git cd xcrashlytics swift build -c release
从一个问题开始调查
最实用的工作方式不是先浏览所有崩溃，而是从一个具体问题开始。例如，发布结账流程后，可以先查最近一周与 checkout 相关的 issue：
xcrashlytics issues "checkout" --since 7d xcrashlytics issues --type FATAL --app-version 6.16.0 --since 30d
需要查看某个 issue 的细节时，show 会组合崩溃消息、版本范围、设备信息和最新堆栈；events 则可以进一步查看单个事件：
xcrashlytics show FB-ISSUE_ID xcrashlytics events FB-ISSUE_ID --latest --app-frames-only --format json
这里的 --app-frames-only 很适合交给 Agent：它减少系统库噪音，保留应用帧和配置为 first-party 的库。若需要用户操作线索，还可以使用 --breadcrumbs。不过要注意，xcrashlytics 只是提取证据，不会替你判断根因，也不会自动修改代码。
不要只看崩溃数量
一次崩溃是否值得优先修复，通常取决于影响范围，而不仅是标题。breakdown 可以按版本、操作系统或设备拆分报告计数：
xcrashlytics breakdown FB-ISSUE_ID --by version --since 30d xcrashlytics breakdown FB-ISSUE_ID --by os --since 30d xcrashlytics breakdown FB-ISSUE_ID --by device --since 30d
项目文档特别区分了精确统计和抽样分析：issues 与 breakdown 用于报告总数；blame 和 --user-id 依赖抽样事件，适合发现可能相关的文件、符号或用户线索，但不应被当成完整总体统计。
如果多个 issue 可能由同一个符号引起，可以试试：
xcrashlytics blame --since 7d --top 20 xcrashlytics groups
这一步的价值在于把“很多看似不同的崩溃”收敛成代码层面的调查方向。
给 Agent 的正确上下文
README 提供了一段可直接交给编码 Agent 的指令：让 Agent 按仓库内的 AGENTS.md 完成安装、扫描应用，并输出前三个 issue 的 JSON 和摘要。实际使用时，建议把范围再收窄，例如要求它只读取 --format json 的结果，明确区分 warnings 和 errors，并且不要把用户标识、日志或自定义键复制到公共渠道。
xcrashlytics issues --since 7d --format json xcrashlytics events FB-ISSUE_ID --latest --app-frames-only --format json
JSON 输出包含 schemaVersion、data 和 warnings；失败结果包含稳定的 error.code 和提示。命令成功不代表证据完整，Agent 仍然应该先检查 warnings，再生成结论。对 CI 或脚本来说，结构化输出比解析人类可读文本可靠得多。
Xcode 本地报告与隐私边界
针对 iOS，工具还可以读取已经下载到 Xcode Organizer 的 .crash 和 .ips 报告，不会连接 Apple 服务：
xcrashlytics issues --xcode xcrashlytics groups --xcode
Firebase 堆栈中如果有未解析的 Apple 二进制帧，可以提供对应构建的 dSYM：
xcrashlytics events FB-ISSUE_ID --latest --dsym path/to/dSYMs --format json
最后用 Markdown 报告把调查结果交给团队：
xcrashlytics export FB-ISSUE_ID --since 30d --output crash.md xcrashlytics open FB-ISSUE_ID
工具声明不会原样打印用户 ID，export 也不会包含用户 ID；但报告仍可能包含堆栈帧和日志，分享前必须人工检查。它只把证据搬到 Agent 面前，不会自动替你做隐私脱敏。
适合什么团队？
如果团队主要使用 macOS、Firebase Crashlytics，并且已经在使用 Claude Code、Codex 或其他终端 Agent，xcrashlytics 的价值很直接：减少控制台与终端之间的复制粘贴，让 Agent 看到“哪个版本、哪些设备、影响多少人、具体哪一帧”的组合信息。它目前不是跨平台崩溃平台，也不是自动修复器；安装包未签名和公证，项目建议通过校验和确认下载内容。把它当成一个证据入口，而不是诊断权威，才是更稳妥的使用方式。
相关链接