Frontend Test Generation & Code Review MCP Server

# 项目特定规则和约定 ## 概述 本文档包含项目特定的代码审查规则和约定。AI 代码审查时应该遵循这些规则，避免提出不符合项目实际情况的建议。 ## 项目特定约定 ### 统一封装的函数和工具 以下函数和工具是项目中统一封装的，且是统一的用法，**不应建议避免使用或修改**： 1. **merge 函数** - 项目中的 `merge` 函数是统一封装的工具函数 - 使用方式是项目中统一的约定 - 如果只是因为 TypeScript 类型定义不完善导致的问题，**不应建议避免使用 merge** - **只应在确实存在类型安全问题（且不是类型定义问题）时才提出建议** 2. **其他统一封装的工具函数** - 项目中可能有其他统一封装的工具函数 - 如果这些函数的使用方式是项目约定，不应建议改变使用方式 ### 审查原则 1. **区分类型定义问题和实际安全问题** - 如果问题只是因为 TypeScript 类型定义不完善，而不是实际的安全问题，**不应提出建议** - 例如：如果 merge 函数的使用本身是安全的，只是因为类型定义不完善导致类型检查报错，不应建议避免使用 2. **尊重项目约定** - 如果某种写法是项目的统一约定，即使不是最佳实践，也不应建议改变 - 除非确实存在严重的安全或性能问题 3. **关注实际问题** - 只关注实际存在的问题，而不是理论上可能的问题 - 如果代码在当前项目上下文中是合理的，不应提出不必要的建议 ## 示例 ### 不应该提出的建议 **错误示例**： - 消息："merge函数可能引起属性覆盖问题" - 建议："避免使用merge，明确指定需要修改的属性" **原因**：如果 merge 是项目中统一封装的函数，且使用方式是项目约定，不应建议避免使用。 ### 应该提出的建议 只有在以下情况才应该提出建议： 1. 确实存在类型安全问题（且不是类型定义问题） 2. 确实存在性能问题 3. 确实存在安全漏洞 ## 审查时的判断标准 在审查代码时，请考虑： 1. 这是项目约定还是实际问题？ 2. 是否存在真正的风险？ 3. 建议是否符合项目的实际情况？ 如果某个"问题"只是项目约定或类型定义不完善导致的，**不应提出建议**。