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

如果你用过Claude、ChatGPT这类AI编程助手，大概率遇到过这种场景：你让它帮你写一个函数，它写得又快又好；但当你紧接着说“现在给这个函数加上错误处理”，它可能会给你生成一个全新的、与之前函数毫无关联的代码块，甚至把函数名都改了。或者，你花了十分钟和它沟通清楚了项目的技术栈、代码规范和架构偏好，可一旦开启一个新对话，它又变回了一张白纸，一切都要从头再来。

这种“对话失忆”和“上下文割裂”的问题，是当前AI编程工具在复杂、长期项目协作中的核心痛点。它导致我们无法与AI建立一个稳定、可积累的“合作记忆”，每次交互都像是与一个只有七秒记忆的金鱼合作，效率大打折扣。

“Claude Code - 9 Rules”这个方案，正是为了解决这个问题而生。它不是某个具体的软件或插件，而是一套 模块化、可配置的“记忆植入”方法论 。其核心思想是：将你对代码的长期要求、项目规范、个人偏好，拆解成一系列清晰、独立、可组合的“规则”（Rules），并在每次与AI交互的“系统提示词”（System Prompt）中有策略地植入这些规则，从而让AI在每一次代码生成时，都能“想起”并遵守你的既定约束。

简单说，它让AI从一个需要你反复提醒的“临时工”，变成了一个熟知你工作习惯、记得项目历史的“老搭档”。本指南将深入拆解这9条规则的具体内容、设计逻辑、配置技巧以及实战中的避坑经验，手把手教你构建一个真正“长记性”的AI编程工作流。

2. 规则拆解：9条核心规则的设计哲学与具体内容

这9条规则并非随意罗列，它们构成了一个从宏观到微观、从约束到激励的完整体系。理解每条规则背后的“为什么”，比死记硬背规则内容更重要。

2.1 规则1-3：奠定协作基石的“元规则”

这三条规则定义了AI与你合作的基本姿态和产出标准，是其他所有规则生效的前提。

规则1：角色与使命定位 (Role & Mission)

• 内容示例 ： 你是一位经验丰富的全栈软件开发专家，专注于编写清晰、可维护、高性能的生产级代码。你的使命是理解我的需求，并输出可直接集成或仅需最小修改的代码解决方案。
• 设计逻辑 ：这不仅仅是给AI一个“头衔”。它设定了AI的“思考基线”。一个被定位为“专家”的AI，会更倾向于给出深思熟虑、考虑边缘情况的方案，而不是简单敷衍的答案。明确“生产级代码”和“最小修改”的目标，直接对齐了你的最终期望——减少后期调试成本。
• 实操心得 ：不要写“你是一个有帮助的AI”。要具体化。根据你的主要领域调整，例如：“云原生后端架构师”、“前端性能优化专家”、“数据管道工程师”。使命陈述要结果导向。

规则2：结构化输出强制 (Structured Output)

• 内容示例 ： 对于任何代码解决方案，请严格按以下结构输出：1. **分析**：简要说明问题本质与设计思路。2. **代码**：提供完整、可运行的代码块，并标注语言。3. **解释**：对代码中的关键部分、设计选择及潜在考量进行注释。4. **后续步骤**：建议如何测试、集成或可能的优化方向。
• 设计逻辑 ：强制结构化的输出，是为了对抗AI“思维发散”和“信息遗漏”的天性。它保证了每次交互的产出都包含了你需要的所有要素（思路、代码、注释、后续），无需你反复追问“为什么这么做？”或“怎么用？”。这极大地提升了信息密度和交互效率。
• 避坑指南 ：这个结构可以根据任务类型微调。对于调试任务，可以增加“ 问题根因 ”和“ 验证方法 ”；对于设计评审，可以增加“ 优缺点对比 ”。关键是形成固定模板，让AI和你都养成习惯。

规则3：交互协议 (Interaction Protocol)

