企业官网建设流程全解析

1. 项目概述：为你的AI编程伙伴装上“持久化大脑”

如果你和我一样，深度依赖Cursor这类AI编程助手，那你一定对它的“健忘症”深有体会。我们花半小时和它讨论项目架构，详细解释了业务逻辑、技术选型和代码规范，结果第二天打开新会话，它又变回了一张白纸，一切都要从头再来。这种割裂感严重拖慢了开发节奏，也让“让AI理解我的项目”这件事变得异常低效。

cursor-bank这个项目，就是为了根治这个痛点而生的。你可以把它理解为给Cursor（或其他基于类似原理的AI助手）安装的一个“外置持久化内存”。它的核心思想非常巧妙：既然AI的会话记忆是临时的，那我们就把所有重要的项目上下文——架构决策、代码规范、待办事项、API设计——结构化地记录下来，形成一个不断更新的“记忆库”。在每次新的会话开始时，自动将这个记忆库作为背景知识喂给AI，让它瞬间“回忆”起项目的全貌。

这不仅仅是简单的文档记录。cursor-bank通过一套与AI助手深度集成的规则和模板，将记忆的创建、更新和调用流程化。它让你和AI的协作从“一次性问答”升级为“持续性的结对编程”。经过一段时间的使用，我发现它彻底改变了我的开发工作流：项目启动更快，上下文切换成本几乎为零，AI生成的代码一致性也大幅提升。接下来，我将详细拆解它的设计思路、具体用法以及我在实战中积累的一系列技巧和避坑指南。

2. 核心设计思路：如何为AI构建可用的“记忆”

在深入实操之前，理解cursor-bank的设计哲学至关重要。这能帮助你在使用中更好地发挥其威力，甚至根据自己团队的需求进行定制。

2.1 解决的根本问题：LLM的上下文窗口与记忆隔离

大型语言模型（LLM）如GPT-4，其“记忆”完全依赖于我们提供的“上下文窗口”。你可以把这个窗口想象成AI工作时的“短期记忆白板”。在一次会话中，你写在白板上的所有内容（对话历史、提供的代码文件）它都能看到并据此回应。但一旦会话结束，白板就被擦干净了。新会话开始，就是一块全新的白板。

cursor-bank的策略是：我们不试图去扩大AI本身的白板（那受限于模型和成本），而是为它准备一本随时可以翻阅的“项目百科全书”。这本百科全书的内容，由你和AI在协作过程中共同撰写和维护。每次新会话，第一件事就是把这本书的目录和核心章节递给AI。

2.2 记忆的结构化：从杂乱对话到有序知识库

原始的对话记录是线性的、冗长的、充满噪音的。直接将其作为记忆喂给AI，效率低下且会浪费宝贵的上下文令牌（Token）。cursor-bank的核心贡献在于定义了一套结构化的记忆模板，将知识分门别类：

1. 项目概览与目标：用一两句话定义项目是什么，解决什么问题。
2. 技术栈与架构：记录使用的框架、库、数据库以及整体的架构图（以文本或注释形式）。
3. 代码规范与约定：命名规范、目录结构、特定的代码风格（如React组件如何组织、API响应格式）。
4. 当前工作上下文：正在实施的功能模块、最近修改的文件、待解决的Bug。
5. 项目特定知识：业务领域的专有名词、核心算法逻辑、第三方服务的集成方式。

通过这种结构化，AI在需要回忆“我们用什么数据库”时，可以直接定位到“技术栈”部分，而不是在几千行的对话历史里大海捞针。

2.3 与Cursor的深度集成：.cursor/rules目录的奥秘

cursor-bank并非一个独立运行的应用，它的威力完全体现在与Cursor编辑器的深度集成上。其关键就在于项目根目录下的.cursor/rules目录。这个目录是Cursor的“智能规则”存放地，里面的文件会直接影响Cursor Agent（那个和你对话的AI）的行为。

cursor-bank的初始化过程，本质上是向你的项目中注入了一套预定义的“规则”。这些规则做了以下几件事：

• 定义记忆的存储格式和位置：告诉AI，记忆库文件（memory-bank.md等）放在哪里，应该按照什么结构去读写。
• 创建交互指令：定义了像PLAN、ACT、update memory bank这样的魔法命令。当你输入这些命令时，Cursor Agent会触发对应的规则逻辑。
• 设置上下文加载策略：可能通过规则配置，让Cursor在启动新Agent时，自动将memory-bank目录下的内容作为初始上下文加载。

