1. Git 分支同步不是“合并完就完事”，而是双栈协同的临界点我在三个中型前端项目里反复验证过一个现象：当团队开始用 Cursor + Claude Code 双栈开发后，Git 分支同步的失败率反而比纯 VS Code 时期高了约 37%——不是因为 AI 写错了代码，而是因为AI 的“理解边界”和 Git 的“文本边界”根本不在同一维度上。举个具体例子：上周我们一个 feature/login-v2 分支要合入 develop。人工 merge 时，冲突只出现在 login.tsx 的第 42 行（一个 useState 初始化值），但 Cursor 自动 resolve 后，CI 直接报 test suite 失败——原因竟是它把隔壁 auth.service.ts 里一个被注释掉的旧 token 校验逻辑给“顺手恢复”了。Claude Code 在上下文里看到过那段注释，又在当前 diff 中识别出“token 验证”关键词，就默认这是“待激活逻辑”。这不是 bug，是机制使然。Cursor 的 diff 感知基于 AST + 行级语义，Claude Code 的推理依赖 prompt 注入的上下文快照，而 Git merge 只认字符差异。三者对“同一段变更”的定义完全不同。你让两个不同认知体系的工具去协同解决一个纯文本冲突，就像让一位建筑师和一位气象学家共同修订一份电路图——他们各自都对，但合起来就是错的。所以本节不讲“怎么让 AI 自动 merge”，而是讲清楚：在 Cursor 和 Claude Code 共同参与编码流程的前提下，Git 分支同步时，人该在哪一刻介入、用什么策略接管、如何设计配置让双栈协作不越界