AI 构建诊断

Native Build 日志很长。当 iOS（Xcode / Fastlane）或 Android（Gradle / Fastlane）构建失败时，Capgo 可以把日志交给 AI 构建工程师分析，精准定位 哪里出了问题以及如何修复 ——这样你就不用自己翻几千行日志了。

启用

添加 --ai-analytics 应用于你的构建：

bunx @capgo/cli@latest build request com.example.app --platform android --ai-analytics

诊断仅在构建 失败时触发 — 成功的 build 不受影响。

运行时机

Build 失败后的处理方式取决于运行位置以及是否传入了该 flag：

环境	--ai-analytics	行为
交互式终端	是	立即诊断失败原因
交互式终端	否	先询问，再提供诊断结果
CI / 非交互模式	是	自动运行并将诊断结果输出到 stderr
CI / 非交互模式	否	已跳过 — 未发送任何内容

因此在 CI 环境中，你必须通过以下方式启用： --ai-analytics；而在终端中，除非使用了预选标志，否则始终会先进行询问。

你将获得

一份简明扼要的 Markdown 报告：

• 可能原因 — 一句话总结。
• 依据 — 从日志中摘录的 1–3 行最相关内容。
• 建议修复方案 — 需要在项目中修改的步骤（如签名配置、缺失的 capability、Gradle 或 CocoaPods 问题、插件冲突等）。 你的 项目（签名配置、缺失的 capability、Gradle 或 CocoaPods 问题、插件冲突等）。

如果日志信息模糊，它会如实说明并列出最可能的假设，而不是凭空捏造错误。

日志由你掌控

AI 诊断功能为 可选开启 — 除非你通过以下方式发送，否则不会发送任何内容： --ai-analytics 或确认 prompt。

• Capgo AI (默认): 你的 build log 会被精简并发送至 Capgo 的分析端点（运行在 Cloudflare Workers AI 上），时长仅够生成诊断结果。Build logs 不属于常规存储 — 它们在 build 期间流式传输到你的终端。
• 将 logs 保留在本地： 在交互式终端中，你可以让 CLI 生成一个本地 prompt 文件 — 包含相同的诊断指令及你的 log — 然后将其粘贴到你自己的 LLM 中。你的 logs 永远不会离开你的机器。

注意

分析过程将你的 build log 视为不可信数据，因此看起来像指令的 log 行（即 prompt-injection 尝试）无法劫持诊断过程。