# 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 再多，也不会重新回到混乱状态。