用Gemini CLI部署LINE Bot：我们踩过的坑比写的代码还多

部署一个带OAuth授权、Firestore数据库和Cloud Run容器的项目，通常意味着新手要在gcloud命令行里挣扎很久。但在即将举行的Build With AI 2026工作坊上，我们打算用Gemini CLI把这个过程变成"聊天就能搞定"的事。

这个项目的核心是个LINE Bot文件备份机器人——用户直接在LINE聊天室上传图片和文件，自动同步到Google Drive，并按月份自动归档。听起来简单，实际涉及的服务链条却很长。

准备工作极简：装好gcloud并登录，再装上Gemini CLI。我们准备了一组"机密参数"（本文均已做Mock处理），然后对AI说了第一句话："帮我用gcloud部署到Cloud Run，需要信息时停下来问我。参考这个repo……"

Gemini CLI立刻分析了Dockerfile和main.go，列出完整作战计划。它先确认了我的gcloud项目设置，然后一次性启用了所需服务：Firestore、Cloud Build、Cloud Run、Artifact Registry。

第一个坑出现在创建Firestore数据库时。Bot需要记录OAuth State防伪标记，AI尝试执行命令却报错。修正后的正确命令是：指定asia-east1位置和firestore-native类型。

接下来是经典的"鸡生蛋"困境：Google OAuth需要Cloud Run的URL作为回调地址，但Cloud Run部署又需要OAuth的Client ID和Secret。Gemini CLI的策略很聪明——先用占位符部署。

部署命令里，GOOGLE_CLIENT_ID、GOOGLE_CLIENT_SECRET、GOOGLE_REDIRECT_URL都填了PENDING，其他LINE相关的密钥也先用占位符。成功后拿到一串URL：https://linebot-backup-service-xxxxx.a.run.app。

这个URL就是后续OAuth配置的关键。整个过程中，AI扮演的DevOps角色确实省了大量查文档的时间，但"奇迹"背后是一连串需要人工介入的bug修复。所谓"用说话完成部署"，更像是"用说话启动部署，然后边骂边调"。

工作坊上会完整展示这些真实踩坑记录——包括那些AI自信满满给出、实际跑不通的命令。