企业官网建设流程全解析

我电脑上常年挂着四五个项目，有的是自己的小工具，有的是帮朋友维护的业务系统，有的还是临时接的定制需求。我本身不是那种能把手头工作完全分给团队的人——人手不够，能指望的只有 AI 编程助手。但我用了一段时间发现一个尴尬的现实：AI 写单段代码确实很强，可一旦我在多个项目间来回切，它就变得“健忘”了。上午刚刚给它交代清楚的架构约定，下午切回这个仓库，它又会把命名规范写得完全不统一，甚至把另一个项目的目录结构当成了当前项目来参考。问题并不出在 AI 本身，而是我从来没有为“多项目并行”这件事设计过工作流。

这篇内容就是我自己摸索出来的解决方案，核心解决一个痛点：一个人维护多个项目时，怎么让 AI 编程任务的上下文切换成本降到最低。我会从项目目录的组织方式、Git worktree 的实战用法、提示词的“交接信息包”设计，再到我踩过的坑，一次讲透。如果你也是一个人扛着多个仓库、每天都在跟 AI 反复交代同样的事，这篇文章应该能直接帮你省掉大量来回拉扯的时间。

1. 先搞清楚“切换”到底贵在哪里

很多人以为多项目切换浪费时间是因为 IDE 启动慢、编辑器标签页太多、或者浏览器里开着一堆后台。真不是。对我来说，最大的成本是“AI 编程上下文的丢失”。

1.1 真正的成本不是切窗口，而是上下文重置

当你在一个项目里连续工作，AI 编程助手会通过对话历史、当前打开的文件、甚至你最近的修改记录来理解你的意图。这个上下文是有“温度”的：你知道项目里那个工具函数叫什么名字、知道测试要跑哪条命令、知道代码风格偏保守还是激进——AI 在你持续对话时也能“感觉到”这些。

可一旦你切到另一个项目，开了新对话，AI 就回到了“失忆”状态。它不认识你的目录结构，不记得你约定的错误处理方式，甚至连你用的是 pnpm 还是 npm 都要重新问一遍。实际情况比这更糟：有些 AI 工具会保留多个会话，但不同会话之间互不共享记忆，上次在项目 A 里说好的技术方案，切到项目 B 后如果误开了同一个会话，它就会把 A 的上下文当成 B 的，输出的代码直接跑偏。

这种重置成本的本质是：你在损耗同一个人的“注意力带宽”。人的大脑在切换任务时需要预热期，而 AI 编程助手同样需要。你每次切过去，都要花几分钟重新把项目背景喂给它，如果喂得不及时、不完整，它就只能靠猜。而 AI 最大的问题就是“猜的时候特别自信”——它不会告诉你“我不确定这个项目的结构”，它会直接按照“最可能的样板”给你写代码，然后写出一堆需要你给回收拾的烂摊子。

1.2 多项目并行的三种工作流，你要先选一种

在谈方案之前，先认清自己属于哪种工作方式，因为不同方式的解法完全不同。

第一种是“物理隔离式”。不同项目放在不同的文件夹，甚至不同的电脑上，工作时只打开一个项目。这种方式的优点是上下文绝对纯净，缺点是切换成本极高，如果你需要频繁跨项目比对代码、复制公共逻辑，那简直是一场灾难。

第二种是“单目录堆叠式”。把所有项目都放在一个大目录里，用编辑器同时打开多个文件夹。这种方式看起来很省事，但当项目数量超过三个，你会发现 AI 编程助手经常混淆路径——它可能在“项目 A 的 src”里生成了“项目 B 的组件”，因为对你来说它们都叫 src，对 AI 来说它们也都是 src，唯一的区别是完整路径不同。而这种区分需要额外喂给它，不然它拼错一个字母就把代码写到了别处。