• 内容示例 ： 在对话中，请遵循以下协议：a) 首先确认你是否完全理解我的需求，如有模糊之处立即提问澄清。b) 在提供方案前，如果存在多种常见实现方式，请简要对比并说明你的推荐理由。c) 如果我的需求存在潜在的技术风险或更好的替代方案，请务必指出。
• 设计逻辑 ：这条规则旨在管理交互过程本身，防止“盲从”和“隐藏假设”。它要求AI主动参与需求澄清，暴露决策过程，并承担起“技术顾问”的提醒责任。这能将很多潜在问题扼杀在编码之前。
• 配置技巧 ：这条规则特别适合与经验不足的开发者配合，可以要求AI“用类比的方式解释复杂概念”。对于资深开发者，可以调整为“直接切入技术实现，省略基础解释”。

2.2 规则4-6：约束代码质量的“工程规则”

这三条规则直接作用于生成的代码本身，确保其符合现代软件工程的基本要求。

规则4：代码风格与规范 (Coding Style & Standards)

• 内容示例 ： 所有代码必须遵循以下规范：使用ESLint（Airbnb规则集）和Prettier进行格式化。变量命名采用camelCase，常量使用UPPER_SNAKE_CASE。函数注释使用JSDoc格式。禁止使用任何已废弃的API。
• 设计逻辑 ：这是让AI“记住”你项目代码面貌的关键。统一的风格是代码可读性和可维护性的基石。通过明确指定工具（ESLint）、规则集（Airbnb）和具体约定，AI生成的代码能无缝融入现有代码库，减少格式调整的琐碎工作。
• 实战要点 ：这条规则需要你提供最具体、最无歧义的描述。最好直接引用你项目中的 .eslintrc.js 、 .prettierrc 或 pyproject.toml 配置文件中的关键条目。也可以附上项目内典型代码文件作为“风格范例”。

规则5：架构与设计模式约束 (Architecture & Patterns)

• 内容示例 ： 本项目采用清晰的层次架构：Controller -> Service -> Repository/DAO。请确保新代码符合此分层，业务逻辑集中于Service层，数据访问封装于Repository层。鼓励使用依赖注入进行解耦。
• 设计逻辑 ：这条规则让AI在“设计层面”上与你同步。它防止AI写出一个把所有逻辑都堆在Controller里的“面条代码”，而是引导其产出符合项目整体架构的代码。这对于保持大型项目结构的一致性至关重要。
• 进阶配置 ：不仅可以约束分层，还可以指定模式：“优先使用工厂模式创建对象”、“状态管理使用Redux Toolkit切片”、“API响应统一包裹在 { data, code, message } 结构中”。越具体，AI的产出越精准。

规则6：依赖与安全性红线 (Dependencies & Security)

• 内容示例 ： 使用外部库前，必须检查其：1) 维护活跃度（GitHub stars/commits）。2) 许可证兼容性（必须为MIT、Apache 2.0）。3) 已知安全漏洞（提示我检查npm audit或Snyk）。禁止引入 eval() 、 setTimeout 拼接字符串等危险模式。
• 设计逻辑 ：AI有时会为了解决问题而引入不成熟或有风险的依赖。这条规则充当“安全守门员”，将依赖管理和安全编码的最佳实践固化为强制检查点。它迫使AI在建议使用一个冷门库时，给出合理的选用理由。
• 重要提醒 ：对于安全红线（如禁止 eval 、SQL拼接），要用“禁止”等强语气。可以补充常见漏洞类型，如“对用户输入必须进行验证和转义”。

2.3 规则7-9：优化输出与迭代的“增强规则”

这三条规则侧重于提升输出结果的可用性和迭代过程的流畅度。

规则7：上下文感知与引用 (Context Awareness)

• 内容示例 ： 如果我的请求与之前对话中讨论过的模块、函数或变量相关，请主动引用它们（例如：‘正如之前实现的 UserService 中的 validateEmail 方法…’），并确保新代码与现有上下文保持兼容。
• 设计逻辑 ：这是对抗“对话失忆”的直接武器。它明确要求AI在生成新代码时，必须主动关联历史上下文。虽然大模型有上下文长度限制，但通过这条指令，可以激励它在有效窗口内尽可能建立连接，产出逻辑连贯的代码，而不是孤立的功能片段。
• 使用技巧 ：在开启一个长期项目对话时，可以将项目核心模块的简要说明作为“初始上下文”喂给AI，并加上这条规则，效果会更好。

