尧图网页设计 
1. 为什么需要给AI编程助手立规矩作为一名长期使用AI编程助手的开发者我深刻体会到没有规矩不成方圆这句话在AI协作中的重要性。去年我在重构一个大型前端项目时曾因为缺乏明确的规则约束导致AI助手产生了以下问题代码风格混乱同一个项目中同时出现了Options API和Composition API混用的情况架构破坏AI擅自将本应放在store中的状态逻辑直接写进了组件安全隐患助手自作聪明地删除了它认为无用的配置文件效率低下每个需求都需要反复沟通基础规范消耗大量时间这些问题本质上不是AI能力不足而是缺乏明确的协作规范。就像带新人一样如果不明确告知工作方式和标准结果必然参差不齐。2. Rule机制的三层架构设计Claude Code的Rule系统采用三层结构这种设计既考虑了通用性又保留了灵活性2.1 用户全局规则(~/.claude/CLAUDE.md)这是影响范围最广的一层适合放置跨项目的通用偏好。我在全局规则中通常会定义# 全局默认规则 ## 基础规范 - 所有交互默认使用中文 - 代码生成使用UTF-8编码 - 禁止修改系统关键路径文件 ## 开发偏好 - 包管理器优先使用pnpm - Git提交信息遵循Conventional Commits规范 - 所有生成的代码必须通过ESLint检查2.2 项目级规则(项目根目录/CLAUDE.md)这是最常用的规则层建议纳入版本控制。一个好的项目级规则应该包含# 项目专属规则 ## 技术栈约束 - 前端Vue 3 Composition API TypeScript - 后端NestJS TypeORM PostgreSQL - 测试Jest Testing Library ## 目录规范 - src/ ├── core/ # 核心业务逻辑 ├── modules/ # 功能模块 ├── shared/ # 公共代码 └── types/ # 类型定义 ## 代码质量 - TypeScript必须开启strict模式 - 所有API响应必须定义类型 - 组件必须包含单元测试2.3 目录级规则(子目录/CLAUDE.md)对于大型项目模块级的约束特别重要。例如在API目录下# API开发规范 ## 请求处理 - 所有路由必须定义Swagger文档 - 错误响应使用统一格式 - 必须进行参数校验 ## 安全规范 - 敏感操作需要权限注解 - 禁止直接返回数据库实体 - 所有SQL查询必须参数化重要提示规则加载采用就近原则内层规则会覆盖外层规则。建议将最关键的约束放在最内层。3. 高效编写Rule的实践技巧3.1 使用AI生成初始规则在项目根目录运行claude init这个命令会自动分析项目结构和技术栈生成基础规则模板。根据我的经验生成的模板能覆盖70%的基础需求。3.2 规则编写的黄金法则优先级排序将最重要的规则放在文件前1/3位置强调关键词使用NEVER、MUST、CRITICAL等强调词具体示例不仅说明要做什么还要说明怎么做# 不好的写法 - 写好单元测试 # 好的写法 - 单元测试必须满足 * 覆盖率80% * 包含边界条件测试 * 使用describe/it分层结构3.3 模块化规则管理对于复杂项目建议拆分规则文件.claude/ └── rules/ ├── frontend.md ├── backend.md ├── database.md └── ci-cd.md每个文件专注一个领域主CLAUDE.md通过include引用# 主规则文件 ## 前端规范 .claude/rules/frontend.md ## 后端规范 .claude/rules/backend.md4. 典型问题与解决方案4.1 AI不遵守规则怎么办现象明明写了规则但AI仍然产生不符合预期的代码解决方案检查规则位置是否正确使用更强烈的措辞如MUST、禁止为规则添加解释# 优化前 - 使用Composition API # 优化后 - MUST使用Composition API本项目已全面迁移至Vue3禁止使用Options API4.2 规则冲突处理现象多层规则之间存在矛盾最佳实践全局规则只定义最基础的约束项目规则明确技术栈选择目录规则规定具体实现方式使用OVERRIDE关键字显式声明覆盖# 在目录级规则中 OVERRIDE 全局的缩进规则 - 本项目使用2空格缩进4.3 规则维护成本高现象随着项目发展规则文件变得臃肿优化方案每季度进行一次规则审计使用claude lint检查规则有效性将过时的规则移到deprecated/目录为规则添加有效期# [2024-07有效] 临时规范 - 因XXX原因暂时允许使用any类型5. 高级应用场景5.1 条件规则通过注释实现条件判断# 环境相关规则 ## 开发环境 IF envdevelopment - 允许console调试日志 - 禁用严格CSP ## 生产环境 IF envproduction - 禁止console.log - 必须启用CSP5.2 规则模板创建可复用的规则模板# Vue3项目模板 ## 基础配置 ~/.claude/templates/vue3-base.md ## 可选模块 ~/.claude/templates/vue3-optional/[pinia|vue-router|i18n].md5.3 规则测试使用测试用例验证规则有效性claude test --rule CLAUDE.md --scenario test-cases/测试用例格式# test-cases/component-check.yaml description: 验证组件规范 input: 创建一个Vue组件 expected: - 使用script setup - 包含类型定义 - 有对应的测试文件6. 性能优化建议规则精简保持规则文件200行缓存机制对稳定的规则启用缓存# [cached] 长期有效规则 - 项目编码规范v3.2懒加载大型规则文件按需加载!lazy-load .claude/rules/large-rule.md规则索引为快速查找添加标签# security critical - 禁止直接执行用户输入在实际项目中我发现合理的规则设计能使AI协作效率提升3-5倍。一个典型的例子是在为金融系统开发时通过严格的安全规则将AI产生的安全漏洞从每周2-3个降到了几乎为零。这让我深刻认识到好的规则不是限制而是高效协作的基础。 AI编程助手规则制定与三层架构实践
1. 为什么需要给AI编程助手立规矩作为一名长期使用AI编程助手的开发者我深刻体会到没有规矩不成方圆这句话在AI协作中的重要性。去年我在重构一个大型前端项目时曾因为缺乏明确的规则约束导致AI助手产生了以下问题代码风格混乱同一个项目中同时出现了Options API和Composition API混用的情况架构破坏AI擅自将本应放在store中的状态逻辑直接写进了组件安全隐患助手自作聪明地删除了它认为无用的配置文件效率低下每个需求都需要反复沟通基础规范消耗大量时间这些问题本质上不是AI能力不足而是缺乏明确的协作规范。就像带新人一样如果不明确告知工作方式和标准结果必然参差不齐。2. Rule机制的三层架构设计Claude Code的Rule系统采用三层结构这种设计既考虑了通用性又保留了灵活性2.1 用户全局规则(~/.claude/CLAUDE.md)这是影响范围最广的一层适合放置跨项目的通用偏好。我在全局规则中通常会定义# 全局默认规则 ## 基础规范 - 所有交互默认使用中文 - 代码生成使用UTF-8编码 - 禁止修改系统关键路径文件 ## 开发偏好 - 包管理器优先使用pnpm - Git提交信息遵循Conventional Commits规范 - 所有生成的代码必须通过ESLint检查2.2 项目级规则(项目根目录/CLAUDE.md)这是最常用的规则层建议纳入版本控制。一个好的项目级规则应该包含# 项目专属规则 ## 技术栈约束 - 前端Vue 3 Composition API TypeScript - 后端NestJS TypeORM PostgreSQL - 测试Jest Testing Library ## 目录规范 - src/ ├── core/ # 核心业务逻辑 ├── modules/ # 功能模块 ├── shared/ # 公共代码 └── types/ # 类型定义 ## 代码质量 - TypeScript必须开启strict模式 - 所有API响应必须定义类型 - 组件必须包含单元测试2.3 目录级规则(子目录/CLAUDE.md)对于大型项目模块级的约束特别重要。例如在API目录下# API开发规范 ## 请求处理 - 所有路由必须定义Swagger文档 - 错误响应使用统一格式 - 必须进行参数校验 ## 安全规范 - 敏感操作需要权限注解 - 禁止直接返回数据库实体 - 所有SQL查询必须参数化重要提示规则加载采用就近原则内层规则会覆盖外层规则。建议将最关键的约束放在最内层。3. 高效编写Rule的实践技巧3.1 使用AI生成初始规则在项目根目录运行claude init这个命令会自动分析项目结构和技术栈生成基础规则模板。根据我的经验生成的模板能覆盖70%的基础需求。3.2 规则编写的黄金法则优先级排序将最重要的规则放在文件前1/3位置强调关键词使用NEVER、MUST、CRITICAL等强调词具体示例不仅说明要做什么还要说明怎么做# 不好的写法 - 写好单元测试 # 好的写法 - 单元测试必须满足 * 覆盖率80% * 包含边界条件测试 * 使用describe/it分层结构3.3 模块化规则管理对于复杂项目建议拆分规则文件.claude/ └── rules/ ├── frontend.md ├── backend.md ├── database.md └── ci-cd.md每个文件专注一个领域主CLAUDE.md通过include引用# 主规则文件 ## 前端规范 .claude/rules/frontend.md ## 后端规范 .claude/rules/backend.md4. 典型问题与解决方案4.1 AI不遵守规则怎么办现象明明写了规则但AI仍然产生不符合预期的代码解决方案检查规则位置是否正确使用更强烈的措辞如MUST、禁止为规则添加解释# 优化前 - 使用Composition API # 优化后 - MUST使用Composition API本项目已全面迁移至Vue3禁止使用Options API4.2 规则冲突处理现象多层规则之间存在矛盾最佳实践全局规则只定义最基础的约束项目规则明确技术栈选择目录规则规定具体实现方式使用OVERRIDE关键字显式声明覆盖# 在目录级规则中 OVERRIDE 全局的缩进规则 - 本项目使用2空格缩进4.3 规则维护成本高现象随着项目发展规则文件变得臃肿优化方案每季度进行一次规则审计使用claude lint检查规则有效性将过时的规则移到deprecated/目录为规则添加有效期# [2024-07有效] 临时规范 - 因XXX原因暂时允许使用any类型5. 高级应用场景5.1 条件规则通过注释实现条件判断# 环境相关规则 ## 开发环境 IF envdevelopment - 允许console调试日志 - 禁用严格CSP ## 生产环境 IF envproduction - 禁止console.log - 必须启用CSP5.2 规则模板创建可复用的规则模板# Vue3项目模板 ## 基础配置 ~/.claude/templates/vue3-base.md ## 可选模块 ~/.claude/templates/vue3-optional/[pinia|vue-router|i18n].md5.3 规则测试使用测试用例验证规则有效性claude test --rule CLAUDE.md --scenario test-cases/测试用例格式# test-cases/component-check.yaml description: 验证组件规范 input: 创建一个Vue组件 expected: - 使用script setup - 包含类型定义 - 有对应的测试文件6. 性能优化建议规则精简保持规则文件200行缓存机制对稳定的规则启用缓存# [cached] 长期有效规则 - 项目编码规范v3.2懒加载大型规则文件按需加载!lazy-load .claude/rules/large-rule.md规则索引为快速查找添加标签# security critical - 禁止直接执行用户输入在实际项目中我发现合理的规则设计能使AI协作效率提升3-5倍。一个典型的例子是在为金融系统开发时通过严格的安全规则将AI产生的安全漏洞从每周2-3个降到了几乎为零。这让我深刻认识到好的规则不是限制而是高效协作的基础。