# AIwelink 项目讨论过程总结

> 用途：记录 AIwelink 从最初想法到当前产品和技术共识的形成过程，帮助新开发者理解决策背景。
>
> 文档性质：这是讨论过程记录，不替代具体技术规范，也不替代飞书中的正式商业和运营文档。
>
> 当前阶段：方向已完成初步收敛，代码目录和 Agent 具体实现尚未定型。

## 1. 最初设想

项目最初的设想是建设一个项目合作平台：

- 用户可以上传简历和个人资料。
- 用户可以发布自己的项目。
- 用户可以发布召集令，寻找队友或协作者。
- 平台面向大学竞赛，也面向真实开发者项目。
- 平台未来保留运营和商业化空间。

最开始看起来像是“项目合作 + 人才资料 + 组队”的平台，但讨论很快发现，如果只是简历、帖子、私聊和找队友，产品会接近校园墙或垂直交友平台，缺乏长期差异化。

## 2. 第一次收窄：先服务大学生竞赛

为了降低冷启动难度，第一阶段选择大学生竞赛作为主要市场，而不是同时服务大学生和成熟开发者。

选择原因：

- 需求集中在明确的赛事周期内。
- 学校、社团、校园墙和学生组织是可触达的渠道。
- 组队需求明确，容易观察“发布、申请、成队”的闭环。
- 技术类竞赛可以自然连接 AI API、课程和工具包。

第一阶段优先关注 AI、软件、数据分析、创新创业等技术关联竞赛，后续再扩展到更多竞赛、科研、开源、企业命题和创业项目。

## 3. 从“交友平台”转向“任务型协作平台”

讨论中确认：如果平台只是“上传简历、发布召集令、私聊”，就会像校园版交友平台。

因此产品目标从“让人认识更多人”调整为：

> 以明确的项目或竞赛任务为中心，帮助用户找到合适的能力、角色和协作者，并把项目真正做完。

平台的成果不应只是浏览、点赞或聊天，而应包括：

- 有效申请。
- 成功组队。
- 持续协作。
- 完成作品。
- 提交竞赛。
- 赛后复盘。

## 4. 与校园墙的区分

校园墙负责让信息被看见，AIwelink 负责让项目推进和结果沉淀。

区分重点：

| 校园墙 | AIwelink |
| --- | --- |
| 单校或本地信息 | 跨学校的机会和项目网络 |
| 非结构化临时帖子 | 绑定赛事、角色、时间和能力要求 |
| 发帖后转到微信 | 记录申请、授权、组队和项目过程 |
| 主要关注曝光 | 关注成队率、完赛率和作品数量 |
| 广告或推广为主 | API、课程、导师、赛事和机构服务 |

校园墙不必完全视为敌人，也可以成为分发渠道：校园墙提供本地触达，AIwelink 承接标准化报名、组队、工具和成果记录。

## 5. 商业化方向的形成

讨论中明确，平台不应主要依靠向学生收取“找队友”会员费。更自然的商业闭环是：

```text
免费赛事与项目机会
  -> 用户组队并开始真实项目
  -> 产生 AI 工具和能力需求
  -> 使用模型 API、工具包、课程或导师服务
  -> 后续对接学校、赛事方和企业
```

主要商业化方向：

1. 面向竞赛团队的模型 API 和场景化工具包。
2. 面向具体赛事的课程、训练营、作品评审和答辩辅导。
3. 学校、社团和赛事方的报名、组队和运营服务。
4. 企业命题赛、模型或算力赞助、品牌合作。
5. 基于真实项目经历的人才发现和项目推荐。

商业表达不应聚焦“帮助用户访问国外 AI”，而应聚焦国内稳定可用、人民币结算、适合竞赛场景的 AI 能力。

API 和课程不应在用户刚进入平台时硬推，而应在用户进入项目、遇到具体困难或进入备赛阶段后出现。

## 6. 首页心智的讨论结果

首页不以产品介绍、API 或课程商城为中心，也不以简历瀑布流或泛校园信息流为中心。

首页应该围绕“机会”和“下一步行动”：

> 找到适合你的下一次挑战，并知道现在应该做什么。

首页的优先内容：

1. 适合用户的竞赛和项目。
2. 即将截止或正在招募的机会。
3. 用户正在参与的项目。
4. 自我认知和成长任务。
5. 真实项目成果和经验。
6. 与当前项目有关的 API、课程和导师服务。

登录策略初步确定为：未登录用户可浏览部分公开机会；收藏、报名、申请组队或开始个性化自我认知时再要求登录。微信作为主登录入口，邮箱作为绑定、验证和恢复方式。

