ai-agent-router 0.1.0

package/openspec/AGENTS.md

@@ -0,0 +1,456 @@
+# OpenSpec Instructions
+
+Instructions for AI coding assistants using OpenSpec for spec-driven development.
+
+## TL;DR Quick Checklist
+
+- Search existing work: `openspec spec list --long`, `openspec list` (use `rg` only for full-text search)
+- Decide scope: new capability vs modify existing capability
+- Pick a unique `change-id`: kebab-case, verb-led (`add-`, `update-`, `remove-`, `refactor-`)
+- Scaffold: `proposal.md`, `tasks.md`, `design.md` (only if needed), and delta specs per affected capability
+- Write deltas: use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements`; include at least one `#### Scenario:` per requirement
+- Validate: `openspec validate [change-id] --strict` and fix issues
+- Request approval: Do not start implementation until proposal is approved
+
+## Three-Stage Workflow
+
+### Stage 1: Creating Changes
+Create proposal when you need to:
+- Add features or functionality
+- Make breaking changes (API, schema)
+- Change architecture or patterns  
+- Optimize performance (changes behavior)
+- Update security patterns
+
+Triggers (examples):
+- "Help me create a change proposal"
+- "Help me plan a change"
+- "Help me create a proposal"
+- "I want to create a spec proposal"
+- "I want to create a spec"
+
+Loose matching guidance:
+- Contains one of: `proposal`, `change`, `spec`
+- With one of: `create`, `plan`, `make`, `start`, `help`
+
+Skip proposal for:
+- Bug fixes (restore intended behavior)
+- Typos, formatting, comments
+- Dependency updates (non-breaking)
+- Configuration changes
+- Tests for existing behavior
+
+**Workflow**
+1. Review `openspec/project.md`, `openspec list`, and `openspec list --specs` to understand current context.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, optional `design.md`, and spec deltas under `openspec/changes/<id>/`.
+3. Draft spec deltas using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement.
+4. Run `openspec validate <id> --strict` and resolve any issues before sharing the proposal.
+
+### Stage 2: Implementing Changes
+Track these steps as TODOs and complete them one by one.
+1. **Read proposal.md** - Understand what's being built
+2. **Read design.md** (if exists) - Review technical decisions
+3. **Read tasks.md** - Get implementation checklist
+4. **Implement tasks sequentially** - Complete in order
+5. **Confirm completion** - Ensure every item in `tasks.md` is finished before updating statuses
+6. **Update checklist** - After all work is done, set every task to `- [x]` so the list reflects reality
+7. **Approval gate** - Do not start implementation until the proposal is reviewed and approved
+
+### Stage 3: Archiving Changes
+After deployment, create separate PR to:
+- Move `changes/[name]/` → `changes/archive/YYYY-MM-DD-[name]/`
+- Update `specs/` if capabilities changed
+- Use `openspec archive <change-id> --skip-specs --yes` for tooling-only changes (always pass the change ID explicitly)
+- Run `openspec validate --strict` to confirm the archived change passes checks
+
+## Before Any Task
+
+**Context Checklist:**
+- [ ] Read relevant specs in `specs/[capability]/spec.md`
+- [ ] Check pending changes in `changes/` for conflicts
+- [ ] Read `openspec/project.md` for conventions
+- [ ] Run `openspec list` to see active changes
+- [ ] Run `openspec list --specs` to see existing capabilities
+
+**Before Creating Specs:**
+- Always check if capability already exists
+- Prefer modifying existing specs over creating duplicates
+- Use `openspec show [spec]` to review current state
+- If request is ambiguous, ask 1–2 clarifying questions before scaffolding
+
+### Search Guidance
+- Enumerate specs: `openspec spec list --long` (or `--json` for scripts)
+- Enumerate changes: `openspec list` (or `openspec change list --json` - deprecated but available)
+- Show details:
+  - Spec: `openspec show <spec-id> --type spec` (use `--json` for filters)
+  - Change: `openspec show <change-id> --json --deltas-only`
+- Full-text search (use ripgrep): `rg -n "Requirement:|Scenario:" openspec/specs`
+
+## Quick Start
+
+### CLI Commands
+
+```bash
+# Essential commands
+openspec list                  # List active changes
+openspec list --specs          # List specifications
+openspec show [item]           # Display change or spec
+openspec validate [item]       # Validate changes or specs
+openspec archive <change-id> [--yes|-y]   # Archive after deployment (add --yes for non-interactive runs)
+
+# Project management
+openspec init [path]           # Initialize OpenSpec
+openspec update [path]         # Update instruction files
+
+# Interactive mode
+openspec show                  # Prompts for selection
+openspec validate              # Bulk validation mode
+
+# Debugging
+openspec show [change] --json --deltas-only
+openspec validate [change] --strict
+```
+
+### Command Flags
+
+- `--json` - Machine-readable output
+- `--type change|spec` - Disambiguate items
+- `--strict` - Comprehensive validation
+- `--no-interactive` - Disable prompts
+- `--skip-specs` - Archive without spec updates
+- `--yes`/`-y` - Skip confirmation prompts (non-interactive archive)
+
+## Directory Structure
+
+```
+openspec/
+├── project.md              # Project conventions
+├── specs/                  # Current truth - what IS built
+│   └── [capability]/       # Single focused capability
+│       ├── spec.md         # Requirements and scenarios
+│       └── design.md       # Technical patterns
+├── changes/                # Proposals - what SHOULD change
+│   ├── [change-name]/
+│   │   ├── proposal.md     # Why, what, impact
+│   │   ├── tasks.md        # Implementation checklist
+│   │   ├── design.md       # Technical decisions (optional; see criteria)
+│   │   └── specs/          # Delta changes
+│   │       └── [capability]/
+│   │           └── spec.md # ADDED/MODIFIED/REMOVED
+│   └── archive/            # Completed changes
+```
+
+## Creating Change Proposals
+
+### Decision Tree
+
+```
+New request?
+├─ Bug fix restoring spec behavior? → Fix directly
+├─ Typo/format/comment? → Fix directly  
+├─ New feature/capability? → Create proposal
+├─ Breaking change? → Create proposal
+├─ Architecture change? → Create proposal
+└─ Unclear? → Create proposal (safer)
+```
+
+### Proposal Structure
+
+1. **Create directory:** `changes/[change-id]/` (kebab-case, verb-led, unique)
+
+2. **Write proposal.md:**
+```markdown
+# Change: [Brief description of change]
+
+## Why
+[1-2 sentences on problem/opportunity]
+
+## What Changes
+- [Bullet list of changes]
+- [Mark breaking changes with **BREAKING**]
+
+## Impact
+- Affected specs: [list capabilities]
+- Affected code: [key files/systems]
+```
+
+3. **Create spec deltas:** `specs/[capability]/spec.md`
+```markdown
+## ADDED Requirements
+### Requirement: New Feature
+The system SHALL provide...
+
+#### Scenario: Success case
+- **WHEN** user performs action
+- **THEN** expected result
+
+## MODIFIED Requirements
+### Requirement: Existing Feature
+[Complete modified requirement]
+
+## REMOVED Requirements
+### Requirement: Old Feature
+**Reason**: [Why removing]
+**Migration**: [How to handle]
+```
+If multiple capabilities are affected, create multiple delta files under `changes/[change-id]/specs/<capability>/spec.md`—one per capability.
+
+4. **Create tasks.md:**
+```markdown
+## 1. Implementation
+- [ ] 1.1 Create database schema
+- [ ] 1.2 Implement API endpoint
+- [ ] 1.3 Add frontend component
+- [ ] 1.4 Write tests
+```
+
+5. **Create design.md when needed:**
+Create `design.md` if any of the following apply; otherwise omit it:
+- Cross-cutting change (multiple services/modules) or a new architectural pattern
+- New external dependency or significant data model changes
+- Security, performance, or migration complexity
+- Ambiguity that benefits from technical decisions before coding
+
+Minimal `design.md` skeleton:
+```markdown
+## Context
+[Background, constraints, stakeholders]
+
+## Goals / Non-Goals
+- Goals: [...]
+- Non-Goals: [...]
+
+## Decisions
+- Decision: [What and why]
+- Alternatives considered: [Options + rationale]
+
+## Risks / Trade-offs
+- [Risk] → Mitigation
+
+## Migration Plan
+[Steps, rollback]
+
+## Open Questions
+- [...]
+```
+
+## Spec File Format
+
+### Critical: Scenario Formatting
+
+**CORRECT** (use #### headers):
+```markdown
+#### Scenario: User login success
+- **WHEN** valid credentials provided
+- **THEN** return JWT token
+```
+
+**WRONG** (don't use bullets or bold):
+```markdown
+- **Scenario: User login**  ❌
+**Scenario**: User login     ❌
+### Scenario: User login      ❌
+```
+
+Every requirement MUST have at least one scenario.
+
+### Requirement Wording
+- Use SHALL/MUST for normative requirements (avoid should/may unless intentionally non-normative)
+
+### Delta Operations
+
+- `## ADDED Requirements` - New capabilities
+- `## MODIFIED Requirements` - Changed behavior
+- `## REMOVED Requirements` - Deprecated features
+- `## RENAMED Requirements` - Name changes
+
+Headers matched with `trim(header)` - whitespace ignored.
+
+#### When to use ADDED vs MODIFIED
+- ADDED: Introduces a new capability or sub-capability that can stand alone as a requirement. Prefer ADDED when the change is orthogonal (e.g., adding "Slash Command Configuration") rather than altering the semantics of an existing requirement.
+- MODIFIED: Changes the behavior, scope, or acceptance criteria of an existing requirement. Always paste the full, updated requirement content (header + all scenarios). The archiver will replace the entire requirement with what you provide here; partial deltas will drop previous details.
+- RENAMED: Use when only the name changes. If you also change behavior, use RENAMED (name) plus MODIFIED (content) referencing the new name.
+
+Common pitfall: Using MODIFIED to add a new concern without including the previous text. This causes loss of detail at archive time. If you aren’t explicitly changing the existing requirement, add a new requirement under ADDED instead.
+
+Authoring a MODIFIED requirement correctly:
+1) Locate the existing requirement in `openspec/specs/<capability>/spec.md`.
+2) Copy the entire requirement block (from `### Requirement: ...` through its scenarios).
+3) Paste it under `## MODIFIED Requirements` and edit to reflect the new behavior.
+4) Ensure the header text matches exactly (whitespace-insensitive) and keep at least one `#### Scenario:`.
+
+Example for RENAMED:
+```markdown
+## RENAMED Requirements
+- FROM: `### Requirement: Login`
+- TO: `### Requirement: User Authentication`
+```
+
+## Troubleshooting
+
+### Common Errors
+
+**"Change must have at least one delta"**
+- Check `changes/[name]/specs/` exists with .md files
+- Verify files have operation prefixes (## ADDED Requirements)
+
+**"Requirement must have at least one scenario"**
+- Check scenarios use `#### Scenario:` format (4 hashtags)
+- Don't use bullet points or bold for scenario headers
+
+**Silent scenario parsing failures**
+- Exact format required: `#### Scenario: Name`
+- Debug with: `openspec show [change] --json --deltas-only`
+
+### Validation Tips
+
+```bash
+# Always use strict mode for comprehensive checks
+openspec validate [change] --strict
+
+# Debug delta parsing
+openspec show [change] --json | jq '.deltas'
+
+# Check specific requirement
+openspec show [spec] --json -r 1
+```
+
+## Happy Path Script
+
+```bash
+# 1) Explore current state
+openspec spec list --long
+openspec list
+# Optional full-text search:
+# rg -n "Requirement:|Scenario:" openspec/specs
+# rg -n "^#|Requirement:" openspec/changes
+
+# 2) Choose change id and scaffold
+CHANGE=add-two-factor-auth
+mkdir -p openspec/changes/$CHANGE/{specs/auth}
+printf "## Why\n...\n\n## What Changes\n- ...\n\n## Impact\n- ...\n" > openspec/changes/$CHANGE/proposal.md
+printf "## 1. Implementation\n- [ ] 1.1 ...\n" > openspec/changes/$CHANGE/tasks.md
+
+# 3) Add deltas (example)
+cat > openspec/changes/$CHANGE/specs/auth/spec.md << 'EOF'
+## ADDED Requirements
+### Requirement: Two-Factor Authentication
+Users MUST provide a second factor during login.
+
+#### Scenario: OTP required
+- **WHEN** valid credentials are provided
+- **THEN** an OTP challenge is required
+EOF
+
+# 4) Validate
+openspec validate $CHANGE --strict
+```
+
+## Multi-Capability Example
+
+```
+openspec/changes/add-2fa-notify/
+├── proposal.md
+├── tasks.md
+└── specs/
+    ├── auth/
+    │   └── spec.md   # ADDED: Two-Factor Authentication
+    └── notifications/
+        └── spec.md   # ADDED: OTP email notification
+```
+
+auth/spec.md
+```markdown
+## ADDED Requirements
+### Requirement: Two-Factor Authentication
+...
+```
+
+notifications/spec.md
+```markdown
+## ADDED Requirements
+### Requirement: OTP Email Notification
+...
+```
+
+## Best Practices
+
+### Simplicity First
+- Default to <100 lines of new code
+- Single-file implementations until proven insufficient
+- Avoid frameworks without clear justification
+- Choose boring, proven patterns
+
+### Complexity Triggers
+Only add complexity with:
+- Performance data showing current solution too slow
+- Concrete scale requirements (>1000 users, >100MB data)
+- Multiple proven use cases requiring abstraction
+
+### Clear References
+- Use `file.ts:42` format for code locations
+- Reference specs as `specs/auth/spec.md`
+- Link related changes and PRs
+
+### Capability Naming
+- Use verb-noun: `user-auth`, `payment-capture`
+- Single purpose per capability
+- 10-minute understandability rule
+- Split if description needs "AND"
+
+### Change ID Naming
+- Use kebab-case, short and descriptive: `add-two-factor-auth`
+- Prefer verb-led prefixes: `add-`, `update-`, `remove-`, `refactor-`
+- Ensure uniqueness; if taken, append `-2`, `-3`, etc.
+
+## Tool Selection Guide
+
+| Task | Tool | Why |
+|------|------|-----|
+| Find files by pattern | Glob | Fast pattern matching |
+| Search code content | Grep | Optimized regex search |
+| Read specific files | Read | Direct file access |
+| Explore unknown scope | Task | Multi-step investigation |
+
+## Error Recovery
+
+### Change Conflicts
+1. Run `openspec list` to see active changes
+2. Check for overlapping specs
+3. Coordinate with change owners
+4. Consider combining proposals
+
+### Validation Failures
+1. Run with `--strict` flag
+2. Check JSON output for details
+3. Verify spec file format
+4. Ensure scenarios properly formatted
+
+### Missing Context
+1. Read project.md first
+2. Check related specs
+3. Review recent archives
+4. Ask for clarification
+
+## Quick Reference
+
+### Stage Indicators
+- `changes/` - Proposed, not yet built
+- `specs/` - Built and deployed
+- `archive/` - Completed changes
+
+### File Purposes
+- `proposal.md` - Why and what
+- `tasks.md` - Implementation steps
+- `design.md` - Technical decisions
+- `spec.md` - Requirements and behavior
+
+### CLI Essentials
+```bash
+openspec list              # What's in progress?
+openspec show [item]       # View details
+openspec validate --strict # Is it correct?
+openspec archive <change-id> [--yes|-y]  # Mark complete (add --yes for automation)
+```
+
+Remember: Specs are truth. Changes are proposals. Keep them in sync.

