三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

AI编程助手“健忘症”终结方案：模块化配置实现上下文持久化

发布时间：2026/8/11 2:12:27 三亩地 编程学习日记
AI编程助手“健忘症”终结方案：模块化配置实现上下文持久化

1. 项目概述：为什么你的AI编程助手总是“健忘”？

每次打开新的对话窗口，都要重新向Claude、ChatGPT或者Cursor解释一遍你的项目结构、编码规范、技术栈偏好，是不是感觉特别心累？我刚开始用这些AI编程助手时，也深受其苦。我明明在十分钟前才告诉它：“我们项目用的是TypeScript，遵循Airbnb代码风格，使用pnpm作为包管理器。”结果，当我新建一个对话，让它帮我写个工具函数时，它又给我生成了一堆CommonJS的require语句，或者用了完全不同的缩进风格。这种“对话失忆症”极大地拖慢了开发效率，也让AI助手的潜力大打折扣。

“Claude Code - 9 Rules”这个方案，正是为了解决这个核心痛点而生的。它不是一个具体的工具或插件，而是一套模块化、可复用的配置思想与实践指南。其核心目标，是让开发者能够像管理项目依赖一样，管理对AI助手的“心智配置”。通过将你的开发习惯、项目约束、技术偏好等固化为一套清晰的“规则”（Rules），并在每次对话开始时“喂”给AI，从而让AI助手能够“长记性”，在同一个项目的不同会话中保持上下文和行为的一致性。

简单来说，它要解决的是AI助手上下文隔离的问题。每个新对话都是一个空白石板，而“9 Rules”就是帮你快速在这块石板上刻下所有必要背景信息的模板。这不仅仅是关于代码风格，它涵盖了从项目架构认知（如“我们使用Clean Architecture”）、到安全红线（如“禁止使用eval”）、再到输出格式要求（如“所有函数必须包含JSDoc注释”）的方方面面。掌握了这套方法，你就能将AI从一个需要反复调教的新手，快速变成一个深刻理解你项目脉络和习惯的“老搭档”。

2. 核心理念与设计思路拆解

2.1 从“临时提示”到“持久化配置”的思维转变

大多数开发者使用AI编程助手的模式是“即问即答”。遇到问题，打开聊天框，输入问题，获得答案。这种模式下的“提示词”（Prompt）是临时、孤立且高度重复的。例如，你可能在十个不同的对话里，输入过十次“请用React函数组件编写，使用TypeScript，不要用any类型”。

“9 Rules”方案倡导的是一种根本性的思维转变：将重复的、基础的、项目级的约束，从临时的对话提示中剥离出来，沉淀为一份独立的、版本可控的配置文件。这份配置就是AI的“岗位说明书”和“项目手册”。

这种转变带来了几个关键优势：

  1. 一致性保障：确保AI在所有对话中的输出都符合同一套标准，避免了不同会话间风格迥异导致的代码混乱。
  2. 效率提升：无需在每次对话开始时都进行冗长的“背景介绍”，直接切入核心问题。对于长期项目，节省的时间是巨大的。
  3. 知识沉淀：这份配置本身成为了项目文档的一部分，新加入项目的开发者（无论是人类还是AI）可以通过阅读它快速了解项目的技术规范和禁忌。
  4. 可复用性：基础规则（如通用代码风格、安全规范）可以提取为模板，在不同项目间复用，实现“一次定义，处处生效”。

2.2 “9 Rules”的模块化设计哲学

为什么是“9”条规则？这个数字并非金科玉律，其精髓在于“模块化”和“关注点分离”。它鼓励你将复杂的约束分解为多个单一职责的、清晰的规则模块。例如，你可以有：

  • 规则1：项目上下文- 描述项目是做什么的，核心业务逻辑是什么。
  • 规则2：技术栈与架构- 说明使用的框架、语言版本、架构模式（如MVC、DDD）。
  • 规则3：代码风格与规范- 链接到ESLint配置、Prettier规则或自定义的命名约定。
  • 规则4：依赖与包管理- 说明使用的包管理器（npm/yarn/pnpm）、以及重要的全局或项目依赖。
  • 规则5：安全与最佳实践- 列出禁止使用的危险函数、必须进行的输入验证等。
  • 规则6：测试要求- 规定测试框架、覆盖率要求、测试文件命名规则。
  • 规则7：API与数据格式- 定义后端API的规范（如RESTful风格）、请求/响应数据的结构。
  • 规则8：提交与部署- 说明Git提交信息格式、CI/CD流程中的关键环节。
  • 规则9：输出格式- 要求AI在输出代码时附带解释、或按照特定结构组织答案。