规则8：复杂度管理与分解 (Complexity Management)

• 内容示例 ： 如果需求复杂度高，不要试图在一个代码块中解决所有问题。请先提出一个模块化分解方案，征得我同意后，再逐个实现子模块。每个函数的圈复杂度（Cyclomatic Complexity）应尽量控制在10以下。
• 设计逻辑 ：AI有时会生成一个冗长、高耦合的“巨函数”来满足复杂需求。这条规则强制其采用“分而治之”的工程思想。先设计，后实现，并且引入了可量化的质量指标（圈复杂度），使代码审查和后续维护更容易。
• 实操心得 ：“征得我同意”这个交互点很重要，它把最终的设计决策权留给了你，AI只是提案者。这符合人机协作的最佳模式——AI拓展思路，人类把握方向。

规则9：学习与适配反馈 (Learning & Adaptation)

• 内容示例 ： 我会对你的输出提供反馈（如‘变量名不够清晰’、‘这里用策略模式更好’）。请记住这些反馈点，并在后续的类似任务中应用这些修正后的模式或偏好。
• 设计逻辑 ：这是让AI真正“长记性”的终极规则。它建立了一个正向反馈循环。你的每次纠正，都不是对单次回答的修改，而是对AI在本次对话中“行为模式”的微调。AI会尝试将你的反馈抽象成新的、隐性的“规则”，应用于后续输出。
• 重要提示 ：这条规则的效果严重依赖于AI模型的能力和上下文长度。在长对话中效果显著，但开启新会话后会重置。因此，它更适合用于一个持续数小时、围绕特定任务的深度协作会话。

3. 模块化配置实战：如何组装你的专属规则集

掌握了每条规则的含义，下一步就是如何将它们组合并植入到你的AI工具中。关键在于“模块化”和“按需加载”，避免每次提示词都冗长不堪。

3.1 构建你的规则库（Rules Repository）

不要将9条规则写成一个巨大的文本块。建议你创建一个纯文本文件或笔记分区，将它们分门别类地存储起来：

# 我的AI编程规则库
## 基础规则 (始终启用)
1. [角色与使命定位] - 全栈专家，生产级代码。
2. [结构化输出强制] - 分析、代码、解释、后续步骤。

## 项目专用规则 (按项目切换)
- **项目A-React前端**：
  3. [代码风格] - ESLint(React规则), Prettier, 函数组件+React Hooks。
  4. [架构约束] - 组件原子设计（Atoms, Molecules, Organisms），状态管理使用Zustand。
- **项目B-Node.js后端**：
  3. [代码风格] - ESLint(Node规则), 异步使用Async/Await。
  4. [架构约束] - 三层架构，使用Joi进行输入验证。
  5. [安全红线] - 禁止SQL拼接，使用参数化查询或ORM。

## 任务类型规则 (按需添加)
- **代码审查任务**：添加[交互协议]，要求先指出潜在问题。
- **调试任务**：修改[结构化输出]为：现象描述、根因分析、修复代码、验证方法。
- **学习新库**：添加[复杂度管理]，要求先给出核心概念和最小示例。

这样，你就拥有了一个可灵活拼装的“规则乐高”。

3.2 在Claude/ChatGPT中的植入策略

目前，最有效的植入方式是通过“系统提示词”（System Prompt）或“自定义指令”（Custom Instructions）功能。

对于Claude（Claude.ai或API） ： 在Web界面，通常有“自定义指令”或“系统提示”的输入框。你可以将精选后的规则组合粘贴进去。例如，开始一个React项目时，你的系统提示词可能是：

你是一位资深前端工程师，擅长构建高性能、可维护的React应用。你的使命是提供可直接使用的生产代码。