package/openspec/changes/add-logging/proposal.md

@@ -0,0 +1,18 @@
+# Change: Add Logging Functionality
+
+## Why
+当前项目缺乏统一的日志记录机制，难以追踪技能脚本的执行情况和调试问题。添加日志功能将帮助开发者了解系统运行状态，快速定位问题。
+
+## What Changes
+- 添加 Python 日志模块集成到核心脚本
+- 支持不同日志级别（DEBUG, INFO, WARNING, ERROR）
+- 日志输出到控制台和可选的文件
+- 在关键操作点添加日志记录（搜索查询、结果数量、错误处理）
+
+## Impact
+- Affected specs: `core` (新增日志记录能力)
+- Affected code: 
+  - `.claude/skills/ui-ux-pro-max/scripts/core.py`
+  - `.claude/skills/ui-ux-pro-max/scripts/search.py`
+  - `.shared/ui-ux-pro-max/scripts/core.py`
+  - `.shared/ui-ux-pro-max/scripts/search.py`

package/openspec/changes/add-logging/specs/core/spec.md

@@ -0,0 +1,21 @@
+## ADDED Requirements
+
+### Requirement: Logging Infrastructure
+The system SHALL provide logging functionality for debugging and monitoring script execution.
+
+#### Scenario: Log search query
+- **WHEN** a search query is executed
+- **THEN** the query text and selected domain are logged at INFO level
+
+#### Scenario: Log search results
+- **WHEN** search results are returned
+- **THEN** the result count and domain are logged at INFO level
+
+#### Scenario: Log errors
+- **WHEN** an error occurs during search or file operations
+- **THEN** the error message and context are logged at ERROR level
+
+#### Scenario: Configurable log levels
+- **WHEN** logging is initialized
+- **THEN** the log level can be configured (DEBUG, INFO, WARNING, ERROR)
+- **AND** logs are output to console by default

