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