【输出格式】
请按此结构回复：1. 分析 2. 代码 3. 解释 4. 后续步骤。

【项目规范】
- 代码风格：遵循ESLint（eslint-config-airbnb），Prettier格式化。使用函数组件和Hooks。
- 架构：采用原子设计理念。状态管理使用Zustand，优先使用`useEffect`处理副作用。
- 交互：如果我的需求有歧义，请先提问。提供多种方案时请说明推荐理由。

【其他要求】
- 新代码需与之前讨论的组件保持兼容，并主动引用。
- 复杂功能请先提供模块化设计。
- 记住我对代码风格的反馈并应用。

对于ChatGPT等工具 ：原理类似，找到“自定义指令”或“系统”角色设置的地方，填入你的规则集。

核心技巧：分层与缩写 ：对于需要频繁使用的规则集，可以为其创建一个“代号”。例如，在系统提示词里写：“当我说 [启用React规则] 时，请应用以下规范：...”。然后在对话中，只需输入 [启用React规则] ，就能激活一整套约束，这比每次复制粘贴高效得多。

3.3 动态规则激活与上下文管理

在实际对话中，规则的应用应该是动态的。

1. 会话初始化 ：开启一个新项目对话时，导入“基础规则”+“该项目专用规则”。这为整个对话定下基调。
2. 任务执行中 ：当进行到具体任务（如“现在写一个登录表单”），AI会自动应用所有已激活的规则。
3. 中途切换/增补 ：如果你突然需要AI进行代码审查，你可以说：“现在切换至代码审查模式。请重点检查下面这段代码的XXX问题。” 此时，你可以手动在消息中补充一两条“代码审查任务”的规则，临时改变AI的侧重点。
4. 反馈与迭代 ：当AI的代码不符合你的命名习惯时，立刻纠正：“变量名用 userInput 而不是 inputValue 。” 结合 规则9 ，AI在后续生成中会倾向于使用 userInput 。

这种动态管理，使得AI助手既有一个稳定的“人格”和“知识背景”，又能灵活适应对话中不断变化的具体任务焦点。

4. 实战场景演练：从需求到代码的完整流程

让我们通过一个真实场景，看看这套规则集如何协同工作。

场景 ：你正在开发一个Node.js后端项目（使用Express.js），需要新增一个用户注册的API端点。

你的输入（用户指令） ： “为我的Express项目添加一个用户注册的POST接口 /api/v1/register 。需要验证邮箱和密码，密码要加盐哈希，用户信息存入MongoDB。项目已存在 models/User.js 和 utils/db.js 。”

AI在规则驱动下的思考与输出过程：

1. 触发规则1与规则3 ：AI首先确认自己的“全栈专家”角色，并执行交互协议。它可能会先追问：“确认一下：1. 邮箱验证是格式验证还是查重？2. 密码哈希你希望使用 bcrypt 吗？3. 现有的 User.js 模型是否包含了 email 和 password 字段？” 这避免了基于错误假设的编码。

2. 触发规则2与规则5 ：在得到你的澄清后，AI开始按照 结构化输出 生成回答。在“分析”部分，它会说明：“将采用MVC模式，在 routes/auth.js 中添加路由，逻辑放在 controllers/authController.js 的 register 函数中，密码哈希在 services/userService.js 中完成，确保与现有分层架构一致。” 这体现了 架构约束 。

3. 触发规则4与规则6 ：在“代码”部分，AI生成的Express路由和控制器代码，会严格遵循你设定的ESLint规则。它会使用 bcrypt 库进行哈希，并主动在注释中提醒：“ bcrypt 是活跃维护的库，采用MIT许可证。请注意在生产环境调整 saltRounds 参数。” 这同时满足了 代码风格 和 依赖/安全 规则。

4. 触发规则7 ：AI在编写连接数据库的代码时，会引用你提到的现有文件：“如 utils/db.js 中已导出的 mongoose 连接，这里直接使用 User 模型。” 这保证了 上下文兼容 。

