# 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 和专用基础设施。