15 KiB
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:
- First Principles Thinking(第一性原理)
- Morphological Analysis(形态分析)
- SCAMPER Method(SCAMPER 方法)
- 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:
-
核心问题识别
- 市面上的 UI 库都是"基础控件库"(Button、TextBox 等通用组件)
- 真正加速开发的应该是"业务场景集成控件"(PropertyGrid、LoggingControl 等)
- 每个开发者业务需求不同,所以没有人做这些集成控件
- 对于固定场景(上位机 + AI 桌面),可以打造专用工具集
-
业务控件的共同特征
- 与数据模型耦合(追求"合适的通用性"而非"极致通用性")
- 由多个基础控件组合而成,但代表通用业务场景
- 例如:PropertyGrid = 自动化 UI 生成;LoggingControl = 领域数据的完整交互
-
市场空白的原因
- 商业逻辑:开源作者倾向做"影响面广"的基础控件
- 需求差异:每个人的业务定义不同
- 技术障碍:AOT、反射限制等
- 对于固定场景(上位机 + AI 桌面),这些限制不存在
Insights Discovered:
- 项目定位:私有生产力工具 > 开源通用库
- 允许高度场景化,不追求过度通用性
- PropertyGrid 可以只支持常用类型,不需要覆盖所有边缘情况
Notable Connections:
- Source Generator 可以解决 AOT 反射限制
- 对接系统接口(ILogger 等)而非重新发明轮子
Morphological Analysis(形态分析)- 25 分钟
Description: 系统化识别项目维度,探索不同选项的组合
Ideas Generated:
-
控件数据模式维度
- 选择:带数据模型的 UserControl(自包含业务单元)
- 允许 CustomControl 和 UserControl 混合存在
-
主题系统维度
- 选择:多主题,与 Avalonia 原生集成
- 采用苹果颜色系统(语义化、自适应暗色模式)
-
样式定制维度
- 选择:Style Class(通过 ClassName 切换主题)
- 利用 Avalonia 的样式扩展特性
-
交互模式维度
- 选择:ReactiveUI 作为核心交互数据流
- Command / Reactive / Event 混合使用
Insights Discovered:
- 控件类型不需要过度分类,实用性优先
- 抽象维度对固定场景项目价值有限
- 应聚焦具体控件清单和功能特性
SCAMPER Method(SCAMPER 方法)- 30 分钟
Description: 基于 Semi/Ursa 进行系统化创新改造
Ideas Generated:
S - Substitute(替代):
- 颜色系统 → 苹果颜色系统(统一规范、语义化)
- 传统样式 → Style Class 系统(灵活主题切换)
C - Combine(组合):
- 战略调整:只用 Semi(样式库),不用 Ursa(控件库)
- 部署方式:NuGet 安装依赖,逐步替换而非 Copy 源码
A - Adapt(调整适配):
- Semi/Ursa 已原生支持 AOT,无需额外适配
- ReactiveUI 只需适配自己的代码,标准库无需特殊集成
M - Modify/Magnify(修改/放大):
- LoggingControl 需要处理百万级日志流(唯一性能焦点)
- 虚拟化 + 过滤策略
E - Eliminate(消除简化):
- Semi 中可删除大量不需要的样式代码
- Ursa 完全不使用,减少依赖
R - Reverse/Rearrange(逆向/重组):
- 开发顺序逆转:自顶向下,先定义复杂控件,再分解基础控件
- 控件依赖设计:先指定基础控件目标,适时插入复杂控件
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:
- 创建 .NET 8+ 解决方案,配置 Avalonia 最新版 + ReactiveUI
- 安装 Semi NuGet 包,评估样式完整性
- 制定苹果颜色系统规范文档(语义颜色、浅色/深色主题)
- 建立 Style Class 命名规范
- 搭建 CI/CD 基础(构建、测试、AOT 兼容性检查)
Resources needed:
- Apple Human Interface Guidelines 文档
- Semi 源码分析
- Avalonia 样式系统文档
Timeline: 1-2 周
#2 Priority: PropertyGrid MVP 开发
Rationale:
- 最高价值控件
- 验证自顶向下开发策略
- 验证 AOT + Source Generator 技术路线
Next steps:
- 定义 PropertyGrid 的核心功能范围(MVP)
- 支持的属性类型(string, int, bool, enum, 等)
- 基础布局(2xN Layout)
- 数据绑定方式
- 设计 Source Generator 方案(AOT 支持)
- 实现 2xN Layout 基础控件
- 开发 PropertyGrid 核心逻辑
- 在一个小型测试项目中验证
Resources needed:
- Source Generator 技术预研
- Roslyn API 文档
- 测试项目(上位机场景)
Timeline: 3-4 周
#3 Priority: 制定完整控件开发路线图
Rationale:
- 明确长期目标和里程碑
- 合理分配开发资源
- 识别控件间的依赖关系
Next steps:
- 完成完整控件清单(包括工具类)
- 为每个控件制定功能规格(简要)
- 识别控件间的依赖关系(例如:UserGuide 依赖 Overlay)
- 制定分阶段开发计划(6 个月、1 年、长期)
- 定义 MVP 范围和"可选特性"
- 建立控件开发模板和最佳实践文档
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