351 lines
13 KiB
Markdown
351 lines
13 KiB
Markdown
# 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 或专用基础设施。
|
||
|