AI 改页面翻车后，才发现 Git 分支根本不够用

最近在做一个项目的新页面改版时，我踩了一个很典型的坑。

原本需求非常简单：现有页面已经能正常使用，主分支也要继续保持稳定。在新版页面没有完全改完之前，我并不想动主分支上的旧页面。因为页面改版不像修一个小 bug，它往往会涉及整体视觉风格、布局结构、图片资源、组件拆分、响应式适配，甚至还可能反复推翻重来。

所以一开始，我的想法也很自然：既然不想影响主分支，那就创建一个新分支，让 AI 在新分支里改版。等新版页面全部完成、测试通过、视觉效果确认后，再统一合并回主分支。

听起来这套流程很正常，也很符合 Git 的基本使用方式。

但真正开始用 AI 做页面改版以后，我才发现，问题并没有想象中那么简单。

一开始只是想用分支隔离页面改版

当时我的操作思路很直接。

主分支继续保留现有页面，改版工作放到一个新的分支里。比如从main拉出一个ui-redesign分支，然后让 AI 在这个分支里重做首页、调整配色、优化卡片、替换背景图、重新设计交互细节。

这种方式在传统开发里是很常见的。一个新需求开一个 feature 分支，一个 bug 修复开一个 fix 分支，一个页面改版开一个 redesign 分支，看起来没有任何问题。

但问题出在：这次不是我手动慢慢改，而是让 AI 参与改版。

AI 改页面和人手动改页面最大的区别是，它的改动速度非常快，而且改动范围有时候会比你预期大得多。你只是让它“重新设计首页”，它可能不仅会改page.tsx，还会改组件、样式文件、布局结构，甚至会替换public目录里的背景图、Logo、卡片图、角色图和装饰图。

一开始我并没有特别在意这个问题。直到后来我发现，public里的图片资源被替换了。

这时候才意识到，单纯创建一个分支，并不能完全解决 AI 改版时的工作区污染问题。

真正的问题不是分支，而是工作区

很多人理解 Git 分支时，会默认认为：只要创建了新分支，就不会影响主分支。

这个理解只对了一半。

分支确实可以隔离提交历史，但如果你仍然在同一个项目目录里工作，那么你的物理工作区其实还是同一个。你只是在同一个文件夹里不断切换不同分支对应的文件状态。

比如你的项目目录是：

~/projects/glownest-next

你在这个目录里从main切到ui-redesign，然后让 AI 去改页面。这个过程中，所有文件仍然在同一个物理目录里被修改，包括src、app、components、styles，也包括最容易被忽略的public。

如果 AI 把新版首页的背景图直接写到了：

public/images/home-bg.png

而旧版首页原本也在使用这个文件，那就很容易出现资源覆盖问题。

理论上，如果这个文件被 Git 跟踪，并且你已经提交，分支切换时 Git 能恢复不同分支对应的文件版本。但真实项目里，经常会有更复杂的情况：有些图片是未跟踪文件，有些资源是 AI 新增的，有些文件被覆盖后还没提交，有些路径被多个页面共用，还有开发服务器和浏览器缓存参与进来。

最后你会发现，明明是在新分支里做页面改版，但旧页面看起来也像被影响了。不是 Git 分支失效了，而是你把所有试验都放在了同一个工作区里。

这就是这次踩坑的核心。

分支隔离的是版本历史，worktree 隔离的是开发现场。

public 目录为什么特别容易被 AI 改乱？

在前端项目里，public目录是一个非常特殊的地方。

很多静态资源都会放在这里，比如 Logo、背景图、图标、字体、插画、角色头像、卡片封面、JSON 配置等。页面引用这些资源时，路径通常非常直接：

<img src="/images/home-bg.png"/>

或者：

background-image:url('/images/hero-bg.png');

这类引用方式很方便，但也带来一个问题：如果 AI 在改版时直接覆盖了同名文件，旧页面和新版页面都可能受到影响。

尤其是 AI 很容易采用“就地优化”的方式。你让它把首页改得更高级，它可能会直接替换原来的hero-bg.png；你让它重新设计卡片，它可能会直接覆盖原来的card-bg.png；你让它换一套品牌视觉，它可能会直接替换 Logo 或背景图。

