关于 AI 工具选型 & 个人实践方式

为准备下单心仪工具的同学，提供取舍攻略参考

主流工具对比

三种方式对比：官方订阅（Claude Code + Codex） / API 中转服务 / Antigravity等 IDE 集成

个人主观判断，非客观标准

• 价格友好方面，Antigravity ＞ 中转服务 ＞ 官方订阅

  • 假设可报销的费用一定，那能否榨干剩余价值是一门学问

• 灵活性上，中转服务 > 官方订阅 > Antigravity

  • 中转服务可配置 Claude 和 Codex

• 编程能力上，官方订阅 > 中转服务 > Antigravity

  • 官方订阅自带的生态最优

  • 中转服务因为号池缓存命中率的问题，会低于官方订阅

• 账号稳定性上，Antigravity > 中转服务 > 官方订阅

  • 官方订阅需要处理：购买渠道、访问线路

  • 中转服务存在跑路情况

• 使用稳定性上， 中转服务 > Antigravity > 官方订阅

  • Retrygravity，老生常谈

  • 官方订阅存在访问网路问题

• 上手易用性上，Antigravity > 中转服务 > 官方订阅

  • 中转服务通常具备一键配置的 shell 脚本

  • Antigravity 开箱即用

踩过的坑 & 一些经验

价格成本上

• Antigravity Ultra 通过家庭组六人均摊，成本预计 300¥，再通过前期打半价的手段，成本能降低到 150¥ 

  • 禁止反代

  • 每个谷歌账号需保持 location => 美国

  • 需要确保家庭组去续费的渠道，为国外渠道

• 中转服务

  • 个人日常使用，每日额度预计需要 70$，换算到具体的中转服务套餐费用上，即 500¥/月 左右

• 官方订阅

  • 没有可操作空间

在解决官方订阅的购买渠道和访问线路问题上

• 购买渠道：Apple渠道卡、国内 visa 卡折转 Google Play ，这两种方案会被封

  • 香港卡不行

  • 国外信用卡，目前是相对稳定的解

• 访问线路：为解决纯净 IP 的问题，通过机场 + vps 落地（价格友好 + 处理简单）

  • 但是会影响自身的访问网速，体感明显

命题：魔高一尺，道高一丈

• 举个例子：官方可通过筛选在东八区时区使用频繁的账号，可进一步锁定国区选手

在 Claude 严厉打击国内使用的背景下，个人觉得无论怎么绕后门，对方都有反制措施（Claude 本身不在乎退款），只能寄希望于官方本身松口 —— 类似 GPT睁一眼闭一眼

中转服务的小tips

• 优先考虑稳定性 + 建站时间长（择取原则，类似机场）

• 好的中转服务，是支持开发票的

• 最好采购两到三个备用

• 速率原因，建议主力使用 Codex（0.25 ：1）/ 对比 Claude 普遍（1:1.3）

  • 因为 GPT Team 封号情况相对 Claude 缓解很多

个人抉择

个人的使用诉求如下：

• 希望既能用 Codex，也能用 Claude

  • Codex 和 Claude 能互相审阅对方，不会出现独断专裁
    • 使用场景：Codex 跑方案，Claude 核查；反之亦然

• 上手易用性和稳定性

最后选择了 ++API 中转服务 + Antigravity 丐版++

• 丐版指的是，不用 Antigravity 来进行 VibeCoding，只用来当 IDE 查阅代码

  • 为什么不用 VS Code？因为未来还有购买 Antigravity Ultra 账号的可能（属于 Plan B）

• 中转服务购买两个

  • 鸡蛋不放一个篮子里

API中转服务相关

• API 中转服务介绍：AI API 中转服务深度解析

• 各中转服务网站概览 & 评测：https://www.helpaio.com/transit、https://www.getcheapai.com/zh-cn

• 个人使用的中转服务：

  • sss-ai（支持包月、支持开票-低消 100）

  • packy-code（按量付费、支持开票-低消 500）

• sss-ai 使用举例

  • 如图，通过 shell 脚本，将 token 写入环境变量，可实现一键安装

• 服务来回切换的配置异常问题

• 场景：使用 a 服务，然后要切换 b 服务，后面又切回 a 服务

• 原因：因为中转服务的配置，通常是 shell 脚本一键覆盖，可能会将自身已经存在的服务覆盖掉，在 a、b 来回切的过程中，环境变量可能存在冲突

• 解决方式：修改 agent 的全局配置，如 .codex/auth.json中，查看实际生效的 provider，进行修改

个人日常使用姿势

Antigravity IDE + Claude Code 插件 + Codex 桌面端：

1. 使用 Codex 处理编程任务，多个代码仓库并行跑任务

   1. 任务两遍没过，就用 Claude 审阅

2. 复杂问题使用 Claude Code 插件

   1. 插件是在 IDE 插件市场可下载

3. 出现多次 work error 的场景，使用 Claude 跟 Codex 互相审阅

   1. 《双方来打辩论赛》

4. 把 Antigravity 自带的 Gemini 当谷歌用

关于 Codex、Claude 二者的配置同步

