AI 构建诊断

原生构建日志很长。当 iOS (Xcode / Fastlane) 或 Android (Gradle / Fastlane) 构建失败时，Capgo 可以将日志传递给 AI 构建工程师，指出 哪里出了问题以及如何修复 — 因此您不必自己浏览数千行日志。

启用它

添加 --ai-analytics 将其添加到您的构建中：

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

诊断仅在构建失败时才会启动 失败的构建 成功的构建将保持不变。

当它运行时

失败的构建的行为取决于您在哪里运行它以及是否传入了标志：

环境	--ai-analytics	行为
交互式终端	是	立即诊断故障
交互终端	否	先询问后提供诊断
CI/非交互	是	自动运行并将诊断打印到标准错误
CI/非交互	否	跳过 — 没有发送任何内容

因此在 CI 中您必须通过 --ai-analytics在终端中，您始终会被要求输入命令，除非您使用了预先设置的标志。

您将获得

一个简短的、聚焦的Markdown报告：

• 可能的原因 —— 一句话。
• 证据 —— 从您的日志中引用的最相关的1-3行。
• 建议的修复 —— 修改 您的 项目（签名配置、缺失的能力、Gradle或CocoaPods问题、插件冲突等）的步骤。

如果日志不明确，它会说明并列出前几种假设，而不是捏造不存在的错误。

你的日志，自由选择

AI 诊断是 可选 ——除非你传递或确认提示，否则不会发送任何内容。 --ai-analytics __CAPGO_KEEP_0__ AI（默认）：

• 你的构建日志会被截取并发送到Capgo的分析端点（该端点在__CAPGO_KEEP_1__ Workers AI上运行）仅用于产生诊断。构建日志不属于正常存储——它们会流式传输到你的终端中。 your build log is trimmed and sent to Capgo’s analysis endpoint (which runs on Cloudflare Workers AI) just long enough to produce the diagnosis. Build logs aren’t part of normal storage — they stream to your terminal during the build.
• 在交互式终端中，你可以让__CAPGO_KEEP_0__代替写一个本地提示文件 in an interactive terminal you can instead have the CLI __CAPGO_KEEP_0__ — 同样的诊断指令加上您的日志 — 那些您粘贴到您的LLM中的内容。您的日志永远不会离开您的机器。

注意

分析会将您的构建日志视为不受信任的数据，因此看起来像指令的日志行（一个提示注入尝试）无法劫持诊断。