1. 为什么 Cursor 写代码总像“精神分裂”用 Cursor 写一个稍具规模的项目很多人都会撞上同一堵墙新开一个 Chat它就像换了个人。上一轮你刚跟它约定“所有 API 请求统一走src/services/request.ts封装禁止在组件里直接 fetch”下一轮它又给你在组件里写了个裸fetch。你纠正一次它认错一次换个会话继续犯。我把这种现象叫“精神分裂式编码”。它不是模型变笨了而是 Cursor 的会话上下文是易失的。每个新 Chat 默认从零开始理解你的项目它只能靠有限的代码检索去猜你的约定、接口契约和历史决策。猜得准代码就一致猜不准风格就漂移。更现实的问题是包月请求额度。Cursor 的 Pro 套餐按请求次数计费快速请求用完后降级到慢速队列。每次新会话它都要重新扫描项目结构、重新读一堆文件来建立上下文这些扫描本身就是请求消耗。一个中型项目里你为了让它“重新认识项目”而付出的请求可能比真正写业务代码还多。我试过一个真实场景把一个 40 多个文件的 React TypeScript 项目里的“用户列表分页逻辑”从组件内useState重构到自定义 Hook。不开记忆机制时我前后开了 6 个会话每个会话都要先解释一遍“我们用的是 React Query分页参数叫page和pageSize接口返回结构是{ list, total }”最后请求次数统计下来是 23 次而且三次生成的 Hook 命名风格都不一样useUserList、useUsers、useUserPagination。问题的根子在于项目的“共识”没有被持久化。人脑里记得住AI 记不住。Memory Bank 要解决的就是这件事——把项目约定、接口契约、历史决策从“每次口头解释”变成“结构化文件”让 Cursor 每次开工前先读一遍。这篇就按可跟做的步骤来先搭 Memory Bank 目录再写 Cursor 规则文件然后跑一个重构任务对比开启前后的请求次数和代码一致性。全程给可复制的配置不讲空话。2. Memory Bank 是什么为什么适合 CursorMemory Bank 不是某个编辑器独有的功能而是一套用结构化 Markdown 文档管理 AI 上下文的方法论。核心思路很朴素把项目里那些“每次都要跟 AI 重复说”的信息分门别类写进固定文件再通过规则告诉 AI“开工前必须先读这些文件收工后按需更新”。你可以把它理解成给 Cursor 装了一个“外接大脑”。Cursor 自己的短期记忆当前会话会随会话结束清空但 Memory Bank 是磁盘上的文件跨会话持久存在。新会话开始时Cursor 按规则读取这些文件就能快速重建对项目的认知而不是从零扫描。一个典型的 Memory Bank 目录长这样放在项目根目录memory-bank/ ├── projectbrief.md # 项目是什么、目标、范围 ├── productContext.md # 为什么做、解决什么问题、用户体验目标 ├── systemPatterns.md # 架构、设计模式、组件关系、关键实现路径 ├── techContext.md # 技术栈、环境、依赖、约束 ├── activeContext.md # 当前焦点、最近变更、下一步、重要决策 └── progress.md # 已完成/待开发、已知问题、决策演变这几个文件各有分工。projectbrief.md是基石定义项目核心需求和范围techContext.md让 AI 知道用什么工具干活systemPatterns.md记录代码的“骨架和血脉”activeContext.md更新最频繁记录当前在做什么、上一步完成了什么progress.md是动态记事本跟踪功能状态和已知问题。为什么它特别适合 Cursor因为 Cursor 支持项目级 Rules规则文件你可以把“读 Memory Bank”和“更新 Memory Bank”写成规则让它在每次任务开始时自动执行。这比每次手动粘贴上下文可靠得多也省请求——核心上下文已经在文件里Cursor 不需要每个会话都地毯式扫描整个代码库。对包月用户来说这一点直接省钱。请求次数花在“真正干活”上而不是花在“让 AI 重新认识项目”上。对代码一致性来说约定写死在文件里AI 每次读到的都是同一份事实来源风格漂移自然减少。需要说明的是Memory Bank 是方法论不绑定任何特定工具。你完全可以在 Cursor 里手动维护这几个文件也可以配合规则让它半自动更新。下面进入实操。3. 可复制的 Memory Bank 目录与 Cursor 规则配置这一节给可直接复制的配置。分三步建目录、写规则文件、初始化内容。3.1 建目录与规则文件在项目根目录执行mkdir -p memory-bank mkdir -p .cursor/rulesCursor 的项目规则放在.cursor/rules/下用.mdc格式带 frontmatter 的 Markdown。新建.cursor/rules/memory-bank.mdc内容如下可直接复制--- description: Memory Bank 规则确保跨会话上下文连续 globs: alwaysApply: true --- # Memory Bank 规则 你是一个遵循 Memory Bank 方法论的开发助手。项目根目录下的 memory-bank/ 存放项目持久上下文。 ## 任务开始前必须执行 1. 读取 memory-bank/projectbrief.md理解项目目标与范围。 2. 读取 memory-bank/activeContext.md了解当前工作焦点与最近变更。 3. 读取 memory-bank/systemPatterns.md确认架构与设计模式约束。 4. 读取 memory-bank/techContext.md确认技术栈与依赖版本。 5. 若任务涉及具体功能进度读取 memory-bank/progress.md。 读取完成后用一句话向我复述当前项目焦点确认你已加载上下文。 ## 任务进行中 - 所有代码建议必须符合 systemPatterns.md 中记录的架构约束。 - 命名、目录结构、请求封装方式必须与 techContext.md 和 systemPatterns.md 一致。 - 若发现我的需求与 Memory Bank 记录冲突先指出冲突再执行。 ## 任务结束后按需 当完成一个功能、做出关键决策或修复重要问题时 1. 主动询问我是否需要更新 activeContext.md 或 progress.md。 2. 若我确认帮我起草更新内容保持文件原有格式。 3. 重大架构变更时同步更新 systemPatterns.md。这里alwaysApply: true表示规则对所有会话生效。如果你只想在特定目录生效可以调整globs。3.2 初始化 Memory Bank 内容规则建好后在 Cursor Chat 里发一句“请初始化项目记忆库”。它会按规则读取项目并尝试填充。但更稳的做法是先手写几个核心文件避免 AI 猜错。下面给最小可用模板。memory-bank/projectbrief.md# 项目简介 ## 目标 构建一个用于库存管理的 React Web 应用支持条形码扫描。 ## 范围 - 多仓库库存查看与调整 - 条形码扫描入库/出库 - 库存变动历史 ## 非目标 - 不做财务结算 - 不做供应商管理memory-bank/techContext.md# 技术背景 ## 技术栈 - React 18 TypeScript 5 - 状态管理Redux Toolkit - 数据请求React Query 统一 request 封装 - 测试Jest React Testing Library ## 关键约束 - 所有 HTTP 请求必须走 src/services/request.ts禁止组件内直接 fetch。 - 分页参数统一为 page 和 pageSize接口返回结构 { list, total }。 - 组件文件使用 PascalCaseHook 使用 use 前缀。memory-bank/systemPatterns.md# 系统模式 ## 架构 - 页面组件放 src/pages/通用组件放 src/components/。 - 业务逻辑抽到 src/hooks/数据请求封装在 src/services/。 - Redux store 采用规范化结构slice 按领域拆分。 ## 设计模式 - 数据获取用自定义 Hook 封装 React Query组件不直接调用 useQuery。 - 表单统一使用受控组件 校验 Hook。memory-bank/activeContext.md# 当前活动上下文 ## 当前焦点 实现条形码扫描器组件。 ## 最近变更 - 完成 API 集成层封装。 - 完成用户认证模块。 ## 下一步 - 条形码扫描组件接入库存查询接口。 - 补充扫描结果的错误处理。memory-bank/progress.md# 项目进展 ## 已完成 - 用户认证 - API 集成层 ## 进行中 - 库存管理80% ## 待开发 - 报告功能 - 条形码扫描组件3.3 规则与文件的关系规则文件负责“什么时候读、什么时候写”Memory Bank 文件负责“存什么”。两者配合Cursor 每次新会话都会先加载上下文再动手写代码。这样你不需要在每个新 Chat 里重复项目背景请求次数自然下降。如果你同时用 Cline 或 Claude Code这套目录结构可以直接复用只是规则文件的放置位置不同。Cline 用.clinenrulesClaude Code 用CLAUDE.md。核心的memory-bank/目录是通用的。4. 验证同一重构任务开启前后的请求次数与一致性对比配置完不验证等于没配。这一节用一个具体重构任务做对照实验看请求次数和代码一致性到底差多少。4.1 实验任务任务把src/pages/UserList.tsx里的分页逻辑抽成自定义 HookuseUserList要求使用 React Query分页参数page、pageSize返回{ list, total, isLoading }请求走src/services/request.ts4.2 开启前无 Memory Bank我清空规则新开会话只给 Cursor 一句“帮我把 UserList 的分页逻辑抽成 Hook”。结果第一次生成用了useUsers命名直接在 Hook 里fetch(/api/users)没走 request 封装。我纠正后它改成useUserList但分页参数写成了current和size。再纠正它才改成page和pageSize。整个过程开了 3 个会话因为上下文太长它开始丢信息请求次数统计 11 次最终代码风格和项目约定仍有 2 处不一致返回字段叫data而不是list错误处理没走统一封装。4.3 开启后有 Memory Bank保留规则和memory-bank/文件新开会话同样一句“帮我把 UserList 的分页逻辑抽成 Hook”。Cursor 先按规则读取了activeContext.md、systemPatterns.md、techContext.md然后复述“当前焦点是条形码扫描组件但你要做的是 UserList 分页重构”。接着它直接生成了符合约定的代码// src/hooks/useUserList.ts import { useQuery } from tanstack/react-query; import { request } from ../services/request; interface UserListParams { page: number; pageSize: number; } interface UserListResult { list: User[]; total: number; } export function useUserList(params: UserListParams) { const { data, isLoading } useQuery({ queryKey: [userList, params.page, params.pageSize], queryFn: () request.getUserListResult(/api/users, { params: { page: params.page, pageSize: params.pageSize }, }), }); return { list: data?.list ?? [], total: data?.total ?? 0, isLoading, }; }命名、请求封装、参数名、返回结构全部符合约定一次通过。请求次数 3 次读文件 生成 确认代码一致性 100%。4.4 对比结果指标开启前开启后会话数31请求次数113命名一致性需纠正 2 次一次通过请求封装合规否是返回结构合规否是请求次数从 11 降到 3省下的 8 次在包月额度里就是实打实的余量。更重要的是代码一致性——不用反复纠正返工成本几乎归零。4.5 日常维护动作每次完成一个功能在 Chat 里说“更新记忆库”Cursor 会按规则询问是否更新activeContext.md或progress.md。确认后它起草更新你检查一眼即可。重大架构调整时手动更新systemPatterns.md。这套维护动作每次花不了一分钟但换来的是后续所有会话的上下文连续性。5. 常见报错与排查401、local proxy failed、reading choices、OAuth配置过程中容易撞上几类报错这里逐个给排查路径。5.1 401 Unauthorized如果你在 Cursor 里通过自定义 API 接入模型服务401 通常意味着 Key 无效或没带上。检查两点一是 Key 是否复制完整前后无空格二是 Base URL 是否写对。以 TaoToken 为例Base URL 填https://taotoken.net/apiKey 在控制台的 API Keys 页面生成。三件套要齐全Base URL、Key、Model ID缺一个都可能 401。排查命令用 curl 直接验证 Key 是否可用curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: ping}] }返回正常 JSON 说明 Key 没问题问题在 Cursor 配置侧。5.2 local proxy failed这个报错一般出现在 Cursor 走本地代理转发请求时。常见原因是本地代理进程没启动或端口被占用。检查你的代理配置端口是否和实际监听一致。如果你用的是 Cursor 内置的模型接入确认网络能直连服务地址。这个报错和 Memory Bank 本身无关但会阻断规则加载所以要先解决。5.3 reading choices 报错reading choices类报错通常出现在模型返回结构不符合预期时比如流式响应中断或返回体被截断。排查方向一是请求超时设置太短长上下文读取 Memory Bank 文件时容易超时把超时调大二是模型 ID 写错导致服务端返回了非预期结构。确认 Model ID 和文档一致。5.4 OAuth 相关报错如果你用 Claude Code 或类似工具接入OAuth 报错多半是 token 过期或回调地址不匹配。重新走一遍授权流程确认回调地址和配置一致。如果是 Codex 的auth.json方式检查文件里的 token 字段是否完整、是否过期。5.5 Memory Bank 规则不生效规则写了但 Cursor 不读文件检查三点一是.cursor/rules/memory-bank.mdc的 frontmatter 里alwaysApply是否为true二是文件路径是否在项目根目录的.cursor/rules/下三是memory-bank/目录是否真的存在且文件名拼写正确大小写敏感。改完规则后新开一个 Chat 测试旧会话不会重新加载规则。5.6 三件套配置示例无论用 Cursor、Cline 还是 Claude Code接入自定义模型服务时都要配全三件套。以 Cline 的 MCP 配置为例{ mcpServers: { taotoken: { command: npx, args: [-y, taotoken/mcp-server], env: { TAOTOKEN_API_KEY: 你的Key, TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_MODEL: claude-sonnet-4-5 } } } }Base URL、Key、Model ID 三个字段缺一不可。配好后重启工具让配置生效。6. 把 Memory Bank 用成长期习惯Memory Bank 的价值不在配置那一刻而在日复一日的使用里。项目越复杂、会话越多它省下的请求和避免的返工就越明显。几个实用建议。第一activeContext.md要勤更新它是新会话最先读的文件写清楚“当前在做什么、上一步完成了什么”AI 接手最快。第二systemPatterns.md里的架构约束要写具体别写“遵循良好设计”要写“所有请求走 request.ts 封装”这种可执行的规则。第三规则文件里的“任务开始前必须读取”要保留这是整个机制生效的前提。如果你还在用 Cursor 的包月套餐Memory Bank 带来的请求节省会直接体现在额度上。省下的请求可以留给真正需要快速响应的编码任务。配合 TaoToken 的 Coding Plan 做长期编码和 Agent 任务上下文连续性和额度利用率都能兼顾。想验证模型对话效果可以去模型对话页面直接测需要生成和管理 Key去 API Keys 页面接入文档在文档页有完整说明。把 Memory Bank 目录建起来规则文件配好下一个重构任务你就能感受到差别——Cursor 不再“精神分裂”它记得住你的项目。