你可以根据项目实际情况增减、合并规则。关键在于，每一条规则都应该目标明确、表述清晰、可独立验证。例如，“代码风格与规范”这条规则，与其说“请写出整洁的代码”，不如直接提供你的.eslintrc.js文件内容，或者明确列出几条关键规则：“使用2个空格缩进”、“字符串优先使用单引号”、“interface优先于type”。

注意：规则的数量和内容完全由你定义。“9”只是一个启发性的数字，提醒你将配置结构化。一个简单的前端demo项目可能只需要3-4条规则，而一个大型全栈企业应用可能需要15条以上。

2.3 规则的有效性：如何让AI“听懂”并“记住”

设计规则不是写给自己看的，是写给AI模型“理解”并“执行”的。因此，规则的表述方式至关重要。基于我的实战经验，有效的规则通常遵循以下原则：

  1. 指令清晰，避免歧义：使用肯定、明确的语句。例如，“必须使用async/await处理所有异步操作，禁止使用回调函数嵌套。” 比 “建议使用更好的异步处理方式” 有效得多。
  2. 提供正反示例：对于复杂的规范，提供一个简单的正确代码示例和一个错误代码示例，能极大提升AI的理解准确度。例如，在定义组件结构时，可以附上一个标准的React函数组件样板。
  3. 利用AI的“知识”：你可以引用一些公认的规范或工具。例如，“请遵循Airbnb JavaScript Style Guide（https://github.com/airbnb/javascript）”，AI在训练时很可能学习过这份广为人知的指南，理解起来会更准确。
  4. 结构化与格式化：将规则用Markdown的标题、列表、代码块组织起来。清晰的结构能帮助AI更好地解析你的意图。一个杂乱无章的文本段落效果远不如一个层次分明的文档。
  5. 分层次，有优先级：如果规则很多，可以声明哪些是最高优先级的“铁律”（如安全规则），哪些是推荐性的“指南”。这有助于AI在遇到约束冲突时做出权衡。

3. 构建你的专属“9 Rules”配置库

3.1 规则内容的具体编写指南

下面，我将以一个典型的全栈Web项目（Node.js后端 + React TypeScript前端）为例，拆解几条核心规则的编写方法。你可以以此为模板进行修改。

规则模板示例：全栈项目核心规则

# AI编程助手项目配置规则 (Project AI Coding Guidelines) ## 规则1：项目全景与目标 - **项目名称**：E-Commerce Platform API & Admin Dashboard - **核心描述**：这是一个B2C电商平台，包含商品管理、订单处理、用户认证和数据分析仪表盘。你作为编程助手，需要帮助维护和开发此后台系统的前后端代码。 - **核心业务概念**： - `Product`: 商品，有SKU、价格、库存、分类等属性。 - `Order`: 订单，关联用户、商品列表、支付状态、物流信息。 - `User`: 用户，分`Admin`和`Customer`角色。 ## 规则2：技术栈与架构约束 - **后端 (API Server)**: - 运行时: Node.js 18 LTS - 框架: Express.js + TypeScript - 数据库: PostgreSQL (主数据存储)， Redis (缓存与会话) - ORM: Prisma - API风格: RESTful， JSON格式请求/响应 - **关键架构**：采用分层架构。所有请求流程为：`Route -> Controller -> Service -> Repository (Prisma) -> Database`。禁止在Controller中直接编写数据库逻辑。 - **前端 (Admin Dashboard)**: - 框架: React 18 with TypeScript - 构建工具: Vite - 状态管理: Zustand (用于全局状态)， React Query (用于服务器状态) - UI组件库: Ant Design - CSS方案: CSS Modules - **关键架构**：组件按`pages/`, `components/`, `hooks/`, `utils/`, `stores/`组织。页面组件负责路由和布局，展示组件保持纯净。 ## 规则3：代码风格与质量门禁 - **通用风格**：严格遵循项目根目录下的`.eslintrc.js`和`.prettierrc`配置。已集成至IDE和CI流程。 - **TypeScript特定要求**： - 禁止使用`any`类型。如遇复杂类型定义，请使用`unknown`或精确的接口/类型别名。 - 所有函数、类、公共方法**必须**包含完整的JSDoc注释，说明用途、参数、返回值。 - 使用`interface`定义对象结构和合同，`type`用于联合类型、交叉类型等。 - **命名约定**： - 变量/函数：`camelCase` - 类/接口/类型：`PascalCase` - 常量：`UPPER_SNAKE_CASE` - 布尔变量/函数：以`is`, `has`, `should`等开头（如`isLoading`）。 - **示例（正确 vs 错误）**: ```typescript // 正确 interface UserProfile { id: number; username: string; isActive: boolean; } const fetchUserData = async (userId: number): Promise<UserProfile> => { /* ... */ }; // 错误 const getUser = async (id) => { /* ... */ }; // 无类型，函数名不清晰

