488 lines
15 KiB
Markdown
488 lines
15 KiB
Markdown
# Brainstorming Session Results
|
||
|
||
**Session Date:** 2025-10-15
|
||
**Facilitator:** Business Analyst Mary
|
||
**Participant:** Project Lead
|
||
|
||
---
|
||
|
||
## Executive Summary
|
||
|
||
**Topic:** Avalonia UI 库开发 - 基于 Semi 样式库的业务场景控件库
|
||
|
||
**Session Goals:**
|
||
|
||
- 明确项目战略定位和核心价值
|
||
- 系统化梳理控件清单和优先级
|
||
- 识别技术挑战和解决方案
|
||
- 制定渐进式开发路线图
|
||
|
||
**Techniques Used:**
|
||
|
||
1. First Principles Thinking（第一性原理）
|
||
2. Morphological Analysis（形态分析）
|
||
3. SCAMPER Method（SCAMPER 方法）
|
||
4. What If Scenarios（假设情景）
|
||
|
||
**Total Ideas Generated:** 50+
|
||
|
||
### Key Themes Identified:
|
||
|
||
- **市场定位**：填补"业务场景集成控件"的市场空白
|
||
- **技术栈**：.NET 8+ / Avalonia 最新版 / ReactiveUI / AOT / 苹果颜色系统
|
||
- **开发策略**：自顶向下、MVP 优先、渐进式替换
|
||
- **目标场景**：上位机开发 + AI 桌面应用
|
||
|
||
---
|
||
|
||
## Technique Sessions
|
||
|
||
### First Principles Thinking（第一性原理）- 40 分钟
|
||
|
||
**Description:** 回归基本原理，重新思考项目的核心价值和根本问题
|
||
|
||
#### Ideas Generated:
|
||
|
||
1. **核心问题识别**
|
||
|
||
- 市面上的 UI 库都是"基础控件库"（Button、TextBox 等通用组件）
|
||
- 真正加速开发的应该是"业务场景集成控件"（PropertyGrid、LoggingControl 等）
|
||
- 每个开发者业务需求不同，所以没有人做这些集成控件
|
||
- 对于固定场景（上位机 + AI 桌面），可以打造专用工具集
|
||
2. **业务控件的共同特征**
|
||
|
||
- 与数据模型耦合（追求"合适的通用性"而非"极致通用性"）
|
||
- 由多个基础控件组合而成，但代表通用业务场景
|
||
- 例如：PropertyGrid = 自动化 UI 生成；LoggingControl = 领域数据的完整交互
|
||
3. **市场空白的原因**
|
||
|
||
- 商业逻辑：开源作者倾向做"影响面广"的基础控件
|
||
- 需求差异：每个人的业务定义不同
|
||
- 技术障碍：AOT、反射限制等
|
||
- 对于固定场景（上位机 + AI 桌面），这些限制不存在
|
||
|
||
#### Insights Discovered:
|
||
|
||
- 项目定位：私有生产力工具 > 开源通用库
|
||
- 允许高度场景化，不追求过度通用性
|
||
- PropertyGrid 可以只支持常用类型，不需要覆盖所有边缘情况
|
||
|
||
#### Notable Connections:
|
||
|
||
- Source Generator 可以解决 AOT 反射限制
|
||
- 对接系统接口（ILogger 等）而非重新发明轮子
|
||
|
||
---
|
||
|
||
### Morphological Analysis（形态分析）- 25 分钟
|
||
|
||
**Description:** 系统化识别项目维度，探索不同选项的组合
|
||
|
||
#### Ideas Generated:
|
||
|
||
1. **控件数据模式维度**
|
||
|
||
- 选择：带数据模型的 UserControl（自包含业务单元）
|
||
- 允许 CustomControl 和 UserControl 混合存在
|
||
2. **主题系统维度**
|
||
|
||
- 选择：多主题，与 Avalonia 原生集成
|
||
- 采用苹果颜色系统（语义化、自适应暗色模式）
|
||
3. **样式定制维度**
|
||
|
||
- 选择：Style Class（通过 ClassName 切换主题）
|
||
- 利用 Avalonia 的样式扩展特性
|
||
4. **交互模式维度**
|
||
|
||
- 选择：ReactiveUI 作为核心交互数据流
|
||
- Command / Reactive / Event 混合使用
|
||
|
||
#### Insights Discovered:
|
||
|
||
- 控件类型不需要过度分类，实用性优先
|
||
- 抽象维度对固定场景项目价值有限
|
||
- 应聚焦具体控件清单和功能特性
|
||
|
||
---
|
||
|
||
### SCAMPER Method（SCAMPER 方法）- 30 分钟
|
||
|
||
**Description:** 基于 Semi/Ursa 进行系统化创新改造
|
||
|
||
#### Ideas Generated:
|
||
|
||
**S - Substitute（替代）:**
|
||
|
||
1. 颜色系统 → 苹果颜色系统（统一规范、语义化）
|
||
2. 传统样式 → Style Class 系统（灵活主题切换）
|
||
|
||
**C - Combine（组合）:**
|
||
|
||
1. 战略调整：只用 Semi（样式库），不用 Ursa（控件库）
|
||
2. 部署方式：NuGet 安装依赖，逐步替换而非 Copy 源码
|
||
|
||
**A - Adapt（调整适配）:**
|
||
|
||
1. Semi/Ursa 已原生支持 AOT，无需额外适配
|
||
2. ReactiveUI 只需适配自己的代码，标准库无需特殊集成
|
||
|
||
**M - Modify/Magnify（修改/放大）:**
|
||
|
||
1. LoggingControl 需要处理百万级日志流（唯一性能焦点）
|
||
2. 虚拟化 + 过滤策略
|
||
|
||
**E - Eliminate（消除简化）:**
|
||
|
||
1. Semi 中可删除大量不需要的样式代码
|
||
2. Ursa 完全不使用，减少依赖
|
||
|
||
**R - Reverse/Rearrange（逆向/重组）:**
|
||
|
||
1. **开发顺序逆转**：自顶向下，先定义复杂控件，再分解基础控件
|
||
2. **控件依赖设计**：先指定基础控件目标，适时插入复杂控件
|
||
|
||
#### Insights Discovered:
|
||
|
||
- 自顶向下避免"不知道要做什么基础控件"的困境
|
||
- 需求驱动：只做真正用到的
|
||
- 符合"快速渐进开发"目标
|
||
|
||
---
|
||
|
||
### What If Scenarios（假设情景）- 25 分钟
|
||
|
||
**Description:** 通过挑衅性情景探索边界和潜在问题
|
||
|
||
#### Ideas Generated:
|
||
|
||
**情景：极端性能挑战（百万级日志流）**
|
||
|
||
- 虚拟化性能应该可以支撑
|
||
- 过滤策略：每次只显示部分，上下卸载
|
||
- 需要编写性能测试
|
||
|
||
**情景：跨平台扩展（桌面 + Pad）**
|
||
|
||
- 当前场景：Windows 桌面 + Linux Pad（无多点触控）
|
||
- 通过 ClassName 切换桌面/Pad 模式（核心显示不变）
|
||
|
||
**情景：开源化路径**
|
||
|
||
- 策略：先私有实现大量功能，再开源
|
||
- 不影响当前设计决策
|
||
|
||
**情景：AOT 兼容性踩坑**
|
||
|
||
- PropertyGrid 如果 AOT 不可用，可以妥协
|
||
- 其他控件必须支持 AOT
|
||
- Source Generator 作为主要解决方案
|
||
|
||
**情景：依赖替换风险**
|
||
|
||
- 最差情况：不替换，可接受
|
||
- 策略：逐步替换，可回退
|
||
|
||
**情景：团队协作与学习曲线**
|
||
|
||
- 技术栈统一：ReactiveUI 为唯一方案
|
||
- 不会的就学，不提供多套 API
|
||
|
||
**情景：快速迭代 vs 质量**
|
||
|
||
- 策略：MVP + 迭代开发
|
||
- 控件库天然适合增量开发（每个控件相对独立）
|
||
- 慢慢替换到现有项目，降低风险
|
||
|
||
#### Insights Discovered:
|
||
|
||
- 职责边界明确：UI 库只负责展示，不管数据持久化
|
||
- 风险可控：允许妥协（PropertyGrid AOT）、允许不替换（Semi）
|
||
- MVP + 渐进式验证设计合理性
|
||
|
||
---
|
||
|
||
## Idea Categorization
|
||
|
||
### Immediate Opportunities
|
||
|
||
*Ideas ready to implement now*
|
||
|
||
#### 1. **依赖策略：只用 Semi，不用 Ursa**
|
||
|
||
- Description: 安装 Semi NuGet 包作为样式基础，删除 Ursa 依赖
|
||
- Why immediate: 简化依赖，减少不必要的代码
|
||
- Resources needed: 评估 Semi 样式完整性，确定需要自定义的部分
|
||
|
||
#### 2. **采用苹果颜色系统**
|
||
|
||
- Description: 建立语义化颜色规范（primary, secondary, accent, success, warning, error 等）
|
||
- Why immediate: 是所有控件样式的基础，必须先定义
|
||
- Resources needed: 研究 Apple Human Interface Guidelines 颜色系统，制定规范文档
|
||
|
||
#### 3. **开发顺序：自顶向下**
|
||
|
||
- Description: 先定义复杂控件需求，再从中分解基础控件
|
||
- Why immediate: 避免过度设计，需求驱动开发
|
||
- Resources needed: 完成控件清单优先级排序
|
||
|
||
#### 4. **MVP 第一阶段：PropertyGrid**
|
||
|
||
- Description: 最高优先级控件，自动从数据模型生成 UI
|
||
- Why immediate: 是最常用、价值最高的控件
|
||
- Resources needed: Source Generator 技术预研（AOT 支持）
|
||
|
||
#### 5. **建立项目结构**
|
||
|
||
- Description: 设置 .NET 8+、Avalonia 最新版、ReactiveUI 的项目模板
|
||
- Why immediate: 基础设施
|
||
- Resources needed: 项目脚手架、CI/CD 配置
|
||
|
||
---
|
||
|
||
### Future Innovations
|
||
|
||
*Ideas requiring development/research*
|
||
|
||
#### 1. **控件开发路线图（分阶段）**
|
||
|
||
- Description: 按优先级逐步实现完整控件库
|
||
- Development needed:
|
||
- Phase 1: PropertyGrid
|
||
- Phase 2: UserGuide 系列控件
|
||
- Phase 3: TextEditor
|
||
- Phase 4: MarkdownRender
|
||
- Phase 5: ImageEx
|
||
- Phase 6: LoggingControl
|
||
- Phase 7: Icon + 2xN Layout
|
||
- Phase 8: CodeEditor
|
||
- Phase 9: PathSelector（接口 + 实现）
|
||
- Timeline estimate: 6-12 个月（根据实际项目需求调整）
|
||
|
||
#### 2. **Chart 控件项目**
|
||
|
||
- Description: 调研 Avalonia 现有 Chart 库，进行二次开发
|
||
- Development needed: 独立项目，包含在当前大项目下
|
||
- Timeline estimate: 单独规划
|
||
|
||
#### 3. **布局/容器优化系列**
|
||
|
||
- Description: 专注性能优化的布局控件
|
||
- Development needed:
|
||
- 先实现 2xN Layout（PropertyGrid 专用）
|
||
- 后续根据需要扩展其他布局
|
||
- Timeline estimate: 按需迭代
|
||
|
||
#### 4. **Avalonia 工具类库**
|
||
|
||
- Description: 开发效率提升工具集
|
||
- Development needed:
|
||
- VisualTreeHelper/LogicalTreeHelper（视觉树/逻辑树查找）
|
||
- ControlLocator（定位控件）
|
||
- AOT Binding Helpers（AOT 绑定辅助）
|
||
- ThemeManager Commands（主题切换命令）
|
||
- LocalizationManager Commands（语言切换命令）
|
||
- 其他工具类按需添加
|
||
- Timeline estimate: 伴随控件开发逐步完善
|
||
|
||
#### 5. **桌面/Pad 双模式支持**
|
||
|
||
- Description: 通过 ClassName 切换不同平台的样式微调
|
||
- Development needed: 样式定义、响应式布局策略
|
||
- Timeline estimate: 第二阶段
|
||
|
||
#### 6. **开源准备**
|
||
|
||
- Description: 在私有功能完善后，准备开源
|
||
- Development needed: 文档、示例、License、贡献指南
|
||
- Timeline estimate: 长期目标
|
||
|
||
---
|
||
|
||
### Moonshots
|
||
|
||
*Ambitious, transformative concepts*
|
||
|
||
#### 1. **LoggingControl 百万级日志流处理**
|
||
|
||
- Description: 支持每秒数万条日志的实时显示和过滤
|
||
- Transformative potential: 成为 Avalonia 生态中性能最强的日志控件
|
||
- Challenges to overcome:
|
||
- 虚拟化渲染优化
|
||
- 内存管理策略
|
||
- 高效的过滤算法
|
||
- 性能测试和压力测试
|
||
|
||
#### 2. **PropertyGrid 的 AOT 完全支持**
|
||
|
||
- Description: 在 AOT 模式下实现完整的动态 UI 生成
|
||
- Transformative potential: 证明 Source Generator 可以完美替代反射
|
||
- Challenges to overcome:
|
||
- Source Generator 复杂度
|
||
- 类型推断和代码生成
|
||
- 编译时元数据收集
|
||
- 可能需要妥协某些高级特性
|
||
|
||
#### 3. **渐进式替换现有项目**
|
||
|
||
- Description: 在不影响稳定性的前提下，将新控件逐步替换到生产项目
|
||
- Transformative potential: 在真实场景中验证控件设计，快速迭代
|
||
- Challenges to overcome:
|
||
- 兼容性保障
|
||
- 回退机制
|
||
- 性能对比验证
|
||
- 团队培训
|
||
|
||
---
|
||
|
||
### Insights & Learnings
|
||
|
||
*Key realizations from the session*
|
||
|
||
- **战略定位清晰**: 私有生产力工具定位允许高度场景化，不追求过度通用性，可以大胆做取舍
|
||
- **需求驱动设计**: 上位机 + AI 桌面应用的固定场景，填补"业务场景集成控件"的市场空白
|
||
- **技术栈统一**: .NET 8+ / Avalonia 最新版 / ReactiveUI / AOT，不向后兼容，换取开发效率
|
||
- **职责边界明确**: UI 库只负责展示，不管数据持久化；对接系统接口（ILogger 等），不重新发明轮子
|
||
- **快速迭代哲学**: 功能优先，测试缓缓（除非必要如性能测试）；MVP + 渐进式开发，在真实项目中验证
|
||
- **自顶向下优势**: 先定义复杂控件，再分解基础控件，避免过度设计，需求驱动
|
||
- **风险可控策略**: PropertyGrid 可以妥协 AOT；依赖替换最差不替换；控件独立可回退
|
||
- **苹果颜色系统的价值**: 语义化颜色、自适应暗色模式、动态颜色支持、设计一致性
|
||
- **ReactiveUI 的核心优势**: 统一的数据流处理模型、天然支持异步操作、便于组合复杂交互逻辑
|
||
|
||
---
|
||
|
||
## Action Planning
|
||
|
||
### Top 3 Priority Ideas
|
||
|
||
#### #1 Priority: 建立项目基础设施和颜色系统
|
||
|
||
**Rationale:**
|
||
|
||
- 所有后续开发的基础
|
||
- 颜色系统是样式定义的核心
|
||
- 项目结构影响长期可维护性
|
||
|
||
**Next steps:**
|
||
|
||
1. 创建 .NET 8+ 解决方案，配置 Avalonia 最新版 + ReactiveUI
|
||
2. 安装 Semi NuGet 包，评估样式完整性
|
||
3. 制定苹果颜色系统规范文档（语义颜色、浅色/深色主题）
|
||
4. 建立 Style Class 命名规范
|
||
5. 搭建 CI/CD 基础（构建、测试、AOT 兼容性检查）
|
||
|
||
**Resources needed:**
|
||
|
||
- Apple Human Interface Guidelines 文档
|
||
- Semi 源码分析
|
||
- Avalonia 样式系统文档
|
||
|
||
**Timeline:** 1-2 周
|
||
|
||
---
|
||
|
||
#### #2 Priority: PropertyGrid MVP 开发
|
||
|
||
**Rationale:**
|
||
|
||
- 最高价值控件
|
||
- 验证自顶向下开发策略
|
||
- 验证 AOT + Source Generator 技术路线
|
||
|
||
**Next steps:**
|
||
|
||
1. 定义 PropertyGrid 的核心功能范围（MVP）
|
||
- 支持的属性类型（string, int, bool, enum, 等）
|
||
- 基础布局（2xN Layout）
|
||
- 数据绑定方式
|
||
2. 设计 Source Generator 方案（AOT 支持）
|
||
3. 实现 2xN Layout 基础控件
|
||
4. 开发 PropertyGrid 核心逻辑
|
||
5. 在一个小型测试项目中验证
|
||
|
||
**Resources needed:**
|
||
|
||
- Source Generator 技术预研
|
||
- Roslyn API 文档
|
||
- 测试项目（上位机场景）
|
||
|
||
**Timeline:** 3-4 周
|
||
|
||
---
|
||
|
||
#### #3 Priority: 制定完整控件开发路线图
|
||
|
||
**Rationale:**
|
||
|
||
- 明确长期目标和里程碑
|
||
- 合理分配开发资源
|
||
- 识别控件间的依赖关系
|
||
|
||
**Next steps:**
|
||
|
||
1. 完成完整控件清单（包括工具类）
|
||
2. 为每个控件制定功能规格（简要）
|
||
3. 识别控件间的依赖关系（例如：UserGuide 依赖 Overlay）
|
||
4. 制定分阶段开发计划（6 个月、1 年、长期）
|
||
5. 定义 MVP 范围和"可选特性"
|
||
6. 建立控件开发模板和最佳实践文档
|
||
|
||
**Resources needed:**
|
||
|
||
- 现有项目需求分析
|
||
- 竞品控件库调研（Semi、Ursa、Material Design）
|
||
|
||
**Timeline:** 1 周
|
||
|
||
---
|
||
|
||
## Reflection & Follow-up
|
||
|
||
### What Worked Well
|
||
|
||
- 第一性原理帮助明确了项目的核心价值和市场定位
|
||
- SCAMPER 方法发现了"自顶向下开发"这一关键策略调整
|
||
- What If Scenarios 识别了潜在风险和应对方案
|
||
- 讨论过程中不断澄清边界，避免了过度设计
|
||
|
||
### Areas for Further Exploration
|
||
|
||
- **Source Generator 技术深度**: 需要专门的技术预研，验证 PropertyGrid 的 AOT 可行性
|
||
- **性能基准测试**: LoggingControl 的百万级日志场景需要建立性能基准
|
||
- **Semi 样式分析**: 详细分析 Semi 的样式结构，确定哪些需要保留、哪些需要删除
|
||
- **控件功能规格**: 每个控件需要更详细的功能设计文档
|
||
- **跨平台测试**: 验证 Windows 桌面和 Linux Pad 的样式差异
|
||
|
||
### Recommended Follow-up Techniques
|
||
|
||
- **SWOT 分析**: 评估项目的优势、劣势、机会、威胁
|
||
- **用户故事映射**: 从用户角度设计控件功能
|
||
- **技术尖峰（Spike）**: 对 Source Generator、LoggingControl 性能等关键技术进行原型验证
|
||
|
||
### Questions That Emerged
|
||
|
||
- Source Generator 能否支持 PropertyGrid 的所有预期功能？
|
||
- Semi 的样式系统如何与苹果颜色系统集成？
|
||
- LoggingControl 的虚拟化策略具体实现方案？
|
||
- 如何设计控件的可扩展性（模板、样式、行为）？
|
||
- Chart 控件选择哪个现有库进行二次开发？
|
||
- 如何平衡"快速开发"和"代码质量"？
|
||
|
||
### Next Session Planning
|
||
|
||
- **Suggested topics:**
|
||
|
||
- PropertyGrid 详细设计会议
|
||
- Source Generator 技术预研总结
|
||
- 苹果颜色系统规范制定
|
||
- 控件模板和最佳实践
|
||
- **Recommended timeframe:** PropertyGrid MVP 完成后（4-6 周后）
|
||
- **Preparation needed:**
|
||
|
||
- 完成项目基础设施搭建
|
||
- 完成 Source Generator 技术预研
|
||
- 收集现有项目中的实际使用场景
|
||
|
||
---
|
||
|
||
*Session facilitated using the BMAD-METHOD™ brainstorming framework*
|