NewPlatform/docs_old/discussion-summary.md

AIwelink 项目讨论过程总结

用途：记录 AIwelink 从最初想法到当前产品和技术共识的形成过程，帮助新开发者理解决策背景。

文档性质：这是讨论过程记录，不替代具体技术规范，也不替代飞书中的正式商业和运营文档。

当前阶段：方向已完成初步收敛，代码目录和 Agent 具体实现尚未定型。

1. 最初设想

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

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

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

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

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

选择原因：

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

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

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

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

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

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

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

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

4. 与校园墙的区分

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

区分重点：

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

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

5. 商业化方向的形成

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

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

主要商业化方向：

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

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

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

6. 首页心智的讨论结果

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

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

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

首页的优先内容：

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

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

7. 自我认知方向的形成

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

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

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

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

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

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

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

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

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

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

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

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

9. 双人画像与社交属性

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

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

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

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

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

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

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

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。

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

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. 总结

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

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

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