如果我是这个“旅搭出行”项目的软件开发负责人，而且只有我一个开发，我不会一上来就猛写代码。我会把自己拆成几个角色来工作：

产品负责人：决定做什么、不做什么
架构负责人：决定系统边界、模块边界、数据边界
后端开发：实现业务能力和接口契约
前端开发：实现 web 管理后台
移动端开发：实现 uni-app 用户端
测试人员：写验收用例、联调清单、异常场景
运维人员：部署、日志、监控、备份、发布流程
UI 设计：交给 AI 生成风格和页面参考

重点不是“一个人硬扛所有事情”，而是：

一个人用 AI 把团队角色拆出来，然后按流程推进。

一、项目定位：先明确“旅搭出行”到底是什么

我会先把项目定义成：

一个面向年轻用户的出行搭子 / 活动社交平台，用户可以发布活动、报名活动、寻找同行搭子，后台运营人员负责内容审核、用户管理、活动管理、订单/报名管理、投诉反馈、运营配置和数据统计。

第一阶段不要做成大而全的旅游平台，也不要一开始做复杂 OTA、酒店、机票、行程商城。

第一阶段核心应该是：

用户注册登录
用户资料
活动发布
活动报名
搭子匹配
动态发布
评论互动
消息通知
后台审核
后台配置
基础运营

也就是先做一个：

活动 + 搭子 + 内容审核 + 运营后台

而不是一上来做：

携程 + 小红书 + Soul + 微信群 + 电商订单系统

那样一个人很容易做散。

二、整体系统组成

我会拆成四个项目：

litour-backend     后端 Spring Boot 项目
litour-web-admin   Web 管理后台 Vue3 项目
litour-uniapp      移动端 uni-app 项目
litour-docs        项目文档 / 接口契约 / 需求文档 / 测试用例

如果你现在已经有三个项目，也可以不单独建 litour-docs，直接在 backend 或根目录维护：

docs/
├── product
├── API
├── database
├── test
├── deploy
└── prompt

但是长期来看，我更建议文档独立管理，或者至少作为 monorepo 根目录的一部分。

三、我会采用的总开发策略

我不会采用“前端先做完，然后后端补接口”，也不会采用“后端先把所有表设计完，再做前端”。

我会采用：

业务流程驱动
接口契约先行
前后端 mock 并行
后端逐步真实实现
联调逐模块推进

整体流程是：

1. 先定 MVP 范围
2. 按模块画出业务流程
3. 为每个模块写接口契约
4. web / uni-app 先用 mock 跑页面
5. backend 按接口契约实现
6. 前端逐个模块切真实接口
7. 每个模块联调完成后冻结契约
8. 最后统一测试、部署、监控

核心原则：

前端 mock 可以先存在
但最终必须沉淀为 API 契约

后端字段可以复杂
但对外接口必须稳定

web 和 uni-app 可以有各自接口
但底层业务能力尽量复用

四、项目角色怎么由 AI 分工

我会给 AI 分配固定角色，而不是随便问。

1. 产品经理 AI

负责：

整理需求
拆模块
写用户故事
写业务流程
写验收标准
判断功能优先级

输出文件：

docs/product/01-项目定位.md
docs/product/02-MVP功能范围.md
docs/product/03-用户端需求.md
docs/product/04-管理后台需求.md
docs/product/05-业务流程.md

2. 架构师 AI

负责：

模块边界
DDD 聚合设计
数据库设计
接口风格
权限模型
异常补偿
状态机
部署结构

输出文件：

docs/architecture/01-系统架构.md
docs/architecture/02-模块边界.md
docs/architecture/03-DDD领域模型.md
docs/architecture/04-权限模型.md
docs/architecture/05-状态机设计.md

3. 后端开发 AI

负责：

Spring Boot 代码
Controller
Application Service
Domain Service
Repository
MyBatis-Plus Mapper
权限校验
接口实现
单元测试

输出：

backend 代码
docs/API 接口契约
docs/database 表结构文档

4. 前端开发 AI

负责 web-admin：

菜单
路由
权限控制
页面开发
表格
表单
审核弹窗
运营配置页面
接口封装
mock 数据

5. 移动端开发 AI

负责 uni-app：

首页
活动列表
活动详情
报名
发布活动
搭子匹配
我的页面
消息通知
登录授权

6. 测试 AI

负责：

测试用例
联调 checklist
异常场景
边界数据
接口测试
回归测试

7. 运维 AI

负责：

Dockerfile
Docker Compose
Nginx
MySQL
Redis
日志目录
备份脚本
发布脚本
监控方案

五、项目模块规划

我会先按业务能力拆模块，而不是按页面拆。

