我的知识库

Appearance

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

产品负责人：决定做什么、不做什么
架构负责人：决定系统边界、模块边界、数据边界
后端开发：实现业务能力和接口契约
前端开发：实现 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 真正有价值的地方。

Powered by VitePress

© 2026 skeeter