308 lines
8.2 KiB
Markdown
308 lines
8.2 KiB
Markdown
# AIwelink 当前知识与开发安排
|
||
|
||
这份总览回答四个问题：
|
||
|
||
1. AIwelink 现在要做什么；
|
||
2. 哪些事情已经确定；
|
||
3. 哪些事情还需要拍板；
|
||
4. 开发应该按什么顺序推进。
|
||
|
||
原来的文档已经备份到 `docs_old/`。
|
||
当前版本放在 `docs/`，内容以容易阅读和实际执行为目标。
|
||
|
||
## 1. 当前状态
|
||
|
||
- 产品方向：帮助大学生认识自己、找到项目机会；
|
||
- 用户在真实合作中积累成长记录；
|
||
- 第一阶段从大学生竞赛和技术项目开始；
|
||
- 技术主线已经确定：Next.js、NestJS、PostgreSQL、Redis、OSS、Docker Compose；
|
||
- 代码目录处于初始化前阶段；
|
||
- AI 助手的模型、对话编排和任务队列列为待决定事项；
|
||
- 第一场重点竞赛、运营节奏和收费价格列为待安排事项；
|
||
- 商业、市场和运营资料继续放在飞书。
|
||
|
||
## 2. 我们已经知道什么
|
||
|
||
### 2.1 用户要完成的事情
|
||
|
||
用户进入平台后，应该可以完成下面的过程：
|
||
|
||
```text
|
||
登录
|
||
-> 填写资料并了解自己
|
||
-> 看到适合的竞赛或项目
|
||
-> 选择项目角色
|
||
-> 邀请朋友并授权共享
|
||
-> 生成双方的合作建议
|
||
-> 申请加入项目
|
||
-> 记录项目进展和队友反馈
|
||
-> 完成复盘并更新个人画像
|
||
```
|
||
|
||
平台的价值来自真实行动和结果。推荐、报告和积分都要服务于这条过程。
|
||
|
||
### 2.2 第一阶段的产品范围
|
||
|
||
第一阶段优先完成这些功能：
|
||
|
||
- 微信登录、邮箱绑定和会话管理；
|
||
- 基础资料和个人画像；
|
||
- 自我认知助手的提问、回答和报告；
|
||
- 竞赛、项目和招募信息；
|
||
- 项目角色、成员和申请；
|
||
- 邀请链接和双方共享许可；
|
||
- 双人合作建议；
|
||
- 项目进展、队友反馈和复盘；
|
||
- 积分流水和基础兑换；
|
||
- 推荐内容和推荐理由；
|
||
- 首页工作台和公开机会页。
|
||
|
||
运营后台、完整商业交易、复杂推荐模型和大规模数据服务放在后续阶段安排。
|
||
|
||
### 2.3 数据应该留下什么
|
||
|
||
核心业务数据集中在 PostgreSQL：
|
||
|
||
- 用户和登录身份；
|
||
- 基础资料和公开资料；
|
||
- 测评回答和个人画像版本；
|
||
- 项目、成员、申请和行为记录；
|
||
- 队友反馈和项目复盘；
|
||
- 邀请、共享许可和审计记录；
|
||
- 积分流水、订单和权益；
|
||
- 推荐内容、推荐理由和用户反馈。
|
||
|
||
Redis 处理缓存、限流、短期状态和任务队列。
|
||
阿里云 OSS 保存简历、作品、报告和项目附件。
|
||
|
||
## 3. 已确认的工程规则
|
||
|
||
### 3.1 应用和访问路径
|
||
|
||
- Web 使用 Next.js + React + TypeScript；
|
||
- API 使用 NestJS + Fastify Adapter；
|
||
- Web 和 API 共用一个域名；
|
||
- API 路径统一从 `/api/v1` 开始；
|
||
- Web 负责页面和交互，API 负责业务规则；
|
||
- 入口代理按路径把请求转给 Web 或 API。
|
||
|
||
### 3.2 代码分层
|
||
|
||
数据库访问按下面的顺序组织：
|
||
|
||
```text
|
||
Controller
|
||
-> Application Service
|
||
-> Repository
|
||
-> PostgreSQL
|
||
```
|
||
|
||
普通查询使用 Drizzle ORM。
|
||
向量检索、全文搜索、推荐排序和复杂报表使用参数化原生 SQL。
|
||
Controller 通过 Repository 访问数据库。
|
||
|
||
### 3.3 部署和基础设施
|
||
|
||
第一阶段的服务包括：
|
||
|
||
```text
|
||
nginx
|
||
web
|
||
api
|
||
worker
|
||
postgres
|
||
redis
|
||
```
|
||
|
||
这些服务使用 Docker Compose 部署到自有 ECS。
|
||
文件上传到 OSS。
|
||
Uptime Kuma 检查首页、健康接口、端口和 HTTPS 证书。
|
||
|
||
## 4. 还需要拍板的事项
|
||
|
||
这些决定会直接影响产品和代码，建议按顺序确认：
|
||
|
||
### 4.1 确定第一个用户场景
|
||
|
||
需要明确第一场重点竞赛或项目，并写出完整流程：
|
||
|
||
- 用户从哪里进入；
|
||
- 需要填写哪些信息；
|
||
- 怎样看到机会；
|
||
- 怎样邀请队友；
|
||
- 怎样提交申请；
|
||
- 怎样记录项目结果。
|
||
|
||
### 4.2 确定个人画像的内容
|
||
|
||
需要确定自我认知助手的输入和输出：
|
||
|
||
- 需要问哪些问题；
|
||
- 报告包含哪些部分；
|
||
- 哪些内容可以公开分享；
|
||
- 用户怎样修改或补充报告；
|
||
- 项目反馈怎样更新画像。
|
||
|
||
### 4.3 确定项目和申请规则
|
||
|
||
需要确定：
|
||
|
||
- 项目有哪些状态；
|
||
- 项目角色怎样定义；
|
||
- 谁可以发布项目；
|
||
- 申请怎样审核；
|
||
- 成员怎样加入和退出；
|
||
- 项目完成后需要提交哪些结果。
|
||
|
||
### 4.4 确定 AI 助手方案
|
||
|
||
需要选择：
|
||
|
||
- 第一阶段使用的模型供应商；
|
||
- 单轮问答还是多轮对话；
|
||
- 报告是否异步生成；
|
||
- 任务失败后的重试方式；
|
||
- 记录哪些提示词、版本和费用信息。
|
||
|
||
### 4.5 确定运行方式
|
||
|
||
需要确定：
|
||
|
||
- PostgreSQL 和 Redis 自建还是托管；
|
||
- 备份保留多久；
|
||
- 生产环境的域名和证书管理；
|
||
- 日志、指标和告警使用哪些工具；
|
||
- 发布和回滚由谁负责。
|
||
|
||
## 5. 建议的开发顺序
|
||
|
||
### 第一步：写清第一个场景
|
||
|
||
先用一页文档写完「用户参加一场竞赛并找到队友」的过程。
|
||
再把页面、接口、数据和成功条件列出来。
|
||
|
||
产出：
|
||
|
||
- 用户流程图；
|
||
- 页面清单；
|
||
- API 清单；
|
||
- 数据表草图；
|
||
- 第一阶段成功指标。
|
||
|
||
### 第二步：初始化单仓库
|
||
|
||
创建下面的基础目录：
|
||
|
||
```text
|
||
apps/web
|
||
apps/api
|
||
apps/worker
|
||
packages/contracts
|
||
packages/db
|
||
packages/validation
|
||
packages/ui
|
||
packages/config
|
||
infra/docker
|
||
docs/decisions
|
||
```
|
||
|
||
同时配置 TypeScript、Lint、测试命令、环境变量示例和数据库迁移流程。
|
||
|
||
### 第三步：先做最小 API
|
||
|
||
建议先完成：
|
||
|
||
1. 登录和会话；
|
||
2. 用户资料；
|
||
3. 机会和项目；
|
||
4. 项目成员和申请；
|
||
5. 邀请和共享许可；
|
||
6. 积分流水；
|
||
7. 健康检查接口。
|
||
|
||
这些接口先用固定测试数据跑通，再接入真实页面。
|
||
|
||
### 第四步：接入自我认知助手
|
||
|
||
先定义统一的输入、输出和任务状态：
|
||
|
||
- 输入：用户回答、资料和项目上下文；
|
||
- 输出：结构化个人画像、推荐理由和待确认建议；
|
||
- 状态：待处理、处理中、完成、失败；
|
||
- 记录：模型名称、版本、提示词版本、耗时和费用。
|
||
|
||
模型供应商确定后，只替换具体实现，不改变业务接口。
|
||
|
||
### 第五步：完成 Web 主流程
|
||
|
||
Web 先实现这些页面：
|
||
|
||
- 公开机会页；
|
||
- 登录页；
|
||
- 个人资料页；
|
||
- 自我认知助手页；
|
||
- 首页工作台；
|
||
- 项目详情页；
|
||
- 邀请和共享确认页；
|
||
- 双人合作建议页；
|
||
- 项目申请页；
|
||
- 项目进展和复盘页。
|
||
|
||
每个页面都要能回到明确的下一步操作。
|
||
|
||
### 第六步：联调和试用
|
||
|
||
按真实用户顺序测试：
|
||
|
||
```text
|
||
登录
|
||
→ 填写资料
|
||
→ 完成自我认知
|
||
→ 浏览机会
|
||
→ 邀请朋友
|
||
→ 确认共享
|
||
→ 申请项目
|
||
→ 记录进展
|
||
→ 完成复盘
|
||
```
|
||
|
||
记录用户在哪一步停下、哪些字段看不懂、推荐理由是否有帮助，再调整页面和数据结构。
|
||
|
||
## 6. 第一阶段完成标准
|
||
|
||
第一阶段完成时，至少要满足：
|
||
|
||
- 用户可以完成登录并保存资料；
|
||
- 用户可以完成一次自我认知并得到结构化报告；
|
||
- 用户可以浏览机会和项目，并看到推荐原因；
|
||
- 用户可以邀请朋友，双方可以明确选择共享内容；
|
||
- 用户可以生成双方合作建议；
|
||
- 用户可以申请加入项目并看到申请状态；
|
||
- 项目可以记录成员、进展、结果和队友反馈；
|
||
- 复盘结果可以形成新的个人画像版本；
|
||
- 积分流水可以追溯到具体行为；
|
||
- 关键接口有权限检查、错误格式和请求编号；
|
||
- 核心流程有自动化测试；
|
||
- 生产环境有健康检查、备份和恢复步骤。
|
||
|
||
## 7. 需要持续记录的知识
|
||
|
||
后续每次决定都记录在对应位置：
|
||
|
||
- 跨模块技术决定：`docs/decisions/`；
|
||
- API 接口和模块实现：`apps/api/docs/`；
|
||
- 数据库结构和迁移：`packages/db/docs/`；
|
||
- 部署、备份和恢复：`infra/docs/`；
|
||
- 临时讨论：`docs-local/`；
|
||
- 商业、市场、运营和合作：飞书。
|
||
|
||
每条决定写清楚「问题、选择、原因、影响和后续复查条件」。
|
||
这样新成员可以直接看懂，也方便以后修改。
|
||
|
||
## 8. 当前一句话结论
|
||
|
||
AIwelink 先做一个围绕真实竞赛和项目的成长平台。
|
||
用户从了解自己开始，找到机会和队友，完成项目，再用结果更新自己的认识。
|
||
|
||
开发先把这条用户流程跑通，再扩展 AI 助手、推荐系统、商业服务和更复杂的基础设施。
|