## 7. 自我认知方向的形成

讨论进一步从“竞赛组队”转向“帮助用户了解自己”。用户真正想知道的不是简单人格标签，而是：

- 自己擅长什么。
- 适合做什么类型的任务。
- 适合承担什么项目角色。
- 更适合什么工作环境和协作方式。
- 容易在哪些环节遇到困难。
- 下一步应该学习或尝试什么。

因此，心理测评不能只是一次性结果。平台应形成：

```text
自我评估
  -> 选择项目
  -> 真实行动
  -> 队友反馈
  -> 项目复盘
  -> 更新自我认知
```

测评结果是当前阶段的假设，真实项目行为和合作反馈是更有价值的证据。

平台不做心理疾病诊断，不用单次测评淘汰用户，也不把用户固定成某种人格类型。

## 8. 自我认知 Agent 与推广机制

随后提出将自我认知 Agent 作为推广阶段的独立产品入口：

```text
免费自我认知 Agent
  -> 生成个人报告
  -> 分享安全摘要
  -> 邀请朋友
  -> 解锁双人或团队分析
  -> 推荐项目和竞赛
```

积分可以作为增长工具，但奖励不应只绑定链接点击或注册，而应绑定有效行为：

- 完成个人报告。
- 被邀请者完成授权。
- 双人报告生成。
- 参与项目或挑战。
- 完成项目复盘。

积分可以兑换深度报告、API 额度、课程优惠、导师问答或挑战资格。

## 9. 双人画像与社交属性

讨论确认，社交属性可以存在，而且可能是产品传播力的一部分，但应该围绕“共同做事”展开。

用户邀请朋友并获得双方授权后，可以生成：

- 彼此互补的优势。
- 适合的分工方式。
- 可能发生冲突的地方。
- 推荐的沟通方式。
- 适合一起参加的项目。
- 合作前应该约定的规则。

社交产品结构可以逐步演进为：

```text
个人画像
  -> 双人协作画像
  -> 三到五人的团队画像
  -> 项目复盘
  -> 长期成长和合作关系
```

共享必须是双向、明确、可撤销的授权。默认私密，用户可以选择共享优势、偏好、协作建议或成长方向，不应默认共享原始回答和敏感结论。

第一阶段优先面向已经认识的朋友、同学和队友，暂不把陌生人交友或恋爱社交作为主场景。

## 10. 个性化推荐方向

推荐系统被定义为平台的长期核心能力，推荐对象包括：

- 竞赛。
- 项目。
- 学科。
- 学习内容。
- 项目角色。
- 合作对象。
- 课程、导师和 AI 工具。

推荐依据不只包括兴趣，还包括：

- 用户能力和目标。
- 可投入时间。
- 工作偏好。
- 已完成或放弃过的项目。
- 项目中的真实行为。
- 队友反馈和复盘结果。

第一阶段采用可解释的规则、标签、行为信号和必要的向量召回，不直接引入复杂黑箱模型。

## 11. 技术选型过程

### 11.1 后端语言

讨论过 Go、TypeScript 和 Python 的适用性。

结论是：全栈 TypeScript 足以支撑第一阶段，因为业务主要是网络 I/O、数据库读写和第三方模型调用。Go 可以作为未来独立高性能服务的选择，Python 更适合未来算法和数据科学任务，但当前不需要为了 AI 提前拆成多语言微服务。

### 11.2 React 与 Next.js

确认 React 是 UI 库，Next.js 是基于 React 的应用框架。由于平台同时需要公开机会页、分享页、搜索收录和登录后的个性化工作台，最终选择：

> Next.js + React + TypeScript

Next.js 负责 Web 应用，视觉质量由设计系统、信息层级、动效、响应式布局和性能实现决定，而不是由框架本身决定。

### 11.3 Web 与 REST API

确认采用 Next.js 与独立 REST API，而不是把核心业务全部放入 Next.js Route Handler。

第一阶段使用同域名反向代理：

```text
https://aiwelink.com/            -> Next.js
https://aiwelink.com/api/v1/*   -> 独立 REST API
```

这样可以保留独立 API 边界，同时避免第一阶段的跨域和子域名复杂度。

### 11.4 API 框架

确认使用：

> NestJS + Fastify Adapter

NestJS 负责模块、依赖注入、权限 Guard、异常处理和 OpenAPI；Fastify 作为底层 HTTP 适配器。

### 11.5 数据访问

对比 Prisma、Drizzle 和原生 SQL 后，确认：