第三种是我现在在用并强烈推荐的“Worktree + 状态文件”模式。它允许你在同一个仓库下检出多个工作目录，每个目录对应一个功能分支或者任务，同时又能保证不同目录之间是物理隔离的。再加上我后面会讲的“AI 可读状态文件”，你就有了一个既隔离又统一的多项目工作区。

2. 用 Git Worktree 把“项目目录”这件事彻底解耦

如果你还没用过 git worktree，那我直接告诉你：这是我在多项目并行的实践中最重要的一环。它解决的问题很简单：同一个 Git 仓库，你可以在不同分支上同时干活，而且这些工作副本互不干扰。

2.1 为什么传统切分支的方式在 AI 编程时代特别吃亏

常规的 Git 工作流是：切到分支 A，写代码；切回主分支，再切到分支 B，写代码。这里有个致命问题，每一次git checkout切换分支都要把这个分支上的文件改动、路径状态、IDE 索引等内容全部翻新一遍。而当你开着 AI 编程助手时，它读取的“当前项目上下文”也会跟着一起变。

我举个例子：你在分支 A 上告诉 AI“这个项目用 FastAPI，路由都放在 app/api 目录下”，AI 记住了。然后你用git checkout切到分支 B，这个分支上可能还没有 app/api 目录，AI 再读这个项目时，它就“看到”了另一个世界。如果你忘了重新强调项目结构，AI 就会按着刚才“记忆里”的 FastAPI 结构来写代码，写出来自然是一堆无法运行的错误。

此外，传统切分支还有一个隐藏成本：如果你不小心在分支 A 上开了 AI 对话框，切到分支 B 后又继续用同一个对话窗口，AI 的上下文就错乱了。它不知道也不关心你切换了分支，它只知道“这个项目应该按之前说的那样做”——于是写出来的代码既不像 A 也不像 B，两头不靠。

而 worktree 直接从物理上规避了这个问题：每个 worktree 就是一个独立的目录，对应一个分支。你在目录 A 里用 AI 写分支 A 的代码，在目录 B 里用 AI 写分支 B 的代码，它们从文件系统层面就是两个项目，AI 读取上下文时看到的是各自完整的结构，不会再串台。

2.2 worktree 的创建、命名与清理实操

worktree 的使用方法不复杂，核心就几个命令。

创建一个新的 worktree 并关联到新分支：

git worktree add ../my-project-feature-login -b feature/login

这条命令的意思是在当前仓库的上一级目录下创建 my-project-feature-login 这个文件夹，并基于当前 HEAD 检出新分支 feature/login。这样你就在同一个仓库里拥有了两个互不干扰的工作目录：原来的目录还在主分支上，新目录在 feature/login 分支上。

你还可以把一个已存在的分支关联到新的 worktree，而不新建分支：

git worktree add ../my-project-hotfix -b hotfix/payment-bug origin/main

这条命令的用途是：你正在主分支上正常开发，突然线上出了个支付 bug 要紧急修复。你不想中断当前的开发进度，也不想把一堆未提交的改动卷进 hotfix 分支，那就可以基于远程 main 分支新建一个轻量的 worktree 专门处理 hotfix。等修完了，在对应目录里提交、合并、删除 worktree，再切回来继续原来的工作。

查看当前仓库下所有 worktree：

git worktree list

清理一个不再需要的 worktree：

git worktree remove ../my-project-feature-login

如果你在那个目录里还有一些未提交的改动，直接 remove 会提示错误，这时候可以加上--force：

git worktree remove ../my-project-feature-login --force

不过我的建议是，除非目录里的东西完全不重要，否则别用 force，先把改动提交或 stash，再清理。因为你一旦把 worktree 目录删了，那个分支上未提交的内容就找不回来了。

我自己的习惯是给每个 worktree 目录命名时带上项目名、分支类型和任务关键词。比如一个项目叫 store-admin，我可能会创建：

git worktree add ../store-admin-feat-optimize-cart -b feat/optimize-cart

