Antigravity 对话 .pb 解码（draft）

术-操作 · 术层 skill 全文

本页是 <code>rules/skills/drafts/bestpractice_antigravity_pb_decoding.md</code> 的逐字投影（仅隐私清洗，零改写）。

Skill: Antigravity 对话 .pb 解码（draft）

元数据

• 类型: BestPractice / API Guide
• 状态: Draft — 单次成功案例（2026-04-20），尚未多次验证
• 适用场景: 需要从 Antigravity（Google Gemini 的 VSCode 插件 fork）的对话存储里提取某次对话的原文
• 触发词: "Antigravity 那次对话"、"Planner 里讨论过"、".pb 解码"、".gemini/antigravity"
• 创建日期: 2026-04-20
• 关联 skill: bestpractice_chat_history_retrieval（主 skill，决定"要不要动用本 skill"）

目标与边界

做：把 ~/.gemini/antigravity/conversations/<uuid>.pb 文件里的对话内容取出来，产出可读的 JSON / Markdown，并在多个 .pb 场景下生成索引便于筛选。

不做：

• 搜索策略和定位目标对话：归 bestpractice_chat_history_retrieval
• 对话内容的语义分析 / 摘要：这是下游任务
• Cursor / 其他 IDE 的对话解码：本 skill 只针对 Antigravity；其他 IDE 的解码后续独立成 skill

验收标准

1. 能给出 .pb 里对话的文本内容（至少够判断话题、时间、关键 step）。
2. 多 .pb 场景下有索引：_INDEX_all_convs.md 列出每个对话的 cascadeId、创建时间、title（若有）、关键词命中次数。
3. 知道什么时候返回"不需要精确解码"：当 strings 粗筛已足够判断相关性时，不浪费 token 走完整解码。

数据位置

~/.gemini/antigravity/conversations/<uuid>.pb        # 每个对话一个 .pb 文件
~/.gemini/antigravity/knowledge/                     # 知识库（与对话分离）
~/.gemini/antigravity/brain/                         # Agent 思考 / 规划状态
~/.gemini/antigravity/context_state/                 # 工作区上下文状态
~/.gemini/antigravity/code_tracker/                  # 代码变更跟踪