对 AI 来说，这样做是为了完成改版目标。但对真实项目来说，这种方式非常危险。因为旧页面还没下线，主分支还要保持稳定，新版页面还在试验阶段，资源不应该直接覆盖。

页面代码的变更，你通常能通过 diff 看出来。但图片资源的替换，很多时候要等页面跑起来以后才会发现。尤其当图片文件名没变，只是内容变了，肉眼 review diff 时很容易忽略。

所以 AI 做页面改版时，public目录一定要特别小心。

为什么页面改版比普通功能开发更适合 worktree？

普通业务开发里，一个分支通常已经够用了。比如新增一个接口、修一个 bug、补一个字段，改动范围相对清楚，最终也比较容易 review。

但页面改版不一样。

页面改版通常是一种试验型工作。你可能会换色系，换布局，换图片，换动效，换首页结构，甚至换整套视觉语言。这个过程里，很多改动一开始并不确定。你可能让 AI 做出一个版本，觉得不满意，又让它换一个方向。反复几轮以后，项目里很容易出现大量临时组件、临时图片、废弃样式和中间版本资源。

如果这些试验都发生在主项目目录里，即使你使用的是新分支，也会带来很强的心理负担。你会担心 AI 是否动到了旧页面资源，是否替换了公共图片，是否影响了当前可用的版本，是否留下了一堆临时文件。

而 worktree 的好处就在这里。

它可以让同一个 Git 仓库在本地同时拥有多个独立工作目录。主分支仍然放在原来的目录里，新版页面改版放在另一个目录里。两个目录各自有自己的public、src、app、components、开发服务器和缓存环境。

这样一来，AI 就可以在改版目录里大胆试验，而主分支目录完全不受影响。

这才是真正意义上的“开发现场隔离”。

worktree 的正确使用方式

假设你的主项目目录是：

~/projects/glownest-next

当前主分支是main。在开始改版之前，第一步一定是先确认主分支工作区是干净的：

git status

如果有未提交内容，先提交或者 stash。不要在工作区混乱的情况下继续开改版任务，否则后面很难判断哪些改动属于旧任务，哪些改动属于新版页面。

接着拉取最新主分支：

git checkout main

git pull origin main

然后使用 worktree 创建一个独立的改版目录：

git worktree add ../glownest-next-ui-redesign -b ui-redesign main

这条命令的意思是：基于main创建一个新分支ui-redesign，并把这个分支 checkout 到一个新的本地目录：

../glownest-next-ui-redesign

此时你本地会同时存在两个目录。

一个是主分支目录：

~/projects/glownest-next

另一个是改版分支目录：

~/projects/glownest-next-ui-redesign

接下来进入改版目录：

cd../glownest-next-ui-redesign

安装依赖并启动项目：

pnpm install

pnpm dev ----port 3001

如果主分支项目仍然运行在3000端口，那么你就可以同时打开两个页面：

http://localhost:3000

查看旧版页面。

http://localhost:3001

查看新版页面。

这时候你就不需要来回切分支，也不需要反复重启项目。旧版和新版可以同时打开、同时对比，非常适合页面改版。

给 AI 的指令必须明确资源边界

使用 worktree 以后，风险已经小很多，但这并不意味着可以完全放开让 AI 随便改。

AI 页面改版仍然需要明确边界。尤其是静态资源，必须提前告诉 AI 不要覆盖旧资源。

我现在更推荐在改版 worktree 里给 AI 这样的指令：

当前目录是页面改版专用 worktree，不是主分支目录。

本次任务是重新设计首页视觉效果，保留现有业务逻辑和路由结构。

允许修改：

1. 首页相关页面组件

2. 首页相关样式文件

3. 新增改版专用组件

4. 新增改版专用静态资源

禁止修改：

1. 不要修改接口调用逻辑

2. 不要修改登录、鉴权、支付、订单等业务模块

3. 不要覆盖 public 目录下已有同名图片

4. 不要删除旧页面资源

5. 不要修改主分支目录中的任何文件

资源规则：

所有新增图片、背景图、图标、装饰图，统一放到 public/redesign/ 目录下，并使用新的文件名。

不要覆盖 public/images/、public/assets/、public/logo.png 等旧资源。

