构建个人AI编码规则库：告别重复Bug，打造智能编程伙伴
1. 项目概述：构建你的个人AI编码规则库
如果你和我一样，每天都要和Claude、Cursor这类AI编码助手打交道，那你肯定也遇到过这种让人抓狂的情况：昨天刚在项目A里花半小时解决的时区处理bug，今天在项目B里，AI助手又给你写出了几乎一模一样的错误代码。它就像个记性不好的实习生，同一个坑能让你反复掉进去。这种重复劳动不仅浪费时间，更消磨开发热情。今天要聊的“Vibe Coding Rules”项目，就是专门为解决这个问题而生的。它本质上是一个个人化的、可迭代的编码知识管理系统，核心目标就一个：让你踩过的每一个坑，都变成AI助手未来避开的经验，实现“一次踩坑，终身免疫”。
简单来说，这是一个基于GitHub仓库的规则库。你把在不同项目中遇到的典型bug、最佳实践、架构约束整理成结构化的Markdown文档，然后通过一套标准化的Prompt，引导你的AI助手在每个新项目开始前主动学习这些规则。开发过程中，每当AI帮你修复一个bug，它还会主动询问你是否要将这个解决方案记录到本地，经过你的审核后，有价值的通用规则可以同步到中央仓库，供所有未来项目参考。这套系统特别适合独立开发者、小团队技术负责人，或者任何希望提升与AI结对编程效率的人。它把零散的经验沉淀为可执行的规则，让AI从“临时工”变成越来越懂你编码习惯和项目规范的“老搭档”。
2. 核心设计思路：为什么是“规则库”而非“备忘录”
很多开发者习惯用笔记软件或代码片段工具记录问题，但为什么我要专门搞一个规则库？这背后的设计逻辑值得深究。首先，“规则”与“记录”有本质区别。一条简单的记录可能是“项目X的登录API返回了500错误”，而一条合格的规则需要提炼为：“在Next.js API路由中处理身份验证时，必须在getServerSideProps或API handler中显式检查会话cookie，因为Edge Runtime环境下的req.headers行为与Node.js服务器不同。” 后者包含了问题上下文、技术栈、根因分析和标准化解决方案，是AI可以直接理解并执行的指令。
其次，这个设计遵循了知识管理的“收集-提炼-应用”闭环。LESSONS_LEARNED.md是收集层，存放原始的问题记录；中央规则库（by-category/,by-stack/）是提炼层，存放经过通用化、结构化的高质量规则；CLAUDE.md和AI的实时读取是应用层，确保规则在编码时被主动调用。这个闭环确保了知识不是静态的存档，而是流动的、能直接影响编码行为的资产。
最后，以AI为第一用户进行设计。所有规则格式都考虑了AI的“阅读”习惯：使用清晰的Markdown标题和列表、提供正反代码示例、明确标注级别（必须/建议）。这就像为AI编写一份它专属的《员工手册》，告诉它在你手下干活需要遵守哪些“公司规定”。这种设计思路让工具的价值最大化，因为它直接嵌入了你的核心工作流——与AI对话编程——而不是一个需要你额外打开查阅的独立文档。
2.1 技术选型与工具链的考量
选择GitHub仓库作为载体，几乎是必然的选择。首先是可访问性，所有主流AI编码助手（Cursor, Windsurf, Claude Code）都能轻松读取公开或私有的GitHub仓库中的Markdown文件。其次是版本控制，规则的增删改查、历史追溯都可以通过Git管理，你可以清晰地看到某条规则是何时、因哪个项目而添加的。最后是生态集成，GitHub的“Use this template”功能让规则库的复制和个性化变得极其简单，而Issues或Discussions未来甚至可以用于规则的讨论和评审。
在AI助手的选择上，这个系统对Claude 3.5 Sonnet、Cursor的Composer模式以及Windsurf的AI代理功能支持得最好。因为它们都具备较强的长上下文理解能力和遵循复杂指令的稳定性。相比之下，一些只擅长单次补全的轻量级插件可能无法完美执行“读取-应用-记录”的完整工作流。因此，如果你主要使用VS Code Copilot进行单行补全，可能需要调整预期，将其更多用于规则库中具体代码模式的触发，而非完整流程的自动化。
注意：规则库的成功极度依赖Prompt的稳定性。不同AI模型对同一段Prompt的理解可能有细微差异。建议在选定主力AI助手后，用几个小任务测试其遵循
SETUP_PROMPT.md的准确度，并微调Prompt的表述，形成一套稳定的“咒语”。我的经验是，在Prompt中明确要求AI“逐步确认每一步”，可以显著提高可靠性。
3. 从零开始：搭建与初始化你的规则库
看到这里，你可能已经跃跃欲试了。别急，我们先从最稳妥的路径开始。整个搭建过程就像装修房子，先打好地基，再砌墙，最后做软装。遵循这个顺序能避免后期大量返工。
3.1 第一步：Fork与基础结构搭建
访问项目模板仓库，点击绿色的“Use this template”按钮，而不是简单的Fork。这两者有细微但重要的区别：“Use this template”会创建一个全新的、独立于原仓库历史记录的仓库，这更干净，也避免了未来不小心向原仓库提交PR的尴尬。给你的新仓库起个名字，比如my-coding-rules或{你的用户名}-dev-rules。
仓库创建完成后，先别急着写规则。打开仓库的设置，做两件事：
- 启用GitHub Pages（可选但推荐）：在Settings -> Pages里，将Source设置为“Deploy from a branch”，分支选择
main，文件夹选择/ (root)。这会把你的规则库发布成一个简单的静态网站，你甚至可以通过https://你的用户名.github.io/my-coding-rules/by-stack/react.md这样的链接直接分享某条规则给队友。 - 检查默认分支保护规则：建议为
main分支启用“Require a pull request before merging”保护。因为规则库是你的核心知识资产，任何直接推送都应该经过思考（哪怕是你自己）。通过PR合并可以强制你为每次添加写一个简短的说明，这个习惯对未来回顾非常有帮助。
接下来，浏览初始的目录结构。templates/文件夹下的几个文件是你的操作手册，尤其是SETUP_PROMPT.md，里面就是那个核心的配置Prompt。我建议你先复制一份到你的笔记软件里，并把其中的https://github.com/YOUR_USERNAME/vibe-coding-rules替换成你刚创建的真实仓库地址。这个地址是整套系统的“指挥中心”，务必确保准确。
3.2 第二步：编写你的“宪法”——MASTER_RULES.md
MASTER_RULES.md是整个规则库的基石，是每个新项目开始时AI必须首先阅读的文件。它不应该放具体的代码规则，而应该定义最高层级的编码哲学、工作流和原则。你可以把它想象成你们团队的“宪法”。
一个好的MASTER_RULES应该包含哪些内容？根据我的经验，这几部分是核心：
- 核心哲学：用一两句话阐明你编码的核心理念。例如：“可读性优于巧妙的技巧”、“所有用户输入都是不可信的”、“错误处理不是可选项，是必选项”。
- 工作流指令：明确告诉AI你希望如何与它协作。例如：“在实现新功能前，请先简要描述你的实现思路，经我确认后再编写代码。”、“所有提交信息需遵循Conventional Commits格式。”
- 通用技术原则：跨技术栈的约束。例如：“禁止使用
any类型（TypeScript）”、“数据库查询必须使用参数化查询，禁止字符串拼接”、“所有API调用必须有超时和重试逻辑”。 - 规则库使用规范：告诉AI如何正确引用和更新规则库。例如：“引用规则时，请注明规则来源的文件和标题。”、“当发现现有规则不适用或过时时，请提醒我更新。”
下面是一个我使用的MASTER_RULES.md开头示例，你可以以此为蓝本修改：
# 核心开发规则 (Master Rules) ## 基本原则 - **安全第一**：任何可能涉及数据安全、用户隐私或系统稳定性的代码，必须经过双重确认。 - **明确优于隐晦**：即使牺牲少量性能或代码长度，也要选择意图最明确的实现方式。 - **自动化一切可自动化的**：重复性的代码模式、构建步骤、检查流程，都应寻求自动化方案。 ## 与AI协作规范 1. **先思考，后编码**：在编写任何代码块前，请用一句话描述你的解决方案。如果我回复“请继续”，再输出代码。 2. **渐进式复杂**：对于复杂功能，请先实现一个最小可行版本，然后根据我的反馈迭代增强。 3. **主动提问**：当需求描述存在歧义、或你发现潜在的技术风险时，请立即停止并向我提问。 ## 代码质量红线（绝对禁止） - 禁止提交包含 `console.log` 调试语句的代码。 - 禁止使用已弃用（deprecated）的API或库版本。 - 禁止在业务逻辑中硬编码配置值（如API密钥、URL）。 ## 规则库使用指南 - 开始新任务时，请先阅读本文件及 `by-stack/` 下相关技术栈的规则。 - 当你修复一个bug，且我认为具有普遍意义时，我会说“记录”。请按模板格式将其追加到项目的 `LESSONS_LEARNED.md`。 - 只有当我明确指令“同步到中央规则库”时，才可发起规则同步流程。花点时间认真撰写这份文件，它决定了AI助手与你合作的“基调”。好的MASTER_RULES能让后续的协作事半功倍。
3.3 第三步：创建你的第一条技术栈规则
有了“宪法”，现在来制定具体的“法律”。打开by-stack/目录，根据你的主力技术栈创建文件，比如nextjs.md。第一条规则写什么？我建议从你最近踩过的一个印象最深的坑开始。这能让抽象的概念立刻变得具体。
假设你最近在Next.js项目里被getStaticProps和getServerSideProps的数据获取时机搞糊涂过，导致页面渲染了过时数据。那么你的第一条规则可以这样写：
### 数据获取函数的选择必须严格匹配渲染需求 - **级别**: 必须 - **来源**: 电商平台项目 - 产品列表页 - **问题**: 产品列表页使用了 `getStaticProps` 但未设置 `revalidate`，导致价格更新后，用户看到的仍是静态生成时的旧价格，必须重新部署才能更新。 - **根因**: 错误理解了 `getStaticProps` 的适用场景。它适用于内容变化不频繁的页面，并在构建时运行。对于需要周期性更新的数据，必须使用 `revalidate` 参数启用增量静态再生（ISR），或改用 `getServerSideProps` 实现服务端渲染。 - **方案**: 根据页面数据的更新频率和一致性要求，严格遵循以下决策流： 1. **完全静态，永不更新**（如博客文章、文档）：使用 `getStaticProps`，不设 `revalidate`。 2. **周期性更新**（如产品价格、新闻列表）：使用 `getStaticProps` 并设置合理的 `revalidate` 时间（如60秒）。 3. **每次请求都需最新数据**（如用户仪表盘、含个性化内容）：使用 `getServerSideProps`。 4. **无需SEO，客户端获取即可**（如用户控制台）：在 `useEffect` 或SWR中获取，使用 `getStaticProps` 返回空props或骨架。 - **代码示例**: ```javascript // 错误：价格频繁变动，却使用无revalidate的静态生成 export async function getStaticProps() { const products = await fetchProducts(); // 构建时获取一次 return { props: { products } }; } // 正确：启用ISR，每60秒重新验证并可能重新生成页面 export async function getStaticProps() { const products = await fetchProducts(); return { props: { products }, revalidate: 60, // 关键：最多每60秒更新一次 }; } // 正确：每次请求都获取最新数据（牺牲部分性能） export async function getServerSideProps() { const products = await fetchProducts(); return { props: { products } }; }注意这条规则的格式：清晰的标题、明确的级别、具体的来源项目、对问题的描述、对根本原因的分析、通用的解决方案，以及正反代码示例。这个格式是AI最容易理解和提取关键信息的结构。写完这条规则后，你可以立刻在一个新的Next.js项目中测试：把仓库地址和这条规则告诉AI，然后让它为你设计一个产品详情页的数据获取策略，看它是否会正确应用这条规则。 ## 4. 深度集成：将规则库注入日常开发工作流 规则库建好了，但如果它不能无缝融入你的开发流程，很快就会变成又一个被遗忘的文档文件夹。关键在于**让使用规则库成为AI助手的默认行为**，而不是你需要额外记起的事情。 ### 4.1 新项目初始化标准化流程 每次启动新项目，无论是全栈应用、脚本还是库，第一件事不是`npm init`，而是让AI配置规则系统。将之前修改好的`SETUP_PROMPT`发送给你的AI助手（例如在Cursor的Chat面板中）。一个健壮的Prompt执行流程应该是这样的： 1. **AI确认理解**：它应该回复：“我将为您设置编码规则系统。首先，我会读取您位于 `https://github.com/yourname/my-coding-rules` 的规则库，然后在本项目根目录创建 `CLAUDE.md` 和 `LESSONS_LEARNED.md` 文件。确认开始吗？” 这给了你纠错的机会。 2. **执行与报告**：你确认后，AI应逐步执行并报告结果：“已读取MASTER_RULES.md和by-stack/react.md。已创建CLAUDE.md，其中引用了您的规则库并说明了项目技术栈。已创建空的LESSONS_LEARNED.md。系统已就绪。从现在起，每次修复bug后，我会询问您是否记录。” 3. **验证产出**：你应检查生成的`CLAUDE.md`文件。一个合格的`CLAUDE.md`可能长这样： ```markdown # 项目编码规则指引 - **项目名称**: 用户管理后台 - **技术栈**: Next.js 14 (App Router), TypeScript, Tailwind CSS, Prisma - **核心规则库**: https://github.com/yourname/my-coding-rules - **关键规则摘要**: 1. 所有API路由必须包含显式的错误处理和状态码返回（参见 `by-category/error-handling.md`）。 2. 数据库查询必须使用Prisma的参数化查询，禁止字符串拼接（参见 `by-category/database.md`）。 3. React组件必须使用TypeScript接口定义Props（参见 `by-stack/react.md`）。 - **指令**: 修复任何bug后，请主动询问：“要记录这个问题到LESSONS_LEARNED.md吗？” ``` 这个文件成了项目的“规则总纲”，任何新加入的开发者（包括未来的你）或者AI，都能快速了解本项目需要遵守的特定约束。 ### 4.2 开发中的实时记录与提炼 这才是系统发挥价值的核心场景。假设你在开发中遇到了一个bug：用户上传头像时，如果文件名包含中文，服务端保存后文件名乱码。你和AI一起定位到问题是因为没有设置正确的编码头。 **理想的交互应该是：** 1. AI修复bug后，主动提问：“Bug已修复（添加了`Content-Disposition`头的`filename*`参数用于UTF-8编码）。要记录这个问题吗？” 2. 你判断这个问题具有通用性（任何涉及文件上传的场景都可能遇到），于是回复：“记录。” 3. AI立即将以下内容追加到项目的`LESSONS_LEARNED.md`： ```markdown ## 2024-05-18: 文件上传接口需处理含非ASCII字符的文件名 - **类型**: 编码/国际化 - **原因**: 当用户上传的文件名包含中文等非ASCII字符时，后端未设置支持UTF-8编码的`Content-Disposition`头，导致保存时文件名乱码。 - **解决方案**: 在服务端设置响应头时，使用 `filename*` 参数并指定UTF-8编码和语言，遵循RFC 5987标准。浏览器和标准HTTP客户端均支持此格式。 - **代码示例**: ```javascript // 错误：普通filename头不支持非ASCII字符 res.setHeader('Content-Disposition', `attachment; filename="${fileName}"`); // 正确：使用filename*并编码 const encodedFileName = encodeURIComponent(fileName); res.setHeader('Content-Disposition', `attachment; filename*=UTF-8''${encodedFileName}`); // 为兼容旧客户端，可同时提供纯ASCII的filename作为fallback const asciiFallback = fileName.replace(/[^\x00-\x7F]/g, '_'); // 替换非ASCII字符 res.setHeader('Content-Disposition', `attachment; filename="${asciiFallback}"; filename*=UTF-8''${encodedFileName}`); ``` ``` 这个过程将“解决问题”和“知识沉淀”无缝衔接，几乎不增加额外负担。`LESSONS_LEARNED.md`逐渐成为该项目独特的“病历本”。 ### 4.3 定期回顾与规则库同步 每周或每完成一个项目里程碑，花15分钟浏览一下`LESSONS_LEARNED.md`。这时，你需要扮演“知识编辑”的角色，判断哪些记录值得升格为中央规则库的正式规则。 **同步决策流程：** 1. **触发**：你对AI说：“请审核`LESSONS_LEARNED.md`中的记录，准备同步通用规则到中央库。” 2. **AI初审**：AI会逐条应用`RULE_QUALITY_CHECKLIST.md`中的标准（通用性、质量、非重复）进行筛选，并给出初步建议：“记录#1关于文件名编码，通用性高、有代码示例、中央库无类似规则，建议同步。记录#2关于某特定第三方API的临时故障，通用性低，不建议同步。” 3. **你终审**：你复核AI的建议。对于同意同步的，你发出最终指令：“将记录#1同步到中央库的`by-category/network-and-files.md`文件中。” 4. **AI执行**：AI会在中央规则库的对应文件中，以标准格式添加这条新规则，并提交一个Pull Request（如果启用了分支保护）。 5. **你合并**：你查看PR的变更，确认无误后合并。至此，这条知识就完成了从“个人项目经验”到“团队通用规则”的转化。 这个流程的关键在于，**审核的最终决定权必须在你手中**。AI可以辅助筛选，但只有你能判断某条经验在未来项目中的潜在价值。这避免了规则库被低质量或过于具体的记录污染。 ## 5. 规则撰写的高级技巧与质量维护 规则库的价值与其中规则的质量直接相关。写一条好规则，比草率地写十条规则更有用。以下是我从数百条规则中总结出的撰写心法。 ### 5.1 如何撰写一条AI友好的高质量规则 一条优秀的规则，应该让AI在5秒内抓住重点，并在编码时能准确触发。它包含以下几个要素： - **标题即摘要**：标题要清晰描述问题或模式，避免模糊。对比“文件上传问题”和“处理含非ASCII字符文件名的HTTP响应头设置”，后者一目了然。 - **级别量化影响**：“必须”意味着违反会导致功能错误、安全漏洞或严重性能问题；“强烈建议”通常关乎可维护性、最佳实践；“建议”则是一些锦上添花的优化。 - **根因分析要深入**：不要只写“代码报错”，要写出错误的本质。例如，不是“API请求失败”，而是“在React组件卸载后，仍尝试更新其状态，导致内存泄漏警告”。深入的根因分析能帮助AI和未来的你理解一类问题，而非一个特例。 - **解决方案要可操作、可泛化**：提供具体的代码修改方法，同时说明其背后的原理，这样AI才能举一反三。例如，在讲解“避免React useEffect的无限循环”时，不仅要给出添加依赖数组的示例，还要解释“依赖数组的比较是浅比较，引用类型的变化会触发重运行”。 - **正反示例对比强烈**：错误示例要典型，正确示例要完整。最好能在正确示例中添加注释，解释关键决策点。对于复杂的正确示例，甚至可以提供一个“更佳实践”版本。 下面是一条关于状态管理的规则示例，展示了如何平衡具体与泛化： ```markdown ### 使用Zustand时，避免在非响应式区域直接修改状态 - **级别**: 强烈建议 - **来源**: 仪表盘项目 - 实时图表更新 - **问题**: 在WebSocket事件监听器（在Zustand store外部初始化）中直接调用 `useStore.getState().updateChart(data)` 更新状态。虽然图表数据变了，但React组件没有重新渲染。 - **根因**: Zustand的响应式更新依赖于在React组件内部调用 `useStore` hook 或使用 `subscribe` 方法。在store外部直接调用 `getState()` 并修改，绕过了Zustand的订阅机制，因此无法通知React组件进行重渲染。 - **方案**: 1. **首选方案**：将状态更新逻辑封装在store的action内部。在任何地方（包括事件监听器、定时器）都通过调用action来更新状态。 2. **备选方案**：如果必须在store外部监听事件，使用store的 `subscribe` 方法监听状态变化，并在回调中触发组件更新（通常通过设置一个本地状态来实现）。 - **代码示例**: ```javascript // 错误：在store外部直接修改状态，组件不更新 const ws = new WebSocket('ws://example.com'); ws.onmessage = (event) => { const data = JSON.parse(event.data); // 错误！这不会触发组件重渲染 useChartStore.getState().setChartData(data); }; // 正确：将更新逻辑封装为store的action // store定义 (store/chartStore.js) import { create } from 'zustand'; const useChartStore = create((set) => ({ chartData: [], // 定义一个action updateChartFromWebSocket: (data) => set({ chartData: data }), })); export const { getState } = useChartStore; // 导出getState用于非组件环境 // 在WebSocket监听器中调用action ws.onmessage = (event) => { const data = JSON.parse(event.data); // 正确：通过导出的getState调用action getState().updateChartFromWebSocket(data); }; // 在React组件中，正常使用hook，状态更新会自动触发重渲染 function ChartComponent() { const chartData = useChartStore((state) => state.chartData); return <Chart data={chartData} />; }### 5.2 规则库的维护与迭代策略 规则库不是一成不变的。技术栈更新、最佳实践演进，规则也需要新陈代谢。我建议采用“**主干稳定，分支实验**”的策略。 - **主干（main分支）**：只存放经过多个项目验证、稳定可靠的规则。这里的规则是“金科玉律”，AI必须遵守。 - **实验性规则**：可以为探索中的新技术（如一个新的状态管理库）或尚存争议的最佳实践，创建一个 `experimental/` 目录或使用Git分支。在特定项目中引用这些实验规则，观察效果。经过2-3个项目验证后，再决定是提升到主干、修改还是废弃。 - **定期审计**：每季度进行一次规则库审计。重点检查： 1. **过时规则**：是否有规则针对的是已废弃的API或旧版本库？ 2. **冲突规则**：不同文件中的规则是否存在矛盾？（例如，一条规则说“始终使用async/await”，另一条又说“在某些场景下使用Promise.then更清晰”） 3. **效用规则**：哪些规则被AI引用和遵守得最多？哪些规则似乎从未被触发？低效用的规则可以考虑删除或重写。 维护一个高质量的规则库，其本身就是一个极好的元认知练习，它能强迫你不断梳理和澄清自己的技术决策。 ## 6. 常见问题与实战排坑指南 在实际推广和使用这套系统的过程中，我和我的团队遇到过不少坑。这里把最常见的几个问题和解决方案整理出来，希望能帮你绕开弯路。 ### 6.1 AI不遵守规则或“忘记”规则 这是最令人沮丧的问题。你明明在规则库里写了“禁止使用`any`”，AI转头就给你生成了一段充满`any`的代码。通常原因和解决方案如下： | 问题现象 | 可能原因 | 解决方案 | | :--- | :--- | :--- | | AI完全忽略规则，仿佛没读过 | 1. Prompt指令不清晰。<br>2. 规则库URL在CLAUDE.md中拼写错误。<br>3. AI上下文过长，规则信息被“挤”出去了。 | 1. 在Prompt中强化指令：“在编写**每一行**代码前，都必须**首先**参考规则库。”<br>2. 仔细检查CLAUDE.md中的链接。<br>3. 对于超长会话，尝试开启AI的“记忆”或“核心指令”功能（如Cursor的Composer指令），或将最关键规则精简后放在MASTER_RULES.md最前面。 | | AI遵守了部分规则，但违反了其他 | 规则之间存在隐含冲突，或某条规则表述模糊，AI优先级判断失误。 | 1. 检查规则一致性。在MASTER_RULES.md中明确规则优先级（如“安全规则 > 性能规则 > 代码风格规则”）。<br>2. 将模糊规则具体化。把“写好错误处理”改为“在所有async函数中使用try-catch，并在catch块中至少记录错误日志和返回用户友好的错误信息”。 | | 在新会话中，AI需要重新“学习”规则 | 每次新开聊天窗口，AI的上下文都是空的。 | 建立项目启动清单：将“向AI提供CLAUDE.md内容”作为项目初始化固定步骤。一些编辑器插件（如Cursor的Project Index）可以自动将项目文件纳入AI上下文，善用此功能。 | 我的经验是，**一致性比复杂性更重要**。开始时，规则库可以很小，只有5-10条你最核心、最不能忍的规则。确保AI在10个项目里都能100%遵守这10条，远比有100条规则但遵守率50%要好。随着你和AI磨合得越来越好，再逐步增加规则。 ### 6.2 规则泛滥与维护负担 另一个常见陷阱是，热情高涨地记录了每一个小问题，导致`LESSONS_LEARNED.md`迅速膨胀，同步审核变成一项繁重任务，最终系统被弃用。 **应对策略：** 1. **设置高同步门槛**：在`RULE_QUALITY_CHECKLIST.md`中严格定义“通用性”。我个人的标准是：这个问题是否会在**不同技术栈**的至少两个项目中遇到？如果答案是肯定的，它才值得进入中央库。 2. **建立分类和标签系统**：在`by-category/`下建立清晰的分类，如`frontend-performance.md`, `backend-security.md`, `devops-pipeline.md`等。这有助于快速定位和避免重复。可以为规则添加标签，如 `#react`, `#security`, `#performance`，方便后期检索。 3. **定期归档与清理**：每个项目完结后，将`LESSONS_LEARNED.md`中未同步的条目移动到一个`archive/`目录或标记为“已处理-无需同步”。保持活动项目的学习记录简洁。 4. **利用AI进行初步筛选**：在Prompt中强化AI的初审责任。例如：“在询问是否记录前，请先根据你的判断，初步评估此问题的通用性。如果它明显是项目特定配置错误（如写死的本地IP），请提示我‘此问题似乎为项目特定配置，可能无需记录’，并询问是否继续。” ### 6.3 团队协作中的规则冲突 当你把规则库推广到团队时，可能会遇到不同成员编码风格或技术偏好不同的问题。比如，你认为“函数组件必须用React Hooks”，而队友认为“类组件在某些场景更清晰”。 **解决之道在于将规则分层：** 1. **团队级规则（强制）**：放在团队共享的规则库中，涉及安全、稳定性、基础代码风格（如命名规范、目录结构）等底线问题。这些需要团队讨论达成共识。 2. **项目级规则（强制）**：在项目的`CLAUDE.md`中定义，针对该项目技术栈和架构的特定约束（如“本项目使用Redux Toolkit，禁止直接使用原生Redux”）。 3. **个人级规则（推荐）**：在你的个人规则库分支中，存放你个人的偏好（如“我喜欢将工具函数放在`utils/`目录而非`lib/`”）。这些规则只在你个人开发时生效，不影响团队。 关键在于沟通。规则库应该是团队技术讨论的产出，而不是某个人的独裁指令。定期举行简短的规则评审会，讨论有争议的新规则提案，能让规则库更具生命力和团队认同感。 ## 7. 超越Bug记录：规则库的扩展应用场景 这套系统的潜力远不止于记录bug。一旦你习惯了这种“经验即规则”的思维模式，就可以把它应用到开发流程的方方面面。 **场景一：架构决策与模式库** 在`by-stack/nextjs.md`里，不仅可以放“避坑指南”，还可以放“最佳实践模式”。例如： - **“数据获取模式：SWR + 服务层”**：详细说明为何选择SWR而非React Query，服务层如何抽象API调用，并提供标准的`useUser`, `useProducts`自定义hook示例。 - **“认证中间件标准实现”**：给出一个经过验证的、包含错误处理和日志的Next.js Auth.js配置模板。 当启动一个新Next.js项目时，AI不仅能避免错误，还能直接帮你搭建起一个符合你团队最佳实践的脚手架。 **场景二：代码审查清单** 将常见的代码审查要点转化为规则。例如，创建一条“Pull Request提交前自查”规则，要求AI在完成一个功能模块后，自动对照清单检查： - [ ] 是否还有`console.log`？ - [ ] TypeScript类型定义是否完整且准确？ - [ ] 新增的依赖是否必要？版本是否锁定？ - [ ] 代码中是否有硬编码的配置值？ 这相当于让AI扮演了第一轮代码审查员的角色。 **场景三： onboarding 新成员或新AI模型** 当有新同事加入，或者你尝试一个新的AI编码模型（比如从Claude换到DeepSeek Coder），这个规则库就是最完美的培训材料。你可以直接告诉新成员或新AI：“这是我的编码规则，请先阅读并理解，我们的项目都遵循这些规范。”这能极大缩短磨合期，确保输出代码质量的一致性。 **场景四：个人技能增长地图** 回过头看你的规则库，`by-stack/`目录下的文件列表，就是你重点投入的技术栈。`by-category/`下的问题分布（比如是“网络错误”多还是“状态管理”多），清晰地反映了你知识体系的强项和薄弱环节。这为你规划学习路径提供了数据支持。 说到底，Vibe Coding Rules项目不仅仅是一个工具，它更是一种**将隐性经验显性化、将个人知识资产化**的思维方式。它强迫你从“解决问题”的层面，上升到“总结模式”和“预防问题”的层面。坚持使用几个月后，你不仅会得到一个越来越聪明的AI编程伙伴，更会收获一个脉络清晰、不断生长的个人技术知识体系。这或许才是它带来的最大价值。