Google Antigravity CLI 1.2.7 在处理 TSX 文件时会把代码写乱

最近在翻 GitHub 上的 Issue，看到有人在折腾 Google Antigravity CLI（版本 1.2.7）的时候踩了个大坑。简单来说，这个工具在尝试修改 JSX/TSX 代码块时，那个所谓的“模糊匹配（Fuzzy Match）”机制简直是灾难，它不是在替换代码，而是在把新旧代码“缝合”在一起。

如果你正在用 Google Antigravity 或者 DeepMind 的 Advanced Agentic Coding 引擎来做自动化开发，遇到这种问题一定要小心，因为它不会报错，而是会静默地把你的代码改得一团糟，最后导致编译直接挂掉。

为什么 replace_file_content 会把代码搞坏

这个问题的核心在于 replace_file_content 这个函数。当 Agent 想要替换一段代码，但发现目标内容（TargetContent）和文件里的实际行号对不上时，它不会直接报错退出，而是会触发一个 fallback 机制，提示你：“We did our best to apply changes despite some inaccuracies”（尽管有一些不准确，我们已尽力应用更改）。

这个机制非常不安全，主要有两个坑点：

• 不安全的模糊替换： 当它无法在指定的 [StartLine, EndLine] 范围内精准匹配到目标内容时，它会尝试进行一种“部分合并”。结果就是，旧的 JSX 标签（比如 <TableHead>）和新的属性还没删干净，新的代码又塞进去了。这种“代码交织”现象会导致大量的语法错误，比如标签没闭合或者属性重复。
• 编辑器缓存冲突： 如果你同时在 Antigravity 编辑器里开着这个文件，Agent 在后台写磁盘，而编辑器的内存 Buffer 又在同步，这种并发冲突会导致旧的、过时的内容被重新写回磁盘，造成 diff 冲突。

复现这个 Bug 的具体步骤

根据开发者 foreturn 的实测，复现这个过程非常典型：

1. 在 Antigravity 编辑器里打开一个稍微复杂点的 TSX 文件（比如超过 50 行的 Table 组件，路径类似 src/app.tsx）。
2. 让 Agent 执行一个修改操作，调用 replace_file_content 来改动这个中大型的 JSX 块。
3. 留意 Agent 的反馈，如果看到 We did our best to apply changes despite some inaccuracies 这句话，说明它已经开始“瞎改”了。
4. 检查文件内容，你会发现新旧代码混在一起了。
5. 在终端运行 bunx tsc --noEmit 检查类型，你会看到满屏的语法错误。

实测报错信息

当代码被弄乱后，TypeScript 编译器会直接报出类似下面的错误。看这个报错就能发现，它在处理模板字符串或者 JSX 逻辑时，由于标签或括号没对齐，导致解析器直接卡在了错误的位置：

Unexpected token, expected "}" (254:6)

 252 | ? "bg-primary/10 font-medium text-primary"
 253 | : "text-muted-foreground hover:bg-secondary hover:text-secondary-foreground"
> 254 | }`;
 | ^
 255 | 
 256 | createEffect(() => {
 257 | location.pathname;
 Plugin: solid-start:server-functions/compiler
 File: D:/workspaces/private/ai/src/app.tsx:254:6

从报错来看，原本应该是闭合逻辑的地方，因为之前的代码交织，导致 } 后面多出了奇怪的符号或者丢失了上下文，直接让 solid-start 的编译器崩溃了。

我对这个问题的看法

我觉得这个设计逻辑确实有问题。对于一个 Agentic Coding 工具来说，Fail Fast（快速失败） 远比“尝试修复”要重要得多。

如果 TargetContent 的匹配置信度不够高，replace_file_content 应该直接抛出错误，让 Agent 意识到这次尝试失败了，然后让它退回到“全量写入文件（Full-file write）”或者使用更精确的 AST（抽象语法树）替换方案。现在的做法就像是医生做手术，发现位置找不对，不报告失败，而是闭着眼睛在那儿缝合，最后把病人缝成了一团乱麻。

如果你现在正在用这个工具，建议在它执行完修改后，养成手动运行 tsc 或者 bunx tsc --noEmit 的习惯，别完全信任 Agent 报告的“执行成功”。