这样即使同时挂着五六个目录，看一眼目录名就能知道哪个对应哪个分支，完全不用打开 IDE 去确认。这个习惯在与 AI 协作时尤其有用，因为你在提示词里可以明确写清楚“请在这个目录下工作：store-admin-feat-optimize-cart，对应分支是 feat/optimize-cart”，AI 就能精确定位，不会再拿错目录里的文件。

3. 给 AI 建立“可搬运的工作记忆”

很多人以为多项目管理只是目录和分支的问题，其实真正决定效率的是：你给 AI 的“记忆载体”是不是结构化的、可搬运的。也就是说，你不能每次都靠嘴巴说，或者靠临场打字来重新交代一遍项目背景，而要有一个文件，让 AI 每次开始工作时自己就能读。

3.1 一份随时可读的 PROJECT_STATE.md 该怎么写

我通常在每个项目（也就是每个 worktree 根目录）下维护一个名为 PROJECT_STATE.md 的文件，它相当于给 AI 的“入职手册”。里面包含三类信息：项目概览、当前任务状态、代码约定。

下面是一个我实际在用的简化模板：

# 项目状态文件 ## 项目概览 - 项目名称：订单后台管理系统 - 技术栈：Vue 3 + TypeScript + Vite + Pinia - 主要目录结构： - src/views —— 页面级组件 - src/components —— 公共组件 - src/api —— 接口请求封装 - src/store —— 全局状态管理 - 包管理器：pnpm - 常用命令： - 安装依赖：pnpm install - 启动开发服务器：pnpm run dev - 执行测试：pnpm run test ## 当前任务 - 本次迭代目标：优化订单列表页的筛选交互 - 涉及的接口：/api/order/list - 相关文件：src/views/order/OrderList.vue、src/api/order.ts - 注意事项： - 筛选条件需要做防抖处理 - 列表数据量大，后端要求使用游标分页而不是 offset 分页 - 组件样式使用 Tailwind，不写单独的 CSS 文件 ## 代码约定 - 命名规范：组件文件用 PascalCase，普通 ts 文件用 camelCase - 状态管理：优先使用 Pinia，不直接修改组件内 props - 接口错误处理：统一在 api 层 catch，页面只处理成功态 - 提交规范：feat/fix/docs/style/refactor 前缀

这个文件最重要的作用是：AI 编程助手在读取当前打开的目录时，如果我在提示词里加了“先阅读 PROJECT_STATE.md，然后按照里面的约定来工作”，它就能在最短时间内恢复“项目记忆”。

你可能会说，AI 助手不是能直接读取整个项目的代码吗？它确实能，但它会自己筛选信息，而它的筛选标准未必和你一致。比如，它可能读了大量已经过时的老代码，然后按着老风格给你写新代码。而 PROJECT_STATE.md 是我自己写的，每一句话都代表“当前真实的项目状态”和“我对这次任务的期望”，等于直接把重点划给 AI 看，它不用再从几百个文件里猜你要什么。

3.2 多项目提示词模板：切换时直接粘贴的“交接信息包”

有了状态文件，还需要一套固定格式的提示词，我把它称为“交接信息包”。每次从一个项目切到另一个项目时，我不会临时组织语言，而是直接粘贴一个模板，把关键信息填进去。

我的模板是这样：

请先阅读当前目录下的 PROJECT_STATE.md 和 README.md，了解项目背景。 本次任务：完成订单列表页的筛选交互优化。 工作目录：src/views/order/OrderList.vue 相关接口：src/api/order.ts 约束： 1. 不要修改其他页面的代码。 2. 筛选条件改变后，需要调用接口重新拉取列表。 3. 如果涉及新增样式，只使用 Tailwind 工具类，不新建 .css 文件。 4. 完成后，请告诉我你修改了哪些文件，以及为什么这样改。