规则4：安全与最佳实践红线

  • 绝对禁止：
    • 在任何地方使用eval()、Function构造函数或setTimeout/setInterval执行字符串代码。
    • 将用户输入直接拼接至SQL查询字符串（使用Prisma参数化查询可避免）。
    • 在日志或响应中泄露敏感信息（密码、密钥、完整堆栈跟踪）。
  • 必须遵守：
    • 所有API端点（除登录/注册）必须经过JWT令牌认证。
    • 对用户输入进行验证和清理，使用zod库进行模式验证。
    • 密码必须使用bcrypt进行哈希存储。
### 3.2 规则的存储与版本管理 规则文档写好了，放在哪里？如何管理？我推荐以下几种实践： 1. **项目内文档化**：在项目根目录创建一个名为`AI_GUIDELINES.md`或`docs/ai-context.md`的文件。这是最简单直接的方式，方便项目成员共同维护。它的好处是与代码库绑定，版本同步。 2. **个人知识库片段**：使用像Obsidian、Notion、或VS Code的代码片段功能，将你的规则保存为可快速插入的模板。这适合你的个人通用规则，跨项目使用。 3. **专用提示词管理工具**：使用如`Promptfoo`、`Windscope`这类专门管理、测试提示词的工具。它们能提供更结构化的管理和测试能力。 **版本管理建议**：将规则文件纳入Git版本控制。当项目技术栈升级或规范变更时（例如从React 17升级到18，或引入了新的状态管理库），同步更新规则文件，并可以通过Commit信息记录变更原因。这保证了AI助手获取的上下文始终与项目最新状态同步。 > **实操心得**：我习惯在项目初期就建立`AI_GUIDELINES.md`文件。在项目技术选型讨论会之后，第一时间把确定的技术栈和架构写成规则。这不仅是给AI看，也是给团队新成员的一份极佳的项目入门指南。随着项目发展，每遇到一个因为AI“不理解”而导致的返工点，我就把它作为一条新规则补充进去。这个文件就这样慢慢生长，成为项目的“活字典”。 ### 3.3 规则的激活与使用流程 有了规则文档，关键在于如何高效地在每次对话中“激活”它。你不能每次都手动复制粘贴几千字的规则。 1. **Claude Desktop / Cursor等桌面应用**：这类应用通常支持“自定义指令”或“项目上下文”功能。你可以将核心的、通用的规则（如代码风格、安全红线）设置为**全局自定义指令**。将项目特定的规则（如技术栈、业务概念）保存在项目内的规则文件中，在开始复杂任务前，将文件内容复制到对话中。 2. **Web界面（ChatGPT, Claude Web）**：这是最常用的场景，也是相对低效的。最佳实践是： * **创建对话模板**：在笔记软件中保存一个包含所有规则的模板。 * **分步引导**：对于非常复杂的项目，不必一次性灌输所有规则。可以第一个对话专门用于“项目初始化”：粘贴`规则1-3`，让AI确认理解。在后续针对具体模块（如“用户认证”）的对话中，再补充相关的`规则4-7`。 * **利用“继续”功能**：在第一个问题中先发送规则，然后立刻发送第二个问题：“好的，这是项目规则。现在请基于以上规则，帮我实现一个用户登录的API端点。” 这能保证规则在上下文的最近位置，记忆效果最好。 3. **API集成**：如果你是高级用户，通过OpenAI或Anthropic的API构建自己的工具，那么可以在每次发送用户消息前，将规则文档作为“系统消息”（System Prompt）或对话历史的一部分预先发送，实现全自动化。 **一个高效的启动对话示例**：

