ZGH/NewPlatform

Fork 0

Files

T

ZGH 28f4efd675 docs: initialize AIwelink project

2026-08-23 00:16:15 +08:00

9.8 KiB

Raw Blame History

AIwelink 讨论结果说明

这份文档把项目从最初想法到当前方案的变化讲清楚。它帮助新成员理解每个决定是怎么来的。

当前状态：产品方向已经收敛到「自我认知 + 项目机会 + 真实合作 + 项目反馈」。技术方案也已经确定第一阶段的主要工具。代码目录、AI 助手和运营节奏还要继续安排。

1. 项目从哪里开始

最初的想法是做一个项目合作平台。用户可以上传简历和资料、发布项目、发起组队，并寻找队友或协作者。平台面向大学竞赛，也保留真实开发者项目的空间。

继续讨论后，团队发现单独提供资料、帖子和私聊，用户很难得到长期价值。于是产品重点逐渐转向「帮助用户找到合适的任务和合作方式，并把项目做完」。

2. 第一阶段先服务大学生竞赛

第一阶段选择大学生竞赛和技术项目，原因有三点：

赛事有明确的报名和截止时间；
学校、社团和学生组织方便触达用户；
发布机会、申请组队和提交作品的过程容易观察。

初期重点关注 AI、软件、数据分析、创新创业等技术相关竞赛。后续可以扩展到科研、开源、企业命题和创业项目。

3. 产品定位逐步明确

AIwelink 的核心场景是带着任务一起做事：

明确的竞赛或项目
  -> 找到需要的角色和能力
  -> 发起申请并组队
  -> 共同完成作品
  -> 记录结果和合作反馈

平台沉淀的结果包括有效申请、成功组队、持续合作、作品完成、竞赛提交和项目复盘。浏览、点赞和聊天只是辅助行为。

校园墙可以作为信息分发渠道。校园墙负责本地触达，AIwelink 承接结构化报名、组队、工具使用和成果记录。

4. 商业方向怎样形成

团队把商业路径安排为：

免费赛事与项目机会
  -> 用户组队并开始真实项目
  -> 用户出现 AI 工具和能力需求
  -> 使用 API、工具包、课程或导师服务
  -> 学校、赛事方和企业采购组织服务

当前重点方向包括：

面向竞赛团队的模型 API 和场景工具包；
赛事课程、训练营、作品评审和答辩辅导；
学校、社团和赛事方的报名、组队与活动管理；
企业命题赛、模型或算力赞助、品牌合作；
基于真实项目经历的人才发现和项目推荐。

平台在用户进入项目、遇到具体困难或开始备赛后展示相关服务。这样服务内容和用户当前任务直接相关。

5. 首页要呈现什么

首页围绕机会和下一步行动安排内容：

适合用户的竞赛和项目；
即将截止或正在招募的机会；
用户正在参与的项目；
自我认知和成长任务；
已完成的作品和经验；
与当前项目有关的 API、课程和导师服务。

登录可以分阶段要求：

未登录用户浏览部分公开机会；
用户收藏、报名、申请组队或开始个性化自我认知时登录；
微信作为主登录入口；
邮箱用于绑定、验证、通知和账号恢复。

6. 自我认知功能怎样形成

用户真正关心的是自己适合什么任务、角色和协作方式。因此，个人画像需要随着行动持续更新：

自我评估
  -> 选择项目
  -> 真实行动
  -> 队友反馈
  -> 项目复盘
  -> 更新个人画像

AI 自我认知助手先给出阶段性建议。真实项目行为、合作结果和队友反馈会成为后续更新的重要依据。

平台通过提问、项目记录和复盘帮助用户了解：

自己擅长什么；
适合承担什么角色；
适合怎样的工作环境；
哪些环节容易遇到困难；
下一步该学习或尝试什么。

7. 邀请、合作报告和积分

自我认知助手也可以作为推广入口：

免费自我认知助手
  -> 生成个人报告
  -> 分享用户选择的安全摘要
  -> 邀请朋友
  -> 生成双方或团队的合作建议
  -> 推荐适合一起参加的项目

双方取得明确许可后，合作报告可以包含：

互补优势；
分工建议；
可能发生摩擦的地方；
推荐的沟通方式；
适合一起参加的项目；
合作前需要约定的规则。

积分奖励绑定真实行为。例如完成个人报告、完成共享许可、生成合作报告、参加项目和完成复盘。积分可以兑换深度报告、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 分开：

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. 给新成员的阅读顺序

先读本文，了解产品方向的变化；
再读 docs/project-handoff.md，了解工程规则；
阅读 docs/architecture/technology-stack.md，掌握整体技术方案；
阅读 docs/architecture/technology-stack-details.md，了解接口、数据和部署细节；
开始实现对应模块前，再阅读模块文档和决定记录；
遇到待决定的事项，先保持接口清楚，把选项和依据记录下来。

14. 讨论结论

项目方向从「项目合作平台」逐步明确为：

项目合作平台
  -> 大学生竞赛组队
  -> 以任务为中心的协作
  -> 以自我认知为长期能力
  -> 推荐项目、学科和合作对象
  -> 双方取得许可后生成合作建议
  -> 通过真实项目积累成长和合作数据
  -> 用 API、课程、导师和机构服务提供收入

技术安排遵循同一原则：先用清楚、稳定、可以持续修改的模块化架构验证用户价值。等用户数量、项目数据和实际故障模式变得清楚后，再决定后续技术投入。候选项包括 AI 助手编排、复杂推荐、Kubernetes 和专用基础设施。

9.8 KiB Raw Blame History Unescape Escape