8.2 KiB
AIwelink 当前知识与开发安排
这份总览回答四个问题：
- AIwelink 现在要做什么；
- 哪些事情已经确定；
- 哪些事情还需要拍板；
- 开发应该按什么顺序推进。
原来的文档已经备份到 docs_old/。
当前版本放在 docs/，内容以容易阅读和实际执行为目标。
1. 当前状态
- 产品方向：帮助大学生认识自己、找到项目机会；
- 用户在真实合作中积累成长记录；
- 第一阶段从大学生竞赛和技术项目开始；
- 技术主线已经确定：Next.js、NestJS、PostgreSQL、Redis、OSS、Docker Compose；
- 代码目录处于初始化前阶段；
- AI 助手的模型、对话编排和任务队列列为待决定事项；
- 第一场重点竞赛、运营节奏和收费价格列为待安排事项；
- 商业、市场和运营资料继续放在飞书。
2. 我们已经知道什么
2.1 用户要完成的事情
用户进入平台后，应该可以完成下面的过程：
登录
-> 填写资料并了解自己
-> 看到适合的竞赛或项目
-> 选择项目角色
-> 邀请朋友并授权共享
-> 生成双方的合作建议
-> 申请加入项目
-> 记录项目进展和队友反馈
-> 完成复盘并更新个人画像
平台的价值来自真实行动和结果。推荐、报告和积分都要服务于这条过程。
2.2 第一阶段的产品范围
第一阶段优先完成这些功能：
- 微信登录、邮箱绑定和会话管理；
- 基础资料和个人画像；
- 自我认知助手的提问、回答和报告；
- 竞赛、项目和招募信息；
- 项目角色、成员和申请；
- 邀请链接和双方共享许可；
- 双人合作建议；
- 项目进展、队友反馈和复盘；
- 积分流水和基础兑换；
- 推荐内容和推荐理由；
- 首页工作台和公开机会页。
运营后台、完整商业交易、复杂推荐模型和大规模数据服务放在后续阶段安排。
2.3 数据应该留下什么
核心业务数据集中在 PostgreSQL：
- 用户和登录身份；
- 基础资料和公开资料；
- 测评回答和个人画像版本；
- 项目、成员、申请和行为记录；
- 队友反馈和项目复盘；
- 邀请、共享许可和审计记录；
- 积分流水、订单和权益；
- 推荐内容、推荐理由和用户反馈。
Redis 处理缓存、限流、短期状态和任务队列。 阿里云 OSS 保存简历、作品、报告和项目附件。
3. 已确认的工程规则
3.1 应用和访问路径
- Web 使用 Next.js + React + TypeScript；
- API 使用 NestJS + Fastify Adapter；
- Web 和 API 共用一个域名；
- API 路径统一从
/api/v1开始； - Web 负责页面和交互，API 负责业务规则；
- 入口代理按路径把请求转给 Web 或 API。
3.2 代码分层
数据库访问按下面的顺序组织：
Controller
-> Application Service
-> Repository
-> PostgreSQL
普通查询使用 Drizzle ORM。 向量检索、全文搜索、推荐排序和复杂报表使用参数化原生 SQL。 Controller 通过 Repository 访问数据库。
3.3 部署和基础设施
第一阶段的服务包括：
nginx
web
api
worker
postgres
redis
这些服务使用 Docker Compose 部署到自有 ECS。 文件上传到 OSS。 Uptime Kuma 检查首页、健康接口、端口和 HTTPS 证书。
4. 还需要拍板的事项
这些决定会直接影响产品和代码，建议按顺序确认：
4.1 确定第一个用户场景
需要明确第一场重点竞赛或项目，并写出完整流程：
- 用户从哪里进入；
- 需要填写哪些信息；
- 怎样看到机会；
- 怎样邀请队友；
- 怎样提交申请；
- 怎样记录项目结果。
4.2 确定个人画像的内容
需要确定自我认知助手的输入和输出：
- 需要问哪些问题；
- 报告包含哪些部分；
- 哪些内容可以公开分享；
- 用户怎样修改或补充报告；
- 项目反馈怎样更新画像。
4.3 确定项目和申请规则
需要确定：
- 项目有哪些状态；
- 项目角色怎样定义；
- 谁可以发布项目；
- 申请怎样审核；
- 成员怎样加入和退出；
- 项目完成后需要提交哪些结果。
4.4 确定 AI 助手方案
需要选择：
- 第一阶段使用的模型供应商；
- 单轮问答还是多轮对话；
- 报告是否异步生成；
- 任务失败后的重试方式；
- 记录哪些提示词、版本和费用信息。
4.5 确定运行方式
需要确定：
- PostgreSQL 和 Redis 自建还是托管；
- 备份保留多久；
- 生产环境的域名和证书管理；
- 日志、指标和告警使用哪些工具；
- 发布和回滚由谁负责。
5. 建议的开发顺序
第一步：写清第一个场景
先用一页文档写完「用户参加一场竞赛并找到队友」的过程。 再把页面、接口、数据和成功条件列出来。
产出：
- 用户流程图；
- 页面清单；
- API 清单；
- 数据表草图；
- 第一阶段成功指标。
第二步：初始化单仓库
创建下面的基础目录：
apps/web
apps/api
apps/worker
packages/contracts
packages/db
packages/validation
packages/ui
packages/config
infra/docker
docs/decisions
同时配置 TypeScript、Lint、测试命令、环境变量示例和数据库迁移流程。
第三步：先做最小 API
建议先完成：
- 登录和会话；
- 用户资料；
- 机会和项目；
- 项目成员和申请；
- 邀请和共享许可；
- 积分流水；
- 健康检查接口。
这些接口先用固定测试数据跑通，再接入真实页面。
第四步：接入自我认知助手
先定义统一的输入、输出和任务状态：
- 输入：用户回答、资料和项目上下文；
- 输出：结构化个人画像、推荐理由和待确认建议；
- 状态：待处理、处理中、完成、失败；
- 记录：模型名称、版本、提示词版本、耗时和费用。
模型供应商确定后，只替换具体实现，不改变业务接口。
第五步：完成 Web 主流程
Web 先实现这些页面：
- 公开机会页；
- 登录页；
- 个人资料页；
- 自我认知助手页；
- 首页工作台；
- 项目详情页；
- 邀请和共享确认页；
- 双人合作建议页；
- 项目申请页；
- 项目进展和复盘页。
每个页面都要能回到明确的下一步操作。
第六步：联调和试用
按真实用户顺序测试：
登录
→ 填写资料
→ 完成自我认知
→ 浏览机会
→ 邀请朋友
→ 确认共享
→ 申请项目
→ 记录进展
→ 完成复盘
记录用户在哪一步停下、哪些字段看不懂、推荐理由是否有帮助，再调整页面和数据结构。
6. 第一阶段完成标准
第一阶段完成时，至少要满足：
- 用户可以完成登录并保存资料；
- 用户可以完成一次自我认知并得到结构化报告；
- 用户可以浏览机会和项目，并看到推荐原因；
- 用户可以邀请朋友，双方可以明确选择共享内容；
- 用户可以生成双方合作建议；
- 用户可以申请加入项目并看到申请状态；
- 项目可以记录成员、进展、结果和队友反馈；
- 复盘结果可以形成新的个人画像版本；
- 积分流水可以追溯到具体行为；
- 关键接口有权限检查、错误格式和请求编号；
- 核心流程有自动化测试；
- 生产环境有健康检查、备份和恢复步骤。
7. 需要持续记录的知识
后续每次决定都记录在对应位置：
- 跨模块技术决定：
docs/decisions/； - API 接口和模块实现：
apps/api/docs/； - 数据库结构和迁移：
packages/db/docs/； - 部署、备份和恢复：
infra/docs/； - 临时讨论：
docs-local/； - 商业、市场、运营和合作：飞书。
每条决定写清楚「问题、选择、原因、影响和后续复查条件」。 这样新成员可以直接看懂，也方便以后修改。
8. 当前一句话结论
AIwelink 先做一个围绕真实竞赛和项目的成长平台。 用户从了解自己开始，找到机会和队友，完成项目，再用结果更新自己的认识。
开发先把这条用户流程跑通，再扩展 AI 助手、推荐系统、商业服务和更复杂的基础设施。