🛠 技术避坑：Antigravity 登录卡顿与验证失败解决方案
有成员反馈 Antigravity 工具（涉及 Cursor 协作或 AI 辅助）在登录 Google 账号时出现卡死、无响应或验证后无法跳转回软件的问题。
经过集体排查，主要症结与解决方案如下：
-
首选方案：开启 TUN 模式
-
这是解决“验证成功但无法回调软件”最有效的手段。多位 Mac 和 Windows 用户验证，将代理工具开启 TUN 模式（或全局代理） 后问题立刻解决。
-
如果普通全局模式无效，建议检查代理软件是否配置了定向过滤（Proxifier 也是一个备选方案）。
-
-
账号与地区因素
-
地区限制： 建议将 Google 账号位置或支付地址改为美国。有群友通过补全虚拟卡的美国地址信息，解决了跳转失败的问题。
-
系统差异： Mac 用户的成功率似乎低于 Windows 用户，部分 Mac 用户在尝试换号、换节点后依然卡顿，而 Windows 用户使用 V2 协议通常较顺畅。
-
-
其他排查点
-
浏览器拦截： 检查默认浏览器的安全设置，确保未拦截软件唤起请求。
-
工具推荐： 群友推荐在 Linux.do 论坛查找相关网络配置规则，或使用专门的多账号管理工具来辅助。
-
⚠️ 开发实战警示：严禁直接修改生产环境数据库
二期群的一位同学分享了一次惨痛教训：在产品已有真实用户的情况下，为了调整价格套餐，直接在 Supabase 生产数据库（Prod）中修改了表格内容，结果导致逻辑崩坏，数据无法正常写入。
由此引发的开发规范与重构建议：
-
开发铁律： 无论项目多小，必须分离开发库（Dev）和生产库（Prod）。任何修改应先在 Dev 环境测试，确认无误后再合并或同步到 Prod，绝对禁止在线上环境“裸奔”改动。
-
面对“屎山代码”怎么办？
-
当项目代码混乱（屎山）但已有真实用户时，是否应该重构？
-
小排老师建议：重做。
-
核心逻辑： 现阶段的核心目标是修炼内功（提升 AI 编程能力）。不要因为项目小众就敷衍，也不要急于变现。正如群友所言：“基础没打好，大钱来了也兜不住。”
-
心态调整： “慢就是快”。通过重构或重写，完整跑通规范流程，总结错误，比单纯维护一个烂摊子更有价值。
-
💡 产品思维：代码廉价时代的“非公约数”机会
在讨论产品方向时，群内产生了一个非常有价值的观点：
-
旧时代逻辑： 代码昂贵，产品经理只关注“最大公约数”需求（即大部分人都会用的功能），以用户规模为评价体系。
-
AI 时代逻辑： 代码变得非常便宜。这使得为**“最大公约数之外”的小众需求**开发个性化产品成为可能。
-
结论： 不需要焦虑受众是否太小众，只要精准满足了细分需求，总归能赚到属于你的那份收益。
🧩 碎片技巧与资源
-
支付接口调试（Creem）： 有同学在测试 Creem 支付时发现总是提示“被拒绝”，实际上是因为测试模式必须使用官方文档指定的测试卡号，而非真实银行卡号。
-
资源回看： 一期手册中的“高手领航”往期视频，现在需要去小鹅通查看二期内容（群公告有地址）。
-
网络配置参考： 针对网络规则配置，群友推荐了 Linux.do 上的技术贴（见下方链接），建议遇到网络疑难杂症多去该站搜索。
🔗 提及资源链接
📝 总结：今日要点
-
Antigravity 登不上？ 先开 TUN 模式，不行就换美国 IP/账号。
-
数据库别乱动： 即使是个人小项目，也要养成 Dev/Prod 分离的习惯，生产环境不可直接修改。
-
学习优先： 面对混乱代码，勇于重构或重做，目的是练手而非单纯为了修 Bug。
-
小众也能活： 利用低成本代码优势，服务那些被大厂忽略的“非主流”需求。