docs: initialize AIwelink project
This commit is contained in:
@@ -0,0 +1,291 @@
|
||||
# AIwelink 讨论结果说明
|
||||
|
||||
这份文档把项目从最初想法到当前方案的变化讲清楚。
|
||||
它帮助新成员理解每个决定是怎么来的。
|
||||
|
||||
当前状态：产品方向已经收敛到「自我认知 + 项目机会 + 真实合作 + 项目反馈」。
|
||||
技术方案也已经确定第一阶段的主要工具。
|
||||
代码目录、AI 助手和运营节奏还要继续安排。
|
||||
|
||||
## 1. 项目从哪里开始
|
||||
|
||||
最初的想法是做一个项目合作平台。
|
||||
用户可以上传简历和资料、发布项目、发起组队，并寻找队友或协作者。
|
||||
平台面向大学竞赛，也保留真实开发者项目的空间。
|
||||
|
||||
继续讨论后，团队发现单独提供资料、帖子和私聊，用户很难得到长期价值。
|
||||
于是产品重点逐渐转向「帮助用户找到合适的任务和合作方式，并把项目做完」。
|
||||
|
||||
## 2. 第一阶段先服务大学生竞赛
|
||||
|
||||
第一阶段选择大学生竞赛和技术项目，原因有三点：
|
||||
|
||||
- 赛事有明确的报名和截止时间；
|
||||
- 学校、社团和学生组织方便触达用户；
|
||||
- 发布机会、申请组队和提交作品的过程容易观察。
|
||||
|
||||
初期重点关注 AI、软件、数据分析、创新创业等技术相关竞赛。
|
||||
后续可以扩展到科研、开源、企业命题和创业项目。
|
||||
|
||||
## 3. 产品定位逐步明确
|
||||
|
||||
AIwelink 的核心场景是带着任务一起做事：
|
||||
|
||||
```text
|
||||
明确的竞赛或项目
|
||||
-> 找到需要的角色和能力
|
||||
-> 发起申请并组队
|
||||
-> 共同完成作品
|
||||
-> 记录结果和合作反馈
|
||||
```
|
||||
|
||||
平台沉淀的结果包括有效申请、成功组队、持续合作、作品完成、竞赛提交和项目复盘。
|
||||
浏览、点赞和聊天只是辅助行为。
|
||||
|
||||
校园墙可以作为信息分发渠道。
|
||||
校园墙负责本地触达，AIwelink 承接结构化报名、组队、工具使用和成果记录。
|
||||
|
||||
## 4. 商业方向怎样形成
|
||||
|
||||
团队把商业路径安排为：
|
||||
|
||||
```text
|
||||
免费赛事与项目机会
|
||||
-> 用户组队并开始真实项目
|
||||
-> 用户出现 AI 工具和能力需求
|
||||
-> 使用 API、工具包、课程或导师服务
|
||||
-> 学校、赛事方和企业采购组织服务
|
||||
```
|
||||
|
||||
当前重点方向包括：
|
||||
|
||||
1. 面向竞赛团队的模型 API 和场景工具包；
|
||||
2. 赛事课程、训练营、作品评审和答辩辅导；
|
||||
3. 学校、社团和赛事方的报名、组队与活动管理；
|
||||
4. 企业命题赛、模型或算力赞助、品牌合作；
|
||||
5. 基于真实项目经历的人才发现和项目推荐。
|
||||
|
||||
平台在用户进入项目、遇到具体困难或开始备赛后展示相关服务。
|
||||
这样服务内容和用户当前任务直接相关。
|
||||
|
||||
## 5. 首页要呈现什么
|
||||
|
||||
首页围绕机会和下一步行动安排内容：
|
||||
|
||||
1. 适合用户的竞赛和项目；
|
||||
2. 即将截止或正在招募的机会；
|
||||
3. 用户正在参与的项目；
|
||||
4. 自我认知和成长任务；
|
||||
5. 已完成的作品和经验；
|
||||
6. 与当前项目有关的 API、课程和导师服务。
|
||||
|
||||
登录可以分阶段要求：
|
||||
|
||||
- 未登录用户浏览部分公开机会；
|
||||
- 用户收藏、报名、申请组队或开始个性化自我认知时登录；
|
||||
- 微信作为主登录入口；
|
||||
- 邮箱用于绑定、验证、通知和账号恢复。
|
||||
|
||||
## 6. 自我认知功能怎样形成
|
||||
|
||||
用户真正关心的是自己适合什么任务、角色和协作方式。
|
||||
因此，个人画像需要随着行动持续更新：
|
||||
|
||||
```text
|
||||
自我评估
|
||||
-> 选择项目
|
||||
-> 真实行动
|
||||
-> 队友反馈
|
||||
-> 项目复盘
|
||||
-> 更新个人画像
|
||||
```
|
||||
|
||||
AI 自我认知助手先给出阶段性建议。
|
||||
真实项目行为、合作结果和队友反馈会成为后续更新的重要依据。
|
||||
|
||||
平台通过提问、项目记录和复盘帮助用户了解：
|
||||
|
||||
- 自己擅长什么；
|
||||
- 适合承担什么角色；
|
||||
- 适合怎样的工作环境；
|
||||
- 哪些环节容易遇到困难；
|
||||
- 下一步该学习或尝试什么。
|
||||
|
||||
## 7. 邀请、合作报告和积分
|
||||
|
||||
自我认知助手也可以作为推广入口：
|
||||
|
||||
```text
|
||||
免费自我认知助手
|
||||
-> 生成个人报告
|
||||
-> 分享用户选择的安全摘要
|
||||
-> 邀请朋友
|
||||
-> 生成双方或团队的合作建议
|
||||
-> 推荐适合一起参加的项目
|
||||
```
|
||||
|
||||
双方取得明确许可后，合作报告可以包含：
|
||||
|
||||
- 互补优势；
|
||||
- 分工建议；
|
||||
- 可能发生摩擦的地方；
|
||||
- 推荐的沟通方式；
|
||||
- 适合一起参加的项目；
|
||||
- 合作前需要约定的规则。
|
||||
|
||||
积分奖励绑定真实行为。
|
||||
例如完成个人报告、完成共享许可、生成合作报告、参加项目和完成复盘。
|
||||
积分可以兑换深度报告、API 额度、课程优惠、导师问答或挑战资格。
|
||||
|
||||
第一阶段先服务已经认识的朋友、同学和队友。
|
||||
随着项目记录增加，再扩展到三至五人的团队合作建议。
|
||||
|
||||
## 8. 推荐系统的方向
|
||||
|
||||
推荐对象包括竞赛、项目、学科和学习内容。
|
||||
也包括项目角色、合作对象、课程、导师和 AI 工具。
|
||||
|
||||
推荐会综合这些信息：
|
||||
|
||||
- 用户能力和目标；
|
||||
- 可以投入的时间；
|
||||
- 工作偏好；
|
||||
- 完成或放弃过的项目；
|
||||
- 项目中的真实行为；
|
||||
- 队友反馈和复盘结果。
|
||||
|
||||
第一阶段先采用规则、标签、行为信号和必要的向量检索。
|
||||
每条推荐带理由，让用户知道选择依据。
|
||||
|
||||
## 9. 技术方案怎样确定
|
||||
|
||||
### 9.1 后端语言
|
||||
|
||||
团队比较了 Go、TypeScript 和 Python。
|
||||
第一阶段业务主要处理网络请求、数据库读写和第三方模型调用。
|
||||
全栈 TypeScript 已经能够覆盖这些工作。
|
||||
|
||||
Go 留作未来独立高性能服务的选择。
|
||||
Python 留作算法和数据分析任务的选择。
|
||||
当前先保持一个主要语言，减少工程维护量。
|
||||
|
||||
### 9.2 Web 框架
|
||||
|
||||
React 负责 UI 组件，Next.js 负责完整 Web 应用。
|
||||
平台需要公开机会页、分享页、搜索收录和登录后的工作台。
|
||||
因此确定使用：
|
||||
|
||||
> Next.js + React + TypeScript
|
||||
|
||||
页面质量由设计系统、信息层级、动效、响应式布局和性能共同决定。
|
||||
|
||||
### 9.3 Web 和 REST API
|
||||
|
||||
Web 与业务 API 分开：
|
||||
|
||||
```text
|
||||
https://aiwelink.com/ -> Next.js
|
||||
https://aiwelink.com/api/v1/* -> 独立 REST API
|
||||
```
|
||||
|
||||
同域名入口减少跨域和子域名配置工作，也保留未来独立扩展 API 的空间。
|
||||
|
||||
### 9.4 API 框架
|
||||
|
||||
后端采用 NestJS + Fastify Adapter。
|
||||
NestJS 负责模块、依赖注入、权限 Guard、异常处理和 OpenAPI。
|
||||
Fastify 负责 HTTP 服务。
|
||||
|
||||
### 9.5 数据访问
|
||||
|
||||
普通增删改查和事务使用 Drizzle ORM。
|
||||
向量相似度、全文搜索、推荐排序和复杂报表通过 Repository 使用参数化原生 SQL。
|
||||
|
||||
### 9.6 数据和基础设施
|
||||
|
||||
- PostgreSQL 保存主要业务数据；
|
||||
- `pgvector` 提供向量检索；
|
||||
- Redis 负责缓存、限流和任务队列；
|
||||
- 阿里云 OSS 保存简历、作品、报告和附件；
|
||||
- Docker 运行 Web、API 和 Worker；
|
||||
- 第一阶段部署在自有 ECS + Docker Compose；
|
||||
- 后续根据规模迁移 Kubernetes；
|
||||
- Uptime Kuma 负责基础可用性监控。
|
||||
|
||||
## 10. 单仓库和文档位置
|
||||
|
||||
项目使用单 Git 仓库（Monorepo），计划按以下目录组织：
|
||||
|
||||
- `apps/web`：Next.js Web；
|
||||
- `apps/api`：NestJS REST API；
|
||||
- `apps/worker`：异步任务；
|
||||
- `apps/admin`：后续运营后台；
|
||||
- `packages/contracts`：OpenAPI、DTO 和共享接口；
|
||||
- `packages/db`：Drizzle Schema、迁移和种子数据；
|
||||
- `infra`：Docker、ECS、备份和后续 Kubernetes 配置。
|
||||
|
||||
文档位置按内容分工：
|
||||
|
||||
| 文档内容 | 位置 |
|
||||
| --- | --- |
|
||||
| 总体架构、技术栈、工程规范 | 根目录 `docs/` |
|
||||
| API 接口和模块实现 | `apps/api/docs/` |
|
||||
| 数据库结构和迁移规范 | `packages/db/docs/` |
|
||||
| 技术部署和备份 | `infra/docs/` |
|
||||
| 临时需求和未确认讨论 | `docs-local/` |
|
||||
| 商业、市场、运营和合作 | 飞书 |
|
||||
|
||||
## 11. 当前已经确定的事情
|
||||
|
||||
- 第一阶段服务大学生竞赛和技术项目；
|
||||
- 产品由自我认知、机会推荐、真实合作和项目反馈组成；
|
||||
- 首页围绕机会和下一步行动；
|
||||
- 双方取得许可后生成合作建议；
|
||||
- 推荐结果说明原因；
|
||||
- 使用 Next.js + React + TypeScript；
|
||||
- 使用独立 REST API，路径为 `/api/v1`；
|
||||
- Web 和 API 共用一个域名；
|
||||
- 使用 NestJS + Fastify Adapter；
|
||||
- 使用 Drizzle 和参数化原生 SQL；
|
||||
- API 内部建立 `Identity` 模块；
|
||||
- 使用 PostgreSQL、`pgvector`、Redis 和阿里云 OSS；
|
||||
- 第一阶段使用 ECS + Docker Compose；
|
||||
- 商业和运营资料放在飞书。
|
||||
|
||||
## 12. 还要决定的事情
|
||||
|
||||
- AI 助手使用哪家模型和怎样路由模型；
|
||||
- AI 助手使用哪种对话编排框架；
|
||||
- 长报告和复杂任务使用哪种队列；
|
||||
- 推荐系统是否拆成独立服务；
|
||||
- 测试工具和日志、指标方案；
|
||||
- 生产环境的 PostgreSQL 和 Redis 使用自建还是托管；
|
||||
- 第一场重点竞赛、运营节奏和具体价格。
|
||||
|
||||
## 13. 给新成员的阅读顺序
|
||||
|
||||
1. 先读本文，了解产品方向的变化；
|
||||
2. 再读 `docs/project-handoff.md`，了解工程规则；
|
||||
3. 阅读 `docs/architecture/technology-stack.md`，掌握整体技术方案；
|
||||
4. 阅读 `docs/architecture/technology-stack-details.md`，了解接口、数据和部署细节；
|
||||
5. 开始实现对应模块前，再阅读模块文档和决定记录；
|
||||
6. 遇到待决定的事项，先保持接口清楚，把选项和依据记录下来。
|
||||
|
||||
## 14. 讨论结论
|
||||
|
||||
项目方向从「项目合作平台」逐步明确为：
|
||||
|
||||
```text
|
||||
项目合作平台
|
||||
-> 大学生竞赛组队
|
||||
-> 以任务为中心的协作
|
||||
-> 以自我认知为长期能力
|
||||
-> 推荐项目、学科和合作对象
|
||||
-> 双方取得许可后生成合作建议
|
||||
-> 通过真实项目积累成长和合作数据
|
||||
-> 用 API、课程、导师和机构服务提供收入
|
||||
```
|
||||
|
||||
技术安排遵循同一原则：先用清楚、稳定、可以持续修改的模块化架构验证用户价值。
|
||||
等用户数量、项目数据和实际故障模式变得清楚后，再决定后续技术投入。
|
||||
候选项包括 AI 助手编排、复杂推荐、Kubernetes 和专用基础设施。
|
||||
Reference in New Issue
Block a user