（你将以下规则文档粘贴到聊天框）

项目规则（详见附件AI_GUIDELINES.md，此处为精简版）

  1. 项目：XX后台，TS+React+Express。
  2. 代码风格：遵循项目.eslintrc，函数需JSDoc，禁用any。
  3. 架构：后端Controller-Service-Repository分层。
  4. 安全：禁用eval，输入用zod验证，API需JWT。

请确认你已理解以上基础规则。接下来，我的第一个任务是：在/src/services/目录下，创建一个ProductService，包含根据ID查询商品和更新库存的方法。请先给出完整的TypeScript接口设计和类骨架。

通过这种方式，AI从一开始就被置于正确的“工作上下文”中。 ## 4. 实战场景：用“9 Rules”解决具体编程问题 让我们看两个具体场景，感受一下拥有“长记性”的AI助手是如何工作的。 ### 4.1 场景一：新增一个API端点 **没有规则时**： 你：“帮我在Express里写一个创建新用户的POST接口。” AI：可能会生成一个使用`body-parser`（你的项目可能用的是`express.json()`）、直接写SQL（而你用的是Prisma）、密码明文存储的代码。你需要反复纠正：“不，我们用Prisma”，“密码要哈希”，“响应格式要统一”。 **有规则时**： 你的提示词：“根据项目规则（分层架构、Prisma、输入验证、统一响应），在`/users`路径下实现一个`POST`接口用于创建用户。请求体应包含`email`, `password`, `name`。” AI生成的代码框架会非常贴近你的预期： ```typescript // 文件路径：src/controllers/userController.ts import { Request, Response } from 'express'; import { createUser } from '../services/userService'; import { UserCreateInput } from '../types/user'; // 假设已有类型定义 import { ApiResponse } from '../utils/responseHandler'; // 假设有统一响应工具 export const createUserController = async (req: Request, res: Response): Promise<void> => { try { // 1. 验证输入（规则4要求） // 这里AI可能会提示需要zod schema，或者直接调用一个验证函数 const userData: UserCreateInput = req.body; // 实际应有验证逻辑 // 2. 调用Service层（规则2架构约束） const newUser = await createUser(userData); // 3. 返回统一格式的成功响应（规则3或自定义输出格式要求） ApiResponse.success(res, 'User created successfully', newUser, 201); } catch (error) { // 4. 错误处理，返回统一格式的错误响应 ApiResponse.error(res, (error as Error).message); } };

同时，AI可能会提醒你：“根据规则，需要在src/services/userService.ts中实现createUser函数，并在其中使用Prisma Client进行数据库操作，并使用bcrypt哈希密码。”

4.2 场景二：修复一个TypeScript类型错误

没有规则时： 你贴出一段报错代码：“这里类型不匹配怎么办？” AI：可能会给出一个使用as any的快速解决方案，这与你的代码质量要求背道而驰。

有规则时： 同样的问题，因为AI“记得”规则3中“禁止使用any类型”和“必须使用精确接口”的铁律，它提供的解决方案会倾向于：

  1. 检查并完善相关的接口定义。
  2. 建议使用类型守卫（Type Guards）或类型断言（as SpecificType）。
  3. 重构函数签名使其类型更安全。 它的回答会体现出对项目类型系统的尊重，而不是图省事绕过类型检查。

5. 进阶技巧与常见问题排查

5.1 如何应对AI的“规则漂移”或遗忘？

即使提供了规则，在超长的多轮对话后，AI也可能在后续回答中逐渐偏离最初的设定。这是当前大语言模型的固有局限（上下文窗口衰减效应）。应对策略如下：

  1. 关键规则复述：在开启一个重要的新子任务时，简要复述最相关的1-2条核心规则。例如：“记住，我们用的是CSS Modules，不要生成内联样式或styled-components的代码。”
  2. 分段对话：对于大型、复杂的任务，拆分成多个独立的对话会话。每个会话开始时都重新粘贴一次完整的规则。虽然有点麻烦，但能保证每个会话的“纯净度”。
  3. 使用“总结与确认”技巧：在复杂任务进行到一段落时，可以让AI自己总结一下目前遵循了哪些项目规则。这既能检验其记忆，也能起到强化作用。
  4. 桌面应用的“系统提示”优势：这也是为什么推荐使用Claude Desktop或Cursor的原因，它们的系统提示词（相当于永久规则）在整个应用生命周期都有效，比Web单次对话更稳定。