用户端 app 模块

认证模块
用户模块
活动模块
搭子匹配模块
动态模块
评论模块
通知模块
文件上传模块
微信支付回调模块
通用模块

对应你现在的 app 文档结构基本合理：

docs/API/app
├── 00-INDEX.md
├── 01-认证模块.md
├── 02-用户模块.md
├── 03-活动模块.md
├── 04-搭子匹配模块.md
├── 05-通知模块.md
├── 06-Post动态模块.md
├── 07-Comment评论模块.md
├── 08-Topic话题模块.md
├── 09-文件上传.md
├── 10-通用模块.md
└── 11-微信支付回调.md

web-admin 模块

认证与管理员
用户管理
内容审核
活动与订单
系统配置
运营管理
数据统计
客服反馈
系统监控
通用工具

你现在这个结构也可以继续用：

docs/API/web-admin
├── 00-INDEX.md
├── 01-认证与管理员.md
├── 02-用户管理.md
├── 03-内容审核.md
├── 04-活动与订单.md
├── 05-系统配置.md
├── 06-运营管理.md
├── 07-数据统计.md
├── 08-客服反馈.md
├── 09-系统监控.md
└── 10-通用工具.md

common 通用接口

我会额外加：

docs/API/common
├── 01-文件上传.md
├── 02-字典枚举.md
├── 03-地区城市.md
├── 04-验证码.md
├── 05-通用配置.md
└── 06-通用响应结构.md

因为有些接口不属于 app，也不属于 web-admin。

比如：

文件上传
字典枚举
城市地区
验证码
系统配置读取
协议内容

这些可以抽到 common。

六、接口契约管理方案

这是你当前最关心的地方。

我会规定：

所有接口新增之前，必须先进入 docs/API
所有字段命名，必须先进入接口契约
所有 mock 数据，必须来自接口契约
所有后端实现，必须对齐接口契约

也就是说：

docs/API 是唯一接口契约中心

不是前端 mock 说了算，也不是后端 Entity 说了算。

真正说了算的是：

业务需求 + API 契约

每个接口文档统一模板

我会让每个接口都按这个格式写：

## 接口名称

### 基本信息

| 项 | 内容 |
|---|---|
| 接口名称 | 活动列表 |
| 接口归属 | app |
| 请求方式 | GET |
| 请求路径 | /api/app/activities |
| 是否需要登录 | 否 |
| 权限码 | 无 |
| 状态 | 待后端开发 |
| 是否复用 | 否 |
| 复用说明 | 复用活动领域服务，不复用后台接口 |

### 使用场景

用户端首页 / 活动列表页展示可报名活动。

### 请求参数

| 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
| keyword | string | 否 | 搜索关键词 |
| cityCode | string | 否 | 城市编码 |
| pageNo | number | 是 | 页码 |
| pageSize | number | 是 | 每页数量 |

### 响应字段

| 字段 | 类型 | 说明 |
|---|---|---|
| id | string | 活动ID |
| title | string | 活动标题 |
| coverUrl | string | 封面图 |
| cityName | string | 城市名称 |
| startTime | string | 开始时间 |
| applyCount | number | 已报名人数 |
| maxPeople | number | 最大人数 |
| status | string | 活动状态 |
| statusName | string | 活动状态文案 |

### 响应示例

```json
{
  "code": "0000",
  "message": "success",
  "data": {
    "records": [
      {
        "id": "10001",
        "title": "周末东京 City Walk",
        "coverUrl": "https://xxx.com/a.jpg",
        "cityName": "东京",
        "startTime": "2026-06-01 10:00:00",
        "applyCount": 8,
        "maxPeople": 12,
        "status": "PUBLISHED",
        "statusName": "报名中"
      }
    ],
    "total": 1
  }
}

异常情况

code	说明
40001	参数错误
50000	系统异常

联调备注

app 只展示已发布活动
不返回审核备注
不返回后台风控字段

---

## 接口状态必须明确

我会定义接口状态：

```text
mock中
待后端开发
后端开发中
后端已完成
联调中
已联调
已上线
废弃

这样你在 vibe coding 的时候，不会乱。

比如：

| 接口名称 | 端 | 方法 | 路径 | 状态 |
|---|---|---|---|---|
| 活动列表 | app | GET | /api/app/activities | mock中 |
| 活动详情 | app | GET | /api/app/activities/{id} | 待后端开发 |
| 活动审核列表 | web-admin | GET | /api/admin/activity/audit/page | 已联调 |

七、web 和 uni-app 接口是否复用的判断规则

我不会强行要求 web 和 uni-app 复用同一个接口。

我会分三类。

