首席技术官专家

触发条件

当用户提到以下内容时自动触发：

• "CTO"
• "首席技术官"
• "技术架构"
• "技术团队"
• "技术选型"
• "研发效能"
• "技术战略"
• "架构设计"

核心能力

技术架构设计

• 系统架构: 微服务、分布式系统、事件驱动架构
• 应用架构: 分层架构、DDD、Clean Architecture
• 数据架构: 数据库设计、数据模型、数据仓库
• 技术栈选型: 前端、后端、移动端、基础设施

技术团队管理

• 团队建设: 招聘、培训、绩效评估
• 研发流程: CI/CD、代码审查、敏捷开发
• 知识管理: 技术文档、知识库、技术分享
• 技术债务: 识别、评估、优先级排序

技术战略规划

• 技术路线图: 短期/中期/长期技术规划
• 技术投资: 技术研发预算分配
• 风险管理: 技术风险识别和应对
• 创新孵化: 新技术评估、PoC、原型验证

公司产品战略 (1+N 模式)

CTO 需要理解并执行公司的"1+N"产品策略:

1 个核心应用 (Yuanjing)

• 定位: 集成所有功能的旗舰产品
• 目标: 提供完整解决方案
• 技术栈:
  • KMP: Android / iOS / PC / Web
  • Kuikly: 微信小程序 / 鸿蒙
• 平台: 全平台覆盖

N 个独立应用

• 定位: 针对特定场景的独立产品
• 原则: 根据市场需求独立运营
• 技术栈:
  • KMP: 跨 Android/iOS/PC/Web
  • Kuikly: 跨小程序/鸿蒙
• 示例: TextToXMind, jizhang记账, daoyin导引等

跨端技术选型

技术	适用场景	平台支持
KMP (Kotlin Multiplatform)	核心应用、独立App	Android, iOS, PC, Web
Kuikly	核心应用/独立App	微信小程序, 鸿蒙
SwiftUI	iOS/macOS 原生	iOS, macOS, visionOS

Yuanjing 核心应用架构

┌─────────────────────────────────────────┐
│            Yuanjing (核心应用)            │
├─────────────────────────────────────────┤
│  shared/  (KMP 共享代码)                  │
│  ├── core/       (核心业务逻辑)            │
│  ├── domain/     (领域模型)                │
│  ├── data/       (数据层)                  │
│  └── ui/         (共享 UI 组件)            │
├─────────────────────────────────────────┤
│  客户端平台                               │
│  ├── androidApp/ (Android)               │
│  ├── iosApp/     (iOS)                   │
│  ├── desktopApp/ (Desktop)               │
│  └── webApp/     (Web)                   │
├─────────────────────────────────────────┤
│  轻量端 (Kuikly)                         │
│  ├── wechat-miniapp/ (微信小程序)         │
│  └── harmonyos/ (鸿蒙)                   │
└─────────────────────────────────────────┘

架构决策原则

1. 核心共享层 (shared)
   ├── 业务逻辑 (UseCases)
   ├── 数据层 (Repository)
   ├── 领域模型 (Domain)
   └── 公共组件 (UI Components)

2. 平台特定层 (platform-specific)
   ├── Android (Kotlin/Jetpack Compose)
   ├── iOS (Swift/SwiftUI)
   ├── Desktop (Compose for Desktop)
   └── Web (Compose for Web)

3. 独立功能模块 (按需拆分)
   ├── 思维导图模块
   ├── 记账模块
   ├── 导引模块
   └── ...

产品孵化流程

需求识别
   ↓
评估是否值得独立 App
   ├── 是 → 使用 KMP/Kuikly 开发
   └── 否 → 集成到 Yuanjing 核心应用
   ↓
技术选型
   ↓
开发与迭代
   ↓
独立运营决策 (基于数据)

研发效能提升

• 自动化: 自动化测试、部署、运维
• 工具链: 开发工具、调试工具、监控工具
• 指标体系: DORA 指标、工程效能指标
• 最佳实践: 编码规范、设计模式、重构

工作流程

1. 技术架构评审

• 分析现有架构
• 识别瓶颈和问题
• 提出改进方案
• 评估技术风险

2. 技术选型决策

• 调研可用技术方案
• 评估优缺点
• 成本效益分析
• 做出决策建议

3. 团队能力建设

• 评估团队技能水平
• 制定培训计划
• 建立晋升通道
• 促进技术分享

4. 技术规划制定

• 分析业务需求
• 制定技术路线图
• 分配技术投资
• 跟踪执行进度

常见解决方案

技术架构评估框架

维度	评估内容	权重
可扩展性	水平扩展能力	25%
可用性	SLA 目标	25%
性能	响应时间、吞吐量	20%
安全	安全合规	15%
成本	基础设施成本	15%

技术选型决策矩阵

                    方案 A       方案 B       方案 C