使用 AI 来帮我完成，例如 prompt: 把当前 Claude code 的全局 rules 、mcp 和 subagent 配置同步到 Codex 中

关于 Claud Code 的使用（推荐）

参阅这篇文章：《你不知道的 Claude Code：架构、治理与工程实践》-- 推特（由浅入深，干货满满）

• 建议学下其中的优化手段，这样对 VibeCoding 有帮助

• 关注其中 SKILL 的使用：npx skills add tw93/claude-health，用以优化自身的 Claude

个人的 Claude 全局 rules

其中特色点：

• 预处理：是否 plan、是否 subagent

  • subagent 会相对更耗 token，需酌情

• 任务留存：关注其中的 lessons 和 task 生成逻辑

  • 类似简化版本的 SDD 方案

• 安全：key、secret 隔离

1
2
3
4
5

# ⚠️ 强制执行规则（CRITICAL — 每次任务必须遵守）

## 任务开始前的强制检查（不可跳过）

收到任何任务后，**第一步必须**在心中过以下检查清单，并在回复开头说明判断结果：

[ ] 是否需要进入规划模式？（见下方判断标准）
[ ] 是否需要用子智能体并行处理？
[ ] 完成后如何验证结果？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

### 「简单任务」白名单（以下情况才可跳过规划）
- 只修改 3 个以内文件的单行或少量改动
- 纯解释类、问答类请求（不写代码）
- 明确且无歧义的单步操作

**除上述情况外，所有任务都视为非简单任务，MUST 进入规划模式。**

---

# 工作流编排

### 1. 规划节点（MUST 执行）
- **MUST**：凡不符合「简单任务白名单」的任务，必须先进入规划模式
- **MUST**：一旦出现问题，立即停止并重新规划，禁止强行推进
- **MUST**：规划模式同样用于验证环节
- **MUST**：提前编写详细规格，减少歧义

### 2. 子智能体策略（MUST 执行）
- **MUST**：调研、探索、并行分析类工作，交给子智能体处理
- **MUST**：复杂问题通过多个子智能体增加算力投入
- **MUST**：每个子智能体只专注一个方向，聚焦执行
- 保持主上下文窗口简洁

### 3. 自我优化循环（MUST 执行）
- **MUST**：收到用户任何修正后，立即将规律写入 `tasks/lessons.md`
- **MUST**：每次项目开始前，回顾 `tasks/lessons.md` 中的相关经验
- 持续迭代规则，直到错误率下降

### 4. 完成前验证（MUST 执行）
- **MUST**：未验证可用前，禁止标记任务完成
- **MUST**：自问「资深工程师会认可这段代码吗？」
- **MUST**：运行测试、查看日志、证明逻辑正确

### 5. 追求优雅（平衡版）
- 非简单修改：停下来思考「有没有更优雅的写法？」
- 如果修复方案感觉很别扭：实现优雅方案
- 简单明确的修复可跳过，不要过度设计
- 展示成果前，先严格自检

### 6. 自主修复 Bug（MUST 执行）
- **MUST**：收到 Bug 报告直接修复，无需用户一步步引导
- **MUST**：定位日志、错误、失败用例，然后解决
- **MUST**：主动修复 CI 失败测试，无需详细指令

---

# 任务管理（MUST 执行顺序）

1. **先规划**：将计划写入 `tasks/todo.md`，列出可勾选项
2. **验证计划**：开始实现前先确认方案
3. **跟踪进度**：完成一项立即标记一项（不批量标记）
4. **说明变更**：每步给出概要总结
5. **记录结果**：在 `tasks/todo.md` 中添加评审章节
6. **沉淀经验**：修正后立即更新 `tasks/lessons.md`

---

# 核心原则

- **简洁优先**：每次修改尽可能简单，影响代码最小化
- **拒绝敷衍**：定位根因，不做临时修复，按资深工程师标准要求
- **最小影响**：只修改必要部分，避免引入新 Bug

---

# 注意事项

- 确保使用中文进行回复、回答
- 输出代码时，在代码的关键位置请添加注释，说明代码的用途
- 创建项目的时候，需要同步创建 .gitignore 文件（如果已经存在则忽略）
- 如果需要生成文档，默认 md 格式，默认保存到 doc 目录（README.md 除外），如果目录不存在则新建目录
- 在做技术方案的调研或者复杂链路的分析时，默认生成一个流程图或者时序图或者架构图，来加以说明
- 出现生成图片的场景，默认使用 svg 格式生成图片

---

# 安全规范（MUST 执行）

### 凭证检查（每次任务开始前）
- **MUST**：发现任何含 `secret` / `token` / `key` / `password` 字样的本地配置文件（如 `.env`、工具本地配置），立即检查是否已加入 `.gitignore`；未加入时先警告，再继续任务
- **MUST**：禁止将凭证字面量写入工具命令白名单中；密钥统一通过环境变量引用（`$SECRET_KEY`）
- **MUST**：`git add` 前检查暂存区是否包含敏感文件；若包含，立即停止并告知用户

### tasks 文件保护
- `tasks/` 目录的内容跨会话累积，切换分支前提醒用户确认 `tasks/lessons.md` 已保存