完成后请输出：

1. 修改了哪些文件

2. 新增了哪些静态资源

3. 是否覆盖了已有资源

4. 是否保留旧页面可回退

5. 如何合并回主分支

这段提示词的核心不是让 AI 做得更快，而是让 AI 改得更可控。

AI 很擅长执行，但它不知道你的工程风险偏好。你必须告诉它哪些地方可以试验，哪些地方不能碰，哪些资源必须隔离，哪些逻辑必须保留。

这就像给 AI 划出一个施工区域。

worktree 是物理隔离，提示词是行为边界。

两者都需要。

新资源一定要有独立命名空间

这次踩坑以后，我对页面改版里的静态资源有一个非常明确的建议：所有新资源都应该放到独立目录里。

比如：

public/redesign/

更进一步，可以按页面拆分：

public/redesign/home/

public/redesign/cards/

public/redesign/icons/

public/redesign/backgrounds/

这样做有几个明显好处。

第一，新旧资源不会混在一起。你一眼就能看出哪些资源是为新版页面准备的。

第二，不会覆盖旧页面资源。旧页面原来引用的public/images/home-bg.png不会被新版资源替换。

第三，review 更清楚。PR 里新增了哪些改版资源，一眼就能看出来。

第四，如果改版方向被推翻，可以直接删除整个public/redesign目录，清理成本非常低。

第五，合并回主分支时，可以更从容地决定哪些资源保留，哪些资源丢弃。

很多项目后期资源混乱，就是因为一开始没有命名空间。新版、旧版、临时图、生成图、测试图全部放在同一个目录里，最后没人知道哪个文件还在用，哪个文件可以删。

AI 改版时更要避免这个问题。

因为 AI 生成资源太快了，如果没有规则，很容易把public变成垃圾场。

新页面也不要一开始就覆盖旧页面

除了静态资源，页面入口也建议先隔离。

比如原来的首页是：

app/page.tsx

如果新版还没有完全确认，就不要一开始直接覆盖它。更稳的方式是先新建一个临时页面：

app/redesign/page.tsx

这样新版可以通过/redesign单独访问。旧首页继续保留，新首页独立预览，两个版本可以同时存在。

如果项目不是 Next.js，而是 React Router 或 Vue Router，也可以先加一个临时路由：

/redesign-home

这个做法非常适合页面改版。

因为页面设计往往不是一次到位。第一版可能色系不对，第二版可能布局不对，第三版可能移动端不行。你需要不断试验和对比。如果一开始就覆盖旧页面，每一次试错都会影响现有可用版本。

先让新版页面独立存在，等视觉、功能、适配都确认后，再替换正式入口。

这才是更稳的前端改版方式。

worktree 让新旧页面对比变得非常自然

页面改版最重要的工作之一，就是对比。

你不能只看新版是不是“更好看”。你还要确认新版有没有丢失旧版功能，有没有遗漏入口，有没有破坏移动端，有没有改变用户熟悉的路径，有没有影响首屏加载，有没有把原来的核心信息弱化掉。

如果只靠一个目录来回切分支，对比体验非常差。你要切分支、重启项目、刷新页面，然后凭记忆比较两个版本。这对视觉判断很不友好。

worktree 则完全不一样。

你可以让主分支运行在3000端口，让改版分支运行在3001端口。两个页面并排打开，左边旧版，右边新版。你可以直接对比首屏、卡片、按钮、图片、字体、移动端布局。

这种对比方式非常适合和 AI 协作。

你可以看完新版后，继续给 AI 反馈：

“新版首屏情绪更强，但旧版的功能入口更清晰，需要把旧版的核心入口保留下来。”

“新版图片风格更统一，但卡片信息密度太低，需要提高一点内容承载能力。”

“新版按钮更好看，但 CTA 不够突出，主按钮和次按钮层级还需要再拉开。”

这种反馈，比单纯说“再优化一下”有效得多。

因为你是在真实对比中给出具体反馈。

改版完成后，不要手动复制文件合并

很多人页面改版完成后，会下意识地手动复制文件回主项目目录。

这不是一个好习惯。

更推荐走标准 Git 流程。

在改版 worktree 里先检查改动：