package/openspec/changes/add-logging/tasks.md

@@ -0,0 +1,16 @@
+## 1. Implementation
+- [ ] 1.1 在 `core.py` 中添加日志配置函数
+- [ ] 1.2 在 BM25 类的关键方法中添加日志记录
+- [ ] 1.3 在搜索函数中添加查询和结果日志
+- [ ] 1.4 在错误处理路径中添加错误日志
+- [ ] 1.5 更新 `search.py` 使用日志功能
+- [ ] 1.6 同步更新 `.shared/` 目录下的脚本
+
+## 2. Testing
+- [ ] 2.1 验证日志在不同级别下正确输出
+- [ ] 2.2 验证日志文件创建和写入（如果启用）
+- [ ] 2.3 验证错误情况下的日志记录
+
+## 3. Documentation
+- [ ] 3.1 更新技能文档说明日志功能
+- [ ] 3.2 添加日志配置示例

package/openspec/changes/add-provider-test-connection/proposal.md

@@ -0,0 +1,22 @@
+# Change: 添加供应商测试连接功能
+
+## Why
+用户需要验证供应商配置是否正确，特别是 API Key 和 Base URL 是否有效。通过测试连接功能，用户可以在添加或编辑供应商后立即验证配置，避免在后续使用过程中才发现配置错误，提升用户体验和配置效率。
+
+## What Changes
+- **新增测试连接按钮**：在供应商管理页面的操作列添加"测试连接"按钮
+- **新增模型选择下拉菜单**：点击测试连接按钮后，显示该供应商下的可用模型列表，用户可以选择一个模型进行测试
+- **新增测试连接 API**：实现后端 API 端点，用于测试供应商连接和模型可用性
+- **新增测试结果反馈**：测试完成后显示成功或失败提示，失败时显示具体错误信息
+
+## Impact
+- Affected specs: 
+  - `model-provider` (修改：添加测试连接功能)
+- Affected code: 
+  - `src/app/providers/page.tsx` (前端：添加测试连接按钮和模型选择下拉)
+  - `src/app/api/providers/route.ts` (后端：添加测试连接 API 端点)
+  - `src/server/providers/index.ts` (可能需要添加测试连接方法)
+  - `src/server/providers/types.ts` (可能需要扩展接口)
+- 技术栈：
+  - 使用现有的 ProviderAdapter 接口进行测试
+  - 通过调用供应商的 API 验证连接

