feat: 重构 pkg/ast/provider 模块，优化代码组织逻辑和功能实现

## 主要改进

### 架构重构
- 将单体 provider.go 拆分为多个专门的模块文件
- 实现了清晰的职责分离和模块化设计
- 遵循 SOLID 原则，提高代码可维护性

### 新增功能
- **验证规则系统**: 实现了完整的 provider 验证框架
- **报告生成器**: 支持多种格式的验证报告 (JSON/HTML/Markdown/Text)
- **解析器优化**: 重新设计了解析流程，提高性能和可扩展性
- **错误处理**: 增强了错误处理和诊断能力

### 修复关键 Bug
- 修复 @provider(job) 注解缺失 __job 注入参数的问题
- 统一了 job 和 cronjob 模式的处理逻辑
- 确保了 provider 生成的正确性和一致性

### 代码质量提升
- 添加了完整的测试套件
- 引入了 golangci-lint 代码质量检查
- 优化了代码格式和结构
- 增加了详细的文档和规范

### 文件结构优化
```
pkg/ast/provider/
├── types.go              # 类型定义
├── parser.go             # 解析器实现
├── validator.go          # 验证规则
├── report_generator.go   # 报告生成
├── renderer.go           # 渲染器
├── comment_parser.go     # 注解解析
├── modes.go             # 模式定义
├── errors.go            # 错误处理
└── validator_test.go    # 测试文件
```

### 兼容性
- 保持向后兼容性
- 支持现有的所有 provider 模式
- 优化了 API 设计和用户体验

This completes the implementation of T025-T029 tasks following TDD principles,
including validation rules implementation and critical bug fixes.

specs/001-pkg-ast-provider/research.md

@@ -0,0 +1,107 @@
+# Research Findings
+
+## Research Results
+
+### 1. 现有代码分析
+**Decision**: 现有 pkg/ast/provider 包包含两个主要文件：
+- `provider.go`: 337行代码，包含复杂的 AST 解析逻辑
+- `render.go`: 65行代码，包含模板渲染逻辑
+
+**Rationale**: 通过分析发现当前代码存在以下问题：
+- Parse 函数过于复杂（337行），违反单一职责原则
+- 缺少测试用例，测试覆盖率为 0%
+- 错误处理不够完善，缺少边界情况处理
+- 代码组织结构不够清晰，解析逻辑和业务逻辑混合
+
+**Alternatives considered**:
+- 保持现有结构，仅添加测试：无法解决代码复杂性问题
+- 完全重写：风险太高，可能破坏现有功能
+
+### 2. 重构策略研究
+**Decision**: 采用渐进式重构策略，按照 SOLID 原则重新组织代码结构
+
+**Rationale**:
+- 单一职责：将解析逻辑、验证逻辑、渲染逻辑分离
+- 开闭原则：使用接口和策略模式支持扩展
+- 依赖倒置：依赖抽象接口而非具体实现
+
+**Alternatives considered**:
+- 大爆炸式重写：风险太高，难以测试
+- 仅添加功能而不重构：会加剧技术债务
+
+### 3. 测试策略研究
+**Decision**: 采用 TDD 方法，先编写测试再实现功能
+
+**Rationale**:
+- 确保重构后功能正确性
+- 提供回归测试保障
+- 达到 90% 测试覆盖率目标
+
+**Alternatives considered**:
+- 先重构后测试：无法保证重构正确性
+- 仅测试公共接口：无法覆盖内部逻辑
+
+### 4. 性能优化研究
+**Decision**: 保持现有性能水平，重点优化代码结构
+
+**Rationale**:
+- 当前性能已经满足需求（<5s 解析）
+- 代码结构优化不会影响性能
+- 过度优化可能引入复杂性
+
+**Alternatives considered**:
+- 并发解析：增加复杂性，收益有限
+- 缓存机制：当前使用场景不需要
+
+### 5. 向后兼容性研究
+**Decision**: 保持完全向后兼容
+
+**Rationale**:
+- 现有用户依赖 @provider 注释格式
+- API 接口不能破坏
+- 生成代码格式保持一致
+
+**Alternatives considered**:
+- 破坏性更新：影响现有用户
+- 提供迁移工具：增加维护成本
+
+## 技术决策总结
+
+### 代码组织优化
+- 将 Parse 函数拆分为多个职责单一的函数
+- 创建专门的解析器、验证器、渲染器接口
+- 使用工厂模式创建不同类型的处理器
+
+### 测试覆盖策略
+- 单元测试：覆盖所有公共和私有函数
+- 集成测试：测试完整的工作流程
+- 基准测试：确保性能不退化
+
+### 错误处理改进
+- 创建自定义错误类型
+- 提供详细的错误信息和建议
+- 支持错误恢复机制
+
+### 文档和注释
+- 为所有公共函数添加 godoc 注释
+- 提供使用示例和最佳实践
+- 维护变更日志
+
+## 风险评估
+
+### 高风险项
+- 重构可能引入新的 bug
+- 测试覆盖不足可能导致回归问题
+
+### 缓解措施
+- 严格按照 TDD 流程开发
+- 每个重构步骤都要有对应的测试
+- 保持现有 API 接口不变
+
+## 下一步计划
+
+1. 创建详细的数据模型和接口设计
+2. 定义测试策略和测试用例
+3. 制定具体的重构步骤
+4. 实施渐进式重构
+5. 验证重构结果