cfdaily
2.2 KiB
2.2 KiB
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"（可运行的产品）
关键特征
-
Product 和 Project 是正交的
- Project 按仓库/组织划分（代码边界）
- Product 按业务目标/交付物划分（产品边界）
- 一个 Product 可能跨越多个 Project
-
Task 间有依赖
- 策略编码依赖数据准备
- 实盘依赖模拟验证
- 跨 Project 的依赖是常见场景
-
SubTask（原子任务）天然跨 Project
- 姜维在 sanguo_vnpy 搭回测引擎，是为了 sanguo_quant_live 的"动量策略v1"这个 Task
- SubTask 的归属：属于某个 Task（需求），但实际工作可能在另一个 Project 目录
-
Product 研发可能颠覆项目制
- 传统：先有项目 → 项目内建功能
- Product 视角：先有产品目标 → 跨项目组织资源
- 这对当前的 Project 为核心的组织方式有根本性挑战
待讨论问题
- Product 的数据模型：独立表？还是轻量标签聚合？
- 跨 Project SubTask 的归属和权限如何处理
- Product 的成果物如何整合（CI/CD？手动？AI 自动？）
- Product 和 Project 的 UI 如何呈现（双维度视图？）
- 是否需要 Product 级别的进度追踪和里程碑
触发条件
当用户频繁出现以下场景时，考虑启动 Product 层设计：
- 手动跨项目协调多个 Task 完成一个产品
- 需要查看"某个产品整体进展"而非单个 Task
- 多个 Task 的产出物需要系统化整合