其中 conversations/*.pb 是主要目标。其他目录在本 skill 范围之外。

.pb 是 Google Protocol Buffer 二进制格式，没有现成的 Antigravity 官方 schema 可用（截至 2026-04-20）。

决策树：要不要解码

已知 uuid（目标对话）？
├── 是 → 单件解码路径
│        └── strings 粗看 → 如有需要再 protobuf 精解
└── 否，要在多个 .pb 里找
         └── 多件批处理路径：先 strings 筛，再批量精解 + 生成索引

单件路径：已知目标 uuid

第一步：strings 粗看

多数场景下这一步就够了。 strings 能把 .pb 里的可打印文本直接抽出来，足以判断话题相关性、大致时间、关键内容。

strings ~/.gemini/antigravity/conversations/<uuid>.pb | head -200
# 或配合 grep 找关键词
strings ~/.gemini/antigravity/conversations/<uuid>.pb | grep -iE "关键词1|关键词2" | head -30

第二步（可选）：精确解码

只在必须要完整对话原文、或 strings 输出因 protobuf 编码噪声而难以阅读时才做。

路径：Python + google.protobuf。由于没有官方 schema，解码需要：

• 尝试用 protoc --decode_raw 先做无 schema 的原始解码（给出字段编号和类型）
• 或者参考开源社区是否已有 Antigravity .proto 定义

# 无 schema 原始解码（输出是字段编号 + 类型 + 内容）
protoc --decode_raw < ~/.gemini/antigravity/conversations/<uuid>.pb | head -200

原始解码能看到字段结构，再人工识别哪个字段是 content、timestamp、step index 等。识别成功后可以写简单 Python 遍历。

多件批处理路径

第一步：枚举和粗筛

ls ~/.gemini/antigravity/conversations/*.pb | wc -l
# 知道总量，决定分批粒度

# 粗筛：对每个 .pb 跑 strings + grep，记录命中次数
for f in ~/.gemini/antigravity/conversations/*.pb; do
  uuid=$(basename "$f" .pb)
  count=$(strings "$f" | grep -ciE "关键词1|关键词2")
  [ "$count" -gt 0 ] && echo "$uuid: $count"
done | sort -t: -k2 -n -r

结果按命中次数倒排。Top 候选才值得进一步解码。

第二步：派 sub-agent 批量解码 Top N

对 Top 候选（通常 ≤ 10 个）派 sub-agent 并行解码，每个 sub-agent 负责 1-2 个 .pb：

• 输入：uuid 列表、关键词、输出目录 /tmp/antigravity_decoded/
• 输出：每个对话一份 <uuid>.json（原始解码） + _summary_<uuid>.md（摘要：时间、step 数、关键内容摘录）

第三步：生成索引

关键产出：/tmp/antigravity_decoded/_INDEX_all_convs.md

# Antigravity 对话索引（解码于 <YYYY-MM-DD>）

| cascadeId | 时间 | title | step 数 | 关键词命中 | 标注 |
|-----------|------|-------|--------|-----------|------|
| 18f72295  | 2026-03-24 → 03-25 | Refining Agent Orchestration Documentation | 94 | "设计方案"×12, "Brain Layer"×8 | NEW_DESIGN |
| 7c1630b1  | 2026-03-27 | Unifying Process Documentation Architecture | 120 | ... | NEW_DESIGN |
| 43700c3b  | 2026-03-26 | Resolving L5 Documentation Conflicts | 40 | ... | EXISTING_MATCH |

第四步：差异化标记

与已知产物（落盘文件、之前产出的文档）比对，给每个 session 标：

• NEW_DESIGN：内容没在已知文件里出现过，是全新产物
• EXISTING_MATCH：内容已经落盘（例如已有 theme-10-modification-plan.md）
• PARTIAL_OVERLAP：部分匹配，需要进一步查验

这一步节省大量时间——解码完可能有 10+ 对话，差异化标记让主搜索 skill 能快速判断"哪几个可能是目标"。

落盘产物命名

当确认某个 .pb 里的对话需要完整落盘到仓库里时：

<project>/.external-inputs/session_<uuid_prefix>_<topic>_<YYYYMMDD>.md

例如：~/code/nightcode/docs/architecture/.external-inputs/session_18f72295_detail_design_20260325.md

文件头部加 frontmatter 说明来源：

# <topic> — Antigravity Planner 会话原文汇编

> **来源**：Antigravity Planner session `<full-uuid>`
> **时间跨度**：<start> → <end>
> **最终落盘对象**：<哪个目标文件，若有>
> **提取说明**：逐字摘录 user + planner，只做时间顺序整理

已知陷阱

陷阱 1：跳过 strings 直接精解，浪费时间

strings 5 秒能说明很多问题。2026-04-20 案例里，仅靠 strings 就看出 18f72295 是"核心需求 + 设计方案"结构。只在这一步不够用时才升级到 protoc 解码。

陷阱 2：没 schema 的 protobuf 被当成"解不了"

protoc --decode_raw 在没有 .proto 文件的情况下也能给出字段编号和类型。人工识别几个关键字段（content / timestamp / step）后就能写出简单的 Python 脚本。

陷阱 3：逐个解码不生成索引

10+ 对话逐个 json 打开判断话题，既慢又容易漏。一定先生成 _INDEX_all_convs.md，再去读具体 JSON。索引是 O(N) 的阅读成本，逐个读是 O(N × 每个 JSON 大小)。

陷阱 4：把 Antigravity 设计成"解码工具"的一般化 skill

本 skill 只覆盖 Antigravity。Cursor、Windsurf 等其他 IDE 的对话格式不同，后续按需各自成 skill。

工具链

• strings（coreutils，macOS 自带）— 粗看
• protoc（protobuf-compiler，brew 装 protobuf）— --decode_raw 无 schema 解码
• python3 + google.protobuf — 精确解码（需要识别字段后编写脚本）
• jq — 操作解码后的 JSON

重要：如果仓库里已经有针对 Antigravity .pb 的解码工具或脚本，优先用那个，不要重新发明。本 skill 维护者发现此类工具时应更新本节。

演进计划

本 skill 是 draft，暂未多次验证。等后续踩过更多坑之后再决定：

• 精解场景的覆盖率是否足够（目前只有 2026-04-20 一个成功案例）
• _INDEX_all_convs.md 的 schema 是否够用
• 是否需要内置一个可复用的 Python 解码脚本（而非每次即兴写）

升级到 formal skill 的触发条件：至少 3 次成功跨场景调用，或用户确认本 skill 可靠。