成品在这里 👉 git-brains
重点先说：100% 纯 vibe，没手写过一行逻辑代码。
0. 需求出发点
起因很简单——diffs.com 太好看了。
我日常用 VS Code 开发，但说实话 VS Code 自带的 diff 体验一言难尽，每次遇到 merge conflict 都得老老实实打开 WebStorm。一个 merge 操作要切编辑器，这事儿属实不优雅。
所以目标很明确：在 VS Code 里实现一个好看、好用的 Git Graph + 三方 Merge 编辑器。
1. 基础调研 + 截图分析产品
忠于核心诉求。一开始想做个独立产品，考虑过 Tauri 和 GPUI，但做着做着发现工作量太大了——光是 UI 框架选型、窗口管理、文件系统交互这些基础设施就够喝一壶的。最后在 merge 的过程中拍板：专注 VS Code 插件，只做 Git Graph 和三方 Merge 两件事。
既然觉得 diffs.com 好看，那必然要拆解学习。让 AI 分析后了解到，它的核心渲染方案是 Shiki 语法高亮 + 逐行分割 + Decorator 装饰器——这也解释了为什么它不支持编辑，本质上渲染出来的是"只读视图"而非编辑器实例。
其他技术选型也完全交给 AI 推荐，包括插件脚手架、node-diff3 这些关键依赖，后面连 Biome 的 lint 配置都是 AI 一手包办的。
调研阶段的技巧：多 Agent 并发
这里强烈推荐用多 agent 并发的方式做调研，一个问题拆成多个子任务同时跑，效率翻倍：
我准备实现一个 VS Code 插件，需求是 xxx
开启多 agent 帮我调研下：
1. @pierre/diffs 是怎么实现的
2. 可以用 diffs 的方案来实现三方编辑器吗
3. 我这样的插件怎么实现比较好
三个问题并发出去，几分钟就能拿到一份相当完整的技术调研报告。
产品规划：截图驱动
产品交互的定稿流程也很有意思：先让 Claude Code 分析竞品截图，再用 ASCII 图定稿交互方案。
技巧是：一次性把竞品截图准备好，按顺序命名（01-首页.png、02-详情页.png...），丢到一个目录里让 AI 批量分析。这样它能看到完整的产品流程，给出的分析比单张截图喂要连贯得多。
Claude Code 画的 ASCII 交互图意外地好用——不需要打开 Figma，直接在终端里就能讨论布局和交互流程，改起来也快，比拖拽画原型高效得多。
2. 御三家各有千秋，选对工具事半功倍
AI Coding 工具这一年卷得厉害，我主要用了三家，各有各的脾气：
Claude Code
最好用的 CLI 产品，没有之一。领先的特性太多了——Skills、Ask Question、Subagent，体验上确实是标杆。
但是——封号实在太恶心了。目前是通过团队版+纯净IP来用的，暂时
Codex
5.3 之前真是人嫌狗弃，10 分钟不吐 1 个字，等到花儿都谢了。
但 5.3 之后脱胎换骨，该有的功能都有了，量大管饱，性价比一骑绝尘。可以给到夯。
Antigravity (Gemini)
听说 Gemini 3.1 很不错，不过我暂时没体验到那个版本的威力。目前的体验是——三家里最难看懂输出的，回复要么是英文，要么是生硬严肃的中文，字都认识，连起来看不懂。
不过它的 Agent Manager 模式倒是有点东西，我怀疑 Codex App 就是照着这个思路抄的。
实战搭配技巧
单用一个工具容易撞墙，混合使用才是正道：
- 疑难杂症找 Codex：复杂 bug、诡异的边界 case，5.3 的推理能力啃得动
- 并发任务找 Claude Code：多 agent 同时跑调研、跑测试，速度拉满
- ASCII 交互图找 Claude Code：终端里讨论产品交互，改起来飞快
- Plan 找 Codex，Review 找 Claude Code：让 Codex 写 plan，Claude Code review 一遍（主要也是为了翻译 plan，中译中），再执行后续实现
- 一次提交塞多个需求：别一个一个问，把相关的需求打包一起丢。比如前面的调研阶段，三个问题一次性提交，AI 能看到完整上下文，回答的关联性和一致性都好很多
3. 需求表述的艺术
在 LLM 能力足够的前提下，怎么描述需求变成了最关键的变量。
同一个功能，换一种表述方式，实现质量可能天差地别。我举个具体的例子：
案例：Git Graph 的分支压缩
Git Graph 里有个常见需求——当一个分支有很多中间 commit 时，需要用虚线省略中间节点，只展示关键节点。
如果用产品语言来描述：
- 当分支的连续 commit 数量超过阈值时，中间的节点要折叠
- 折叠后用虚线连接首尾节点
- 虚线上要有一个展开按钮，点击后展示所有节点
AI 实现出来的效果会非常糟糕——它会尝试在渲染层做各种条件判断、DOM 操作、状态管理，逻辑纠缠在一起，改一个地方崩三个地方。
但当我把这个需求类比为压缩树之后，一次就实现了，没有任何返工。前面折腾了好几轮的东西，换个说法一句话搞定。
为什么差距这么大？因为"压缩树"是 AI 训练数据里大量存在的成熟概念——数据结构课、算法题、开源项目里到处都是。AI 知道怎么在数据结构层面做压缩和还原，渲染层只需要根据节点类型做简单的分支判断就行了。你给它一个它"见过"的模型，它就能复用已有的知识；你给它一堆零散的产品描述，它只能从零拼凑。
最后
最大的感受是：大人，时代变了。