git status

gitdiff

确认没有误删旧资源、没有覆盖不该覆盖的图片、没有修改业务逻辑以后，提交改版分支：

git add .

git commit -m "feat: redesign home page"

然后推送到远程：

git push origin ui-redesign

接下来通过 PR 或 MR 合并到主分支。

合并前重点 review 几类内容：第一，public目录有没有覆盖旧资源；第二，是否误改接口调用、登录鉴权、订单支付等业务逻辑；第三，是否新增了无用图片或临时文件；第四，移动端适配是否完整；第五，构建和类型检查是否通过。

页面改版不是只看视觉效果。

最终能不能合并，还是要看工程质量。

所以合并前至少应该跑：

pnpm build

如果项目有类型检查，也要跑：

pnpm typecheck

如果项目有 lint，也要跑：

pnpm lint

确认通过后，再考虑合并。

改版结束后如何清理 worktree

当新版页面已经合并，或者这个改版方案决定废弃，就可以清理 worktree。

先回到主项目目录：

cd~/projects/glownest-next

查看当前 worktree：

git worktree list

如果确认改版目录不再需要，可以删除：

git worktree remove ../glownest-next-ui-redesign

如果本地分支也不需要了，可以删除：

git branch -d ui-redesign

如果远程分支也要删除：

git push origin --delete ui-redesign

worktree 的好处是，整个改版实验环境可以干净移除。不会在主项目目录里留下大量临时资源，也不会让你事后分不清哪些文件属于改版试验，哪些文件属于主分支。

这对 AI 改版尤其重要。

因为 AI 很容易生成中间文件和临时资源。如果没有隔离目录，后期清理会非常痛苦。

这次踩坑真正的教训

这次页面改版最大的教训，不是“不要用分支”。

分支当然要用。

真正的教训是：当 AI 参与页面改版时，仅仅使用分支还不够。因为 AI 的改动不只是代码提交，它会影响整个开发现场，包括静态资源、页面入口、未跟踪文件、开发服务器、缓存和临时资源。

分支解决的是版本管理问题。

worktree 解决的是工作区隔离问题。

页面改版这种任务，天然需要大量试验、反复对比和资源替换，因此更适合 worktree。主分支目录继续保持稳定，改版分支目录用来大胆试错。AI 的所有试验都发生在改版目录里，旧页面不会被打扰，public 资源不会互相覆盖，新旧版本也可以同时运行对比。

这才是更适合 AI 改版页面的工作方式。

最后

AI 让页面改版变快了，但也让改版风险变大了。

以前人手动改页面，可能一天只改几个文件；现在 AI 一次就可能改几十个文件，还会顺手替换图片、重写组件、调整样式、改文案、加动效。效率是提高了，但如果没有工程隔离，项目很容易被改乱。

所以，AI 改页面时，不要只关注提示词怎么写，也不要只关注页面最终好不好看。更重要的是，先给 AI 一个安全的改版环境。

主分支保持稳定。

改版分支使用 worktree。

新资源放到独立目录。

新页面先用临时路由预览。

新旧版本同时启动对比。

改版完成后通过 PR review 合并。

这套流程看起来比直接切分支麻烦一点，但它能避免很多后期问题。尤其当 AI 开始参与真实项目改版时，worktree 几乎会变成一个非常重要的安全边界。

如果你也准备让 AI 重新设计项目页面，不建议一上来就在主目录里切个分支就开干。

更稳的方式是：

先开 worktree，再让 AI 改版。

这样旧页面继续稳定，新页面大胆试验，最后再把真正满意的结果合并回主分支。

这才是 AI 时代更适合前端页面改版的工程流程。

今天就讲到这里，如果有问题需要咨询，大家可以直接留言或扫下方二维码来知识星球找我，我们会尽力为你解答。

快速搭建属于您的专属官网，就上TechWisdom（www.techwisdom.cn）！

提供100+ 精美模板，支持二级域名和独立域名配置，可根据需求进行个性化定制开发。首次上线还有专业团队协助上传内容，轻松打造高效、专业、吸睛的官网！立即访问网站，选择您心仪的模板，开启建站新体验吧！

作者：路条编程（转载请获本公众号授权，并注明作者与出处）