package/openspec/changes/add-provider-test-connection/specs/model-provider/spec.md

@@ -0,0 +1,68 @@
+## MODIFIED Requirements
+
+### Requirement: 模型供应商管理
+The system SHALL allow users to add, configure, and manage multiple AI model providers.
+
+#### Scenario: 添加新供应商
+- **WHEN** 用户在 Web 界面填写供应商信息（名称、协议类型、baseUrl、API Key）
+- **THEN** 供应商信息保存到数据库
+- **AND** API Key 加密存储
+- **AND** 供应商出现在供应商列表中
+
+#### Scenario: 编辑供应商配置
+- **WHEN** 用户修改供应商的 baseUrl 或 API Key
+- **THEN** 更新后的配置保存到数据库
+- **AND** 配置立即生效，无需重启网关
+
+#### Scenario: 删除供应商
+- **WHEN** 用户删除供应商
+- **THEN** 供应商从数据库删除
+- **AND** 关联的模型也被标记为不可用（或删除）
+
+#### Scenario: 验证供应商配置
+- **WHEN** 用户添加或编辑供应商
+- **THEN** 系统验证 baseUrl 格式和 API Key 格式
+- **AND** 如果配置无效，显示错误提示
+
+### Requirement: 供应商协议类型
+The system SHALL support different provider protocol types.
+
+#### Scenario: 选择协议类型
+- **WHEN** 用户添加供应商
+- **THEN** 可以从下拉列表选择协议类型（OpenAI、Anthropic、Gemini）
+- **AND** 根据协议类型显示相应的配置字段
+
+## ADDED Requirements
+
+### Requirement: 供应商测试连接功能
+The system SHALL allow users to test the connection to a provider by selecting a model and sending a test request.
+
+#### Scenario: 测试连接成功
+- **WHEN** 用户在供应商列表点击"测试连接"按钮
+- **AND** 从下拉菜单选择一个模型
+- **AND** 点击"开始测试"
+- **THEN** 系统发送测试请求到供应商 API
+- **AND** 如果连接成功，显示成功提示（例如："连接成功，模型可用"）
+- **AND** 测试过程中显示加载状态
+
+#### Scenario: 测试连接失败 - API Key 无效
+- **WHEN** 用户测试连接时 API Key 无效或已过期
+- **THEN** 系统显示错误提示（例如："API Key 无效，请检查配置"）
+- **AND** 错误信息清晰明确，帮助用户定位问题
+
+#### Scenario: 测试连接失败 - Base URL 不可访问
+- **WHEN** 用户测试连接时 Base URL 无法访问（网络错误、DNS 解析失败等）
+- **THEN** 系统显示网络错误提示（例如："无法连接到服务器，请检查 Base URL 和网络连接"）
+
+#### Scenario: 测试连接失败 - 模型不存在
+- **WHEN** 用户选择的模型在供应商中不存在或不可用
+- **THEN** 系统显示模型错误提示（例如："模型不存在或不可用"）
+
+#### Scenario: 测试连接超时
+- **WHEN** 测试请求超过 10 秒未响应
+- **THEN** 系统显示超时错误提示（例如："连接超时，请检查网络或稍后重试"）
+
+#### Scenario: 模型列表为空
+- **WHEN** 用户点击"测试连接"按钮
+- **AND** 该供应商下没有配置任何模型
+- **THEN** 系统提示用户先添加或拉取模型（例如："该供应商下没有模型，请先添加或拉取模型"）

