292 lines
9.8 KiB
Markdown
292 lines
9.8 KiB
Markdown
# 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 和专用基础设施。
|