第一类：可以直接复用

例如：

文件上传
验证码
地区城市
字典枚举
协议内容
图片资源

这种可以放到：

/api/common/xxx

第二类：不能复用接口，但可以复用业务服务

例如：

活动列表
活动详情
用户详情
动态详情
评论列表
订单详情

app 和 web-admin 都需要，但是视角不同。

app 关注：

能不能展示
能不能报名
用户看到什么
是否已收藏
是否已报名

web-admin 关注：

审核状态
创建人
举报数
下架原因
审核记录
内部备注
操作日志

这种我会设计成：

/api/app/activities/{id}
/api/admin/activities/{id}

Controller 分开，但后端复用：

ActivityApplicationService
ActivityDomainService
ActivityRepository

第三类：完全独立接口

例如：

后台管理员登录
后台角色权限
后台运营配置
后台系统监控
app 用户报名
app 搭子匹配
app 发布动态

这些不需要强行复用。

八、后端架构设计

你的项目是重后端，我会坚持后端主导业务能力。

后端使用：

Spring Boot 3.4
JDK 17
MyBatis-Plus
MySQL
Redis
Spring Security
JWT
Knife4j / Swagger
Docker
Nginx

项目结构我会按模块 + 六边形架构组织。

大概是：

backend
├── litour-bootstrap
├── litour-common
├── litour-infrastructure
├── litour-domain
├── litour-application
└── litour-adapter

如果你觉得多模块太重，也可以先用单体模块，但包结构按六边形分：

com.litour
├── common
├── security
├── module
│   ├── auth
│   ├── user
│   ├── activity
│   ├── match
│   ├── post
│   ├── comment
│   ├── notification
│   ├── admin
│   ├── permission
│   └── system
└── infrastructure

后端 Controller 分端

我会明确分：

app 端接口
admin 端接口
common 通用接口
callback 回调接口

例如：

controller
├── app
│   ├── AppAuthController
│   ├── AppUserController
│   ├── AppActivityController
│   └── AppPostController
├── admin
│   ├── AdminAuthController
│   ├── AdminUserController
│   ├── AdminActivityController
│   └── AdminAuditController
├── common
│   ├── FileController
│   └── DictController
└── callback
    └── WechatPayCallbackController

接口路径统一：