这种集成方式非常优雅，它没有修改Cursor本体，而是利用了其开放的、可配置的规则系统，实现了功能增强。这也是为什么它看起来如此“无缝”。

3. 详细安装与初始化指南

了解了原理，我们开始动手。安装cursor-bank极其简单，但初始化过程中的一些选择，会影响你后续的使用体验。

3.1 安装方式对比与选择

项目推荐了三种方式，我逐一分析其适用场景：

方式一：使用npx（推荐给绝大多数用户）

# 在你的项目根目录下执行 npx cursor-bank init

这是最干净、最推荐的方式。npx会临时下载并运行cursor-bank包，执行初始化脚本后即完成，不会在你的系统或项目里永久安装任何额外的全局依赖。它自动完成两件事：

1. 创建.cursor/rules目录，并放入定义好的规则文件。
2. 在项目根目录创建memory-bank文件夹，里面包含记忆库的模板文件（如memory-bank.md）。

注意：执行此命令前，请确保你位于正确的项目目录下。你可以通过pwd(Unix) 或cd(Windows) 命令确认当前路径。对于使用 Git 的项目，这通常就是包含.git文件夹的目录。

方式二：全局安装

npm install -g cursor-bank # 然后在项目目录中 cursor-bank init

这种方式会将cursor-bank作为一个命令行工具安装到你的电脑上。适合那些需要在多个不同项目、且网络环境不便频繁使用npx下载的开发者。但代价是增加了一个全局依赖。对于大多数单项目或偶尔使用的场景，方式一更优。

方式三：手动下载文件直接访问项目的GitHub仓库，手动下载.cursor/rules目录，然后拷贝到你的项目里。这种方式给了你最大的控制权，你可以仔细查看甚至修改这些规则文件。适合高级用户，或者在公司内网等无法直接执行npx命令的环境。

我的选择与建议：对于新手和绝大多数项目，无脑选择方式一。它简单、隔离性好，不会污染环境。只有当你需要频繁在不同离线环境初始化，或者需要定制化规则时，才考虑方式二或三。

3.2 初始化流程详解：新旧项目的不同策略

安装完成，文件就位，接下来是关键的一步：引导AI初始化记忆库。官方指南区分了现有项目和新项目，这里我结合自己的经验详细说明。

对于现有项目（已有代码库）：

1. 在Cursor中，打开你的项目。
2. 在Chat面板中，直接对Cursor Agent说：“initialize memory bank”。
3. AI会识别到已存在的memory-bank目录和规则，并开始工作。它通常会做以下几件事：
   • 扫描项目根目录，尝试理解项目结构。
   • 读取主要的配置文件（如package.json,README.md,docker-compose.yml）。
   • 在memory-bank.md中生成一个初步的项目框架，包括它推断出的技术栈、目录结构等。
   • 可能会向你提问，以确认或补充一些信息（例如：“我注意到你使用了 Express 和 PostgreSQL，这个项目的核心功能是什么？”）。

对于全新的项目（从零开始）： 这是最能体现cursor-bank价值的场景。我推荐的黄金工作流如下：

1. 规划阶段：在Chat中输入PLAN命令。这会触发“计划模式”。在此模式下，你可以用自然语言详细描述你想构建的东西。

   PLAN 我想构建一个个人博客系统。前端使用 Next.js 14 (App Router)，Tailwind CSS 进行样式设计。后端 API 使用 Next.js 的 Route Handlers 实现，无需单独后端服务。数据库使用 Supabase (PostgreSQL)。需要实现的功能包括：用户认证（使用 Supabase Auth）、文章的 Markdown 编写与渲染、文章分类标签、简单的评论功能。代码风格使用 ESLint 和 Prettier 进行统一，组件采用原子设计理念进行组织。

2. AI生成计划：Cursor Agent 会根据你的描述，输出一个详细的开发计划，可能包括推荐的文件夹结构、需要安装的依赖、第一步要创建的文件等。
3. 批准并进入实施：你审查计划后，输入ACT命令。AI会切换到“实施模式”，开始根据计划生成具体的代码文件。
4. 初始化记忆库：在AI生成了一部分基础框架（比如创建了app/,components/,lib/目录和基础配置文件）后，立即输入：“initialize memory bank”。
5. 记忆库的持续生长：此时，AI会将之前PLAN阶段讨论的所有目标、技术决策，以及刚刚创建的初始项目结构，全部记录到memory-bank中。此后，每一个重要的架构决策、新功能的讨论，都可以通过update memory bank命令来同步。