> Drizzle ORM 作为默认数据访问工具，原生 SQL 作为复杂查询补充。

普通 CRUD 和事务使用 Drizzle；pgvector、全文搜索、推荐排序和复杂报表通过 Repository 使用参数化原生 SQL。

### 11.6 身份系统

确认在 API 内部建立 Identity 模块，统一管理微信登录、邮箱绑定、会话、验证和登录审计。第一阶段不把身份体系绑定在 Next.js 上。

### 11.7 数据与基础设施

确认使用：

- PostgreSQL 作为业务主数据库。
- `pgvector` 作为 PostgreSQL 扩展。
- Redis 用于缓存、限流和队列基础设施。
- 阿里云 OSS 存储简历、作品、报告和附件。
- Docker 容器化 Web、API 和 Worker。
- 自有 ECS + Docker Compose 作为第一阶段部署方式。
- 后续业务规模增长后再迁移 Kubernetes。
- Uptime Kuma 作为第一阶段基础可用性监控。

数据按身份、资料、原始测评、推测画像、行为证据、公开画像和授权审计分层存储。提前按业务边界分表，但不提前做跨库分片。

## 12. Monorepo 与文档管理决定

确认使用单 Git 仓库和 Monorepo，代码按以下概念划分：

- `apps/web`：Next.js Web。
- `apps/api`：NestJS REST API。
- `apps/worker`：异步任务，Agent 方案暂不定型。
- `apps/admin`：后续运营后台。
- `packages/contracts`：OpenAPI、DTO 和共享接口。
- `packages/db`：Drizzle Schema、迁移和种子。
- `infra`：Docker、ECS 和未来 Kubernetes。

文档边界确定为：

| 文档内容 | 位置 |
| --- | --- |
| 总体架构、技术栈、工程规范 | 根目录 `docs/`，进入 Git |
| API 具体接口和模块实现 | `apps/api/docs/`，进入 Git |
| 数据库规范 | `packages/db/docs/`，进入 Git |
| 技术部署和备份 | `infra/docs/`，进入 Git |
| 临时需求和未确认讨论 | `docs-local/`，Git 忽略 |
| 商业、市场、运营和合作 | 飞书，不进入 Git |

## 13. 当前已确认与未确认

### 已确认

- 第一阶段面向大学生竞赛和技术项目。
- 平台核心是自我认知、项目机会、真实协作和成长反馈。
- 社交围绕双人或团队协作画像展开。
- 推荐系统要可解释并帮助用户理解自己。
- 使用 Next.js + React + TypeScript。
- 使用独立 REST API，路径为 `/api/v1`，与 Web 同域名反向代理。
- 使用 NestJS + Fastify Adapter。
- 使用 Drizzle + 原生 SQL。
- 使用 API 内部 Identity 模块。
- 使用 PostgreSQL、pgvector、Redis 和阿里云 OSS。
- 使用 ECS + Docker Compose，后续迁移 Kubernetes。
- 商业和运营文档使用飞书。

### 暂未定型

- Agent 使用的具体模型供应商和模型路由。
- Agent 的对话编排框架。
- 长报告和复杂任务的具体队列实现。
- 推荐系统是否拆为独立服务。
- 测试工具和完整可观测性方案。
- 生产数据库和 Redis 的最终托管或自建形态。
- 具体的第一场竞赛、运营节奏和商业价格。

## 14. 新开发者阅读顺序

建议按以下顺序了解项目：

1. 阅读本文，理解产品为什么不是校园墙或普通交友平台。
2. 阅读 `docs/project-handoff.md`，了解当前工程共识和接手规则。
3. 阅读 `docs/architecture/technology-stack.md`，了解技术基线。
4. 阅读 `docs/architecture/technology-stack-details.md`，了解 API、数据和部署细节。
5. 阅读对应模块下的文档和决策记录。
6. 对未定型事项先保持接口边界，不要擅自提前固化实现。

## 15. 总结

本次讨论的核心收敛过程是：

```text
项目合作平台
  -> 大学生竞赛组队
  -> 区别于校园墙的任务型协作
  -> 以自我认知为长期核心
  -> 个性化推荐项目、学科和合作对象
  -> 双方授权后生成协作画像
  -> 通过真实项目形成成长和关系数据
  -> 用 API、课程、导师和机构服务商业化
```

技术选择遵循同一个原则：先用清晰、稳定、可迭代的模块化架构验证真实用户价值；在规模和业务证据出现后，再增加 Agent 编排、复杂推荐、Kubernetes 或专用基础设施。