DevPulse｜LLM 结合 CodeArts 团队实战：从自然语言兴趣到分论坛报名

目录

第一部分：项目实战与协作复盘

一、我们希望解决什么问题

本文记录 Forum Atlas 在 2026 年 11 月 5 日完成的实现与验证。系统以 CNCC 会议服务为场景，使用 12 个自建教学论坛演示业务流程，论坛资料不属于官方议程。

面对大量会议分论坛，参会者经常需要在议程、论坛简介和个人时间之间来回切换。即使找到了感兴趣的内容，也仍然需要确认是否报名、是否与其他论坛冲突，以及是否有新的时间或地点通知。

Forum Atlas 将这些操作放在一条连续的流程中：

探索论坛 → 描述研究兴趣 → 查看推荐理由与来源
        → 核对真实论坛详情 → 自主报名
        → 查看个人日程 → 接收论坛通知

我们将大语言模型用于辅助理解兴趣和组织推荐理由，将论坛资料、报名状态、权限和人数统计保留在业务系统中。推荐结果只有能够回到真实论坛，并继续完成报名，才对参会任务有帮助。

二、实际完成的功能

通知采用 站内通知与每 20 秒轮询，不是短信或邮件推送。页面处于可见状态时自动更新；新报名用户可以看到该论坛的历史通知，取消报名后不再接收该论坛的新消息。

多语言覆盖导航、表单、按钮、提示和主要交互；论坛原始介绍保留中文，另外提供英文标题。当前没有将所有原始会议内容自动翻译为五种语言。

三、程序运行截图

3.1 论坛首页

首页提供日期、主题和关键词筛选。论坛卡片展示报名所需的基本信息，详情和加入日程入口保持相邻，减少反复跳转。

3.2 个人日程与冲突提示

同一用户报名两个时间重叠的论坛后，系统展示冲突。用户可以查看双方详情后取消其中一项，也可以保留报名，自行安排实际参与方式。

3.3 论坛通知

消息中心展示与当前报名相关的通知，支持标记已读。测试中取消订阅后，对应论坛通知不再出现在个人列表中。

3.4 真实模型推荐

本次通过浏览器输入大语言模型、软件工程与 RAG 相关需求，实际调用 deepseek-flash。校验后的结果包含“大模型时代的软件工程”和“检索增强生成与知识工程”两个已存在的教学论坛，并通过推荐卡片继续完成报名。

原始验证结果保存在仓库 docs/live-model-result.json。该文件包含验证时间、请求主题、HTTP 状态和推荐结果，不包含密钥。

3.5 管理端与授权范围

秘书可以查看参会者信息和发布通知；分论坛主席的管理列表仅包含授权的论坛。通过修改请求中的论坛 ID 访问其他论坛时，后端返回 403。

3.6 多语言与移动端

四、体系结构与数据库设计

4.1 技术栈

flowchart LR
    UI[Vue 前端] --> Nginx[Nginx]
    Nginx --> API[FastAPI 业务接口]
    API --> DB[(MySQL)]
    API --> Check[推荐适配与结果校验]
    Check --> Model[DeepSeek]

前端负责交互和展示，后端负责权限、事务与业务状态。模型服务只参与推荐流程，不能直接写入论坛资料或替用户报名。

4.2 数据模型

数据库包含九张业务表：

