Xiaoxia AI
b5a62ee9a3
- domain: User, Workspace, Project, AssetLibrary, Asset, IngestJob - ports: repository interfaces - application: use cases - adapters: in-memory - API: FastAPI 5 routes - worker: Celery ingest_asset - tests: 4 passing
229 lines
3.7 KiB
Markdown
229 lines
3.7 KiB
Markdown
# SaaS 开发协作流程与制度（第一版）
|
|
|
|
本文档定义新 SaaS 项目的开发流程、提交流程、验收流程和 AI 协作制度。
|
|
|
|
目标：
|
|
|
|
- 避免边想边改
|
|
- 避免多人同时乱改
|
|
- 避免 AI 输出直接进主线
|
|
- 让每一步都可回溯、可检查、可收口
|
|
|
|
---
|
|
|
|
## 1. 总流程
|
|
|
|
新 SaaS 项目统一按 7 步执行：
|
|
|
|
1. 定目标
|
|
2. 写文档
|
|
3. 拆任务
|
|
4. 做设计
|
|
5. 写代码
|
|
6. Review / 测试
|
|
7. 提交 / 发布
|
|
|
|
禁止跳步直接开写。
|
|
|
|
---
|
|
|
|
## 2. 需求到开发的流程
|
|
|
|
### 第 1 步：需求确认
|
|
|
|
由老大提出：
|
|
|
|
- 目标
|
|
- 用户对象
|
|
- 边界
|
|
- 验收标准
|
|
|
|
### 第 2 步：小虾整理
|
|
|
|
小虾负责：
|
|
|
|
- 转成结构化需求
|
|
- 明确范围
|
|
- 识别依赖
|
|
- 标记风险
|
|
|
|
### 第 3 步：文档先行
|
|
|
|
至少先补以下之一：
|
|
|
|
- PRD / 范围文档
|
|
- 架构文档
|
|
- 流程文档
|
|
- 数据模型草稿
|
|
- API 草稿
|
|
|
|
文档不清，不开工。
|
|
|
|
### 第 4 步：任务拆解
|
|
|
|
一个功能必须拆成明确任务，例如：
|
|
|
|
- 前端页面
|
|
- API 接口
|
|
- 用例层
|
|
- 数据模型
|
|
- 任务执行链
|
|
- 测试
|
|
|
|
### 第 5 步：实现
|
|
|
|
按既定分工执行：
|
|
|
|
- UI AI 先出页面方案
|
|
- 小虾定架构和边界
|
|
- 编码 AI 实现模块
|
|
|
|
### 第 6 步：Review 和测试
|
|
|
|
必须独立执行：
|
|
|
|
- Review AI 看架构和风险
|
|
- QA AI 看测试和回归
|
|
- CI 跑自动检查
|
|
|
|
### 第 7 步：收口
|
|
|
|
小虾负责：
|
|
|
|
- 汇总变更
|
|
- 检查一致性
|
|
- 确认是否满足验收标准
|
|
- 再执行提交/推送/发布
|
|
|
|
---
|
|
|
|
## 3. 提交流程
|
|
|
|
统一流程：
|
|
|
|
1. 开发完成
|
|
2. 本地检查 / 单测 / 必要验证
|
|
3. Review
|
|
4. CI 通过
|
|
5. `git add`
|
|
6. `git commit`
|
|
7. `git push`
|
|
8. 记录发布或变更说明
|
|
|
|
铁律：
|
|
|
|
- 不能停在 commit
|
|
- 没 review / 没测试 / 没 CI 通过的代码不能进主线
|
|
|
|
---
|
|
|
|
## 4. 验收流程
|
|
|
|
每个功能都必须有验收标准。
|
|
|
|
验收至少包含：
|
|
|
|
- 功能是否符合目标
|
|
- 是否超出边界
|
|
- 是否破坏架构
|
|
- 是否有测试
|
|
- 是否可回归
|
|
- 是否文档同步
|
|
|
|
如果只是“代码写出来了”，不算完成。
|
|
|
|
---
|
|
|
|
## 5. AI 协作制度
|
|
|
|
### 5.1 分工制度
|
|
|
|
- 老大：产品 owner
|
|
- 小虾：技术 owner
|
|
- UI AI：页面和交互
|
|
- 编码 AI：具体实现
|
|
- Review AI：代码审查
|
|
- QA AI：测试和回归
|
|
|
|
### 5.2 一个任务一个 owner
|
|
|
|
- 一个任务只能有一个主执行者
|
|
- 其他 AI 可以辅助，不能平行乱改
|
|
|
|
### 5.3 架构收口权唯一
|
|
|
|
- 架构方向由小虾收口
|
|
- 老大拍板
|
|
- 其他 AI 不能随意改主方向
|
|
|
|
### 5.4 AI 输出不能直接上线
|
|
|
|
AI 输出必须经过：
|
|
|
|
- 人工确认
|
|
- Code Review
|
|
- 自动化测试
|
|
- CI 验证
|
|
|
|
---
|
|
|
|
## 6. 分支与变更管理建议
|
|
|
|
如果新项目正式启动，建议采用：
|
|
|
|
- `master` / `main`：稳定主线
|
|
- 功能分支：按模块开发
|
|
- 重要改动走 PR / 合并审查
|
|
|
|
如果前期仍是小团队轻量开发，也至少要做到：
|
|
|
|
- 每次改动范围明确
|
|
- commit message 清楚
|
|
- 一轮改动一个主题
|
|
|
|
---
|
|
|
|
## 7. 发布流程
|
|
|
|
发布前必须确认：
|
|
|
|
- 功能验收通过
|
|
- 回归通过
|
|
- CI 通过
|
|
- 文档更新
|
|
- 日志/监控可用
|
|
- 回滚方式明确
|
|
|
|
发布后必须确认：
|
|
|
|
- 服务在线
|
|
- 核心流程在线可用
|
|
- 巡检和告警正常
|
|
|
|
---
|
|
|
|
## 8. 不允许再发生的情况
|
|
|
|
- 边想边改、越改越乱
|
|
- 没有文档直接开工
|
|
- 多个 AI 同时改同一块逻辑
|
|
- AI 代码直接进主线
|
|
- 口头规则替代正式制度
|
|
- 旧桌面版那种临时修复脚本文化带入新项目
|
|
|
|
---
|
|
|
|
## 9. 当前阶段结论
|
|
|
|
新 SaaS 项目从第一天开始就要按正规软件流程走：
|
|
|
|
- 先定目标
|
|
- 再写文档
|
|
- 再拆任务
|
|
- 再设计
|
|
- 再实现
|
|
- 再 review / 测试
|
|
- 最后提交 / 发布
|
|
|
|
这样我们后面人再多、AI 再多，也不会重新回到混乱状态。
|