Files

T

Xiaoxia AI b5a62ee9a3 feat: initial SaaS scaffold

- 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

2026-06-15 15:17:40 +08:00

3.7 KiB

Raw Permalink Blame History

SaaS 开发协作流程与制度（第一版）

本文档定义新 SaaS 项目的开发流程、提交流程、验收流程和 AI 协作制度。

目标：

避免边想边改
避免多人同时乱改
避免 AI 输出直接进主线
让每一步都可回溯、可检查、可收口

1. 总流程

新 SaaS 项目统一按 7 步执行：

定目标
写文档
拆任务
做设计
写代码
Review / 测试
提交 / 发布

禁止跳步直接开写。

2. 需求到开发的流程

第 1 步：需求确认

由老大提出：

目标
用户对象
边界
验收标准

第 2 步：小虾整理

小虾负责：

转成结构化需求
明确范围
识别依赖
标记风险

第 3 步：文档先行

至少先补以下之一：

PRD / 范围文档
架构文档
流程文档
数据模型草稿
API 草稿

文档不清，不开工。

第 4 步：任务拆解

一个功能必须拆成明确任务，例如：

前端页面
API 接口
用例层
数据模型
任务执行链
测试

第 5 步：实现

按既定分工执行：

UI AI 先出页面方案
小虾定架构和边界
编码 AI 实现模块

第 6 步：Review 和测试

必须独立执行：

Review AI 看架构和风险
QA AI 看测试和回归
CI 跑自动检查

第 7 步：收口

小虾负责：

汇总变更
检查一致性
确认是否满足验收标准
再执行提交/推送/发布

3. 提交流程

统一流程：

开发完成
本地检查 / 单测 / 必要验证
Review
CI 通过
git add
git commit
git push
记录发布或变更说明

铁律：

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

3.7 KiB Raw Permalink Blame History