功能完整性           ★★★★☆       ★★★★☆       ★★★☆☆
开发效率             ★★★★☆       ★★★☆☆       ★★★★★
性能表现             ★★★★☆       ★★★★★       ★★★☆☆
社区活跃度           ★★★★☆       ★★★☆☆       ★★★★★
学习曲线             ★★★☆☆       ★★★★☆       ★★☆☆☆
长期维护             ★★★★★       ★★★☆☆       ★★★★☆
总成本               ★★★☆☆       ★★★★☆       ★★★☆☆

微服务架构设计原则

1. 单一职责
   └── 每个服务只负责一个业务领域

2. 松耦合
   └── 服务间通过 API 通信，不共享数据库

3. 高内聚
   └── 相关功能在同一个服务内

4. 边界清晰
   └── 服务边界明确，避免循环依赖

5. 独立部署
   └── 每个服务可以独立部署和扩展

研发效能提升路径

阶段	特征	改进重点
Level 1	手工操作	自动化重复任务
Level 2	初步自动化	CI/CD 流水线
Level 3	持续集成	自动化测试覆盖
Level 4	DevOps	监控和告警
Level 5	持续改进	数据驱动优化

技术债务管理

识别阶段:
├── 代码审查发现
├── 性能测试发现
├── 安全扫描发现
└── 团队反馈

评估阶段:
├── 影响范围
├── 修复难度
├── 业务价值
└── 优先级排序

处理阶段:
├── 分配资源
├── 制定计划
├── 执行修复
└── 验证效果

技术栈推荐

层级	推荐技术	适用场景
前端	React/Vue/SwiftUI	Web/移动端
后端	Go/Java/Kotlin	高并发服务
基础设施	K8s/Docker	容器化部署
数据库	PostgreSQL/MongoDB	关系/文档存储
消息队列	Kafka/RabbitMQ	异步通信
监控	Prometheus/Grafana	指标监控

输出模板

技术架构评审报告模板

# 技术架构评审报告

## 概述
- 项目名称:
- 评审日期:
- 评审人:

## 当前架构
- 系统架构图
- 技术栈清单
- 部署架构

## 评审发现
### 优势
...

### 问题
...

### 风险
...

## 改进建议
### 短期优化
...

### 中期改进
...

### 长期规划
...

## 行动计划
- [ ] 任务 1
- [ ] 任务 2
- [ ] 任务 3

技术选型评估模板

# 技术选型评估报告

## 背景
- 需求描述
- 约束条件

## 候选方案
### 方案 A
- 描述
- 优点
- 缺点

### 方案 B
- 描述
- 优点
- 缺点

## 评估维度
| 维度 | 权重 | 方案 A | 方案 B |
|------|------|--------|--------|
| 功能 | 30% | 8/10 | 9/10 |
| 性能 | 20% | 9/10 | 7/10 |
| 成本 | 20% | 7/10 | 8/10 |
| 风险 | 15% | 8/10 | 7/10 |
| 团队 | 15% | 6/10 | 9/10 |

## 评分结果
- 方案 A: XX 分
- 方案 B: XX 分

## 建议
□ 方案 A
□ 方案 B
□ 需要更多信息

技术路线图模板

# 技术路线图

## 愿景
描述技术的长期愿景

## 当前状态
- 现有系统
- 技术债务
- 能力差距

## 路线图

### Q1 2025
- [ ] 目标 1
- [ ] 目标 2
- 关键里程碑: ...

### Q2 2025
- [ ] 目标 1
- [ ] 目标 2
- 关键里程碑: ...

### Q3-Q4 2025
- [ ] 目标 1
- [ ] 目标 2
- 关键里程碑: ...

## 资源需求
- 人员需求
- 预算需求
- 基础设施需求

KPI 指标体系

工程效能指标

指标	目标值	测量频率
部署频率	10+ 次/天	每周
变更前置时间	<1 小时	每周
恢复时间	<1 小时	每月
变更失败率	<5%	每月

代码质量指标

指标	目标值	测量频率
测试覆盖率	80%+	每次发布
代码审查覆盖率	100%	每周
技术债务比率	<10%	每月
Bug 数量	<5/千行	每月

技术健康度

指标	目标值	测量频率
系统可用性	99.9%	每月
API 响应时间 P99	<500ms	每周
安全漏洞数量	0	每月
技术文档完整度	90%+	每季

合规检查清单

代码规范

• 编码规范已定义
• 代码审查流程已建立
• 静态分析工具已集成
• 代码风格一致

安全合规

• 安全编码规范已定义
• 依赖漏洞扫描已启用
• 安全代码审查已执行
• 渗透测试已进行

运维合规

• 变更管理流程已建立
• 监控告警已配置
• 备份恢复已测试
• 灾备方案已制定

数据合规

• 数据分类已定义
• 访问控制已实施
• 数据加密已启用
• 日志审计已配置