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的“岗位说明书”和“项目手册”。这种转变带来了几个关键优势一致性保障确保AI在所有对话中的输出都符合同一套标准避免了不同会话间风格迥异导致的代码混乱。效率提升无需在每次对话开始时都进行冗长的“背景介绍”直接切入核心问题。对于长期项目节省的时间是巨大的。知识沉淀这份配置本身成为了项目文档的一部分新加入项目的开发者无论是人类还是AI可以通过阅读它快速了解项目的技术规范和禁忌。可复用性基础规则如通用代码风格、安全规范可以提取为模板在不同项目间复用实现“一次定义处处生效”。2.2 “9 Rules”的模块化设计哲学为什么是“9”条规则这个数字并非金科玉律其精髓在于“模块化”和“关注点分离”。它鼓励你将复杂的约束分解为多个单一职责的、清晰的规则模块。例如你可以有规则1项目上下文- 描述项目是做什么的核心业务逻辑是什么。规则2技术栈与架构- 说明使用的框架、语言版本、架构模式如MVC、DDD。规则3代码风格与规范- 链接到ESLint配置、Prettier规则或自定义的命名约定。规则4依赖与包管理- 说明使用的包管理器npm/yarn/pnpm、以及重要的全局或项目依赖。规则5安全与最佳实践- 列出禁止使用的危险函数、必须进行的输入验证等。规则6测试要求- 规定测试框架、覆盖率要求、测试文件命名规则。规则7API与数据格式- 定义后端API的规范如RESTful风格、请求/响应数据的结构。规则8提交与部署- 说明Git提交信息格式、CI/CD流程中的关键环节。规则9输出格式- 要求AI在输出代码时附带解释、或按照特定结构组织答案。你可以根据项目实际情况增减、合并规则。关键在于每一条规则都应该目标明确、表述清晰、可独立验证。例如“代码风格与规范”这条规则与其说“请写出整洁的代码”不如直接提供你的.eslintrc.js文件内容或者明确列出几条关键规则“使用2个空格缩进”、“字符串优先使用单引号”、“interface优先于type”。注意规则的数量和内容完全由你定义。“9”只是一个启发性的数字提醒你将配置结构化。一个简单的前端demo项目可能只需要3-4条规则而一个大型全栈企业应用可能需要15条以上。2.3 规则的有效性如何让AI“听懂”并“记住”设计规则不是写给自己看的是写给AI模型“理解”并“执行”的。因此规则的表述方式至关重要。基于我的实战经验有效的规则通常遵循以下原则指令清晰避免歧义使用肯定、明确的语句。例如“必须使用async/await处理所有异步操作禁止使用回调函数嵌套。” 比 “建议使用更好的异步处理方式” 有效得多。提供正反示例对于复杂的规范提供一个简单的正确代码示例和一个错误代码示例能极大提升AI的理解准确度。例如在定义组件结构时可以附上一个标准的React函数组件样板。利用AI的“知识”你可以引用一些公认的规范或工具。例如“请遵循Airbnb JavaScript Style Guidehttps://github.com/airbnb/javascript”AI在训练时很可能学习过这份广为人知的指南理解起来会更准确。结构化与格式化将规则用Markdown的标题、列表、代码块组织起来。清晰的结构能帮助AI更好地解析你的意图。一个杂乱无章的文本段落效果远不如一个层次分明的文档。分层次有优先级如果规则很多可以声明哪些是最高优先级的“铁律”如安全规则哪些是推荐性的“指南”。这有助于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): PromiseUserProfile { /* ... */ }; // 错误 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此处为精简版项目XX后台TSReactExpress。代码风格遵循项目.eslintrc函数需JSDoc禁用any。架构后端Controller-Service-Repository分层。安全禁用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): Promisevoid { 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类型”和“必须使用精确接口”的铁律它提供的解决方案会倾向于检查并完善相关的接口定义。建议使用类型守卫Type Guards或类型断言as SpecificType。重构函数签名使其类型更安全。 它的回答会体现出对项目类型系统的尊重而不是图省事绕过类型检查。5. 进阶技巧与常见问题排查5.1 如何应对AI的“规则漂移”或遗忘即使提供了规则在超长的多轮对话后AI也可能在后续回答中逐渐偏离最初的设定。这是当前大语言模型的固有局限上下文窗口衰减效应。应对策略如下关键规则复述在开启一个重要的新子任务时简要复述最相关的1-2条核心规则。例如“记住我们用的是CSS Modules不要生成内联样式或styled-components的代码。”分段对话对于大型、复杂的任务拆分成多个独立的对话会话。每个会话开始时都重新粘贴一次完整的规则。虽然有点麻烦但能保证每个会话的“纯净度”。使用“总结与确认”技巧在复杂任务进行到一段落时可以让AI自己总结一下目前遵循了哪些项目规则。这既能检验其记忆也能起到强化作用。桌面应用的“系统提示”优势这也是为什么推荐使用Claude Desktop或Cursor的原因它们的系统提示词相当于永久规则在整个应用生命周期都有效比Web单次对话更稳定。5.2 规则冲突与优先级处理当规则之间可能存在冲突时需要在规则文件中明确优先级。例如规则A安全禁止执行动态代码。规则B功能需要生成一些灵活的配置逻辑。你可以在规则中声明“安全规则第4条具有最高优先级任何情况下不得违反。” 或者在可能冲突的规则旁添加注释“当此规则与规则X冲突时以规则X为准。”5.3 规则库的维护与更新你的项目不是一成不变的规则库也应迭代。定期审查每个迭代周期结束或技术栈重大更新后回顾规则文档看是否有过时的内容或需要补充的新约束。收集“故障”案例当AI产出不符合预期的代码时不要仅仅纠正它。分析原因是因为规则描述不清还是缺少某条规则将这次“故障”转化为一条新的或更清晰的规则。团队协作在团队中共享规则文件鼓励所有成员共同维护。每个人在调教AI时发现的好方法、遇到的坑都可以补充进去使之成为团队的集体智慧。5.4 不同AI模型对规则的响应差异目前Claude 3尤其是Opus和Sonnet版本在长上下文理解和复杂指令遵循方面表现突出非常适合“9 Rules”这种方案。GPT-4 Turbo同样优秀但有时在非常细致的风格约束上可能需要更明确的提示。一些更轻量或专注于代码的模型如Claude 3 Haiku, GPT-4的早期版本可能对大量规则的理解和执行会打折扣。应对建议对于能力稍弱的模型可以精简规则只保留最核心、最重要的几条如技术栈、安全红线、最关键的风格要求用更简练的语言描述。将详细的ESLint规则替换为“请写出非常整洁、符合行业标准的TypeScript代码”这样的概括性指令有时反而效果更好。6. 效果评估与个性化调优实施“9 Rules”后如何判断它是否有效可以从以下几个维度评估代码首次通过率AI生成的代码无需或仅需极少量修改就能符合项目规范、通过ESLint检查、并实现预期功能的比率是否显著提高提示词效率为了得到一个可用的代码块你所需要进行的对话轮数是否减少了是否不再需要反复纠正基础的技术栈和风格问题心智负担你在使用AI编程时是否需要时刻惦记着提醒它各种基础事项这个负担是否减轻了根据评估结果你可以对规则进行个性化调优如果AI经常忽略某条规则检查规则表述是否足够清晰、强硬。尝试增加示例或将其拆分成更小、更具体的子规则。如果规则太多导致AI响应变慢或质量下降考虑合并相关规则或将为不同任务如前端、后端、数据库准备的规则分开按需提供而不是一次性灌输所有。补充“元规则”你可以增加一条关于“如何理解规则”的规则。例如“如果你对任何一条规则不确定请先向我提问而不是猜测。在输出代码时如果某处处理方式有多个选择请简要说明你为何选择当前这种方式。”我个人在实际操作中的体会是构建和维护这套规则库的前期投入会在项目的中后期获得指数级的回报。它就像为你量身定制了一个永不疲倦、随叫随到、并且深刻理解你项目每一个细节的编程伙伴。最开始可能需要花费一两个小时来精心编写规则但接下来几个月里它为你节省的重复沟通和代码重构时间可能高达数十个小时。更重要的是它让AI生成的代码从一开始就更容易融入你的项目肌理提升了整个代码库的一致性和可维护性。这不仅仅是关于效率更是关于打造一种人与AI协同编程的新范式。