实操心得：对于新项目，不要在项目完全空白时初始化记忆库，因为那时AI没有足够的上下文来生成有意义的记忆。最好在PLAN讨论完毕，并且AI已经创建了项目骨架（哪怕只有几个文件夹和配置文件）之后再进行。这样记忆库的“第一版”就是充实且准确的。

4. 核心工作流与命令实战

cursor-bank的精髓在于一套与AI协同的工作流。它通过几个简单的命令，将“规划-实施-记录”的循环固化下来。

4.1PLAN与ACT：将想法转化为可执行蓝图

这对命令构成了项目开发的战略循环。

• PLAN：这不是一个简单的“我们来聊聊”。当你在Chat中输入PLAN并回车，你实际上是激活了一个特定的规则。AI会进入一种“架构师”或“产品经理”模式。在这个模式下，你应该提供高层次、目标导向的描述。

  • 正确示例：“PLAN- 我们需要在用户个人中心添加一个‘我的收藏’页面，用于展示用户收藏的文章列表。页面需要分页，每篇文章要显示标题、摘要、收藏时间和一个取消收藏的按钮。后端需要新增一个GET /api/user/favorites接口，关联users和articles表。”
  • 错误示例：直接开始讨论具体的代码实现细节（比如“这个按钮的 onClick 事件该怎么写？”）。这属于ACT阶段的事情。
  • AI的典型回应会包括：功能描述、API端点设计、数据库变更（如果需要）、前端组件结构、可能的风险点以及实施步骤列表。

• ACT：当你对AI生成的计划感到满意时，输入ACT。这标志着从“设计阶段”正式进入“编码阶段”。AI会基于刚刚制定的计划，开始生成具体的代码片段、创建新文件、修改现有文件。

  • 在ACT模式下，你可以提出更具体的指令，比如：“现在，请实现第一步，创建app/api/user/favorites/route.ts文件。”
  • AI会将其行动和生成的代码，视为对PLAN的具体落实。

为什么这个循环重要？它强制你和AI进行“先设计，后编码”的 disciplined（有纪律的）开发。这极大地减少了返工，并且为memory-bank提供了清晰、阶段性的记录素材。每一次PLAN的讨论，都是记忆库需要捕获的重要决策。

4.2update memory bank：让记忆与项目同步进化

这是整个工作流中最常用、也最关键的命令。项目不是静态的，记忆库也必须随之更新。

• 何时使用？

  1. 完成一个功能模块后：当你们通过ACT模式实现了一个PLAN中的功能（比如“我的收藏”页面），立即使用此命令。
  2. 做出重要架构变更后：例如，决定从 REST API 迁移到 GraphQL，或者引入一个新的状态管理库。
  3. 遇到并解决了一个棘手的Bug后：将问题的现象、排查思路、根本原因和解决方案记录到记忆库的“常见问题”或“技术债务”部分，造福未来的自己和其他协作者。
  4. 定期同步：在一天工作结束或一个开发阶段完结时，可以命令AI：“总结我们今天关于用户认证模块的所有讨论和修改，并update memory bank。”

• 命令如何工作？当你输入update memory bank，AI会根据.cursor/rules中的定义，执行以下操作：

  1. 回顾当前会话中（或根据规则指定的范围）所有与项目相关的讨论和代码变更。
  2. 提取关键信息：新的设计决策、实现的函数、更新的接口、解决的难题。
  3. 按照memory-bank.md的模板结构，将这些信息归类、整合、润色，然后写入或更新对应的文件。
  4. 它可能会向你确认某些信息，或者让你审核它生成的更新内容。

