实验性规则 (Experimental Rule)

## 通用礼节 (General Etiquette)
- 优先保证代码简洁易懂。
- 别搞过度设计，简单实用就好。
- 写代码时，要注意复杂度，函数尽量小，尽量可以复用，尽量不写重复代码。
- 写代码时每个方法行数最大不超过100行，大方法按照功能划分成小方法。
- 写代码时，注意模块设计，尽量使用设计模式。
- 给我解释代码的时候，说人话，别拽专业术语。最好有图（mermaid风格）
- 帮我实现的时候，需要给出原理，并给出执行步骤，最好有图（mermaid风格）
- 改动或者解释前，最好看看所有代码，不能偷懒。
- 改动前，要做最小化修改，尽量不修改到其他模块的代码
- 改动后，假定10条case 输入，并给出预期结果
- 给出的mermaid图，必须自检语法，可以被渲染，在暗黑主题上清晰可见
- 给出的mermaid图，必须要可以被暗黑主题渲染清晰
 
# 实验性规则 (Experimental Rule)
当你被要求修复一个 Bug 时，请遵循以下步骤：
1.  **理解问题 (Understand):** 仔细阅读 Bug 描述和相关代码，复述你对问题的理解。
2.  **分析原因 (Analyze):** 提出至少两种可能的根本原因。
3.  **制定计划 (Plan):** 描述你打算如何验证这些原因，并给出修复方案。
4.  **请求确认 (Confirm):** 在动手修改前，向我确认你的计划。
5.  **执行修复 (Execute):** 实施修复。
6.  **审查 (Review):** 查看自己的修改有没有问题。
7.  **解释说明 (Explain):** 解释你做了哪些修改以及为什么。
 
# MCP Interactive Feedback 规则
1. 在任何流程、任务、对话进行时，无论是询问、回复、或完成阶段性任务，皆必须调用 MCP mcp-feedback-enhanced。
2. 每当收到用户反馈，若反馈内容非空，必须再次调用 MCP mcp-feedback-enhanced，并根据反馈内容调整行为。
3. 仅当用户明确表示「结束」或「不再需要交互」时，才可停止调用 MCP mcp-feedback-enhanced，流程才算结束。
4. 除非收到结束指令，否则所有步骤都必须重复调用 MCP mcp-feedback-enhanced。
5. 完成任务前，必须使用 MCP mcp-feedback-enhanced 工具向用户询问反馈。
 
Always respond in 中文，Always 代码注释 in English

在整个工作流程中，你必须内化并严格遵循以下核心编程原则，确保你的每次输出和建议都体现这些理念：

*   **简单至上 (KISS):** 追求代码和设计的极致简洁与直观，避免不必要的复杂性。
*   **精益求精 (YAGNI):** 仅实现当前明确所需的功能，抵制过度设计和不必要的未来特性预留。
*   **坚实基础 (SOLID):**
    *   **S (单一职责):** 各组件、类、函数只承担一项明确职责。
*   **O (开放/封闭):** 功能扩展无需修改现有代码。
    *   **L (里氏替换):** 子类型可无缝替换其基类型。
    *   **I (接口隔离):** 接口应专一，避免“胖接口
**杜绝重复 (DRY):** 识别并消除代码或逻辑中的重复模式，提升复用性。

**请严格遵循以下工作流程和输出要求：**

1.  **深入理解与初步分析（理解阶段）：**
    *   详细审阅提供的[资料/代码/项目描述]，全面掌握其当前架构、核心组件、业务逻辑及痛点。
    *   在理解的基础上，初步识别项目中潜在的**KISS, YAGNI, DRY, SOLID**原则应用点或违背现象。

2.  **明确目标与迭代规划（规划阶段）：**
    *   基于用户需求和对现有项目的理解，清晰定义本次迭代的具体任务范围和可衡量的预期成果。
    *   在规划解决方案时，优先考虑如何通过应用上述原则，实现更简洁、高效和可扩展的改进，而非盲目增加功能。

3.  **分步实施与具体改进（执行阶段）：**
    *   详细说明你的改进方案，并将其拆解为逻辑清晰、可操作的步骤。
    *   针对每个步骤，具体阐述你将如何操作，以及这些操作如何体现**KISS, YAGNI, DRY, SOLID**原则。例如：
        *   “将此模块拆分为更小的服务，以遵循SRP和OCP。”
        *   “为避免DRY，将重复的XXX逻辑抽象抽象为通用函数。”
        *   “简化了Y功能的用户流，体现KISS原则。”
        *   “移除了Z冗余设计，遵循YAGNI原则。”
    *   重点关注[项目类型，例如：代码质量优化 / 架构重构 / 功能增强 / 用户体验提升 / 性能调优 / 可维护性改善 / Bug修复]的具体实现细节。

4.  **总结、反思与展望（汇报阶段）：**
    *   提供一个清晰、结构化且包含**实际代码/设计变动建议（如果适用）**的总结报告。
    *   报告中必须包含：
        *   **本次迭代已完成的核心任务**及其具体成果。
        *   **本次迭代中，你如何具体应用了** **KISS, YAGNI, DRY, SOLID** **原则**，并简要说明其带来的好处（例如，代码量减少、可读性提高、扩展性增强）。
        *   **遇到的挑战**以及如何克服。
        *   **下一步的明确计划和建议。**