1. 项目概述为什么你的AI编程助手总是“健忘”如果你用过Claude、ChatGPT或者任何一款AI编程助手大概率经历过这种挫败感你花了十分钟详细解释了项目的技术栈、代码规范、甚至核心的业务逻辑AI助手也给出了完美的代码片段。但当你切换到下一个文件或者开始一个新功能时它就像得了“短期失忆症”又开始问一些你刚刚才回答过的基础问题或者写出不符合你项目约定的代码。这种重复的“上下文对齐”工作极大地消耗了开发者的耐心也让AI助手的效率大打折扣。“Claude Code - 9 Rules”这个项目正是为了解决这个核心痛点而生的。它不是某个官方功能而是一套由社区开发者总结提炼的、用于与Claude特别是Claude for Code或Claude Desktop高效协作的模块化配置方案。其核心思想是将你与AI助手交互中那些重复的、固定的“上下文”和“规则”通过一套结构化的“提示词规则”固化下来让AI助手能够“长记性”在每一次对话中都自动带入这些关键信息从而实现更连贯、更精准的协作。简单来说它就像为你和Claude的对话建立了一个“项目知识库”和“协作规范手册”。你不用每次都从头解释而是通过预先配置好的规则让AI在一开始就进入“懂你项目”的状态。这套方案提炼出了9条核心规则Rules涵盖了从项目认知、编码风格到协作流程的方方面面。接下来我将以一个全栈开发者的视角为你深度拆解这9条规则的实战应用分享如何根据你的具体项目进行定制化配置并附上我踩过坑之后总结的独家心得。2. 核心规则深度解析与设计哲学“9 Rules”之所以有效是因为它精准地模拟了人类开发者加入一个新项目时的认知路径。我们不会一上来就写代码而是先看文档、了解技术栈、熟悉代码风格最后才动手。这套规则就是引导AI走完这个路径。2.1 规则一角色与上下文锚定context这是所有规则的基石。它的作用是为AI设定一个明确的、稳定的“人设”和对话背景。内容示例context 你是一位经验丰富的全栈软件工程师正在协助我开发一个名为“Project Nexus”的现代化Web应用。本项目采用前后端分离架构当前对话将专注于后端API服务的开发与重构。请基于此上下文提供专业、精准的代码建议。 /context设计逻辑context标签像一个“舞台布景”。它首先定义了AI的角色资深全栈工程师这会影响其思考深度和回答范围。其次它锚定了项目名称和核心架构为后续所有讨论提供了一个不变的参考系。最后它指明了本次对话的焦点领域后端API帮助AI过滤无关信息提高回答的相关性。实操心得角色要具体“高级Python后端工程师”比“程序员”更好。“精通React性能优化的前端专家”比“前端开发”更有效。具体的角色能激活AI更专业的知识库。范围要收敛如果本次对话只改一个模块就在这里写明。避免让AI在庞大的项目空间中“迷路”。这是一个“一次性”设定通常只在对话开始时或重置上下文后使用后续对话会默认继承此上下文。2.2 规则二技术栈与依赖声明stack这是让AI写出“可用”代码而非“通用”代码的关键。错误的技术栈信息会导致AI推荐不兼容的库或过时的语法。内容示例stack **后端**Python 3.11 FastAPI框架 SQLAlchemy 2.0异步ORM Pydantic v2数据验证 PostgreSQL 14。 **关键依赖**authlib用于OAuth2 redis用于缓存 celery用于异步任务。 **前端**不涉及本次对话。 **工具链**代码格式化使用black和isort导入排序由isort管理。 /stack设计逻辑明确的技术栈相当于给了AI正确的“工具箱”。它确保了生成的代码片段可以直接复制粘贴使用无需额外修改导入或语法。注明版本号如Python 3.11能避免AI使用旧版本已废弃的特性如Python 3.7的asyncio用法。声明工具链black,isort是为规则四代码风格做铺垫。避坑指南版本号至关重要特别是主版本号如Pydantic v1 vs v2 SQLAlchemy 1.x vs 2.0的差异会导致完全不同的API。务必写明。列出“非标准”依赖像authlib、celery这类并非每个项目都用的库明确列出能极大提升AI建议的准确性。动态更新当项目引入新库如加入了websockets时记得更新此规则。2.3 规则三项目结构导航structure当项目具有特定目录结构时此规则能帮助AI理解文件间的引用关系和模块化设计。内容示例structure project-nexus/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI应用入口 │ ├── api/ # 路由层 │ │ ├── v1/ # API版本v1 │ │ │ ├── endpoints/ │ │ │ └── routers.py │ ├── core/ # 核心配置数据库、安全等 │ ├── models/ # SQLAlchemy数据模型 │ ├── schemas/ # Pydantic响应/请求模型 │ ├── crud/ # 数据库增删改查操作 │ └── services/ # 业务逻辑层 └── tests/ /structure设计逻辑清晰的目录树能帮助AI理解代码的组织逻辑。当你说“在services层创建一个用户服务”时AI能立刻知道该文件应该放在app/services/下并且知道如何正确地从models导入User模型从schemas导入UserCreate结构。这避免了AI将代码生成到错误位置或使用错误的导入路径。注意事项保持简洁不需要列出每个文件只列出关键的一级和二级目录表明模块的职责划分即可。说明关键文件对main.py、config.py等入口或核心配置文件加以简短注释能帮助AI更好地把握项目启动流程和配置加载顺序。2.4 规则四代码风格与规范契约style这是保证生成代码与项目现有代码“浑然一体”的秘诀。不一致的风格会让代码审查变得痛苦。内容示例style 1. **命名** - 变量/函数snake_case - 类名CamelCase - 常量UPPER_SNAKE_CASE - 私有成员前缀单下划线 _private_method 2. **格式化** - 遵循black默认配置行宽88。 - 使用isort规范导入顺序标准库 - 第三方库 - 本地库。 3. **语言特性** - 优先使用类型注解Type Hints。 - 异步函数使用async/await避免直接使用asyncio.run在非入口点。 - 字符串格式化优先使用f-string。 4. **文档** - 公共API函数和类必须包含Google风格的docstring。 - 复杂的业务逻辑需添加行内注释。 /style设计逻辑style规则是一份可执行的代码契约。它强制AI的输出符合团队约定减少了后期人工调整格式的时间。将工具链black,isort的规则用文字描述出来确保了即使在没有运行格式化工具的环境下如AI的思考过程中代码也是整洁的。独家技巧引用你的.editorconfig或pyproject.toml你可以直接粘贴相关配置片段如[tool.black]部分这比文字描述更精确。禁止某些模式如果你不希望看到*导入、不希望使用eval可以在这里明确写出“禁止使用from module import *”。分语言配置如果是全栈项目可以用[Python]、[JavaScript/React]这样的子标题来分别定义不同语言的风格。2.5 规则五领域术语与业务逻辑词典glossary当你的项目有独特的业务概念、缩写或内部术语时这个规则能防止AI“望文生义”。内容示例glossary - **UTX** 用户旅程User Journey的缩写指用户从访问到完成关键操作如支付的完整路径。 - **风控引擎** 指位于app/services/risk_engine.py中的模块负责评估交易风险等级返回HIGH/MEDIUM/LOW。 - **S级客户** 指在CRM系统中标记为“战略合作伙伴”级别的客户群体享有不同的业务规则。 - **订单履约** 指从订单支付成功到商品出库的完整流程涉及Order、Inventory、Logistics多个服务。 /glossary设计逻辑AI是基于公共语料训练的它不理解你公司内部的“黑话”。glossary就是为AI定制的业务词典。当你的需求中提到“为UTX中的S级客户绕过风控引擎”AI就能准确理解这些术语的指代从而生成符合业务逻辑的代码而不是基于通用理解进行猜测。实战建议这个规则应该随着你对AI解释业务概念的次数增多而逐步完善。每当你发现AI误解了某个术语就把它添加到词典里。2.6 规则六输出格式与结构化要求output此规则用于约束AI回复的形式而非内容。它让回复更易于你后续处理。内容示例output 1. 请先简要说明你的实现思路1-2句话。 2. 提供完整的、可运行的代码块代码块需标注语言类型如python。 3. 在代码后以“**说明**”为标题解释代码中的关键决策点或复杂逻辑。 4. 如果需要最后可以提出1-2个潜在的改进方向或注意事项。 /output设计逻辑它标准化了交互界面。你不需要在每次提问时都说“请先解释思路再给代码”。通过预设输出格式你能 consistently 获得结构清晰、信息完整的回答节省了从冗长回复中提取信息的时间。灵活变体对于代码审查请求可以要求格式为问题描述 - 代码位置 - 建议修改。对于方案设计可以要求使用列表和优缺点对比表格。2.7 规则七任务分解与执行流程workflow对于复杂的、多步骤的任务此规则指导AI如何一步步思考和工作模仿人类开发者的分解过程。内容示例workflow 当你接到一个功能开发请求时请按以下步骤执行 1. **需求澄清**与我确认需求的边界、输入、输出及异常情况。 2. **影响分析**分析此功能会影响哪些现有模块、数据库表或API接口。 3. **设计提案**提供1-2个实现方案并对比其优缺点。 4. **增量实现**在我确认方案后优先实现核心逻辑并提供可验证的代码片段。 5. **错误处理**为关键步骤添加必要的错误处理和日志记录。 6. **测试要点**列出需要单元测试或集成测试的关键点。 /workflow设计逻辑它防止AI“跳跃式”思考直接给出一个可能考虑不周的完整方案。通过强制其遵循一个结构化的流程能确保需求的全面理解和方案的稳健性。这对于架构设计、数据库迁移等复杂任务尤其有效。注意事项workflow是元规则它管理的是AI的“思考过程”。它常与output规则结合使用output规定最终答案的形态workflow规定得出答案的路径。2.8 规则八对话状态与记忆管理memory这是实现“长记性”的核心技术规则。它明确告诉AI哪些信息需要被记住并在后续对话中持续生效。内容示例memory 以下信息将在本次对话的整个上下文中持续有效除非我明确要求更改 - 上述所有规则context, stack, structure, style, glossary, output, workflow的定义。 - 在本对话中已确认过的业务决策和技术选型例如“已确认使用JWT作为认证方案”。 - 已生成的、且被我认可的核心函数或类定义。 /memory设计逻辑AI模型有上下文窗口限制且对于哪些信息重要、需要长期记忆并无内置判断。memory规则是一种显式的优先级标注。它像高亮笔一样告诉AI“这些是背景信息请牢牢记住在回答每个新问题时都要考虑它们。”这有效减少了因上下文过长而导致关键信息被“挤到后面”遗忘的现象。高级用法你可以要求AI主动总结记忆。例如在完成一个复杂模块的讨论后你可以说“请根据我们刚才的讨论更新memory规则将新定义的PaymentService类及其核心方法摘要加入。”2.9 规则九反馈与迭代循环feedback定义了当你指出AI的错误或提出修改时它应该如何响应和调整。这是将单向指令变为双向协作的关键。内容示例feedback 1. 如果我的反馈是“这里需要修改”请直接给出修改后的完整代码块并指出具体更改了哪里。 2. 如果我的反馈是“解释一下这行代码”请聚焦于该行代码说明其意图和可能的风险。 3. 如果我的反馈是“有错误”请首先尝试自行分析并修复错误然后解释错误原因和修复方案。 4. 如果无法理解我的反馈请提出澄清性问题而不是猜测。 /feedback设计逻辑它优化了协作效率。没有这个规则当你说“不对”时AI可能会重新生成一大段完全不同的代码或者陷入无意义的道歉。有了feedbackAI的修正行为变得可预测、高效更像一个理解你工作习惯的搭档。个性化定制你可以根据自己最常给的反馈类型来定制这条规则。比如如果你经常说“性能不行”就可以规定AI接到此反馈后必须进行时间复杂度分析并提供优化方案。3. 模块化配置方案实战从零搭建你的规则集理解了每条规则的含义下一步就是将它们组合成一个真正可用的、模块化的配置方案。生搬硬套9条规则只会让你和AI都感到臃肿。关键在于按需组合、分层管理。3.1 第一步创建基础规则模板全局级这是一个所有项目都可能用到的通用规则集保存在一个如claude_base_rules.md的文件中。# Claude 协作基础规则 ## context 你是一位经验丰富的全栈软件工程师正在协助我进行软件开发。你的回答应专业、精准并以产出高质量、可维护的代码为首要目标。 ## output 1. 首先用一两句话概括你的实现思路或问题分析。 2. 然后提供完整的代码或解决方案。代码必须放在标记了语言类型的代码块中例如 \\\python。 3. 最后在“**说明**”部分解释关键决策、复杂逻辑或潜在注意事项。 ## feedback 1. 如果我的反馈指出代码错误请直接给出修正后的代码并简要说明错误原因。 2. 如果我的反馈是要求解释请聚焦于被问及的部分进行详细说明。 3. 如果我的要求模糊请提出有针对性的问题来澄清。 ## workflow 对于复杂任务请遵循理解需求 - 分析影响 - 设计提案 - 增量实现 - 考虑边界情况 的流程。这个模板定义了协作的基本礼仪和流程适用于任何新对话的起点。3.2 第二步创建项目级规则配置为每个独立项目创建一个规则文件如project_nexus_rules.md。它引用并扩展基础模板。# Project Nexus 开发规则 **继承自基础规则并以下列项目特定规则为准。** ## context 你是一位专注于后端开发的资深Python工程师正在协助我开发“Project Nexus”的API服务。当前对话聚焦于业务逻辑实现与代码优化。 ## stack - **语言与框架** Python 3.11, FastAPI, SQLAlchemy 2.0 (异步), Pydantic v2。 - **数据库** PostgreSQL 14。使用Alembic进行数据库迁移。 - **核心依赖** redis (缓存), celery (异步任务), authlib (OAuth2), python-jose (JWT)。 - **开发工具** 代码格式化使用 black (行宽88) 和 isort。使用 pytest 进行测试。 ## structure (此处粘贴项目的精简目录树如前文示例) ## style (此处粘贴项目的详细代码风格约定如前文示例) ## glossary (此处粘贴项目的业务术语词典如前文示例) ## memory 本次对话中以上所有规则context至glossary持续有效。已讨论确认的技术方案如“用户认证采用JWT”也需记住。这个文件包含了项目的全部静态上下文。当你开始一个关于该项目的新对话时只需将这份配置发给Claude即可。3.3 第三步会话级动态规则管理在单个对话会话中根据当前任务动态调整或追加规则。这是模块化最灵活的部分。场景A进行数据库模式迁移首先发送 project_nexus_rules.md 然后在提出具体任务前追加以下内容 ## context update 当前任务设计并实现一个数据库迁移脚本为User表添加phone_number_verified布尔字段。 ## workflow update 请严格按以下步骤 1. 分析在User模型中添加此字段的影响现有数据、关联查询等。 2. 编写Alembic迁移脚本的upgrade和downgrade函数。 3. 提供更新对应的Pydantic UserSchema的建议。 4. 给出在代码中设置该字段默认值的建议位置如在用户注册服务中。场景B进行代码审查首先发送 project_nexus_rules.md 然后发送待审查的代码片段并追加 ## output update 请按以下格式进行代码审查 - **代码位置** [文件:行号] - **问题描述** [清晰描述问题如潜在bug、性能问题、风格不符] - **严重等级** [高/中/低] - **修改建议** [提供具体的修改后代码片段] - **依据规则** [指出违反了我们约定的哪条style或最佳实践] ## memory update 请记住我们刚刚在/app/api/v1/endpoints/users.py中重构了get_user函数以加入缓存。现在审查的是其调用方代码。通过这种“基础层 - 项目层 - 会话层”的三级配置你实现了规则的最大复用和灵活定制。基础规则免去了重复劳动项目规则固化了核心上下文会话规则则让AI能聚焦于当下最具体的任务。4. 高阶技巧与避坑指南让协作如虎添翼掌握了基本配置后下面这些从实战中总结的高阶技巧和常见陷阱能帮助你真正将这套方案的威力发挥到极致。4.1 技巧一用“规则引用”减少令牌消耗Claude的上下文窗口是有限的。每次对话都粘贴完整的项目规则可能上千字会快速消耗宝贵的令牌数。解决方案是使用引用。操作方法在对话开始时发送一个精简版提示。我将遵循我们为“Project Nexus”项目建立的协作规则集。所有关于技术栈Python 3.11/FastAPI/SQLAlchemy 2.0、代码风格black/isort、项目结构以及业务术语UTX, S级客户的约定均适用。请在此框架下协助我。原理你不需要逐字重复规则只需提醒AI“激活”某套已知的规则。这基于一个假设AI在之前的对话中已经“学习”了这套规则。虽然模型并非真正记忆但通过这种指代你能将对话重点集中在新任务上而非重复旧上下文。如果AI表现出困惑你再粘贴具体的规则片段。4.2 技巧二主动管理上下文定期“刷新记忆”在长对话中即使有memory规则最早的信息也可能因超出上下文窗口而被“遗忘”。你需要主动管理。症状AI开始询问之前已经明确过的技术栈细节或者生成的代码风格偏离了约定。解决方案在对话进行到一定长度例如讨论了5、6个不同问题后主动总结并重申核心规则。让我们暂停一下同步上下文。请记住我们仍在“Project Nexus”后端工作技术栈依然是Python 3.11 FastAPI SQLAlchemy 2.0代码风格遵循black。接下来我们需要解决用户上传文件的异步处理问题。进阶操作你可以要求AI自己总结。请根据我们之前的对话简要总结当前任务的核心上下文和约束条件。这不仅能刷新记忆还能检验AI是否准确理解了现状。4.3 技巧三将规则转化为可执行的“检查点”不要让规则停留在文档层面将其转化为AI可以执行的“动作”。示例在代码生成后自动审查在output规则中增加一条在提供任何代码块后请自动执行一次简易审查检查其是否符合style中的命名约定和基本规范并在“**自查**”部分注明结果。示例在方案设计时强制对比在workflow中规定在“设计提案”阶段必须提供至少两个方案并使用表格对比其优缺点如可维护性、性能、实现复杂度。这样AI的输出会直接包含一个对比表格迫使它进行更全面的思考。4.4 常见陷阱与排查陷阱规则冲突或过载现象AI行为混乱或输出质量下降。排查检查不同层级的规则特别是会话级追加的是否有矛盾。例如基础模板的output要求先给思路但某个会话级更新要求直接给代码。规则越多AI需要平衡的约束就越多可能导致性能下降。精简规则确保核心、无冲突。陷阱规则过于模糊现象AI生成的代码符合规则字面意思但不符合你的真实期望。排查将“写出高质量的代码”这种模糊要求替换为具体、可衡量的指令。例如“函数长度不超过30行”、“必须包含完整的错误处理”、“数据库查询必须使用异步会话”。陷阱忽略了AI的“创造力”限制现象你希望AI基于规则自主设计一个全新架构但它给出的方案很平庸。理解规则主要用于约束和引导而非激发无中生有的创造力。对于高度创新性任务规则应更侧重于workflow分解步骤和output结构化呈现而不是用style或stack过度限制。给AI一些探索空间在它提出方案后再用规则进行修正和优化。陷阱不更新过时的规则现象项目技术栈从Pydantic v1升级到了v2但规则里没改导致AI生成的代码使用废弃的API。最佳实践将项目级规则文件纳入版本控制如Git。当项目依赖或结构发生重大变更时像更新代码一样去更新你的claude_rules.md文件。这保证了协作上下文与项目实际状态同步。这套“Claude Code - 9 Rules”模块化配置方案本质上是将你与AI协作的“隐性知识”和“重复劳动”进行了一次系统的“外化”和“工程化”。它开始可能会觉得有些繁琐但一旦建立起来就像为你的开发工作流增加了一个拥有超强记忆力和严格规范性的永久结对程序员。它记住的不只是代码风格更是你项目的“灵魂”——业务逻辑、技术决策和团队习惯。花时间打磨属于你自己的规则集是当前阶段最大化AI编程助手价值的最高效投资。 AI编程助手健忘症解决方案：Claude Code 9 Rules模块化配置实战
1. 项目概述为什么你的AI编程助手总是“健忘”如果你用过Claude、ChatGPT或者任何一款AI编程助手大概率经历过这种挫败感你花了十分钟详细解释了项目的技术栈、代码规范、甚至核心的业务逻辑AI助手也给出了完美的代码片段。但当你切换到下一个文件或者开始一个新功能时它就像得了“短期失忆症”又开始问一些你刚刚才回答过的基础问题或者写出不符合你项目约定的代码。这种重复的“上下文对齐”工作极大地消耗了开发者的耐心也让AI助手的效率大打折扣。“Claude Code - 9 Rules”这个项目正是为了解决这个核心痛点而生的。它不是某个官方功能而是一套由社区开发者总结提炼的、用于与Claude特别是Claude for Code或Claude Desktop高效协作的模块化配置方案。其核心思想是将你与AI助手交互中那些重复的、固定的“上下文”和“规则”通过一套结构化的“提示词规则”固化下来让AI助手能够“长记性”在每一次对话中都自动带入这些关键信息从而实现更连贯、更精准的协作。简单来说它就像为你和Claude的对话建立了一个“项目知识库”和“协作规范手册”。你不用每次都从头解释而是通过预先配置好的规则让AI在一开始就进入“懂你项目”的状态。这套方案提炼出了9条核心规则Rules涵盖了从项目认知、编码风格到协作流程的方方面面。接下来我将以一个全栈开发者的视角为你深度拆解这9条规则的实战应用分享如何根据你的具体项目进行定制化配置并附上我踩过坑之后总结的独家心得。2. 核心规则深度解析与设计哲学“9 Rules”之所以有效是因为它精准地模拟了人类开发者加入一个新项目时的认知路径。我们不会一上来就写代码而是先看文档、了解技术栈、熟悉代码风格最后才动手。这套规则就是引导AI走完这个路径。2.1 规则一角色与上下文锚定context这是所有规则的基石。它的作用是为AI设定一个明确的、稳定的“人设”和对话背景。内容示例context 你是一位经验丰富的全栈软件工程师正在协助我开发一个名为“Project Nexus”的现代化Web应用。本项目采用前后端分离架构当前对话将专注于后端API服务的开发与重构。请基于此上下文提供专业、精准的代码建议。 /context设计逻辑context标签像一个“舞台布景”。它首先定义了AI的角色资深全栈工程师这会影响其思考深度和回答范围。其次它锚定了项目名称和核心架构为后续所有讨论提供了一个不变的参考系。最后它指明了本次对话的焦点领域后端API帮助AI过滤无关信息提高回答的相关性。实操心得角色要具体“高级Python后端工程师”比“程序员”更好。“精通React性能优化的前端专家”比“前端开发”更有效。具体的角色能激活AI更专业的知识库。范围要收敛如果本次对话只改一个模块就在这里写明。避免让AI在庞大的项目空间中“迷路”。这是一个“一次性”设定通常只在对话开始时或重置上下文后使用后续对话会默认继承此上下文。2.2 规则二技术栈与依赖声明stack这是让AI写出“可用”代码而非“通用”代码的关键。错误的技术栈信息会导致AI推荐不兼容的库或过时的语法。内容示例stack **后端**Python 3.11 FastAPI框架 SQLAlchemy 2.0异步ORM Pydantic v2数据验证 PostgreSQL 14。 **关键依赖**authlib用于OAuth2 redis用于缓存 celery用于异步任务。 **前端**不涉及本次对话。 **工具链**代码格式化使用black和isort导入排序由isort管理。 /stack设计逻辑明确的技术栈相当于给了AI正确的“工具箱”。它确保了生成的代码片段可以直接复制粘贴使用无需额外修改导入或语法。注明版本号如Python 3.11能避免AI使用旧版本已废弃的特性如Python 3.7的asyncio用法。声明工具链black,isort是为规则四代码风格做铺垫。避坑指南版本号至关重要特别是主版本号如Pydantic v1 vs v2 SQLAlchemy 1.x vs 2.0的差异会导致完全不同的API。务必写明。列出“非标准”依赖像authlib、celery这类并非每个项目都用的库明确列出能极大提升AI建议的准确性。动态更新当项目引入新库如加入了websockets时记得更新此规则。2.3 规则三项目结构导航structure当项目具有特定目录结构时此规则能帮助AI理解文件间的引用关系和模块化设计。内容示例structure project-nexus/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI应用入口 │ ├── api/ # 路由层 │ │ ├── v1/ # API版本v1 │ │ │ ├── endpoints/ │ │ │ └── routers.py │ ├── core/ # 核心配置数据库、安全等 │ ├── models/ # SQLAlchemy数据模型 │ ├── schemas/ # Pydantic响应/请求模型 │ ├── crud/ # 数据库增删改查操作 │ └── services/ # 业务逻辑层 └── tests/ /structure设计逻辑清晰的目录树能帮助AI理解代码的组织逻辑。当你说“在services层创建一个用户服务”时AI能立刻知道该文件应该放在app/services/下并且知道如何正确地从models导入User模型从schemas导入UserCreate结构。这避免了AI将代码生成到错误位置或使用错误的导入路径。注意事项保持简洁不需要列出每个文件只列出关键的一级和二级目录表明模块的职责划分即可。说明关键文件对main.py、config.py等入口或核心配置文件加以简短注释能帮助AI更好地把握项目启动流程和配置加载顺序。2.4 规则四代码风格与规范契约style这是保证生成代码与项目现有代码“浑然一体”的秘诀。不一致的风格会让代码审查变得痛苦。内容示例style 1. **命名** - 变量/函数snake_case - 类名CamelCase - 常量UPPER_SNAKE_CASE - 私有成员前缀单下划线 _private_method 2. **格式化** - 遵循black默认配置行宽88。 - 使用isort规范导入顺序标准库 - 第三方库 - 本地库。 3. **语言特性** - 优先使用类型注解Type Hints。 - 异步函数使用async/await避免直接使用asyncio.run在非入口点。 - 字符串格式化优先使用f-string。 4. **文档** - 公共API函数和类必须包含Google风格的docstring。 - 复杂的业务逻辑需添加行内注释。 /style设计逻辑style规则是一份可执行的代码契约。它强制AI的输出符合团队约定减少了后期人工调整格式的时间。将工具链black,isort的规则用文字描述出来确保了即使在没有运行格式化工具的环境下如AI的思考过程中代码也是整洁的。独家技巧引用你的.editorconfig或pyproject.toml你可以直接粘贴相关配置片段如[tool.black]部分这比文字描述更精确。禁止某些模式如果你不希望看到*导入、不希望使用eval可以在这里明确写出“禁止使用from module import *”。分语言配置如果是全栈项目可以用[Python]、[JavaScript/React]这样的子标题来分别定义不同语言的风格。2.5 规则五领域术语与业务逻辑词典glossary当你的项目有独特的业务概念、缩写或内部术语时这个规则能防止AI“望文生义”。内容示例glossary - **UTX** 用户旅程User Journey的缩写指用户从访问到完成关键操作如支付的完整路径。 - **风控引擎** 指位于app/services/risk_engine.py中的模块负责评估交易风险等级返回HIGH/MEDIUM/LOW。 - **S级客户** 指在CRM系统中标记为“战略合作伙伴”级别的客户群体享有不同的业务规则。 - **订单履约** 指从订单支付成功到商品出库的完整流程涉及Order、Inventory、Logistics多个服务。 /glossary设计逻辑AI是基于公共语料训练的它不理解你公司内部的“黑话”。glossary就是为AI定制的业务词典。当你的需求中提到“为UTX中的S级客户绕过风控引擎”AI就能准确理解这些术语的指代从而生成符合业务逻辑的代码而不是基于通用理解进行猜测。实战建议这个规则应该随着你对AI解释业务概念的次数增多而逐步完善。每当你发现AI误解了某个术语就把它添加到词典里。2.6 规则六输出格式与结构化要求output此规则用于约束AI回复的形式而非内容。它让回复更易于你后续处理。内容示例output 1. 请先简要说明你的实现思路1-2句话。 2. 提供完整的、可运行的代码块代码块需标注语言类型如python。 3. 在代码后以“**说明**”为标题解释代码中的关键决策点或复杂逻辑。 4. 如果需要最后可以提出1-2个潜在的改进方向或注意事项。 /output设计逻辑它标准化了交互界面。你不需要在每次提问时都说“请先解释思路再给代码”。通过预设输出格式你能 consistently 获得结构清晰、信息完整的回答节省了从冗长回复中提取信息的时间。灵活变体对于代码审查请求可以要求格式为问题描述 - 代码位置 - 建议修改。对于方案设计可以要求使用列表和优缺点对比表格。2.7 规则七任务分解与执行流程workflow对于复杂的、多步骤的任务此规则指导AI如何一步步思考和工作模仿人类开发者的分解过程。内容示例workflow 当你接到一个功能开发请求时请按以下步骤执行 1. **需求澄清**与我确认需求的边界、输入、输出及异常情况。 2. **影响分析**分析此功能会影响哪些现有模块、数据库表或API接口。 3. **设计提案**提供1-2个实现方案并对比其优缺点。 4. **增量实现**在我确认方案后优先实现核心逻辑并提供可验证的代码片段。 5. **错误处理**为关键步骤添加必要的错误处理和日志记录。 6. **测试要点**列出需要单元测试或集成测试的关键点。 /workflow设计逻辑它防止AI“跳跃式”思考直接给出一个可能考虑不周的完整方案。通过强制其遵循一个结构化的流程能确保需求的全面理解和方案的稳健性。这对于架构设计、数据库迁移等复杂任务尤其有效。注意事项workflow是元规则它管理的是AI的“思考过程”。它常与output规则结合使用output规定最终答案的形态workflow规定得出答案的路径。2.8 规则八对话状态与记忆管理memory这是实现“长记性”的核心技术规则。它明确告诉AI哪些信息需要被记住并在后续对话中持续生效。内容示例memory 以下信息将在本次对话的整个上下文中持续有效除非我明确要求更改 - 上述所有规则context, stack, structure, style, glossary, output, workflow的定义。 - 在本对话中已确认过的业务决策和技术选型例如“已确认使用JWT作为认证方案”。 - 已生成的、且被我认可的核心函数或类定义。 /memory设计逻辑AI模型有上下文窗口限制且对于哪些信息重要、需要长期记忆并无内置判断。memory规则是一种显式的优先级标注。它像高亮笔一样告诉AI“这些是背景信息请牢牢记住在回答每个新问题时都要考虑它们。”这有效减少了因上下文过长而导致关键信息被“挤到后面”遗忘的现象。高级用法你可以要求AI主动总结记忆。例如在完成一个复杂模块的讨论后你可以说“请根据我们刚才的讨论更新memory规则将新定义的PaymentService类及其核心方法摘要加入。”2.9 规则九反馈与迭代循环feedback定义了当你指出AI的错误或提出修改时它应该如何响应和调整。这是将单向指令变为双向协作的关键。内容示例feedback 1. 如果我的反馈是“这里需要修改”请直接给出修改后的完整代码块并指出具体更改了哪里。 2. 如果我的反馈是“解释一下这行代码”请聚焦于该行代码说明其意图和可能的风险。 3. 如果我的反馈是“有错误”请首先尝试自行分析并修复错误然后解释错误原因和修复方案。 4. 如果无法理解我的反馈请提出澄清性问题而不是猜测。 /feedback设计逻辑它优化了协作效率。没有这个规则当你说“不对”时AI可能会重新生成一大段完全不同的代码或者陷入无意义的道歉。有了feedbackAI的修正行为变得可预测、高效更像一个理解你工作习惯的搭档。个性化定制你可以根据自己最常给的反馈类型来定制这条规则。比如如果你经常说“性能不行”就可以规定AI接到此反馈后必须进行时间复杂度分析并提供优化方案。3. 模块化配置方案实战从零搭建你的规则集理解了每条规则的含义下一步就是将它们组合成一个真正可用的、模块化的配置方案。生搬硬套9条规则只会让你和AI都感到臃肿。关键在于按需组合、分层管理。3.1 第一步创建基础规则模板全局级这是一个所有项目都可能用到的通用规则集保存在一个如claude_base_rules.md的文件中。# Claude 协作基础规则 ## context 你是一位经验丰富的全栈软件工程师正在协助我进行软件开发。你的回答应专业、精准并以产出高质量、可维护的代码为首要目标。 ## output 1. 首先用一两句话概括你的实现思路或问题分析。 2. 然后提供完整的代码或解决方案。代码必须放在标记了语言类型的代码块中例如 \\\python。 3. 最后在“**说明**”部分解释关键决策、复杂逻辑或潜在注意事项。 ## feedback 1. 如果我的反馈指出代码错误请直接给出修正后的代码并简要说明错误原因。 2. 如果我的反馈是要求解释请聚焦于被问及的部分进行详细说明。 3. 如果我的要求模糊请提出有针对性的问题来澄清。 ## workflow 对于复杂任务请遵循理解需求 - 分析影响 - 设计提案 - 增量实现 - 考虑边界情况 的流程。这个模板定义了协作的基本礼仪和流程适用于任何新对话的起点。3.2 第二步创建项目级规则配置为每个独立项目创建一个规则文件如project_nexus_rules.md。它引用并扩展基础模板。# Project Nexus 开发规则 **继承自基础规则并以下列项目特定规则为准。** ## context 你是一位专注于后端开发的资深Python工程师正在协助我开发“Project Nexus”的API服务。当前对话聚焦于业务逻辑实现与代码优化。 ## stack - **语言与框架** Python 3.11, FastAPI, SQLAlchemy 2.0 (异步), Pydantic v2。 - **数据库** PostgreSQL 14。使用Alembic进行数据库迁移。 - **核心依赖** redis (缓存), celery (异步任务), authlib (OAuth2), python-jose (JWT)。 - **开发工具** 代码格式化使用 black (行宽88) 和 isort。使用 pytest 进行测试。 ## structure (此处粘贴项目的精简目录树如前文示例) ## style (此处粘贴项目的详细代码风格约定如前文示例) ## glossary (此处粘贴项目的业务术语词典如前文示例) ## memory 本次对话中以上所有规则context至glossary持续有效。已讨论确认的技术方案如“用户认证采用JWT”也需记住。这个文件包含了项目的全部静态上下文。当你开始一个关于该项目的新对话时只需将这份配置发给Claude即可。3.3 第三步会话级动态规则管理在单个对话会话中根据当前任务动态调整或追加规则。这是模块化最灵活的部分。场景A进行数据库模式迁移首先发送 project_nexus_rules.md 然后在提出具体任务前追加以下内容 ## context update 当前任务设计并实现一个数据库迁移脚本为User表添加phone_number_verified布尔字段。 ## workflow update 请严格按以下步骤 1. 分析在User模型中添加此字段的影响现有数据、关联查询等。 2. 编写Alembic迁移脚本的upgrade和downgrade函数。 3. 提供更新对应的Pydantic UserSchema的建议。 4. 给出在代码中设置该字段默认值的建议位置如在用户注册服务中。场景B进行代码审查首先发送 project_nexus_rules.md 然后发送待审查的代码片段并追加 ## output update 请按以下格式进行代码审查 - **代码位置** [文件:行号] - **问题描述** [清晰描述问题如潜在bug、性能问题、风格不符] - **严重等级** [高/中/低] - **修改建议** [提供具体的修改后代码片段] - **依据规则** [指出违反了我们约定的哪条style或最佳实践] ## memory update 请记住我们刚刚在/app/api/v1/endpoints/users.py中重构了get_user函数以加入缓存。现在审查的是其调用方代码。通过这种“基础层 - 项目层 - 会话层”的三级配置你实现了规则的最大复用和灵活定制。基础规则免去了重复劳动项目规则固化了核心上下文会话规则则让AI能聚焦于当下最具体的任务。4. 高阶技巧与避坑指南让协作如虎添翼掌握了基本配置后下面这些从实战中总结的高阶技巧和常见陷阱能帮助你真正将这套方案的威力发挥到极致。4.1 技巧一用“规则引用”减少令牌消耗Claude的上下文窗口是有限的。每次对话都粘贴完整的项目规则可能上千字会快速消耗宝贵的令牌数。解决方案是使用引用。操作方法在对话开始时发送一个精简版提示。我将遵循我们为“Project Nexus”项目建立的协作规则集。所有关于技术栈Python 3.11/FastAPI/SQLAlchemy 2.0、代码风格black/isort、项目结构以及业务术语UTX, S级客户的约定均适用。请在此框架下协助我。原理你不需要逐字重复规则只需提醒AI“激活”某套已知的规则。这基于一个假设AI在之前的对话中已经“学习”了这套规则。虽然模型并非真正记忆但通过这种指代你能将对话重点集中在新任务上而非重复旧上下文。如果AI表现出困惑你再粘贴具体的规则片段。4.2 技巧二主动管理上下文定期“刷新记忆”在长对话中即使有memory规则最早的信息也可能因超出上下文窗口而被“遗忘”。你需要主动管理。症状AI开始询问之前已经明确过的技术栈细节或者生成的代码风格偏离了约定。解决方案在对话进行到一定长度例如讨论了5、6个不同问题后主动总结并重申核心规则。让我们暂停一下同步上下文。请记住我们仍在“Project Nexus”后端工作技术栈依然是Python 3.11 FastAPI SQLAlchemy 2.0代码风格遵循black。接下来我们需要解决用户上传文件的异步处理问题。进阶操作你可以要求AI自己总结。请根据我们之前的对话简要总结当前任务的核心上下文和约束条件。这不仅能刷新记忆还能检验AI是否准确理解了现状。4.3 技巧三将规则转化为可执行的“检查点”不要让规则停留在文档层面将其转化为AI可以执行的“动作”。示例在代码生成后自动审查在output规则中增加一条在提供任何代码块后请自动执行一次简易审查检查其是否符合style中的命名约定和基本规范并在“**自查**”部分注明结果。示例在方案设计时强制对比在workflow中规定在“设计提案”阶段必须提供至少两个方案并使用表格对比其优缺点如可维护性、性能、实现复杂度。这样AI的输出会直接包含一个对比表格迫使它进行更全面的思考。4.4 常见陷阱与排查陷阱规则冲突或过载现象AI行为混乱或输出质量下降。排查检查不同层级的规则特别是会话级追加的是否有矛盾。例如基础模板的output要求先给思路但某个会话级更新要求直接给代码。规则越多AI需要平衡的约束就越多可能导致性能下降。精简规则确保核心、无冲突。陷阱规则过于模糊现象AI生成的代码符合规则字面意思但不符合你的真实期望。排查将“写出高质量的代码”这种模糊要求替换为具体、可衡量的指令。例如“函数长度不超过30行”、“必须包含完整的错误处理”、“数据库查询必须使用异步会话”。陷阱忽略了AI的“创造力”限制现象你希望AI基于规则自主设计一个全新架构但它给出的方案很平庸。理解规则主要用于约束和引导而非激发无中生有的创造力。对于高度创新性任务规则应更侧重于workflow分解步骤和output结构化呈现而不是用style或stack过度限制。给AI一些探索空间在它提出方案后再用规则进行修正和优化。陷阱不更新过时的规则现象项目技术栈从Pydantic v1升级到了v2但规则里没改导致AI生成的代码使用废弃的API。最佳实践将项目级规则文件纳入版本控制如Git。当项目依赖或结构发生重大变更时像更新代码一样去更新你的claude_rules.md文件。这保证了协作上下文与项目实际状态同步。这套“Claude Code - 9 Rules”模块化配置方案本质上是将你与AI协作的“隐性知识”和“重复劳动”进行了一次系统的“外化”和“工程化”。它开始可能会觉得有些繁琐但一旦建立起来就像为你的开发工作流增加了一个拥有超强记忆力和严格规范性的永久结对程序员。它记住的不只是代码风格更是你项目的“灵魂”——业务逻辑、技术决策和团队习惯。花时间打磨属于你自己的规则集是当前阶段最大化AI编程助手价值的最高效投资。