package/openspec/changes/add-provider-test-connection/tasks.md

@@ -0,0 +1,31 @@
+## 1. 后端 API 实现
+- [x] 1.1 在 `src/app/api/providers/test/route.ts` 添加 `POST /api/providers/test` 端点
+- [x] 1.2 实现测试连接逻辑：根据 provider_id 和 model_id 获取供应商和模型信息
+- [x] 1.3 使用 ProviderAdapter 发送测试请求（可以发送一个简单的 chat completion 请求）
+- [x] 1.4 处理测试结果：成功返回成功信息，失败返回错误详情
+- [x] 1.5 添加超时处理（建议 10 秒超时）
+
+## 2. 前端 UI 实现
+- [x] 2.1 在供应商列表的操作列添加"测试连接"按钮
+- [x] 2.2 实现点击按钮后显示模型选择下拉菜单（显示该供应商下的所有模型）
+- [x] 2.3 实现选择模型后触发测试连接请求
+- [x] 2.4 实现测试过程中的加载状态显示
+- [x] 2.5 实现测试结果提示（成功/失败 Toast 提示）
+- [x] 2.6 失败时显示详细错误信息
+
+## 3. 测试连接逻辑
+- [x] 3.1 确定测试请求的方式（发送一个简单的 chat completion 请求验证连接）
+- [x] 3.2 处理不同协议的错误响应格式
+- [x] 3.3 验证 API Key 有效性
+- [x] 3.4 验证 Base URL 可访问性
+
+## 4. 错误处理
+- [x] 4.1 处理网络错误（连接超时、DNS 解析失败等）
+- [x] 4.2 处理认证错误（API Key 无效）
+- [x] 4.3 处理模型不存在错误
+- [x] 4.4 处理其他 API 错误（返回友好的错误信息）
+
+## 5. 用户体验优化
+- [x] 5.1 测试过程中禁用按钮，防止重复点击
+- [x] 5.2 优化加载状态显示（按钮显示加载动画）
+- [x] 5.3 优化错误信息展示（可读性更好的错误提示）