• 一个实战例子：

  （假设我们刚刚和AI一起修复了一个关于图片上传时内存泄漏的Bug） 我：太好了，这个内存泄漏问题终于解决了。请更新记忆库，记录下这个问题的根本原因和解决方案。 AI：好的，正在更新记忆库... （AI开始操作，然后可能在记忆库的“已知问题与解决方案”部分添加了如下内容） ## 已知问题与解决方案 * **问题**：使用 `sharp` 库处理大尺寸图片上传时，未及时调用 `.destroy()` 释放内存，导致服务内存持续增长。 * **根因**：`sharp` 实例持有图片缓冲区引用，Node.js 垃圾回收器无法自动回收。 * **解决方案**：在所有 `sharp` 处理流程的最后，显式调用 `await sharpInstance.destroy()`。已在 `/lib/image-processor.ts` 的 `processImage` 函数中修复。 * **预防措施**：未来使用任何需要手动管理资源的库（如数据库连接、文件句柄），必须在 finally 块或生命周期结束时确保释放。

  这样，三个月后当你或你的同事再次遇到类似问题，记忆库就能提供直接的指引。

4.3 记忆库的文件结构与维护

初始化后，你的项目里会多出一个memory-bank目录。理解里面每个文件的作用，能帮助你更好地维护它。

通常，核心文件是memory-bank.md。一个组织良好的记忆库可能包含以下部分：

# 项目记忆库 ## 项目概述 * **目标**：构建一个现代化的个人博客平台... * **核心用户**：技术写作者、独立开发者... ## 技术栈 * **前端**：Next.js 14, React, Tailwind CSS, Zustand (状态管理) * **后端**：Next.js Route Handlers, Supabase (PostgreSQL + Auth) * **工具**：TypeScript, ESLint, Prettier, Jest, React Testing Library ## 架构决策 * **为什么选择 Supabase 而非独立后端？**：项目初期需要快速迭代，Supabase 提供了开箱即用的 Auth、Database 和 Storage，极大减少了运维成本。详见 [决策记录#1](./adr/001-supabase-choice.md)。 * **采用 App Router 而非 Pages Router**：为了利用 React Server Components 和更简单的数据获取模式，以提升首屏性能。 ## 目录结构说明

project-root/ ├── app/ # Next.js App Router │ ├── api/ # API routes │ ├── (auth)/ # 认证相关路由组 │ └── blog/ # 博客文章路由 ├── components/ # 可复用组件 │ ├── ui/ # 基础UI组件 (按钮、输入框等) │ └── blog/ # 博客相关组件 ├── lib/ # 工具函数、数据库客户端等 └── memory-bank/ # 本项目记忆库

## 当前工作上下文 (最近更新：2023-10-27) * **正在开发**：用户个人资料编辑页面。 * **近期修改**：重构了 `lib/db.ts` 中的数据库连接池配置，以解决高并发下的连接超时问题。 * **待办事项**： * [ ] 为文章评论功能添加敏感词过滤。 * [ ] 优化博客列表页的图片懒加载。 ## 代码规范 * **组件命名**：使用 PascalCase，如 `UserProfileCard`。 * **函数命名**：使用 camelCase，动词开头，如 `fetchUserData`。 * **API 响应格式**：统一使用 `{ success: boolean, data?: any, error?: string }`。 * ... ## 已知问题与解决方案 （如前文所述的内存泄漏问题）

你可以根据项目复杂度，将不同部分拆分成独立的文件，比如tech-stack.md、decisions.md、todos.md，然后在主文件中引用。关键是保持结构清晰，方便AI和人类快速检索。

5. 高级技巧与实战心得

经过多个项目的实战，我总结出一些能让你事半功倍的技巧，以及必须绕开的“坑”。

5.1 如何高效利用记忆库进行上下文切换

场景：你正在开发A功能（用户认证），突然需要紧急修复B功能（文章搜索）的一个Bug。传统模式下，你需要花时间向AI重新解释搜索功能是怎么工作的。

cursor-bank解法：

1. 在开始修复B功能前，先对AI说：“让我们先回顾一下文章搜索模块的相关背景。请查看记忆库中关于‘搜索’的部分。”
2. AI会去读取memory-bank.md中关于搜索的实现逻辑、使用的库（比如Elasticsearch的配置）、API接口等。
3. 然后你可以直接切入正题：“现在，搜索API在输入中文长句时会超时，我们来看看日志...”
4. 修复完成后，立即update memory bank，记录下这个Bug和修复方案。

心得：把记忆库当作你和AI之间的“交接班日志”。每次上下文切换，先让AI“阅读日志”了解情况，能节省大量重复沟通的成本。

5.2 记忆库的“保鲜”策略：避免信息过时或冗余

记忆库不是只增不减的日志，它需要维护。

