1. 切换切换切到最后人先累了我现在的日常状态是电脑上开着四个终端窗口两个代码编辑器外加十几个浏览器标签页。一个项目在等AI生成接口代码另一个项目的编译报错还没处理第三个项目的需求文档刚发过来。我在这几个项目之间来回折腾最直观的感受不是代码写不完而是脑子转不过来。一个人做多个项目用AI编程之后确实轻松了不少但也带来了一个很具体的新问题AI本身没有跨项目记忆。你在这个项目里跟它聊了半小时业务背景切到另一个项目它完全不记得了。每次切换都是一次“重新自我介绍”项目背景、技术栈、目录结构、构建命令、编码规范全都要再交代一遍。时间久了你会发现真正消耗精力的不是让AI写代码而是让AI“想起来”当前这个项目是怎么回事。这也是我想写这篇东西的原因。我不是什么AI专家就是一个长期一个人维护多个项目的开发者前端、后端、嵌入式都沾一点。最近这半年我一直在琢磨怎么让AI编程的多项目切换成本降下来试了不少办法有些管用有些踩了坑。今天把我觉得真正有效的一套做法整理出来核心就三件事用git worktree做工作区隔离用规则文件把项目上下文外置把常用任务模板化成提示词和skill。不管你现在用的是哪款AI编程工具只要你同时维护两个以上的项目这套思路应该都能用上。它不依赖某个具体工具更多是一种工作方式上的调整。2. 切换成本到底花在哪了不只是在“换项目”本身想解决切换问题得先搞清楚切换到底贵在哪里。我以前以为切换成本就是“换个目录、换个终端”那几秒钟的事后来认真观察了自己几天的操作才发现完全不是这么回事。2.1 上下文重建AI不记得你你也得帮它回忆AI编程工具在工作时依赖的是当前会话里的对话历史、当前目录的文件内容以及你能提供给它的项目信息。它没有跨会话的长期记忆或者说即便有记忆能力也远没有可靠到让你省去解释这一步。这就导致了一个特别常见的场景你切回一个上周没动的项目打算让AI修一个Bug。你得先解释这个项目是干什么的、用的什么框架、哪个目录是核心逻辑、Bug的现象是什么、你尝试过哪些排查。解释到一半你发现这不比你自己看代码来得快多少。更让人头疼的是AI在没有足够上下文的时候会“一本正经地胡说八道”。比如它会假设你的项目用的是某个版本的依赖会给出一段在当前版本里根本不存在的API调用。你还得花时间去纠错这一来一回切换到成本就被无限放大了。2.2 工具链切换每个项目都有自己的“脾气”多个项目的切换成本不只在AI这边也在你这边。不同项目可能用的是完全不同的技术栈一个是前端Vue项目一个是Python后端服务还有一个是STM32的嵌入式工程。每个项目的依赖安装方式不同、构建命令不同、调试方式不同甚至连代码风格都不一样。我记得有一段时间我上午在写Python下午切到嵌入式C语言到了晚上又是JavaScript。每次切换我的大脑都需要一段时间来“加载”对应的知识体系。有时候切得太频繁我会把Python的语法习惯带到C语言里或者把前端的命名风格带到后端代码里。这种心智负担比AI那边的上下文问题更隐蔽但也更消耗精力。2.3 任务切换的科学真相人比AI更怕切换心理学里有个概念叫“任务切换损耗”指的是人在两个任务之间切换时注意力需要重新聚焦这个重新聚焦的过程本身会产生时间成本。对于复杂任务来说这个成本可能高达20%到40%。也就是说如果你在三个项目之间来回切理论上每个项目只做了实际工作量的一半。联系到AI编程情况就更复杂了。因为你不是单纯在“做任务”你还在“指导AI做任务”。你需要把项目的背景、需求、约束条件用自然语言表达清楚然后检查AI的输出是否符合预期。这个过程比你自己写代码更依赖对项目上下文的完整理解。一旦上下文断了你连“怎么给AI下指令”都得重新想。所以我的结论是减少切换成本首先要做的是“让上下文可以随时恢复”而不是“强行减少切换次数”。因为很多时候你不得不切换比如一个项目在等编译另一个项目的需求很紧急。你能做的是让每次切换之后的“恢复时间”尽可能短。3. git worktree让每个项目分支都有独立的“房间”我第一次意识到git worktree对于AI编程的价值是某次在同一个仓库里同时开发两个功能分支。当时我在主分支上让AI改一个东西改到一半发现另一个分支有个紧急问题要处理。直接切分支吧当前改动会冲突不切吧紧急问题又等不了。以前我遇到这种情况要么是复制一份仓库目录要么是先把改动提交到临时分支。这两种方式都很别扭复制目录会把AI工具的工作目录也搞乱提交临时分支又会污染提交历史。直到我认真用上了git worktree这个问题才算是真正解决。3.1 worktree本质上是什么git worktree允许你在同一个仓库里同时检出多个分支到不同的目录。听起来很抽象其实可以类比成“给每个分支单独开了一个房间”。它们共享同一个.git历史记录但是工作目录、暂存区、分支指针都是独立的。打个比方你原来住在一个单间里想同时干两件事就得把东西搬来搬去。git worktree相当于给了你一套多居室的房子每个房间可以单独布置、单独使用但都还在同一个地址下。3.2 配合AI编程的具体用法我在用AI编程时习惯按功能分支来创建worktree。比如我有一个主项目在~/work/ai-project现在要开发一个“用户登录”功能我会这样操作cd ~/work/ai-project git worktree add ../ai-project-login -b feature/user-login这样就会在~/work/ai-project-login目录下新建一个分支feature/user-login的工作区。然后我把AI编程工具的工作目录直接指向~/work/ai-project-login告诉它“这个目录就是项目根目录”。这套做法的好处非常明显物理隔离每个worktree是独立的目录AI工具打开这个目录看到的文件就是当前分支的文件不会混杂其他分支的半成品。互不干扰我在一个worktree里让AI跑代码生成、跑测试完全不影响另一个worktree里的工作。切换极快从一个功能分支切到另一个功能分支不需要做任何暂存、隐藏操作直接打开对应目录就行目录天然对应当前任务。3.3 我在实际使用中的几个细节用了一段时间之后我总结出几个值得注意的细节**第一分支和worktree是一一绑定的。**同一个分支不能同时在两个worktree里检出。如果你在一个worktree里做完了功能开发合并回主分支后记得把worktree清理掉否则下次想再开同名分支时会报错。# 清理不再需要的worktree git worktree remove ../ai-project-login**第二依赖还是要单独装的。**每个worktree是独立的目录node_modules、虚拟环境、编译产物这些都不会共享。第一次切换到新worktree时需要重新安装依赖。我一开始觉得这很麻烦后来发现其实是好处——不同分支可能依赖不同版本的包分开装反而避免了版本冲突。**第三给AI的“项目路径”要明确。**AI编程工具比如带自动补全、代码生成的那些插件通常会自动探测当前工作目录。如果你开了多个worktree一定要确认每个会话对应的是哪个目录别让AI把另一个worktree的文件当成当前项目的文件来参考。3.4 一个完整的“worktreeAI”工作流示例我现在处理多项目时基本遵循这个流程主项目仓库保留稳定分支比如main或develop。接到新需求时从主分支拉一个新worktree分支名就是需求名。在worktree目录里打开AI编程工具开始对话前先确认工作目录正确。让AI在这个分支上完成功能开发、写测试、跑测试。功能完成后回到主仓库目录执行合并、删除worktree。这套流程对单人开发特别友好因为AI生成的代码质量不太稳定你经常需要基于它生成的结果做多轮修改。如果直接在主分支上让AI改改到一半发现思路不对想退回重来就得处理一堆临时改动。有了worktree你可以很从容地在分支上试错不行就删掉worktree重新来完全不影响主分支的状态。4. 规则文件把项目背景写进“AI必读手册”解决了工作区隔离的问题下一个要解决的就是上下文重建。我的做法是给每个项目准备一份规则文件把AI需要知道的项目背景、技术栈、构建方式、编码规范全部写进去让它每次开始工作前先读这个文件。这个思路源自一个很朴素的观察AI在对话中没有长期记忆但它在当前会话里是可以“记住”你告诉它的信息的。如果能把每次切换项目都要重复交代的内容沉淀成一份固定文件让AI每次自动加载那切换成本就能大幅降低。4.1 规则文件应该放在哪里不同的AI编程工具对规则文件的命名和位置约定不太一样。我用过的几种工具里Cursor会读取项目根目录下的.cursorrules文件Claude Code会读取CLAUDE.md还有一些工具支持AGENTS.md或者通用的.ai/rules.md。我的建议是不管工具默认读哪个你都要在项目根目录下放一份明文规则文件。原因很简单规则文件不仅是给AI看的也是给未来的你或者你的同事看的。当你三个月后重新打开一个项目时这份规则文件能帮你自己快速回忆项目是怎么回事。如果你用的工具不支持自动加载规则文件那就在每次开新会话时把规则文件的内容粘贴进对话里。虽然多了两步操作但比你每次从头解释项目背景要高效得多。4.2 一份能实际用的规则文件模板我把自己项目里的规则文件整理成了一个通用模板你可以根据自己的情况调整# 项目名称XXX ## 一句话简介 这是一个用于XXX的YYY项目主要解决ZZZ问题。 ## 技术栈 - 前端Vue 3 TypeScript Vite - 后端Python 3.11 FastAPI - 数据库PostgreSQL 15 - 其他Redis、Docker ## 常用命令 - 安装依赖npm install / pip install -r requirements.txt - 启动开发服务npm run dev / uvicorn main:app --reload - 运行测试npm run test / pytest - 构建npm run build ## 重要目录结构 - src/pages前端页面 - src/components公共组件 - backend/api后端接口 - backend/models数据模型 ## 编码规范 - 前端组件使用 Composition API 风格 - Python 代码严格遵循 PEP 8 - 命名使用驼峰前端和下划线后端 - 提交信息遵循 Conventional Commits 规范 ## AI注意事项 - 不要修改数据库迁移文件除非明确要求 - 不要使用未在 package.json 中声明的依赖 - 涉及用户鉴权的代码必须使用项目封装的 auth 工具函数 - 生成的代码需要有基本的错误处理不能只是主流程你可能觉得这些内容很简单但恰恰是这些“简单信息”在AI对话中最容易被忽略。AI生成代码时经常不自觉地引入新的依赖、改变目录结构、忽略现有的封装。有了规则文件你可以直接在“AI注意事项”里用否定句明确禁止这些行为效率提升非常明显。4.3 规则文件不是越长越好有一点特别想提醒你规则文件不是项目文档不是写得越多越好。我有段时间把规则文件写得很详细项目的全部业务逻辑、数据库设计、接口文档都塞进去了。结果AI每次对话都要先读很长的内容响应速度变慢而且因为信息太多它反而抓不住重点更容易忽略关键约束。正确做法是规则文件聚焦“AI容易出错”和“你不想重复解释”这两类信息。业务细节、完整文档可以放链接让AI按需去查。规则文件控制在几十行以内最合适让它能在每次会话开始时完整读一遍。4.4 跨项目的“规则模板”管理当你同时维护多个项目时每个项目的规则文件会有一些共性的内容比如“提交信息规范”“代码风格要求”“通用的AI使用约定”。这些通用内容如果每个项目都复制一份后续更新就很麻烦。我的做法是在项目根目录放一个精简的AGENTS.md或对应的规则文件里面通过相对路径引用一个公共规则文件。比如# 项目特定规则 ## 技术栈 ... ## 项目特有约束 ... ## 通用约定 请同时阅读 ../../shared/ai-rules.md 中的通用规则当然这个做法取决于你的AI工具能不能跟踪相对路径引用。如果不行那就退而求其次把通用规则复制到每个项目里。但至少你要意识到规则文件是有“模板版本”的需要定期同步更新。5. 提示词模板和skill同一类任务只说一次话规则文件解决的是“项目上下文”的问题但项目中还有一个隐藏的重复成本同一类型的任务每次都要用不同的话重新描述一遍。比如“修复Bug”这个需求你在项目A里对AI说“这个函数返回结果不对帮我看看”在项目B里可能说“这里报了个TypeError帮我查一下原因”。虽然是不同的项目、不同的问题但对AI下达指令的结构其实是类似的描述现象、给出复现步骤、指出可能的模块、要求输出什么格式的修复方案。如果你能把“怎么给AI下指令”这件事也标准化那你就不需要每次切换项目时重新组织语言了。这就是提示词模板和skill要做的事。5.1 从“写提示词”到“用模板”我现在给AI编程时会分场景维护一组提示词模板。大多数项目的常见任务无非这么几类新功能开发、Bug修复、代码评审、写测试、重构。我给每类任务设计一个模板像填表一样往里填项目具体信息。以“Bug修复”为例我的模板是这样的## 当前问题 [描述Bug现象包括报错信息、运行环境、出现频率] ## 复现步骤 [描述如何触发这个Bug] ## 期望行为 [描述正确情况应该是什么样的] ## 我尝试过的排查 [列出你已经做过的尝试避免AI重复建议] ## 请帮我 1. 定位Bug根因并解释为什么会发生 2. 给出修复方案尽量使用项目现有的封装 3. 提醒我修改后可能对哪些模块产生副作用你可能会觉得这算什么模板不就是把问题说清楚吗但关键在于有了模板你在切换项目时就不需要思考“应该给AI提供哪些信息”了。你只需要按模板填空几分钟就能写出一条高质量的指令而不是对着对话框憋半天。5.2 更进一步把“提示词”变成“skill”最近AI编程圈子里很火的一个概念是“skill”技能在“oh my pi”这类AI编程智能体的讨论里“AI agent编程”“ai编程一些常用的skill”也是热门话题。简单来说skill就是把一组提示词、脚本、规则打包成一个可复用的能力单元。拿我自己的实践来说我给项目配置了一个“代码评审”skill它做的事情是读取当前分支的改动文件对照项目的编码规范逐项检查输出一个包含“问题位置、问题类型、修改建议”的评审报告。以前我每次要花十几分钟手动让AI做这件事现在一个命令就搞定了。skill的好处在于它把“提示词”和“操作流程”绑定在了一起让AI从一个“被动回答问题的助手”变成了“能按固定流程执行任务的执行者”。这也回应了“怎么学习ai agent编程”这个很多人都在问的问题——首先你要搞清楚你的任务里有哪些是可标准化的流程然后把它们写成skill。我建议从这几个skill开始积累生成规范提交信息读取git diff按Conventional Commits格式生成提交信息代码自检检查新增代码是否符合项目规范、有没有明显逻辑问题写单元测试为指定函数或组件生成测试代码依赖安全扫描检查项目依赖有没有已知漏洞5.3 多项目场景下的skill管理当你手头有多个项目时skill可以分成两类通用skill和项目专属skill。通用skill放在公共目录里所有项目都能调用。比如“生成提交信息”“代码自检”这种和具体项目无关纯粹是辅助AI编程的效率工具。项目专属skill放在项目仓库里通过规则文件的“AI注意事项”引用。比如某个前端项目有特殊的状态管理约定某个嵌入式项目有特殊的编译流程这些就写成项目专属skill。我自己管理skill的方式是把每个skill写成纯文本的markdown文件放在一个专门存放AI配置的Git仓库里。这样所有项目的skill配置都可以版本管理换新电脑也能快速恢复。5.4 模板和skill的数量控制别把工具变成负担最后说一句题外话模板和skill不是越多越好。我有一次兴致勃勃地写了十几个模板从“生成数据库ER图”到“优化Dockerfile”应有尽有。结果真到用的时候我根本想不起来自己有哪些模板每次还是用最笨的方式直接对话。到头来那些模板都躺在文件夹里吃灰。根据自己的经验模板控制在五六个以内skill控制在三四个以内是比较合适的。宁可少而精不要多而杂。只有当你反复遇到“同样结构的话又要说一遍”的场景时才值得为它创建一个新模板。否则模板管理本身的成本比省下来的对话成本还高。6. 针对不同项目类型的AI工作流差异前面聊的都是通用方法但实际做过多项目的人应该清楚不同类型的项目AI编程的切换痛点其实完全不同。纯软件项目和嵌入式项目的差别尤其大。如果你也像我一样既写Web应用又碰MCU开发这一章的对比应该能帮你少走一些弯路。6.1 纯软件项目规则文件快速验证对于前端、后端这种纯软件项目AI编程的生产力已经非常高。这类项目的特点是修改代码后能立即运行反馈循环很短。所以我会特别强调“让AI自己验证”这个动作。比如在后端项目里我会在规则文件里明确告诉AI“每次修改完代码必须运行pytest跑一遍相关测试。”在提示词里也会加一句“变更后请先执行测试并贴上结果再解释代码逻辑”。这能有效避免AI生成一堆“看起来能跑实际一测就挂”的代码。这类项目的切换重点在环境隔离同一个仓库的多个子项目比如微服务架构我会用worktree为每个服务建独立工作区不同的技术栈项目用规则文件说明各自的运行方式。实际体验下来配合规则文件和快速验证Web/后端项目的AI切换成本已经压得很低了。6.2 嵌入式MCU项目AI在线编程的特殊闭环嵌入式项目是另一个极端。我自己常碰STC单片机的开发这类项目用AI编程时有一个非常不同的痛点你没法让AI直接“跑一下看看”。代码要编译、烧录到芯片里再接上串口工具看日志整个反馈循环比纯软件项目长得多而且每一次烧录都有测试板的状态成本。这里要特别提一下“stc单片机ai在线编程”这个方向。STC单片机可以通过串口进行在线下载编程也就是说你写完代码之后不需要额外的仿真器直接用串口把固件烧录到芯片里。这个特性配合AI编程就很有想象力了AI生成代码 → 本地编译 → 串口在线下载 → 板子跑起来 → 通过串口把调试日志回传给AI → AI根据日志再次修正代码。我目前的实践流程是这样的在规则文件里写明芯片型号、晶振频率、所用外设串口、定时器、ADC等、编译工具链比如SDCC或Keil以及烧录命令。让AI生成外设初始化代码时我会把“寄存器配置必须附上数据手册的依据”写进提示词防止它凭空编寄存器值。编译通过后通过串口工具烧录到单片机同时打开串口调试助手。如果运行异常把串口日志反馈给AI让它结合日志和前一次代码分析哪里出了问题。这套闭环用熟了之后嵌入式项目里的AI不是“一次性生成完事”而是变成了一个“先做再说、根据观察修正”的开发搭档。虽然不像纯软件项目那么快速但已经比完全自己调试高效太多了。6.3 “ai辅助设计mcu编程”给我的启发在调研这个方向时我注意到一个热搜词“ai辅助设计mcu编程”。这个词组挺能说明问题的AI在MCU开发中的角色不光是“替你写代码”还包括“帮你做设计决策”。比如选型的时候AI可以帮你对比不同芯片的功耗和外设资源画PCB之前可以让AI帮你规划引脚分配写驱动之前可以让AI帮你梳理寄存器操作的正确流程。这给我的启发是多项目切换时不仅要在“代码生成”阶段用AI在“项目启动设计”阶段也可以让AI介入。很多时候我们切换项目之所以累是因为我们对某个项目的记忆停留在“上次做到一半”的状态。如果你能在项目开始时让AI帮你产出设计摘要架构方案、关键决策、遗留问题并存成一份AI_DESIGN.md文件那下次切换回来时你只需要花五分钟读这份文件就能快速进入状态。这一招对嵌入式项目尤其管用因为嵌入式项目的硬件环境、引脚分配、通信协议这些信息一旦断了重新接上非常费劲。6.4 多项目混合时的“AI工作台”组织方式最后我分享一下自己当前一个比较满意的多项目目录组织方式谈不上标准但实测下来很稳。核心思路是“一个总工作目录一个整合同步工具”。我的主工作区在~/work下面按项目分目录每个目录里有项目的代码、规则文件、设计摘要。另外我在~/work/ai-assets里统一存放所有提示词模板和通用skill的配置文件。这样我可以把ai-assets做成一个Git仓库一台新机器clone下来配合软链接使用规则文件和skill的版本全都能追溯。再配合shell脚本把“打开项目加载规则初始化AI会话”这几件事串成一条命令。比如我有个devagent的小脚本执行devagent frontend-a就会自动进入前端项目A的worktree目录读取规则文件给出对应的起步提示词。这一套东西看起来很简陋但确实把我每天“从零开始进入一个项目”的时间压缩到了几分钟以内。最后再分享一个实实在在的经验有人可能会问这套工作流是不是有点复杂我觉得分阶段看如果你只是刚开始用AI编程其实不需要一开始就搞worktree加规则文件那么重。完全可以先从一个项目做起把规则文件写起来把你的提示词固定下来然后再慢慢加worktree、加skill。不要让“优化切换”这件事本身变成了一个新的负担。对我个人来说最大的转折点其实是“承认AI没有记忆”这件事。一开始我总指望工具能自动记住我所有项目的背景后来发现靠工具不如靠自己把上下文写下来。现在我的规则文件和模板已经不光是给AI看的了也是给我自己看的。很多时候我重开一个搁置了很久的项目读一遍规则文件自己也就进入状态了。另外还有一个小习惯每个周五下班前我会花十分钟把本周在几个项目里新总结出来的约束条件补进对应的规则文件里。比如这周某个项目里AI连续踩了两次同样的坑我就会在“AI注意事项”里加一条。这个小习惯坚持了小半年之后我发现AI在项目里出错的频率真的降下来了而且每次切换到项目时打开AI编程工具的那一下“启动焦虑”也基本消失了。这套东西并不神秘就是给自己和AI之间建一套稳定的“交接班制度”。如果你现在也被多项目的AI编程切换折磨着不妨先从给一个项目写规则文件开始试试。