feat: add code quality standard

Author: MonkeyCode-AI

.ai-ready/rules/code-quality-standards.md

@@ -0,0 +1,61 @@
+# Code Quality Standards Rule
+
+在开发过程中，必须遵循以下代码质量标准。这些标准确保代码的功能性、可维护性和长期健康。
+
+## 1. 功能与正确性 (The "Does it Work?")
+
+这是最基本的要求。代码必须实现它声称要实现的功能。
+
+- **符合需求**：代码是否完整且正确地实现了需求的描述？
+- **逻辑正确**：代码的核心逻辑是否正确？是否存在明显的 bug？
+- **边界情况**：是否考虑了各种边缘情况（Edge Cases）？例如：
+  - 输入为空（null）、为 0、为负数或超大数值
+  - 列表为空或只有一个元素
+  - 并发访问
+- **回归分析**：是否意外地破坏了现有的功能？
+
+## 2. 设计与架构 (The "Is it Well-Designed?")
+
+这是更高一个层面的考量，关乎代码的"骨架"和长期健康。
+
+- **职责单一**：每个函数、类（Class）或模块（Module）是否只做一件事，并且做得很好？
+- **抽象合理**：抽象的层次是否恰当？有没有过度设计（Over-engineering）或设计不足（Under-engineering）？
+- **重复代码 (DRY)**：是否有不必要的重复代码？（Don't Repeat Yourself）
+- **耦合性**：新代码是否与系统的其他部分过度耦合？修改它是否会"牵一发而动全身"？
+- **扩展性**：如果未来需求发生变化，这段代码是否容易扩展？
+- **模式应用**：是否正确使用了合适的设计模式（Design Patterns）？
+
+## 3. 可读性与可维护性 (The "Can Others Understand it?")
+
+代码是写给人看的，只是顺便让机器执行。
+
+- **清晰命名**：变量、函数、类的命名是否清晰、准确且有意义？（避免使用 `data`, `temp`, `a`, `b` 等模糊命名）
+- **简洁性**：是否可以用更简单、更直白的方式实现同样的功能？
+- **注释**：
+  - 是否有必要的注释来解释"为什么"（Why）这么做？（代码本身应该说明"做什么"）
+  - 是否有多余的、误导性的或已过时的注释？
+- **代码"异味" (Code Smells)**：是否有超长函数、过深的嵌套、巨大的类等不良信号？
+
+## 4. 测试与健壮性 (The "Is it Proven & Safe?")
+
+代码不仅要能工作，还要能被证明是可靠的。
+
+- **测试质量**：如果写了测试用例，测试用例是否有效？它们是在测试正确的逻辑，还是只是为了"跑通"？
+- **错误处理**：是否对可能发生的错误（如 API 调用失败、文件读取失败、数据库异常）进行了妥善处理？用户会看到友好的提示，还是程序会崩溃？
+
+## 5. 规范与一致性 (The "Does it Fit In?")
+
+一个项目应该看起来像一个人写的，而不是一群人写的。
+
+- **代码风格**：是否遵循了团队的编码规范（Style Guide / Linter）？（例如缩进、空格、括号位置等）
+- **项目约定**：是否遵循了项目已有的约定和模式？（例如，API 的返回格式、日志的记录方式等）
+- **无用代码**：是否移除了调试用的 `console.log`、被注释掉的代码块（Dead Code）？
+
+## 6. 性能与安全 (The "Is it Efficient & Secure?")
+
+- **性能**：是否存在明显的性能瓶颈？（例如，在循环中进行数据库查询、不必要的全表扫描、内存泄漏等）
+- **安全**：是否引入了常见的安全漏洞？（例如，SQL 注入、跨站脚本 (XSS)、硬编码的密钥、权限校验不严等）
+
+## 执行要求
+
+在模型生成代码时，必须对照以上六个维度进行自检，确保代码质量达标后再提交。