# Product 方向备忘录

> 日期：2026-05-18
> 状态：讨论记录，非当前实施范围
> 参与者：用户、庞统

## 核心概念

### 当前三层模型（v2.7+ 实施中）

```
Project（项目/仓库）
  └── Task（用户需求/意图/目标）
        └── SubTask（Agent 执行的原子任务/Stage）
```

### 未来方向：Product 层

Product（产品）= 跨 Project 的 Task 聚合，多个 Task 的产出物组合成一个完整产品。

```
Product（产品/交付物）
  ├── Task A（sanguo_quant_live：动量策略开发）
  ├── Task B（sanguo_vnpy：回测引擎搭建）
  ├── Task C（sanguo_quant_live：实时数据接入）
  └── Task D（sanguo_vnpy：模拟交易平台）
  
  产出物整合 → "动量交易系统 v1"（可运行的产品）
```

### 关键特征

1. **Product 和 Project 是正交的**
   - Project 按仓库/组织划分（代码边界）
   - Product 按业务目标/交付物划分（产品边界）
   - 一个 Product 可能跨越多个 Project

2. **Task 间有依赖**
   - 策略编码依赖数据准备
   - 实盘依赖模拟验证
   - 跨 Project 的依赖是常见场景

3. **SubTask（原子任务）天然跨 Project**
   - 姜维在 sanguo_vnpy 搭回测引擎，是为了 sanguo_quant_live 的"动量策略v1"这个 Task
   - SubTask 的归属：属于某个 Task（需求），但实际工作可能在另一个 Project 目录

4. **Product 研发可能颠覆项目制**
   - 传统：先有项目 → 项目内建功能
   - Product 视角：先有产品目标 → 跨项目组织资源
   - 这对当前的 Project 为核心的组织方式有根本性挑战

### 待讨论问题

- [ ] Product 的数据模型：独立表？还是轻量标签聚合？
- [ ] 跨 Project SubTask 的归属和权限如何处理
- [ ] Product 的成果物如何整合（CI/CD？手动？AI 自动？）
- [ ] Product 和 Project 的 UI 如何呈现（双维度视图？）
- [ ] 是否需要 Product 级别的进度追踪和里程碑

### 触发条件

当用户频繁出现以下场景时，考虑启动 Product 层设计：
1. 手动跨项目协调多个 Task 完成一个产品
2. 需要查看"某个产品整体进展"而非单个 Task
3. 多个 Task 的产出物需要系统化整合