• 定期回顾与清理：每周或每两周，花10分钟和AI一起快速浏览记忆库。可以问AI：“记忆库中是否有已经过时或已完成的信息？例如，‘待办事项’里已经完成的任务，或者被推翻的旧架构决策。” 然后一起清理掉。
• 使用“决策记录”：对于重大的、有长期影响的架构选择（比如“为什么我们选MongoDB而不是PostgreSQL”），建议在memory-bank/adr/目录下创建独立的“架构决策记录”文件。这比在主文档里写一大段更清晰，也更容易引用。
• 版本控制的配合：memory-bank目录应该被纳入 Git 版本控制。这样，记忆库的变更历史就和代码的变更历史绑定在一起。你可以看到某个功能开发时，对应的设计决策是如何被记录下来的。

5.3 与团队协作：共享一个“团队大脑”

cursor-bank在团队环境中潜力巨大。想象一下，团队每个成员都在和各自的Cursor AI协作，但大家共享同一份项目记忆库。

• 操作流程：
  1. 将.cursor/rules和memory-bank目录纳入版本控制。
  2. 在团队README或 onboarding 文档中，加入如何使用cursor-bank的简要说明。
  3. 约定团队规范：例如，任何人在完成一个功能分支合并前，需要检查并更新记忆库中相关的部分。
• 带来的好处：
  • 新人快速上手：新成员克隆代码后，让AI“阅读记忆库”，能在几分钟内了解项目全貌、技术栈、当前工作重点和代码规范，远超阅读零散的文档。
  • 知识同步：A成员解决的疑难杂症，通过记忆库能立刻被B成员知晓，避免重复踩坑。
  • 设计一致性：记忆库中记录的架构决策和代码规范，能约束所有AI助手生成代码的风格，保证项目代码的一致性。

5.4 常见问题与排查（踩坑实录）

1. 问题：输入PLAN或ACT后，AI没有特殊反应，就像普通对话一样。

   • 排查：首先检查项目根目录下是否存在.cursor/rules文件夹，以及里面是否有从cursor-bank复制过来的规则文件（.cursor/rules/memory-bank.cursor.md等）。如果没有，说明初始化未成功，重新运行npx cursor-bank init。
   • 确保：你是在Cursor编辑器的Chat面板中，与“Cursor Agent”对话，而不是在普通的编辑器区域。

2. 问题：update memory bank后，记忆库文件内容混乱或格式错误。

   • 原因：AI有时会误解指令，或者记忆库的Markdown模板结构被破坏。
   • 解决：不要完全依赖AI。将记忆库视为一个“由AI辅助维护的文档”。每次更新后，快速浏览一下。如果发现格式问题，可以手动调整，或者更明确地指示AI：“请将关于XXX的更新，以清晰的列表形式，添加到‘技术栈’章节的末尾。”

3. 问题：记忆库文件变得非常庞大，导致每次加载都消耗大量Token。

   • 优化策略：
     • 拆分文件：将“技术栈”、“架构决策”、“代码规范”等相对静态的内容拆分到独立文件（如tech-stack.md），在主文件中用链接引用。AI可以按需读取。
     • 摘要化：对于“当前工作上下文”这类频繁更新的部分，只保留最近1-2周的关键信息。将更早的、已完成的条目归档到另一个文件（如archive/目录下）。
     • 利用Cursor的“引用文件”功能：你可以手动在Chat中通过@符号引用特定的记忆库文件，而不是每次都加载全部。结合清晰的文档结构，可以做到精准加载。

4. 问题：AI在更新记忆库时，遗漏了某些重要对话。

   • 技巧：在重要的设计讨论开始时，可以给对话打上“标签”。例如，你可以说：“【开始讨论：用户支付模块设计】”。在讨论结束时，再说：“【结束讨论】。请将我们刚刚关于支付模块的所有讨论，更新到记忆库的‘架构决策’部分。” 这样能给AI更明确的指令范围。

cursor-bank不是一个安装即忘的工具。它像一棵植物，需要你偶尔的浇灌（使用update命令）和修剪（定期回顾）。当你养成“规划-行动-记录”的肌肉记忆后，你会发现你和AI的协作效率产生了质的飞跃。它不再是一个每次都要从头教起的实习生，而是一个真正拥有项目长期记忆、能和你并肩作战的资深搭档。