/api/app/**
/api/admin/**
/api/common/**
/api/callback/**

后端不要让 Entity 直接返回前端

我会严格分：

Entity：数据库表映射
Domain：领域对象
Command：写操作入参
Query：查询入参
DTO：应用层数据
VO：接口响应

例如：

ActivityEntity
ActivityAggregate
CreateActivityCommand
ActivityPageQuery
ActivityDetailDTO
AppActivityDetailVO
AdminActivityDetailVO

app 和 admin 可以使用不同 VO：

AppActivityDetailVO
AdminActivityDetailVO

这可以避免一个接口返回越来越臃肿。

九、权限系统方案

你前面已经遇到权限码不一致的问题，所以我会一开始就定死规则。

权限码格式

module:resource:action

例如：

system:admin-user:list
system:admin-user:view
system:admin-user:create
system:admin-user:update
system:admin-user:delete

content:post:list
content:post:view
content:post:approve
content:post:reject

activity:activity:list
activity:activity:view
activity:activity:approve
activity:activity:reject
activity:activity:offline

权限来源

我会规定：

后端权限字典是唯一来源
前端路由 meta.permission 必须对齐后端权限码
数据库 permissions 表由后端初始化或脚本维护

不要让前端随便写权限码。

登录返回

后台登录返回：

{
  "token": "xxx",
  "userInfo": {
    "id": "1",
    "nickname": "管理员"
  },
  "permissions": [
    "system:admin-user:list",
    "content:post:approve"
  ],
  "menus": []
}

前端根据：

permissions 控制按钮
menus 或 asyncRoutes 控制菜单

但是最终安全依然在后端：

@PreAuthorize("hasAuthority('content:post:approve')")

十、数据库设计策略

我不会一次性把所有表设计到极致。

我会分阶段：

第一阶段核心表

用户表
用户资料表
管理员表
角色表
权限表
角色权限表
管理员角色表
活动表
活动报名表
动态表
评论表
通知表
文件表
审核记录表
系统配置表
操作日志表

第二阶段扩展表

搭子匹配偏好表
搭子匹配记录表
话题表
用户收藏表
举报表
反馈表
订单表
支付流水表
退款记录表
消息会话表

第三阶段运营数据表

活动浏览统计
用户行为日志
转化统计
运营活动配置
推荐权重配置
风控记录

十一、前端 web-admin 方案

web-admin 我不会做得花里胡哨。

目标是：

运营人员能用
审核人员能用
自己能维护
权限清晰
页面稳定

技术栈：

Vue3
Vite
TypeScript
Pinia
Vue Router
Element Plus
Axios
Mock

后台页面结构：

登录
首页工作台
用户管理
内容审核
活动管理
报名 / 订单管理
运营配置
数据统计
客服反馈
系统配置
权限管理
系统监控

web-admin 开发方式

我会让 web 先基于 mock 跑通：

页面
表格
搜索
分页
详情
审核弹窗
新增编辑表单
权限控制

但是 mock 文件必须和 API 文档同步。

也就是：

mock 数据不是随便写
mock 数据必须来自 docs/API

十二、uni-app 移动端方案

uni-app 第一阶段不要做太复杂。

核心页面：

首页
活动列表
活动详情
发布活动
搭子匹配
动态列表
动态详情
消息通知
我的
登录授权
个人资料

第一阶段优先做：

用户能看活动
用户能报名
用户能发布活动
用户能查看自己的报名
后台能审核
后台能管理

这条闭环打通，项目就有价值了。

十三、UI 设计怎么交给 AI

UI 我不会自己纠结太久。

我会先定一套风格：

年轻化
轻社交
旅行感
清爽
卡片式
暖色
适合小程序

然后让 AI 生成：

首页设计稿
活动卡片
活动详情
报名弹窗
我的页面
后台工作台
审核列表
数据看板

前端不需要 100% 还原设计图，先做到：

布局清晰
风格统一
操作顺畅

十四、测试方案

一个人开发最容易忽略测试，但我会让 AI 帮我生成测试清单。

每个模块有三类测试：

1. 接口测试

正常参数
缺少参数
非法参数
未登录
无权限
数据不存在
重复提交
状态不允许

2. 前端页面测试

列表加载
搜索筛选
分页
空数据
错误提示
按钮权限
弹窗确认
表单校验

3. 业务流程测试

例如活动审核：

用户发布活动
后台看到待审核活动
后台审核通过
app 活动列表展示
用户报名活动
报名人数增加
活动满员后禁止报名
活动下架后不再展示

十五、运维部署方案

第一阶段我会用简单但规范的 Docker Compose。

服务包括：

Nginx
backend
MySQL
Redis
web-admin 静态资源

目录结构：

deploy
├── docker-compose.yml
├── nginx
│   ├── nginx.conf
│   └── conf.d
├── mysql
│   ├── data
│   └── initdb
├── redis
├── logs
└── scripts
    ├── deploy-backend.sh
    ├── deploy-web.sh
    └── backup-mysql.sh

访问路径

web-admin:
https://admin.xxx.com

backend API:
https://api.xxx.com/api

uni-app:
请求 https://api.xxx.com/api/app/**

日志策略

backend 日志挂载到宿主机
Nginx 日志挂载到宿主机
MySQL 定时备份
Redis 不保存核心业务数据
异常日志后续接入 AI 分析

十六、项目推进节奏

如果是我一个人做，我会按 6 个阶段推进。

第一阶段：项目骨架和规范

目标：

三个项目能启动
文档结构建立
接口规范建立
权限规范建立
部署结构建立

产出：

backend 基础工程
web-admin 基础工程
uni-app 基础工程
docs/API
docs/product
docs/deploy

第二阶段：认证与权限闭环

目标：

app 用户登录
web-admin 管理员登录
JWT 鉴权
RBAC 权限
菜单权限
按钮权限

为什么先做这个？

因为后面所有接口都依赖身份和权限。

第三阶段：活动业务闭环

目标：

app 发布活动
web-admin 审核活动
app 展示活动
app 报名活动
web-admin 管理报名

这是项目第一条核心业务闭环。

第四阶段：内容互动闭环

目标：

用户发动态
用户评论
后台审核动态
后台处理举报
通知用户审核结果

第五阶段：运营后台增强

目标：

运营配置
话题管理
推荐配置
数据统计
反馈处理
系统监控

第六阶段：部署上线和优化

目标：

服务器部署
Nginx 配置
HTTPS
日志
备份
接口压测
异常修复
上线验收

十七、我会怎么安排每天的开发工作

我不会每天打开 Cursor 就让它随便写。

我会这样做：

上午：梳理当天模块契约
下午：让 AI 生成代码
晚上：联调和修复
睡前：更新文档和 checklist

每个功能固定流程：

1. 写业务说明
2. 写接口契约
3. 写 mock 数据
4. 写后端接口
5. 写前端调用
6. 联调
7. 写测试结果
8. 标记接口状态

这套流程会让你越做越稳。

十八、具体到 Cursor 的工作方式

我会开三个 Cursor 窗口：

Cursor Backend
Cursor Web Admin
Cursor Uni-app

但是它们不能各干各的。

它们共同读取：

docs/API
docs/product
docs/architecture

我会给每个 Cursor 一个固定规则。

Backend Cursor 规则

你只能根据 docs/API 实现接口。
如果发现接口字段不合理，先修改文档，不要直接改代码。
Entity 不允许直接返回前端。
Controller 只做参数接收和响应返回。
业务逻辑放 Application Service。
权限码必须来自 docs/architecture/权限模型.md。

Web Cursor 规则

你只能根据 docs/API/web-admin 和 docs/API/common 写接口。
mock 数据必须和接口文档响应结构一致。
如果页面需要新增字段，先更新接口文档。
不要随意创造后端不存在的字段。
权限 meta.permission 必须来自权限码文档。

Uni-app Cursor 规则

你只能根据 docs/API/app 和 docs/API/common 写接口。
页面字段必须来自接口文档。
mock 数据必须和接口文档一致。
如果需要新增接口，先写到 docs/API/app。

十九、开发细节放最后：我的推荐技术实现

后端

JDK 17
Spring Boot 3.4
Spring Security
JWT
MyBatis-Plus
MySQL 8
Redis
Knife4j
MapStruct
Validation
Lombok
Docker

web-admin

Vue3
Vite
TypeScript
Element Plus
Pinia
Vue Router
Axios
Mock
ECharts

uni-app

uni-app
Vue3
TypeScript
Pinia
uView Plus / uni-ui
微信小程序
H5 兼容

文档

Markdown
OpenAPI
Apifox / Apipost
Swagger / Knife4j

二十、最终我会坚持的原则

如果我是这个项目负责人，我会坚持这几条：

1. 先闭环，再扩展
2. 先契约，再代码
3. 前端 mock 不决定后端模型
4. 后端 Entity 不直接暴露给前端
5. app 和 admin 接口不强行复用
6. 业务能力尽量复用
7. 权限码必须统一来源
8. 文档是项目的中枢，不是附属品
9. 每个模块必须有联调 checklist
10. AI 可以写代码，但人必须控制边界

最重要的是：

你一个人做这个项目，真正要搭建的不是某一个页面、某一个接口，而是一套能让 AI 持续稳定参与开发的工程化流程。

这才是 vibe coding 真正有价值的地方。

一、项目定位：先明确“旅搭出行”到底是什么 ​

二、整体系统组成 ​

三、我会采用的总开发策略 ​

四、项目角色怎么由 AI 分工 ​

1. 产品经理 AI ​

2. 架构师 AI ​

3. 后端开发 AI ​

4. 前端开发 AI ​

5. 移动端开发 AI ​

6. 测试 AI ​

7. 运维 AI ​

五、项目模块规划 ​

用户端 app 模块 ​

web-admin 模块 ​

common 通用接口 ​

六、接口契约管理方案 ​

每个接口文档统一模板 ​

异常情况 ​

联调备注 ​

七、web 和 uni-app 接口是否复用的判断规则 ​

第一类：可以直接复用 ​

第二类：不能复用接口，但可以复用业务服务 ​

第三类：完全独立接口 ​

八、后端架构设计 ​

后端 Controller 分端 ​

后端不要让 Entity 直接返回前端 ​

九、权限系统方案 ​

权限码格式 ​

权限来源 ​

登录返回 ​

十、数据库设计策略 ​

第一阶段核心表 ​

第二阶段扩展表 ​

第三阶段运营数据表 ​

十一、前端 web-admin 方案 ​

web-admin 开发方式 ​

十二、uni-app 移动端方案 ​

十三、UI 设计怎么交给 AI ​

十四、测试方案 ​

1. 接口测试 ​

2. 前端页面测试 ​

3. 业务流程测试 ​

十五、运维部署方案 ​

访问路径 ​

日志策略 ​

十六、项目推进节奏 ​

第一阶段：项目骨架和规范 ​

第二阶段：认证与权限闭环 ​

第三阶段：活动业务闭环 ​

第四阶段：内容互动闭环 ​

第五阶段：运营后台增强 ​

第六阶段：部署上线和优化 ​

十七、我会怎么安排每天的开发工作 ​

十八、具体到 Cursor 的工作方式 ​

Backend Cursor 规则 ​

Web Cursor 规则 ​

Uni-app Cursor 规则 ​

十九、开发细节放最后：我的推荐技术实现 ​

后端 ​

web-admin ​

uni-app ​

文档 ​

二十、最终我会坚持的原则 ​