erDiagram
    users ||--o{ registrations : registers
    forums ||--o{ registrations : contains
    conferences ||--o{ forums : includes
    users ||--o{ forum_grants : authorized
    forums ||--o{ forum_grants : scoped
    forums ||--o{ notices : publishes
    users ||--o{ notices : authors
    users ||--o{ notice_reads : reads
    notices ||--o{ notice_reads : tracked
    users ||--o{ login_sessions : authenticates
    users ||--o{ recommendation_runs : requests

4.3 统计不能混淆“人数”和“人次”

一个人报名三个论坛，应该计为一名大会参会者、三次论坛报名。因此，大会人数对有效报名的用户去重，不能直接相加各论坛人数，也不能统计所有已注册账号。

取消部分报名后，用户仍计入大会人数；取消最后一个报名后，才从大会参会人数中移除。对应边界已经进入后端测试。

4.4 时间冲突的边界

系统采用左闭右开区间 [start, end)：

A.start < B.end 且 B.start < A.end

两个条件同时满足才算冲突。一个论坛在 12:00 结束，另一个在 12:00 开始，不构成重叠。当前不额外计算会场之间的交通时间。

报名变化后即时重算；主席或秘书修改时间地点后自动生成通知，个人日程在下一次查询或轮询中使用最新时间重新检查。

五、AI Coding：实际过程与验证

5.1 给 AI 的真实任务与约束

本次从课程需求和空仓库开始，使用 Codex 辅助实现会议系统，并接入 DeepSeek 完成分论坛推荐。模型地址、名称与密钥通过环境变量配置。

过程中补充并落实了以下约束：四类角色的后端权限、注册时选择论坛、人数去重、真实模型调用、异常结果处理、五语言统一资源，以及日程更新后的冲突检测。

开发任务、实现摘要和迭代验证记录保存在 docs/AI开发记录.md；运行时推荐提示词保存在 backend/app/recommendations.py，便于追溯模型调用的具体约束。

5.2 案例一：模型返回的论坛是否真实、相关

AI 生成了推荐适配和校验代码，关键输出结构为：

{
  "recommendations": [
    {
      "forum_id": 1,
      "reason": "与用户研究兴趣相关的具体理由",
      "evidence": "来自该论坛资料的原文片段"
    }
  ]
}

这里只是结构示例，真正的响应保存在验证 JSON 中。后端校验 ID、重复项、理由、原文证据和可识别的主题关系，然后用数据库记录补齐卡片。这样，即使模型输出了不存在的 ID，也无法把它变成可报名的论坛。

验证时构造五条结果：一条有效、一条重复、一条 ID 不存在、一条真实但主题无关、一条伪造原文证据。系统保留有效项，剔除其余四项。

我们采纳了候选约束和后置校验，没有采用“模型接口失败时返回固定推荐”的方案。对于模型超时、接口失败或非法结构，页面明确提示服务问题，并保留手动浏览入口。

这张截图来自测试主动注入超时响应，用于验证失败路径，不代表 DeepSeek 在实测时发生故障。

5.3 案例二：并发报名不能只依赖页面禁用按钮

首版实现使用联合唯一约束和用户行锁。代码检查进一步识别到 MySQL 事务快照的边界：等待用户行锁之后，如果报名关系仍采用普通快照读取，可能读到较旧的结果。

最终将已有报名关系查询改为锁定读取，与用户行锁配合，保证重复请求读取当前状态。这一风险在代码审查中被识别，并通过并发测试验证修订后的行为。

随后通过 Docker 部署版进行并发验证：8 个工作线程发起 16 次相同报名请求，16 次均返回成功，最终只保留 1 个有效报名。 测试后恢复了演示账号原来的报名集合。

5.4 案例三：用实际页面检查生成界面

首次截图时，论坛卡片的进入动画尚未结束，静态画面出现低透明度内容。实际页面可以正常操作，但截图不适合作为清晰的运行证据。

测试配置随后启用减少动画模式，再重新执行浏览器验收。减少动画模式使页面截图能够稳定呈现完整内容。移动端也检查了 390 × 844 视口，未出现横向溢出。

六、测试与部署结果

测试包括原子注册、重复报名、取消最后一项报名、用户隔离、主席授权范围、秘书信息访问、通知已读、时间首尾相接、论坛时间修改及模型异常。

本地部署命令：

docker compose up -d --build --wait

项目的启动说明在 README.md，本地运行与配置步骤在 deploy/部署说明.md。

七、团队职责

团队按认证与报名、前端交互、智能推荐、通知与多语言、测试与部署划分模块，分工方案如下。

八、开发难点与解决方法

开发中的难点主要集中在业务口径、并发一致性、模型结果约束和跨页面状态同步。各模块的处理方式如下。

九、贡献比例

本次贡献分采用平均分配，五位成员各 20 分，占总分的 20%，合计 100 分。

十、个人 PSP 工时估算

按模块职责整理工时预算，分别列出基础估算与包含调试余量的估算，单位为分钟。

10.1 郑宇凌

余量分析： 含调试余量的估算比基础估算增加 100 分钟，主要增加在编码与边界测试阶段。可将报名状态、统计口径和并发场景提前列入验收清单，降低联调阶段的返工。

10.2 陈仕杰

余量分析： 含调试余量的估算比基础估算增加 80 分钟，主要分配给页面设计、编码和联调。后续可提前确认接口字段与空状态，并在首轮实现时同步检查窄屏布局。

10.3 郑栋兴

余量分析： 含调试余量的估算比基础估算增加 130 分钟，编码与测试各增加 40 分钟。模型返回存在结构和语义变化，估算时应单独预留异常样本与真实接口验证时间。

10.4 张幼

余量分析： 含调试余量的估算比基础估算增加 90 分钟，主要用于编码、显示检查和文档整理。可先建立统一文案资源表，再集中检查长文本、按钮宽度和缺失翻译。

10.5 郑天一

余量分析： 含调试余量的估算比基础估算增加 120 分钟，主要增加在测试脚本、环境验证和报告整理。后续可提前验证配置模板，并将本地测试与容器验收分开估算。

第二部分：选题反思与具体行动

十一、重新思考选题价值

完成本次实践后，我们重新审视了选题中的一个核心问题：如何证明引入大模型产生了实际价值？

DevPulse 之前的选题关注知识库问答，会议系统则把同一个问题放在了更具体的场景中：用户描述研究兴趣后，能否找到相关论坛，理解选择原因，并完成报名？

对这一问题，功能验证已经提供了一部分证据。真实模型能够根据输入返回实际论坛，结果经过校验后进入详情与报名流程；无效输出和服务故障也有明确处理。这说明系统能够完成基本任务，但还不能直接得出“比手动浏览更高效”的结论。

下一步应让用户分别使用手动浏览和智能推荐完成同一任务，比较完成时间、选择是否合适以及是否需要重新查找。只有完成这种对照验证，才能进一步讨论推荐功能带来的实际收益。

十二、新的认识与已经采取的行动

12.1 把“可信”拆成可检查的条件

可靠推荐需要检查：论坛存在、理由有依据、页面信息来自数据库、用户能自主决定报名、失败时不会得到伪装成功的结果。只写一句“不要产生幻觉”并不能替代这些机制。

已经采取的行动是，将输出白名单、证据检查和错误分支写成代码，并为其建立反例测试。真实模型调用与注入失败的测试分别记录，避免混淆证据。

12.2 AI 生成速度不能代替业务定义

大会人数、报名人次、通知范围和时间重叠，表面上都是简单概念，但只有明确边界，前端、后端和测试才能验证同一件事。

已经采取的行动是，将人数去重、重复报名、取消最后一个报名和时间首尾相接纳入测试。数据库约束、事务逻辑与页面提示共同表达这些规则。

12.3 交付证据需要区分已完成与尚未完成

功能实现、自动化测试和真实模型调用分别提供不同层面的验证。本机容器运行记录、浏览器操作截图与模型响应共同构成当前版本的验证材料。

测试结果、运行截图及 AI 开发记录与对应功能一起保存，便于按模块复核实现结果。功能验证与后续用户效果评估分别记录，使完成情况和改进方向保持清晰。

当前版本已经形成从兴趣表达、推荐、报名到日程和通知的可运行流程。后续工作应围绕真实数据与用户验证展开，并继续以具体证据判断每项改进是否有效。

资料来源

• 课程作业要求：本文的交付结构与提交规则依据。
• 本项目代码、实际模型响应、测试与运行截图：均保存在上述 CodeArts 仓库。
• 默认论坛数据：团队场景下自建的教学示例，不是官方议程副本。