这里面有一个关键设计：最后一条“告诉我你修改了哪些文件，以及为什么这样改”。这招特别有用。因为当一个 AI 编程任务涉及多个文件时，它会自作主张地修改它认为“应该修改”的东西，有时候甚至把关联动到不该动的模块。强制它汇报修改清单，你就能一眼看出它有没有越界。

我在多项目切换时，会为一个项目准备一个专门的对话会话，然后在这个会话里把“交接信息包”粘贴过去。如果这个会话被我不小心关闭了，下次打开时我就不重新描述需求了，而是发一句话：“读取 PROJECT_STATE.md，恢复上下文，然后我们继续做订单列表筛选的事。”这样 AI 就能借助文件快速回到之前的状态。

3.3 任务卡片化的管理节奏

除了文件维度，我自己还坚持一个习惯：任务的颗粒度要足够小，小到“每次切回来都能在一个小时内完成”，这样即使 AI 忘掉了一部分细节，你也能迅速检查出来。

如果是一个大功能，比如“改造整个用户中心的接口调用逻辑”，我不会一次性把任务丢给 AI，而是把它拆成几个子任务，比如：

• 子任务一：封装用户中心所有接口方法，不动 UI。
• 子任务二：替换用户信息页的数据调用。
• 子任务三：替换订单列表页的数据调用。
• 子任务四：替换设置页的数据调用，清理废弃代码。

每个子任务都是可以独立提交的，这样即使你半路去处理另一个项目，回来时也只需要从“下一个子任务”继续，不用从零开始回忆“这个功能到底做到哪一步了”。对 AI 来说，小任务的上下文也很简单，它不容易“忘记”也不会“混乱”。

我在实践里还会把“当前做到哪一步”写在 PROJECT_STATE.md 的当前任务部分，每完成一个小阶段就更新一下。比如写“子任务一已完成，下一步开始子任务二”。这样 AI 每次读取状态文件时，就能看到清晰的进度，而不是你只告诉它“我在做用户中心的改造”，它还得自己去猜你改到哪了。

4. 几个常见问题与排查思路

方案听起来很顺，实际用起来总会遇到一些坑。我把最常遇到的四个问题列出来，每个都附上我的排查思路和解决方法。

4.1 AI 把 A 项目的代码塞进 B 项目

这个是我早期最头疼的问题。某个 AI 编程助手如果同时建立了多个项目会话，偶尔会发生串线：它明明是在项目 A 的对话里，却输出了项目 B 的文件路径，甚至直接把项目 B 的代码复制过来。

我排查后发现，大部分原因是我在提示词里没有明确交代“当前项目绝对路径”，AI 只能根据上下文猜测。解决方法是，在提示词的最前面固定加一句：

当前项目是独立工作区，路径是 /Users/username/worktrees/store-admin-feat-optimize-cart，所有操作只能在当前目录下进行。

这一句话看着不起眼，但效果极好。它相当于给 AI 划定了一个“操作范围”，即便它的记忆里有其他项目的内容，也会因为你标注了明确路径而优先处理当前目录。

另外一种情况是，AI 工具自带的“跨会话记忆”功能太强了，它会把之前在其他项目对话里学到的约定用过来。这种时候我会主动在提示词里写“忽略之前所有对话中学到的项目约定，以当前 PROJECT_STATE.md 为准”。

4.2 worktree 分支冲突与清理时报错

worktree 用久了，目录会越来越多，清理时经常遇到“branch is checked out at another worktree”之类的报错。这个报错的意思是：你试图删除一个分支，但这个分支仍然被一个 worktree 占用。

排错步骤很简单：

git worktree list

找到占用该分支的 worktree 路径，然后：

git worktree remove /path/to/that/worktree

删除之后再删分支，就顺利了。如果那个 worktree 已经不存在于文件系统里，可以用 prune 清理：

git worktree prune

这个命令会清理掉所有已经不存在的 worktree 记录，避免 Git 认为它们还在占用分支。