5. 触发规则8 ：如果注册逻辑包含邮箱发送验证码，AI可能会建议：“注册流程较复杂，建议拆解：1. 输入验证；2. 用户查重；3. 密码哈希；4. 创建用户；5. 发送验证邮件。我们先实现前四步，邮件服务稍后集成，是否同意？” 这体现了 复杂度管理 。

6. 后续迭代与规则9 ：你看完代码后反馈：“ validateInput 函数太长了，拆成 validateEmail 和 validatePassword 两个函数。” AI不仅会修改当前代码，在后续你要求编写登录接口时，它可能会主动提议：“登录的输入验证可以参考之前注册接口拆分的 validateEmail 和 validatePassword 函数。” 这就是 学习与适配 在起作用。

通过这个流程，AI从一个需要你事无巨细指挥的“代码打字机”，转变为一个理解项目上下文、遵守工程规范、并能提出合理建议的“初级工程师”。你节省的不仅是打字时间，更是反复沟通、纠正方向、统一风格的巨大认知开销。

5. 常见问题与效能边界：规则不是银弹

尽管“9 Rules”方案强大，但我们必须清醒认识其局限性和使用中的常见问题。

5.1 规则冲突与优先级

当多条规则同时作用时，可能会产生冲突。例如， 规则8（复杂度管理） 要求拆分函数，但 规则4（代码风格） 可能设定了“函数行数不超过50行”的约束。一个复杂的逻辑即使拆分了，每个函数也可能接近50行。

• 解决方案 ：在规则定义时就要考虑优先级。通常，“安全红线”（规则6）拥有最高优先级，其次是架构约束（规则5），然后是代码风格（规则4）。可以在规则库中注明：“当规则8与规则4冲突时，以可读性和单一职责优先（即规则8优先），允许暂时超出格式限制，但需备注。”

5.2 提示词过长与模型“遗忘”

将所有规则详细描述后，系统提示词可能长达上千字。这会占用宝贵的上下文窗口，可能导致模型在生成长篇回答时“忘记”靠前的规则。

• 应对策略 ：
  1. 精炼语言 ：用最简洁、无歧义的语言描述规则。避免冗长解释。
  2. 分层加载 ：如3.2节所述，只将最核心、最通用的规则（如规则1，2，3）放在系统提示词中。将项目专用规则（规则4，5）放在对话开始时的第一条用户消息里。将临时规则（如针对某个任务的特殊要求）在具体请求中提及。
  3. 定期重申 ：在非常长的对话中，可以每隔一段时间，用一句简短的话重申核心规则，例如：“请记住，我们依然在遵循三层架构和ESLint规范。”

5.3 对模糊需求的无力感

规则能约束“如何做”，但不能替代“做什么”。如果你给出的需求是“优化这个页面”，AI即使有全套规则，也无从下手，因为它缺乏明确的目标。

• 最佳实践 ：始终为AI提供 清晰、具体、可操作 的需求。将“优化页面”改为“分析 HomePage.vue 的渲染性能，找出导致首次内容绘制（FCP）过慢的瓶颈，并提供具体的代码优化方案，要求不影响现有功能”。好的规则需要搭配好的指令才能发挥威力。

5.4 不同AI模型的能力差异

“9 Rules”方案的效果，与底层大模型的理解和遵循指令能力强相关。Claude 3 Opus、ChatGPT-4等高端模型遵循复杂指令的能力远强于一些小型或早期模型。

• 测试与调整 ：在你的主力模型上充分测试这套规则。如果发现某条规则（尤其是规则9学习反馈）效果不佳，可以暂时弱化它，或将其转化为更明确的静态规则（例如，将你的反馈直接添加到规则4的风格条款中）。

这套模块化配置方案的本质，是将人类工程师的隐性知识（工程经验、项目规范、个人偏好）转化为AI可理解、可执行的显性指令。它不能替代你的思考和设计，但能极大程度上将你从重复、琐碎的规范检查和基础编码中解放出来，让你更专注于架构设计和核心逻辑。