5.2 规则冲突与优先级处理

当规则之间可能存在冲突时，需要在规则文件中明确优先级。例如：

  • 规则A（安全）：禁止执行动态代码。
  • 规则B（功能）：需要生成一些灵活的配置逻辑。

你可以在规则中声明：“安全规则（第4条）具有最高优先级，任何情况下不得违反。” 或者，在可能冲突的规则旁添加注释：“当此规则与规则X冲突时，以规则X为准。”

5.3 规则库的维护与更新

你的项目不是一成不变的，规则库也应迭代。

  1. 定期审查：每个迭代周期结束或技术栈重大更新后，回顾规则文档，看是否有过时的内容或需要补充的新约束。
  2. 收集“故障”案例：当AI产出不符合预期的代码时，不要仅仅纠正它。分析原因：是因为规则描述不清？还是缺少某条规则？将这次“故障”转化为一条新的或更清晰的规则。
  3. 团队协作：在团队中共享规则文件，鼓励所有成员共同维护。每个人在调教AI时发现的好方法、遇到的坑，都可以补充进去，使之成为团队的集体智慧。

5.4 不同AI模型对规则的响应差异

目前，Claude 3（尤其是Opus和Sonnet版本）在长上下文理解和复杂指令遵循方面表现突出，非常适合“9 Rules”这种方案。GPT-4 Turbo同样优秀，但有时在非常细致的风格约束上可能需要更明确的提示。一些更轻量或专注于代码的模型（如Claude 3 Haiku, GPT-4的早期版本）可能对大量规则的理解和执行会打折扣。

应对建议：对于能力稍弱的模型，可以精简规则，只保留最核心、最重要的几条（如技术栈、安全红线、最关键的风格要求），用更简练的语言描述。将详细的ESLint规则替换为“请写出非常整洁、符合行业标准的TypeScript代码”这样的概括性指令，有时反而效果更好。

6. 效果评估与个性化调优

实施“9 Rules”后，如何判断它是否有效？可以从以下几个维度评估：

  1. 代码首次通过率：AI生成的代码，无需或仅需极少量修改就能符合项目规范、通过ESLint检查、并实现预期功能的比率是否显著提高？
  2. 提示词效率：为了得到一个可用的代码块，你所需要进行的对话轮数是否减少了？是否不再需要反复纠正基础的技术栈和风格问题？
  3. 心智负担：你在使用AI编程时，是否需要时刻惦记着提醒它各种基础事项？这个负担是否减轻了？

根据评估结果，你可以对规则进行个性化调优：

  • 如果AI经常忽略某条规则：检查规则表述是否足够清晰、强硬。尝试增加示例，或将其拆分成更小、更具体的子规则。
  • 如果规则太多导致AI响应变慢或质量下降：考虑合并相关规则，或将为不同任务（如前端、后端、数据库）准备的规则分开，按需提供，而不是一次性灌输所有。
  • 补充“元规则”：你可以增加一条关于“如何理解规则”的规则。例如：“如果你对任何一条规则不确定，请先向我提问，而不是猜测。在输出代码时，如果某处处理方式有多个选择，请简要说明你为何选择当前这种方式。”

我个人在实际操作中的体会是，构建和维护这套规则库的前期投入，会在项目的中后期获得指数级的回报。它就像为你量身定制了一个永不疲倦、随叫随到、并且深刻理解你项目每一个细节的编程伙伴。最开始可能需要花费一两个小时来精心编写规则，但接下来几个月里，它为你节省的重复沟通和代码重构时间，可能高达数十个小时。更重要的是，它让AI生成的代码从一开始就更容易融入你的项目肌理，提升了整个代码库的一致性和可维护性。这不仅仅是关于效率，更是关于打造一种人与AI协同编程的新范式。

编程学习 学习日记 实战经验
← 返回列表