还有一个我踩过的坑：如果你在 worktree 里改了文件但没有提交，直接在主目录里执行git merge或者git pull会提示冲突。因为同一个仓库下，其他 worktree 里未提交的改动也会影响分支状态。解决办法是：每次准备切换任务前，尽量先把当前 worktree 的改动提交或 stash 干净。这不仅是良好的习惯，更是配合 worktree 使用的必要条件。

4.3 长时间不用的项目回来上下文全丢

我自己有个小工具项目，可能一个月都不动一次。等我想起来要改时，AI 会话早没了，我之前写的 PROJECT_STATE.md 也过时了，因为我不在的这段时间，可能有其他人提交了新代码，或者依赖库大版本换代了。

我的解决办法是：在状态文件里加一个“最后更新时间”字段，每次回去改完代码就顺手更新一下。然后重新回去时，第一件事不是直接让 AI 写代码，而是让它：

阅读 PROJECT_STATE.md 和最近的 git log，总结一下这个项目现在的状态，指出和我状态文件里记录不一致的地方。

这相当于让 AI 先做一轮“差异分析”，把项目的最新情况跟你的记忆对齐。它分析完你再安排任务，就不会出现“AI 按照一个月前的约定写代码，但代码已经不符合当前项目的情况”这种尴尬。

4.4 AI 对话变长后上下文膨胀，输出质量下降

这个问题不在多项目切换里也会遇到，但在多项目场景下更明显。一个对话重用太久，AI 会逐渐“刷屏”，因为它太执着于之前的讨论细节，反而忽略了当前任务的重点。

我现在的做法是：一个会话只干一个子任务。完成一次提交，就开新会话，让新会话重新读 PROJECT_STATE.md。这样每次对话的上下文都保持在干净、可控的范围内。

如果你担心新会话不懂项目背景，别慌，在你写好 PROJECT_STATE.md 的前提下，AI 重新读一遍文件所需的成本比你在长对话里“翻历史记录”低得多。实测下来，长对话在超过 20 轮以后，AI 的有效输出质量明显下降，还不如让它“失忆重来”。

5. 方案落地的节奏建议

这套方案不是某一天突然就能全部铺开的，我建议你分阶段落地，每个阶段只增加一个习惯，等稳了再进入下一步。

第一步，先把所有项目的状态文件建起来。这个不用花很多时间，每个项目写一页纸就够了，关键是让 AI 每次工作前能自己读。

第二步，把 worktree 用起来。哪怕你只有一个项目，也可以用 worktree 把开发功能和线上修复隔离开来；等你在多项目之间跑顺了，worktree 带来的优势会更明显。

第三步，设计你的“交接信息包”模板。不用跟我完全一样，但要包含几个核心要素：项目路径、任务目标、涉及文件、约束条件、输出要求。重点是“约束条件”和“输出要求”，这两条决定了 AI 是乖乖干活还是放飞自我。

第四步，建立“会话生命周期”的管理习惯：一个任务一个会话，完成了就结束，绝不恋战。这会让你从根源上摆脱上下文污染。

我在实际使用中发现，这套方法除了让 AI 编程效率提升之外，还让我的心态稳了很多。以前切项目就像“换一个战场”，总担心忘了什么、丢了什么；现在每次切回一个项目时，只要看一眼状态文件，把交接信息包粘贴给 AI，它就能快速接上，而我也能迅速进入状态。尤其是当你同时维护四五个仓库时，这种“随时拿得起、随时放得下”的感觉真的很重要。

最后再分享一个小技巧：我会把 PROJECT_STATE.md 提交到 Git 仓库里，但放在一个独立的约定路径下，比如 docs/project-state.md，这样不会污染根目录。每次提交代码时顺带更新一下这份文件，长期下来它就是你的项目活档案。你不只给 AI 留了记忆，也给自己留了一本随时可查的项目笔记，比翻聊天记录好用太多了。