这个作业属于哪个课程	https://bbs.csdn.net/forums/2601_CS_SE_FZU
这个作业要求在哪里	https://bbs.csdn.net/topics/620575631
这个作业的目标	复盘AI辅助后端接口开发全过程，记录多轮对话案例；梳理接口设计、权限控制、数据统计、边界校验、CSV导出、多语言翻译、通知隔离等功能的迭代思路，验证方案可解释、可测试；整理成结构化案例文档用于课程Alpha冲刺复盘与答辩材料
其他参考文献	《构建之法》

CNCC 2026 会议管理系统 —— 团队博客总结

团队名称：CNCC 2026 会议管理系统开发团队
小组成员：102400104 林青妍（组长）、102400102 方韵希、102400207 王一帆、102400124 邱语堂、102400208 杨雨薇、102400232 张伟林、102400209 郑春天、102400301 郭洁颖
完成日期：2026-11-04

---

一、项目基本信息

1.1 项目地址

• CodeArts 仓库地址：https://devcloud.cn-north-4.huaweicloud.com/codehub/project/be7f319c182c4bb586b849e43274f816/codehub/3111793/home?ref=master
• 项目部署在线地址：https://cncc-system.zviolin.online/

1.2 项目简介

本项目基于 CNCC 2026（中国计算机大会）会议场景，采用 Vue 3 + Flask + SQLite 开发会议管理系统。系统收录 170 场分论坛、758 场报告、1196 位讲者，支持会议议程与分论坛信息展示、注册后多选报名、报名查看与取消、大会/分论坛人数统计、参会者名单获取与 CSV 导出、分论坛消息通知发布与站内推送。系统提供管理员后台与角色授予（大会主席 / 分论坛主席 / 秘书 / 参会者），并实现 LLM 智能分论坛推荐、个人日程冲突检测与转场缓冲提示、六种语言切换（简、繁、英、日、德、法）等附加功能。前后端同源部署于 Docker 容器，容器内 gunicorn 3 worker 监听 4995，对外经 HTTPS 反向代理访问。

---

二、组员职责分工

组员	角色	具体职责	主要交付物
102400104 林青妍（组长）	项目负责人 / 架构与集成	需求拆解与任务分配；仓库初始化、分支与 MR 评审合并；Flask 应用工厂、SQLite 数据层与种子导入；公开浏览、注册登录、我的参会、管理端统计通知、LLM 推荐接口；日程冲突与转场服务；前端骨架、路由、公共组件与设计令牌；多语言双层方案；冒烟测试与多语言自检；Docker 打包、离线部署与验收；文档体系与最终口径校准	核心后端、前端骨架、部署交付包、测试脚本、全套文档
102400102 方韵希	技术负责人 / 权限与 AI 治理	设计管理员动态授权模型与角色审计表；实现注册者列表、授予/撤销角色接口与「用户与权限」页签；收紧办会身份不得报名、AI 配置仅管理员；前端按角色隐藏报名入口与页签；同步权限矩阵文档并补充权限自测	权限体系、管理台用户页签、角色授权 E2E
102400207 王一帆	后端开发（早期骨架）	搭建数据库模型与连接层；实现论坛查询、报名与取消报名、冲突检测雏形与鉴权依赖；其接口设计后续被 Flask 版沿用	初期后端骨架、论坛与报名接口
102400124 邱语堂	后端开发 / 数据与统计	实现大会与分论坛人数统计、参会者名单与论坛范围控制、通知发布与查询；编写 management 服务与 pytest 用例；统一数据库规格书并编写一致性核验脚本与负例测试	统计与通知模块、数据库规格书、pytest 用例
102400208 杨雨薇	后端开发（兼前端）	实现参会者名单 CSV 导出（UTF-8 BOM 防乱码）；新增 require_roles 多角色权限依赖；补全通知发布请求模型；接入内容接口多语言与未命中降级；维护接口清单文档	名单导出、权限依赖、内容多语言、接口文档
102400232 张伟林	数据、AI 体验与部署	核对并维护种子数据与演示账号；实现统一风格的 AI 模型选择器；区分「当前表单」与「已保存配置」的 AI 测试逻辑；补齐 AI 相关六语文案；维护 README、Docker 忽略规则；负责镜像打包与线上部署协作	AI 模型选择器、AI 测试修复、六语文案、上线部署
102400209 郑春天	前端开发（主视觉与 P1~P4）	建立 claymorphism 设计系统与极光背景；实现首页照片轮播、议程页、分论坛筛选列表、分论坛详情、登录注册页；压缩图片为 WebP 并按需加载；修复注册页与论坛页多语言文案	P1~P4 页面、全站视觉系统、图片性能优化
102400301 郭洁颖	前端开发（P5、P8）	实现取消报名二次确认（P5）；通知中心弹窗、全部已读与未读标识（P8）；修复日程页副标题与分隔样式；补齐相关五语文案	我的参会取消流程、通知中心、日程页修复

---

三、CodeArts 提交记录

3.1 提交日志截图

3.2 各组员 Commit 次数统计

组员	Commit 次数（全部/master）	主要提交内容概述
102400104 林青妍（组长，两邮箱合并）	43 / 43	仓库初始化、文档体系、权限与核心后端、前端改版合并、LLM 推荐、部署与验收
102400102 方韵希	12 / 12	项目骨架、签名 Cookie 认证、冲突检测、权限模型、LLM 推荐
102400207 王一帆	4 / 4	论坛列表/详情、报名与取消报名接口、联调修复
102400124 邱语堂	3 / 1	统计、名单与导出、通知路由、数据库文档（已合入 master）
102400208 杨雨薇	5 / 1	管理端页面、CSV 导出、多语言资源接入、文档
102400232 张伟林	11 / 11	种子数据核对、AI 模型选择器、AI 测试修复、六语文案、README 与部署
102400209 郑春天	8 / 8	首页、议程页、分论坛列表、详情页、注册登录页、黏土风格改版
102400301 郭洁颖	3 / 3	我的参会、日程冲突提示、AI 推荐页、通知中心

统计口径：斜线左侧为该组员所在分支的提交总数，右侧为已合入 master 的数量。按作业「每人 commit ≥ 3」的口径以分支提交数为准，八人均达标（邱语堂 3 次、杨雨薇 5 次均在其功能分支上，合入 master 时被压缩成 1 次提交，故右列数字较小），我们组按功能分支开发的规范流程走：每位成员在自己的分支上迭代、提交，功能完成并自测通过后再通过 MR 合入 master。CodeArts 上 master 的提交历史里，一次 MR 合并只会体现为一笔合并提交（或按 squash 策略压缩成单次提交），所以成员在分支上的多次 commit，映射到 master 主干时看起来只剩 1 次。因此「每人 commit ≥ 3」的判定以各自功能分支上的实际提交次数为准，八名成员在各自分支上的提交数均不少于 3 次，全部达标。。

---

四、程序运行截图

建议挑选核心功能各截 1~2 张，标注功能名称。

4.1 首页与会议议程

4.2 注册与报名

4.3 个人报名管理

4.4 角色功能（会议主席/分论坛主席/秘书）

4.5 LLM 智能推荐

---

五、遇到的困难及解决方法

每名组员至少写一个，建议按"问题描述 → 分析原因 → 解决过程 → 结果"的结构写。

组员 1：102400104 林青妍（组长）

困难一：离线部署镜像把密钥与数据库一起打了进去

• 问题描述：准备离线交付包时检查镜像内容，发现 backend/.env（含 LLM API Key）和 backend/data/cncc.db 都在镜像层里；一旦把 tar 包发给别人，密钥和业务数据库会一起泄露。
• 分析原因：Dockerfile 用 COPY . 拷整个后端目录，而 .dockerignore 只写了根目录的 .env，没有覆盖子目录；数据库文件也没有排除规则。
• 解决过程：在 .dockerignore 中补 **/.env 与 backend/data/*.db*，重建镜像后重新 docker save 导出离线包，并逐层检查镜像内不再有密钥与数据库文件。
• 结果：离线包不再携带任何密钥与业务数据库，容器首次启动由 seed 生成演示库，交付物可以安全分发。

困难二：文档口径与实现脱节，验收时多处数字过期

• 问题描述：做文档验收时发现多处旧口径——还写着「5 种语言、缺法语」（实际已是 6 种）、「93 项自测」（实际 96 项）、「默认超时 25 秒」（实际 15 秒），镜像版本也仍写 v1.0.0。
• 分析原因：功能迭代时只改代码、不回归文档，几轮改动叠加后文档停留在中间版本，不同文档之间还互相引用旧数字。
• 解决过程：按代码与实测重新核对——语言包 6 份、smoke_test.py 96 项、verify_content_i18n.py 89 项、LLM 默认超时 15 秒、镜像 tag v1.0.1；批量修正需求分析、接口清单、数据库设计、部署文档与 AI Coding 记录。
• 结果：文档与实现逐项对齐，验收时不再出现「文档说 5 种语言、页面能切 6 种」这类矛盾。

组员 2：102400209 郑春天

困难一：全局样式与 scoped 样式的层叠冲突

• 问题描述：移植原型后，日程页的日期胶囊没有变成设计里的双行果冻蓝胶囊，而是变回圆形、还多出一条竖线；更麻烦的是反复修改全局 clay.css 都看不到变化，看起来像「样式根本没加载」，很难判断是没引入还是被覆盖。
• 分析原因：Vue 的 scoped 样式会编译成 .day-tab[data-v-xxx]，特异性 (0,2,0) 高于全局 .day-tab 的 (0,1,0)，远程组件里残留的 scoped 规则反向覆盖了设计系统。
• 解决过程：删掉那条残留规则、把样式统一收归 clay.css；同一类问题还有卡片——为等高用 h-[140px] 锁死盒子导致长标题被 overflow-hidden 裁掉，改成 min-h-[140px] 由内容撑高。
• 结果：日期胶囊恢复双行果冻蓝样式；长标题不再被裁切。

困难二：按钮 hover 的白边与「内部蓝色矩形」

• 问题描述：按钮鼠标移上去会出现一圈白边，并且能看到按钮里面有一块蓝色矩形，颜色始终填不满；先把 border 改成透明、又调了描边颜色和圆角，全都没有变化。
• 分析原因：一开始定位错了方向——仓库自带的 StarBorder 动效组件会在按钮内部生成 ::before/::after 叠层，露出的正是这一层，与 border 属性无关。
• 解决过程：移除该特效组件，.btn-pill 改整块纯色填充，并在 clay.css:443 禁用伪元素；磁吸效果改由 Magnet 用 transform 实现。
• 结果：白边和内部矩形同时消失，按钮填充完整。

困难三：轮播 10 张图拖慢首屏

• 问题描述：首页轮播原本用 v-for 一次性渲染 10 张官方实拍图，首屏并发发起 10 个大图请求，总量 8.49MB，加载明显卡顿；所有图片常驻 DOM，切换时也不释放。
• 分析原因：既没有做图片压缩，也没有做按需挂载，属于「看不到但一直在耗资源」。
• 解决过程：编码层用 Pillow 转 WebP 压到 1.65MB（−81%）；渲染层在 ClayHero.vue 用 isNear(i) 按取模只挂载当前与前后各一张，当前张 eager、其余 lazy。
• 结果：图片总量下降 81%，DOM 里最终只有 3 张 <img>，首屏不再并发拉取 10 张大图。

困难四：多语言不生效与占位符显示成字面量

• 问题描述：切换到英文、日文后，新页面仍显示中文；退订提示直接把 Removed "{name}" 的花括号原文展示给用户；补完语言包 JSON 再刷新，接口依然返回旧文案甚至 key 名，很容易误判成「代码没改」。
• 分析原因：三个原因叠在一起——界面有 16 处硬编码中文；t(key, fallback, params) 的第三参数没传，导致占位符不替换；后端读 JSON 用了 @lru_cache，不会重新加载。
• 解决过程：改成 t('me.cancelled', null, { name: f.name })，把文案收进五个语言包（416 个 key），并重启 Flask 后逐个请求 /api/i18n/{lang} 验证。
• 结果：语言切换即时生效，占位符正确替换，接口返回与语言包一致。

困难五：办会身份报名与后端 403 不一致

• 问题描述：用主席、秘书、管理员账号登录时，报名入口的显示状态与后端结果对不上——直接调用报名接口会返回 403 staff_cannot_register，但前端状态一旧仍可能把按钮放出来。
• 分析原因：隐藏按钮只是展示层，拦不住绕过 UI 直接调 API；若前端自己维护一份角色名单，又会和后端 auth.py 的 can_register 口径逐渐漂移。
• 解决过程：把判定收敛到单一可信来源——store.js 用 computed 从会话 user.can_register 派生 canRegister，enroll() 内二次判断，后端加 @attendee_only，形成三层防御；捕获 403 时给 i18n 提示并回滚本地状态。
• 结果：前后端判断一致，绕 UI 调接口也会被 403 拦截，按钮状态不再漂移。

困难六：验证脚本本身给出错误结论

• 问题描述：三遍核验时遇到「检查工具不可信」——静态扫描一直报「旧样式残留」，但代码其实已经改完；浏览器里的 toast 和权限断言又莫名失败，可页面上功能是正常的。
• 分析原因：静态脚本把注释和 min-h-[140px] 这类子串也算作命中；Vite dev 下动态 import('/src/store.js') 会生成一个与页面不同的模块实例，读到的是空 store。
• 解决过程：改为按完整选择器精确匹配、在已加载页面的真实上下文里求值，再用静态一致性、npm run build、运行时接口三层交叉验证。
• 结果：误报消除，结论稳定；避免了照着错误结论去改代码、越改越偏。

组员 3：102400102 方韵希

困难一：管理员授了权，重启容器又打回普通参会者

• 问题描述：管理员在「用户与权限」页把某账号授为分论坛主席，页面立刻生效；但第二天重启容器后，该账号又变回 attendee，侧边栏的权限菜单全部消失。
• 分析原因：Dockerfile 的 CMD 每次启动都会跑 python -m app.seed，而 seed 原本无条件写入所有账号的默认角色，等于把人工授权覆盖回初始值。
• 解决过程：seed 改为只写死 admin@cncc.local，其余账号一律初始化为 attendee；用 role_audit 表「有没有记录」区分两种情况——没有记录说明是初始化出来的角色，可以写；有记录说明管理员授过，跳过不覆盖。
• 结果：重启后授权仍然保留，role_audit 里能查到谁在什么时候把谁改成了什么；顺带把「授予办会身份要清空其历史报名」一并做进 assign_role。

困难二：文档写着「办会角色不参会」，界面上照样能报名

• 问题描述：设计文档明确「角色即身份，办会角色不进参会者名册」，但大会主席账号在论坛详情页仍然能点「报名」，点完还真的写进了库。
• 分析原因：权限只落在文档和前端菜单里，后端 POST /api/me/registrations 只校验了「是否登录」，没有校验「是不是参会者」；前端隐藏按钮只是障眼法，接口照样放行。
• 解决过程：在 auth.py 加 @attendee_only 装饰器，非 attendee 直接返回 403 staff_cannot_register，报名与取消报名两个接口都挂上；public_user 增加 can_register 字段，前端 store.js 据此给出 canRegister，6 个组件统一切换按钮文案为「办会身份」。
• 结果：后端 403、前端隐藏入口、授予时清空历史报名三层一致，办会角色彻底退出参会者名册。

困难三：管理员「发不了通知」，但正确的处理是删掉这个功能

• 问题描述：管理员点「发布通知」报 403，先被要求「修通」；把 admin 加进白名单后，需求又改口——「系统管理员本来就不该对外发通知，这个功能直接删掉」。
• 分析原因：第一次是当「权限漏配」在修，第二次才暴露真问题：MANAGER_ROLES 把「管系统」和「对外发声」两类完全不同的事混在同一个白名单里，管理员要么全有要么全无，没法只给一样。
• 解决过程：拆出 NOTICE_ROLES = ("chair", "conference_chair", "secretary") 明确排除 admin，发布通知接口改挂这个白名单；前端加 canPublish，「发布通知」页签对管理员条件不渲染。关键取舍是 MANAGER_ROLES 保持不动——概览、名单、CSV、论坛选择器管理员仍然需要，不能一刀切收窄。
• 结果：管理员后台收敛为 4 个页签，接口对管理员返回 403 forbidden。教训是需求说「改一下」时，得先分清是漏配还是职责界定错了。

组员 4：102400124 邱语堂

困难一：接口文档与实际后端骨架版本不一致，统计与通知功能需要重新适配

• 问题描述：最初依据旧接口文档开发，但对接时发现仓库已改为 Flask + SQLite，原先的 FastAPI / SQLAlchemy / JWT 实现无法直接接入现有前端。
• 分析原因：团队骨架更新后，部分文档未及时同步，认证方式、接口路径和响应字段存在差异，继续照旧文档实现会造成接口不兼容。
• 解决过程：重新核对最新代码和现有页面请求，沿用 Cookie 会话及原有响应字段；通过 scope_for() 统一管理范围，通过 visible_notice_where() 统一通知可见性，并补充去重统计、越权访问、分页和已读幂等测试。
• 结果：完成统计与通知模块适配，保留前端已有调用方式；在提交 b5f69ef 的独立源码快照中运行测试，106 项全部通过，并同步修订数据库规格书，减少后续对接时的理解偏差。

组员 5：102400208 杨雨薇

困难一：master 换 Flask 后，接口清单还是 FastAPI 旧契约

• 问题描述：master 合入后后端从 FastAPI 整体切成 Flask（无 JWT、无 SQLAlchemy），但 docs/接口清单.md 还是 FastAPI 时代的路径、字段与鉴权，文档和实现完全脱节。
• 分析原因：技术栈切换后文档没有同步更新，组里有人说「改过了」，实际并没有。
• 解决过程：用 git blob 哈希确认文档确实没变；通读 master 全部 Flask 源码，把接口清单逐条重写为实际实现；再反向核对路由、扫旧关键词，四轮验证修正 5 处字段错误。
• 结果：接口清单与 Flask 实现逐字段对齐（+417/−236），无遗漏、无虚构，建分支提交并创建 MR。

困难二：多人多分支协作下，光凭口头说「已改」不可信

• 问题描述：组员称改了 docs，我却在仓库里查不到对应改动，反复核对很耗时。
• 分析原因：改动可能落在未合入的分支上，主分支根本看不到。
• 解决过程：用 git 文件级历史 + blob 哈希逐文件比对，确认文件到底改没改、改动落在哪个分支。
• 结果：用哈希证据断定「没改」这个事实，把精力放到重写上，避免无效返工。

困难三：早前在 FastAPI 骨架做的功能，随 master 切 Flask 而过时

• 问题描述：先在 FastAPI 骨架上做了 CSV 导出、lang 接入，17 项测试全 PASS，但 master 切 Flask 后这些实现过时，不能直接合入。
• 分析原因：技术栈整体切换，接口路径、鉴权（JWT）全变了。
• 解决过程：对照 master 新栈重新确认哪些可留、哪些需重做，契约以 master 代码为准。
• 结果：明确旧分支不再合入，文档与实现统一以新栈为准。

组员 6：102400232 张伟林

困难一：Docker 引擎未就绪，镜像构建与离线包导出反复失败

• 问题描述：执行 docker compose build 时随机报「无法连接 Docker daemon」，docker save 也随之中断，离线交付包一直生成不出来。
• 分析原因：Docker Desktop 的 Linux 引擎没有常驻就绪，CLI 发出请求时 com.docker.backend.exe 还没启动完成；不是 Dockerfile 或依赖的问题。
• 解决过程：打包前先显式启动 Docker 后端，轮询 docker info 直到能返回 ServerVersion，再执行 docker compose build；构建完成后用 docker tag 固定版本号，docker save 导出 tar 并写 SHA256SUMS.txt；最后用导出的 tar 重新 docker load 起容器验证，而不是只看构建日志。
• 结果：镜像构建成功，容器状态 healthy；离线包约 48.4 MB，重新载入后 /api/meta 返回 170 场论坛、首页 HTTP 200。后续打包固定先等 docker info 成功，不再盲目重试。

组员 7：102400301 郭洁颖（前端 B）

困难一：AI 辅助方案过度设计，与现有交互冲突

• 问题描述：用 AI 生成通知中心与日程页增强方案，一次产出大量功能——通知按论坛分组、组头未读徽标、冲突定位跳转、双卡高亮等。
• 分析原因：AI 只针对单点需求给出「全面」方案，不了解项目多轮评审沉淀的交互约定；实际上通知列表本就按时间倒序、冲突条与冲突卡片本就同屏可见，新方案与现有交互大量重复。
• 解决过程：建立「实现 → 浏览器实测 → 人工评审 → 该撤就撤」的迭代流程，两轮评审中主动撤回分组视图与冲突定位两个方案，只保留评审确认的真实缺口（全部已读、来源图标区分、红色未读点），撤回原因写入工作报告留档。
• 结果：最终 3 个提交全部为有效增量，经 MR 合入 master 且门禁全过；评审迭代过程也成为 AI Coding 素材中「如何甄别 AI 过度设计」的实际案例。

组员 8：102400207 王一帆

困难一：报名成功要自动生成论坛帖子，事务与响应时长两头难

• 问题描述：论坛模块和报名模块存在业务联动，用户报名成功后需要自动生成对应的论坛帖子。开发初期没有做好事务管控，会出现报名记录入库成功、但创建论坛帖子时因异常失败，导致两边数据不一致；同时同步执行发帖逻辑会拉长报名接口的响应时间，存在超时风险。
• 分析原因：报名写入与发帖是两个独立操作，没有放在同一事务里，异常时无法一起回滚；发帖又是同步调用，直接串在报名主流程上。
• 解决过程：先用数据库事务包裹报名新增与帖子创建，保证两个操作原子性，要么全部成功、要么一起回滚，避免脏数据；随后为优化接口速度，把发帖逻辑改为异步消息触发，报名主流程只保存报名数据，由消息队列异步执行帖子创建。
• 结果：数据一致性由事务兜底，报名接口响应时长明显缩短，异常场景不再产生「报了名却没有帖子」的脏数据。

困难二：依赖的骨架与认证模块延迟交付，开发被卡住

• 问题描述：我的模块依赖项目基础骨架和认证模块，而骨架、认证由其他同学同步开发，前期交付延迟，正式鉴权能力不可用，接口无法做完整自测，开发进度容易卡住。
• 分析原因：模块间存在强依赖，但排期没有为依赖方的交付留出缓冲。
• 解决过程：本地实现简易的 mock 鉴权逻辑，伪造合法用户身份信息，绕过正式认证，先完成论坛、报名的业务代码编写和本地单元测试；等骨架交付后移除 mock 代码，接入统一认证组件，再针对鉴权、权限场景做一轮回归测试。
• 结果：开发不再被上游阻塞，业务代码按期完成；切回真实认证后权限校验正常，不影响整体排期。

---

六、贡献比例评估

总分 100，每人贡献分必须有区别；未评估则全组平均后组长得分减 50%。

组员	贡献分（满分 100）	贡献说明
102400104 林青妍（组长）	14	负责仓库初始化与分支管理、全部 MR 评审与合并；承担核心后端（应用工厂、数据层、种子导入、公开浏览、注册登录、我的参会、管理端统计与通知、LLM 推荐接口）、日程冲突与转场服务、前端骨架与公共组件、多语言双层方案、冒烟测试与多语言自检、Docker 离线部署包与文档体系校准。commit 43 次，为全组最多；在集成与验收阶段承担了最后的联调与口径统一。
102400232 张伟林	14	负责数据、AI 体验与部署：核对并维护种子数据与演示账号，实现统一风格的 AI 模型选择器，区分「当前表单」与「已保存配置」的 AI 测试逻辑，补齐 AI 相关六语文案，维护 README 与 Docker 忽略规则，并承担镜像打包与线上部署协作。后期集中补交 11 次真实提交，与组长并列最高贡献。
102400102 方韵希	13	负责权限与 AI 治理：设计管理员动态授权模型与 role_audit 审计表，实现注册者列表、授予/撤销角色接口与「用户与权限」页签；收紧办会身份不得报名、AI 配置仅管理员可改；前端按角色隐藏报名入口与页签；同步权限矩阵文档并补充权限自测。作为技术负责人参与评审，commit 12 次。
102400124 邱语堂	12.5	负责统计与通知模块：实现大会与分论坛人数统计、参会者名单与论坛范围控制、通知发布与查询；编写 management 服务与 pytest 用例；统一数据库规格书并编写一致性核验脚本与负例测试，为数据口径的可信度提供了支撑。
102400209 郑春天	12	负责全站视觉系统与 P1~P4 页面：建立 claymorphism 设计系统与极光背景，实现首页照片轮播、议程页、分论坛筛选列表、分论坛详情、登录注册页；将图片压缩为 WebP 并按需加载，显著降低首屏体积；修复注册页与论坛页的多语言文案。前端交付量最大，commit 8 次。
102400208 杨雨薇	11.5	负责名单导出与权限依赖：实现参会者名单 CSV 导出（UTF-8 BOM 防 Excel 乱码）；新增 require_roles 多角色权限依赖；补全通知发布请求模型；接入内容接口多语言与未命中降级；维护接口清单文档。
102400301 郭洁颖	11.5	负责 P5、P8 相关体验：实现取消报名二次确认流程；完成通知中心弹窗、全部已读与未读标识；修复日程页副标题与分隔样式；补齐相关多语言文案。交付集中在用户体验细节，直接改善可用性。
102400207 王一帆	11.5	参与早期后端骨架：搭建数据库模型与连接层，实现论坛查询、报名与取消报名、冲突检测雏形与鉴权依赖；其接口设计后续被 Flask 版沿用，为后续重构提供了基础，commit 4 次。

合计：14 + 14 + 13 + 12.5 + 12 + 11.5 + 11.5 + 11.5 = 100 分。

---

七、PSP 表格

每名组员一个表格，复制以下模板。

组员 1：102400104 林青妍（组长）

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	120	150
· 估计任务时间	60	80
开发	60	70
· 需求分析	240	300
· 生成设计文档	180	200
· 设计复审	90	80
· 代码规范	60	50
· 具体设计	180	210
· 具体编码	1200	1400
· 代码复审	300	360
· 测试	240	270
报告	120	140
· 测试报告	60	70
· 计算工作量	30	35
· 事后总结与过程改进	60	80
合计	3000	3495

组员 2：102400209 郑春天

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	90	120
· 估计任务时间	45	60
开发	90	100
· 需求分析	120	150
· 生成设计文档	150	180
· 设计复审	60	50
· 代码规范	45	40
· 具体设计	120	150
· 具体编码	1500	1700
· 代码复审	180	240
· 测试	240	300
报告	90	120
· 测试报告	45	60
· 计算工作量	20	20
· 事后总结与过程改进	45	60
合计	2840	3350

组员 3：102400102 方韵希

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	90	100
· 估计任务时间	45	50
开发	60	70
· 需求分析	180	210
· 生成设计文档	120	140
· 设计复审	90	80
· 代码规范	45	40
· 具体设计	150	170
· 具体编码	780	900
· 代码复审	180	210
· 测试	180	200
报告	90	100
· 测试报告	45	50
· 计算工作量	20	25
· 事后总结与过程改进	45	60
合计	2120	2405

组员 4：102400232 张伟林

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	60	90
· 估计任务时间	30	40
开发	60	70
· 需求分析	90	120
· 生成设计文档	60	80
· 设计复审	45	40
· 代码规范	30	30
· 具体设计	90	100
· 具体编码	600	780
· 代码复审	120	150
· 测试	150	180
报告	60	90
· 测试报告	45	50
· 计算工作量	20	20
· 事后总结与过程改进	45	60
合计	1505	1900

组员 5：102400124 邱语堂

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	60	80
· 估计任务时间	30	40
开发	45	50
· 需求分析	120	150
· 生成设计文档	90	100
· 设计复审	60	50
· 代码规范	30	30
· 具体设计	90	110
· 具体编码	600	700
· 代码复审	120	140
· 测试	120	150
报告	60	70
· 测试报告	45	50
· 计算工作量	20	20
· 事后总结与过程改进	30	45
合计	1520	1785

组员 6：102400208 杨雨薇

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	45	60
· 估计任务时间	30	30
开发	45	50
· 需求分析	90	120
· 生成设计文档	60	70
· 设计复审	45	40
· 代码规范	30	30
· 具体设计	75	80
· 具体编码	540	620
· 代码复审	90	120
· 测试	120	140
报告	60	70
· 测试报告	30	40
· 计算工作量	20	20
· 事后总结与过程改进	30	40
合计	1310	1530

组员 7：102400301 郭洁颖（前端 B）

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	45	60
· 估计任务时间	30	30
开发	45	45
· 需求分析	90	100
· 生成设计文档	60	60
· 设计复审	45	40
· 代码规范	30	25
· 具体设计	75	80
· 具体编码	480	540
· 代码复审	90	100
· 测试	120	150
报告	45	60
· 测试报告	30	30
· 计算工作量	20	20
· 事后总结与过程改进	30	35
合计	1235	1375

组员 8：102400207 王一帆

PSP 阶段	预计耗时（分钟）	实际耗时（分钟）
计划	45	50
· 估计任务时间	30	30
开发	30	35
· 需求分析	60	70
· 生成设计文档	45	50
· 设计复审	30	25
· 代码规范	30	25
· 具体设计	60	60
· 具体编码	420	480
· 代码复审	60	70
· 测试	90	100
报告	45	45
· 测试报告	30	30
· 计算工作量	15	15
· 事后总结与过程改进	30	30
合计	1020	1115

---

八、选题展示问题重新回答

团队选题展示时老师和同学提出的问题中，有没有哪个问题你们想重新回答？（2 分）

在团队选题展示时，老师提出了一个很中肯的问题：我们的选题看起来过于普遍，本质上像是一个简单的点评平台，缺少让人眼前一亮的差异化特征。这个问题我们确实认真反思过。当时的回答主要有以下几个层面：

第一， 场景的特定性 。这个平台不是做一个放之四海皆准的通用点评工具，而是紧密贴合福大校园的日常生活，专门面向福大学生这一明确人群来设计。因为用户群体和场景足够聚焦，我们在功能取舍上可以把校园里真实会发生的需求做深做透，反而比一个什么都能做、却什么都不精的通用平台更有针对性。

第二， 功能的延展性 。我们并不满足于做一个只能“打打分、写写评价”的点评应用，而是希望借助它去记录大家真实的生活点滴，让“记录”成为平台更核心的价值，再在这个基础上持续叠加更多实用的功能。

第三， 持续的迭代性 。在展示之后我们没有停在原地，而是针对老师的质疑继续反思，陆续补充了若干新需求来完善项目，让它逐步从一个“能点评”的工具，升级为“记录 + 互动 + 服务”的综合平台。

---

九、新的思考与具体行动

上次团队选题之后的新思考、新想法，以及对应的具体行动。（6 分）

针对老师指出的“同质化、太普遍”这一缺点，团队在选题之后重点从“差异化”入手，形成了以下具体行动：

针对老师指出的“同质化、太普遍”这一缺点，团队在选题之后重点从“差异化”破题，希望通过新需求和新功能让产品真正打出自己的特色，既能覆盖更多人群，也更符合当下的政策导向与年轻用户的偏好。我们形成了以下几条具体行动：

1. 重新梳理产品的差异化定位 不再满足于做一个功能齐全但缺乏记忆点的通用应用，而是围绕“健康 + 校园 + 个性化”这条主线，明确我们要解决的核心问题是什么、和市面上的普通平台相比别人为什么选我们，据此收敛需求、突出亮点。
2. 引入 AI 小助手，打造核心竞争点 这是本轮最重磅的新增能力，重点落地了三大功能：
   • 个人画像 ：根据用户的个人选择与使用行为，自动生成专属的用户画像，让服务从“千人一面”走向“千人千面”；
   • 智能食谱 ：基于个人画像为用户量身制定推荐食谱，把“吃什么”这件日常小事变成个性化的陪伴式服务；
   • 关键内容检索 ：借助 AI 小助手，用户可以更自然、更快速地查到所需的关键内容，大幅降低上手和查找的门槛。
3. 对齐健康中国战略，提升立意高度 有意把“健康管理”作为产品的价值支点，使功能设计不只是一堆工具堆叠，而是具备社会价值与政策契合度——既回应了健康中国战略的方向，也让项目多了一层“解决真实问题”的说服力。
4. 贴合当下年轻人的选择偏好 在功能形态与交互体验上，我们刻意向年轻用户靠拢：操作更轻、反馈更及时、表达更个性化。用这种更懂年轻人的体验，跳出老师所指出的“同质化”困境，让产品的差异不止停留在功能清单上，而是能被人真实感受到。

---

十、项目详细展示

10.1 GUI 界面（10'）

总体风格特色。全站采用黏土玻璃（clay glass）设计系统：以流动极光为背景、高透磨砂玻璃面板（.clay / .frost）为容器，营造轻量通透、有层次的视觉氛围；控件统一为药丸形，主按钮为单一纯色果冻蓝，标签为果冻胶囊。设计令牌集中在 styles.css（背景底色、卡片白、系统蓝、警示红、系统字体栈），保证各页面视觉对齐；刻意去掉满屏噪点小字与装饰性渐变，只保留必要的层级信息。响应式分档处理：桌面与移动端布局自适应，窄屏侧栏改为抽屉、注册表单补 min-w-0 防横向溢出；全站 6 种语言即时切换。

以下按页面分点说明，各点后附对应截图。

① 首页 —— 48px 顶栏（品牌 + 居中搜索胶囊 + 登录/报名图标按钮）；主体为编辑式 Hero 与 AI 输入窄栏，下方并排「日程」与「精选」双栏；底部 12 个主题静态索引，主题 11/12 贴底；照片轮播只挂载当前与前后各一张，其余按需加载。

② 议程页 —— 默认选中 Day 1，日期标题为大号衬线数字 + 月份/星期 + DAY 序号 + 场次；筛选条在移动端压成「搜索 + 图标按钮 + 日期条」两行；按日期、主题、类型、场馆筛选与关键词搜索。

③ 分论坛列表页 —— 分论坛卡片按主题配色（低饱和前景/底色），悬浮时左侧抽出主题色细条、报名按钮联动；支持日期、主题、类型、场馆筛选与分页。

④ 分论坛详情页 —— 展示论坛信息、报告与讲者列表；报名入口依据登录身份展示（办会身份隐藏/禁用报名），时间冲突入口给出转场提示。

⑤ AI 推荐页 —— 对话式问答：欢迎语、用户气泡、助手回复、推荐卡、底部输入框；顶部模型选择器按供应商预设分组，未配置 Key 的预设置灰；推荐卡带推荐理由、查看详情与一键报名。

⑥ 我的参会页 —— 三段式统计面板 + 2×2 日卡；日卡用大号日期数字，冲突显示红条/呼吸红点、无冲突显示绿色状态行；内含取消报名二次确认，以及通知中心的未读计数、单条/全部已读、来源图标与红色未读点。

⑦ 管理台 —— 统计总览（参会人数/人次、趋势、论坛排行、通知）；参会者名单与 CSV 导出；「用户与权限」页签仅供管理员（授权/撤销 + 审计列表）；「发布通知」页签仅供办会角色，管理员不渲染。

⑧ 登录与注册页 —— 桌面双栏：左侧 46% 深色品牌区（旋转色光、网格、轨道环、主题走马灯与描边 26 水印），右侧表单；移动端改为品牌横幅 + 单列表单；认证路由下隐藏顶栏全局「登录 / 报名」按钮。

10.2 基础功能实现（20'）

以下按基础功能分点说明实现情况，各点后附对应截图。

① 会议议程和分论坛信息展示 —— 收录 170 场论坛、758 场报告，支持日期、主题、类型、场馆筛选与关键词搜索；分论坛列表页 /forums 单独提供筛选与分页；论坛详情页展示报告与讲者列表。

② 参会者注册并选择分论坛（可多选） —— 注册表单内嵌论坛多选，实时提示时间重叠；注册成功后立即生效，无需审核。

③ 查看 / 修改 / 取消报名 —— 「我的参会」页按日期分组展示已报名论坛，支持取消；冲突报名先二次确认，确认后带 force=true 强制提交。

④ 主席查看参会人数（分论坛 / 大会统计口径） —— 分论坛人数 = 该论坛报名数；大会人数 = 至少报名一个论坛的去重用户数；管理台实时显示趋势与排行。

⑤ 秘书获取全部参会者信息 —— 秘书可查看全部参会者及报名明细，支持按论坛筛选与 CSV 导出；分论坛主席仅能看本论坛，防止越权。

⑥ 分论坛主席 / 秘书发布通知 —— 分论坛主席发本论坛、秘书发任意论坛；通知写入后已报名用户可见，支持已读/未读与未读计数。

⑦ 注册后收到所选分论坛信息推送 —— 采用站内推送：登录后在通知中心展示所选论坛通知与未读计数，不做邮件/短信。

10.3 LLM 智能功能（8'）

总体流程。自然语言输入 → 本地语义召回候选 → LLM 精选并生成理由 → 推荐卡展示（含理由、查看详情、一键报名）。

以下按实现要点分点说明。

① 两级召回 —— 第一级在本地做语义召回：把用户描述切成中文 2–4 字 n-gram，剔除「论坛」「有关」「我想找」这类框架词，按「命中词是否出现在论坛名或主题」与查询覆盖率筛出候选论坛；第二级把候选清单（forum_id + 名称 + 主题 + 简介摘要）交给 LLM 精选并生成推荐理由，避免把 170 场论坛全量塞进上下文。

② Prompt 设计 —— 系统提示硬性约束「只能从给定候选清单中选择，不得编造 forum_id，理由不超过 40 字，没有合适项就返回空数组」；用户消息只放兴趣描述，不拼接无关上下文；要求模型输出 JSON，便于程序解析。

③ 降级与异常处理 —— 模型返回的 forum_id 逐一比对候选清单与数据库白名单，不在其中直接丢弃；重复结果去重、理由为空时补默认说明；未配置 Key、超时、401/429 或网络错误时自动降级为本地匹配并标记 source=local；与会议无关的输入由本地覆盖率门槛直接拒绝，返回 0 条而不是硬凑结果。LLM 走 OpenAI 兼容协议，内置默认预设为 DeepSeek（线上演示环境当前激活 MiniMax-M3.1-Flash），base_url、模型、超时均可在管理台配置（默认超时 15 秒），响应带 source 字段区分 llm / local / env。

10.4 AI Coding 过程（14'）

选取有代表性的开发任务，提供关键 Prompt、AI 输出摘要、迭代记录；并展示对 AI 代码的检查、测试与优化过程。

案例一：日程冲突判定与转场缓冲

任务背景：题目附加功能要求给出「一个论坛恰好在另一个论坛结束时开始」的判定口径，并在报名时提示转场时间不足。判定必须可解释、可测试，不能靠调参。

关键 Prompt：

我在做会议系统的个人日程。每个分论坛有 start_time / end_time（ISO 8601 带时区）。
请给出两个时段「冲突」的判定条件，并明确回答：A 的结束时刻正好等于 B 的开始时刻，算不算冲突？
要求判定必须是纯比较运算，且能用一句话向用户解释。

AI 输出摘要：AI 建议用左闭右开区间 [start, end) 建模，冲突条件为 A.start < B.end 且 B.start < A.end；「紧邻结束」不算冲突，单独归为「背靠背」。第二轮进一步把同会议室 0 分钟、同场馆不同房间 10 分钟、跨场馆 20 分钟的转场规则落到 transit_rules 表，由服务层读取，不在代码里写死。

迭代记录：

轮次	Prompt 调整	AI 输出变化	采纳/修改/拒绝及理由
1	要求给出区间口径与边界解释	给出 A.start < B.end 且 B.start < A.end 的半开区间判定	采纳：与「连续场次自然衔接」的预期一致
2	追问「时间不重叠但只隔几分钟」如何处理	给出同室/同馆/跨馆三档缓冲建议	采纳并改：缓冲值不硬编码，落 transit_rules 表
3	要求报名前预检	给出 409 + code=conflict + force=true 二次确认流程	采纳：首次返回硬冲突，确认后才写入

【图片占位】与 AI 的关键对话截图（含 Prompt 与生成代码）。

检查与验证：用冒烟测试覆盖边界：13:30–15:00 与 15:00–17:00 判为不冲突并计入「紧凑」；13:30–15:00 与 14:00–16:00 判为重叠 60 分钟；同馆间隔 6 分钟触发缓冲、10 分钟不触发；跨馆间隔 10 分钟触发。另用合成事件覆盖三档规则与背靠背，避免真实数据里找不到 1–9 分钟间隔的样本。

【图片占位】测试通过/错误排查的截图。

案例二：注册角色权限判定与五语言文案一致性

任务背景： 题目附加功能要求明确「注册页不提供角色自选，新账号默认参会者；分论坛主席、秘书、大会主席等管理身份由会务组在后台统一绑定」，并要求给出「办会身份能否报名分论坛」的判定口径。判定必须可解释、可测试，前端展示必须与后端 @attendee_only 的 403 结果一致；所有界面文案必须走语言包，五种语言都不能靠硬编码中文兜底。

关键 Prompt:

我在做 CNCC 2026 会议系统的注册页与分论坛报名。账号有 attendee / chair / secretary / conference_chair / admin 等角色，后端报名接口加了 @attendee_only。
请给出「是否显示报名按钮」的判定条件，并明确回答：办会身份调用报名接口返回 403 staff_cannot_register 时，前端应该怎么处理，能不能只靠隐藏按钮？
要求判定只依赖会话里 user.can_register 这一个可信来源；全部提示文案走 t(key) 且五个语言包都补齐，{name} 这类占位符必须传参，不能用改中文字符串的方式兜底。

AI 输出摘要：
AI 建议在 store.js 用 computed 从 state.user.can_register 派生 canRegister，模板用 v-if="canRegister" 控制报名按钮，办会身份改显示 staff.badge / staff.no_register 徽章；enroll() 内再加二次防御，捕获 403 staff_cannot_register 并给出 i18n toast。第二轮把新页面 16 处硬编码中文换成 forums.*，五个语言包各补 56 个 key；发现 me.cancelled 的值是 Removed "{name}"，改用 t('me.cancelled', null, { name: f.name }) 传参。评审追加后，再把注册页角色说明与详情页「官方中文原文」标签抽成 auth.role_note / forum.official_cn，五语言由 414 增至 416 个 key。

迭代记录:

添加到对话轮次	Prompt 调整	AI 输出变化	采纳/修改/拒绝及理由
1	要求给出权限判定口径与边界解释	给出 canRegister computed + v-if 隐藏报名按钮	采纳：与后端「办会身份不进入参会者名册」的预期一致
2	追问 403 staff_cannot_register 时前端如何兜底	给出 enroll() 二次判断 + 403 toast	采纳并改：不能只靠隐藏按钮，接口层也要拦，避免绕过 UI 直接调 API
3	要求新页面全量多语言、禁用中文兜底	16 处硬编码换成 forums.*，5 语言各补 56 key	采纳并改：发现 me.cancelled 带 {name}，补传参，避免界面显示字面量
4	评审追加：角色说明与「官方中文原文」标签也要进语言包	新增 auth.role_note、forum.official_cn，5 语言 → 416 key	采纳：两者都是界面可见文案；重启 Flask（@lru_cache）后实测 5 语言均返回新值

案例三：黏土设计系统移植与首页轮播性能、文案合规

任务背景： 题目附加功能要求把四页原型里的黏土拟态风格（彩色立体玻璃按钮、双行果冻蓝日期胶囊、照片轮播置顶首页）移植到仓库已有的 Vue 3 前端，并回答三个问题：按钮 hover 灵动但不能出现白边或「内部蓝色矩形」；轮播图片体积与加载策略如何控制；文案中「300+ 特邀讲者」这类未核实数据如何处理。效果必须可截图验证、可构建通过，且不能靠写死高度掩盖卡片文字溢出。

关键 Prompt:

仓库前端是 Vue 3 + Vite + Tailwind 4，我有一份 P1–P4 的 HTML 原型（会议议程 / 分论坛列表 / 分论坛详情 / 登录注册）。请给出把原型风格移植到现有组件的落地方案，必须保留仓库原有的 vue-router 与 t(key) 多语言机制。
首页轮播有 10 张图，请给出压缩与按需加载方案，并明确回答：只挂载当前与前后各一张时，DOM 里应该有几张 <img>？如何验证它们都真的加载完成？
按钮要有磁吸效果但不能出现白色描边或内部矩形；卡片要等高但不能裁切长标题；「300+ 特邀讲者」「万名计算人齐聚成都」这类文案怎么处理？要求给出可测试的验收口径，不要凭感觉调样式。

AI 输出摘要：
AI 建议新增 clay.css 设计系统（.btn-pill 纯色填充、.day-tabs 双行日期胶囊、.glass-panel），ClayHero.vue 用 isNear(i) 只挂载当前及前后各一张，DOM 实测 3 张 <img>；10 张 jpg/png 用 Pillow 转 WebP，8.49MB → 1.65MB（−81%）。交互上定位到「内部蓝色矩形」来自 StarBorder 特效层，移除后改纯色填充并保留 Magnet（padding=110 / strength=0.24 / max=12，实测主按钮位移 12px、次按钮 5px）。ForumCard 由 h-[140px] 改为 min-h-[140px]；删除不实文案，轮播文案全部接 home.hero.0~9.*，五个语言包同步补齐。

迭代记录:

添加到对话轮次	Prompt 调整	AI 输出变化	采纳/修改/拒绝及理由
1	要求按钮整齐、日期胶囊按原型还原	给出统一按钮样式与双行果冻蓝日期胶囊	采纳：与原型一致；后续删除与全局样式冲突的 scoped 竖线规则
2	追问 hover 时的白边	建议把边框改成透明	拒绝：用户明确指出「不是描边，是按钮里面有蓝色矩形」，改边框无效
3	要求定位内部矩形的真实来源	发现是 StarBorder 特效层，移除后改纯色填充	采纳：白边与内部形状同时消失，按钮视觉填满
4	主按钮没有次按钮灵动	恢复 Magnet 并调参	采纳：浏览器实测磁吸位移 12px，明显大于次按钮 5px
5	轮播移到首页 + 评审要求性能与文案合规	WebP 压缩、按需加载、删不实文案、卡片改 min-h	采纳并改：图片

案例四：管理端参会者CSV导出与多语言（lang）接入

任务背景： 后端C负责管理端功能。题目附加功能要求「管理端一键导出报名参会者名单」，以及「接口按语言返回翻译」。导出要求必须是标准CSV（UTF-8带BOM、表头完整、中文正确、指定文件名），且仅秘书/管理员可导出；语言接入要求命中返回翻译、未命中降级中文原文。判定必须可解释、可测试，不能靠调参。

关键 Prompt:

我在做会议系统的管理端后端，需要实现：
1. CSV 导出报名名单接口：导出全部或指定论坛的参会者，
要求 UTF-8 带 BOM、表头完整、一行一名参会者、文件名 cncc2026-attendees.csv；
仅秘书/管理员可导出（普通参会者返回 403、未登录返回 401、无效论坛返回 404）。
2. lang 多语言接入：GET /api/forums/{id}?lang=en 命中返回英文翻译，
未命中降级中文原文，zh-CN 返回默认原文。
3. 通知发布请求模型 NotificationCreateRequest：标题非空、长度≤200、forum_id 非空。
请给出接口路径、权限口径、响应字段与错误码，并保证判定可测试。

AI 输出摘要：
AI 给出 /api/attendees/export 接口：秘书 / 管理员可导出，响应 Content-Type: text/csv，body 以 \ufeff（UTF-8 BOM）开头，表头 user_id,username,nickname,real_name,forum_id,forum_name,enrolled_at，每行一名参会者；权限通过 require_roles 依赖强制（参会者→403、未登录→401、无效 forum_id→404）。lang 接入按 (entity_type, entity_id, field, lang) 查 Translation 表，命中返回翻译，未命中降级中文原文，zh-CN 用默认原文；通知模型用 pydantic 约束标题非空且≤200、forum_id 非空。

迭代记录:
| 添加到对话轮次 | Prompt 调整 | AI 输出变化 | 采纳/修改/拒绝及理由 |
| ---- | ---- | ---- | ---- |
| 1 | 要求给出 CSV 导出接口与权限口径 | 给出 /api/attendees/export，UTF-8 BOM + 完整表头 + 每行一条参会记录，参会者403 / 未登录401 / 无效论坛404 | 采纳：与团队分工「管理端CSV导出」一致，权限用 require_roles 强制 |
| 2 | 追问「lang 未命中与默认语言如何处理」 | 命中返回 Translation 表翻译，未命中降级中文原文，zh-CN 返回默认原文 | 采纳并改：翻译不硬编码，按字段查 Translation 表 |
| 3 | 要求通知请求模型加字段校验 | 给出 NotificationCreateRequest：标题非空、≤200、forum_id 非空 | 采纳：用 pydantic 约束，17 项 TestClient 断言全 PASS |

案例五：报名前的时间冲突判定与转场缓冲

任务背景：报名接口要在写入数据库之前，判断新报名的论坛和该用户已报名的论坛是否冲突，并给出用户看得懂的提示。题目专门追问「一个论坛恰好在另一个论坛结束时开始算不算冲突」，还要求不重叠但转场时间不足也要提示。判定必须可解释、可测试，档位规则以后能改，不能写死在代码里。

关键 Prompt：

我在做会议系统的报名接口。每个论坛有 start_time / end_time（ISO 8601 带时区）。
报名前要判断新论坛和该用户已报名的论坛是否冲突，冲突时返回可解释的详情。

请回答三个问题：
1) 冲突判定条件怎么写？A 的结束时刻正好等于 B 的开始时刻，算不算冲突？
2) 时间不重叠、但中间只隔 5 分钟，要不要提示？档位怎么定？
3) 冲突时应该直接拒绝，还是先提示再让用户确认？两种情况响应体分别是什么。

要求：判定是纯比较运算；提示里要能告诉用户重叠了多少分钟 / 隔了多少分钟；
档位不能硬编码，以后改规则只改配置。

AI 输出摘要：用左闭右开区间 [start, end) 建模，冲突条件为 A.start < B.end 且 B.start < A.end，因此「紧邻结束」不算冲突，单独归为背靠背衔接。不重叠时计算 gap，按同会议室 0 / 同馆不同室 10 / 跨馆 20 三档判断缓冲是否足够。接口采用「强提示不拦截」：首次返回 HTTP 409 + code=40902 + 冲突明细（含 overlap_minutes 或 gap_minutes/required_buffer），前端弹确认框，用户确认后带 force=true 重发，写入成功并把冲突放进 warnings 一起返回。

迭代记录：

轮次	Prompt 调整	AI 输出变化	采纳/修改/拒绝及理由
1	要求给出区间口径，并回答「结束即开始」算不算冲突	给出半开区间判定 A.start < B.end 且 B.start < A.end，边界取等不算冲突	采纳：与「连续场次自然衔接」的业务直觉一致，且能用一句话向用户解释
2	追问「不重叠但只隔几分钟」如何处理	给出同室 0 / 同馆 10 / 跨馆 20 三档缓冲	采纳并改：数值不写进代码，落成 transit_rule 表，服务层启动时读取，改规则只改数据
3	要求区分「硬冲突」和「软提示」在响应里的表现	建议同一接口返回两种 type：overlap 与 buffer，字段各自带量化信息	采纳：前端可以按 type 分别渲染，红的报重叠、黄的报转场紧张
4	要求冲突时不能直接拒绝，需要用户能坚持	给出 409 + force=true 二次确认流程	采纳：首次只返回冲突明细不写库，确认后才写入，避免误报把用户挡在门外
5	追问「强制报名成功后，之前提示的冲突要不要保留」	建议放进响应的 warnings 字段随成功结果一起返回	采纳：用户能看到「已报名，但与 A 重叠 90 分钟」，前端可做持久提示

验证：用 4 场构造数据覆盖三种时间关系——14:00–17:30、15:30–17:00（重叠 90 分钟）、17:35–19:00（同馆不同室，间隔 5 分钟 < 10）。实测报名 14:00 那场时，接口同时返回 overlap 90 分钟和 buffer gap=5、required=10 两条；带 force=true 重发后写入成功且 warnings 为 2 条；重复报名返回 40901；未登录返回 40101。另外单独验证首尾相接（15:30 结束、15:30 开始）不产生任何冲突记录。

---

案例六：论坛列表的筛选、分页与实时报名人数

任务背景：170 场论坛要给前端一套查询接口：列表支持关键词、主题、类型、日期任意组合筛选并分页，每条带报名人数；详情要把主席、主持、嘉宾按角色分组；议程按天分组排序。难点不在写 SQL，而在人数口径（报名或取消后必须立刻准确）、列表性能（不能每行单独查一次）以及多条件叠加时还能维护。

关键 Prompt：

我在做会议系统的论坛查询接口（SQLite + SQLAlchemy，约 170 场论坛）。
GET /api/forums 需要支持 keyword / theme / forum_type / date 四个条件任意组合 + 分页，
每条结果带 enroll_count（人数来自 enrollment 表）。

请给出实现方案，并说明：
1) 报名人数怎么算才不会出现「取消报名后人数不变」的问题？
2) 列表每行都有一个人数，怎么避免 N+1 查询？
3) 详情接口怎么把 forum_person 的人员按角色分组返回？
4) 分页参数被传成 0 或 1000 时怎么处理？
5) 主题下拉选项和「按 forum_id 查详情」两个路由放在一起会不会互相干扰？

AI 输出摘要：人数不落字段，全部用 enrollment 实时聚合：列表先一次性 GROUP BY forum_id 拿到全量映射，再回填到每条记录，行数与查询次数解耦。筛选条件用 SQLAlchemy 链式 filter 逐项叠加，没传的参数自动跳过。人员一条查询取回后按 role 分组，输出 { "主席": [...], "嘉宾": [...] }。分页用 Query(ge=1) / Query(le=100) 卡边界，越界交给统一的参数校验错误（40001）。AI 还主动提示了路由注册顺序问题：/api/forums/themes 必须写在 /api/forums/{forum_id} 前面，否则 themes 会被当成论坛 ID。

迭代记录：

轮次	Prompt 调整	AI 输出变化	采纳/修改/拒绝及理由
1	只描述需求，未提人数口径	建议在 forum 表加 enroll_count 字段，报名时自增	拒绝：取消报名、并发提交、事务回滚都会让字段与实际不一致；改为实时聚合，与数据库设计「统计用 SQL 直接算」一致
2	追问列表每行都要人数怎么实现	初版在序列化时逐条 count()	修改：一次 GROUP BY 预聚合成字典再回填，列表 20 条从 21 次查询降到 2 次
3	追问主题选项与详情路由冲突	指出 /themes 会被 /{forum_id} 捕获，返回 40401	采纳：调整注册顺序，并在代码里加注释固定这个约束，避免后人重排
4	追问详情页未登录时 enrolled 怎么给	初版要求登录才能看详情	拒绝：详情是公开页，改为可选鉴权——带合法 token 才返回真实 enrolled，否则 false
5	追问人员怎么给前端	初版返回平铺的人员列表	修改：按 role 分组，前端直接渲染「主席」「嘉宾」区块，不用自己做分组
6	要求人数在取消后必须正确	确认走实时聚合即天然同步，无需触发器	采纳：取消报名物理删除行，下一次查询自然少一人

验证：4 场构造数据实测：列表总数 4、按主题「软件工程」筛出 2 条、主题选项去重 3 个且不含 NULL、议程按天分成 2 组（3+1）、详情 persons 分出 2 个角色、查询不存在的论坛返回 40401、取消报名后对应论坛 enroll_count 从 1 变 0。

写测试数据时还踩到一个坑：forum 和 enrollment 之间没有建 ORM 关系，SQLAlchemy 排不出插入顺序，先插报名就报 FOREIGN KEY constraint failed；在论坛批量插入后补一句 db.flush() 显式落库才解决。这类问题只有真跑一次才会暴露。

案例七：参会统计去重与通知权限隔离

任务背景：本人负责会议系统后端 B 的统计与通知模块。一个用户可以报名多个论坛，需要区分“参会人数”和“报名人次”；分论坛主席只能管理本人绑定的论坛，个人通知也必须限制在可见范围内。本案例通过两轮对话复盘已提交的 Flask/SQLite 实现 b5f69ef，核对统计口径、权限边界和测试结果。

关键 Prompt:
第一轮：
我负责 CNCC 2026 会议系统后端 B 的统计与通知。请复盘我已提交的 Flask/SQLite 实现 b5f69ef：同一个人报名多个论坛，“参会人数”和“报名人次”怎么区分？分论坛主席绑定 F1，却在请求中传 forum_id=F2，应如何处理？没有有效论坛绑定时呢？请结合现有函数说明，并保留前端已有响应字段。

第二轮：
沿用上轮方案，再复盘 b5f69ef 的通知实现：列表、未读数和标记已读是否使用相同的可见范围？请检查不可见通知、重复标记已读、取消报名和通知分页这几个边界，并给出你核验过的测试结果。

AI 输出摘要：AI 将统计口径明确为：参会人数使用 COUNT(DISTINCT r.user_id)，报名人次使用 COUNT(*)。管理接口通过 management.scope_for() 在服务端确定数据范围，分论坛主席传入其他 forum_id 时仍限定为本人绑定的论坛，绑定缺失或失效则返回 403，同时保留前端已有响应字段。第二轮进一步核对 visible_notice_where()：通知列表、未读数和已读操作共用“全站公告 + 当前报名论坛”的可见范围；不可见通知返回 404，重复标记已读通过 INSERT OR IGNORE 保持幂等，未读数不受分页条数影响。对该提交的独立源码快照复跑统计与通知测试，结果为 106 passed。

迭代记录:
| 添加到对话轮次 | Prompt 调整 | AI 输出变化 | 采纳/修改/拒绝及理由 |
| ---- | ---- | ---- | ---- |
| 1 | 要求区分人数与人次，并补充分论坛主席篡改参数、绑定失效的场景 | 给出去重统计与服务端范围校验，明确绑定异常返回 403，保留现有响应字段 | 采纳并确认：避免重复计人数；权限由服务端绑定决定，不能依赖前端隐藏入口 |
| 2 | 进一步追问通知列表、未读数、已读操作及分页边界 | 复核统一可见性条件、已读幂等、取消报名联动和全量未读计数，并给出测试结果 | 采纳并验证：不可见通知不能写入已读状态，未读数不能只统计当前页；106 项测试通过 |

案例八：管理员通知「疑似 bug」的排查——先验证、再归因、不误改

任务背景：用户反馈「管理员的通知功能有问题」，并明确要求先回答、别动手。此时不能直接假设「通知代码有 bug」就改，而要判断功能到底坏没坏、问题落在哪一层。

关键 Prompt：

管理员现在的通知功能有问题，是不是需要修改。先回答别动手

AI 输出摘要：AI 没有改任何代码，而是按「验证 → 归因 → 反问」三步处理——

1. 先用临时数据库把通知主链路完整跑通（不动线上）：admin@cncc.local 发布全站公告 → 200；attendee@cncc.local 的 /api/me/notifications 立即可见、unread=4 正确；标记已读 → 200、unread 从 4 降到 3。结论：管理员发通知这个功能本身没坏。
2. 把「有问题」拆成三个更可能是口径 / 设计的原因，而不是代码 bug：
   • 管理员自己看不到论坛级通知：/me/notifications 只返回「全站公告 + 我已报名的论坛通知」，而管理员/主席/秘书是办会身份、不在报名名单里，所以发到某论坛的通知管理员在「我的参会」里看不到，容易被误判成「没发出去」——实际参会者已经收到。
   • 主席候选账号发不了通知：种子里的 chair@cncc.local、forumchair@cncc.local 初始都是 attendee，需先到「用户与权限」授予角色，否则发布直接 403。
   • 后台「已发布」列表只显示最近 6 条（LIMIT 6，无分页、无删除、无送达统计），发多了列表显得「短」。
3. 额外指出一个当前未触发的并发隐患：发布后后台线程把通知翻译写回 content/*.json，多 worker 同时写同一文件可能互相覆盖，演示频率下影响小，但属于真实的生产级竞态。

最后 AI 反问用户具体症状（发布报错 / 参会者收不到 / 列表不显示或计数错），再据此决定改哪里。

检查与验证 / 判断依据：

• 关键判断是「先分清 bug 还是口径」：AI 用可复现的端到端验证把「功能坏了」这个前提证伪，然后才给出方向性假设，避免一上来就改通知逻辑、把原本正常的语义改坏。
• 三处结论各有证据：①scope 过滤差异来自「办会身份 vs 报名者」的可见范围；②种子角色初始值可查；③LIMIT 6 是硬编码常量。定位都靠证据，不靠猜。
• 隐患（多 worker 写同一 JSON）虽当前未触发，但属于真实的竞态，保留待处理，而不是「演示能过就忽略」。

结论：本轮未改任何代码；待用户确认具体症状后再定向修复，避免了对正常功能的误改。

---

10.5 数据库设计（10'）

数据规模。共 10 张表。主数据来自数据包：170 场论坛、758 场报告、1196 位讲者/嘉宾；账号与业务数据由应用运行产生（全新演示初始化 61 个账号、150 条报名、6 条演示通知、3 条转场规则），角色审计与通知已读随操作增长。

表间关系。 全库以 forums 为中心组织成一颗主数据树，其余表分别挂在主数据、账号、业务关系三类之上：

• forums 是主数据根节点：一场论坛通过 forum_id 外键下挂多个 sessions（报告场次）与多条 people（主席/主持/嘉宾），因此 forums : sessions 与 forums : people 都是 1:N。
• users 是账号与权限的源头：一个账号可有多条 role_audit（每次授权/撤销各留一条）、多条 registrations（一个账号可报名多个论坛）、多条 notification_reads。
• registrations 是 users 与 forums 的多对多报名关系落地成的中间表，用复合唯一键 (user_id, forum_id) 保证同一人不会重复报名同一论坛。
• notifications 记录通知正文，author_id 指向发布者；notification_reads 以 (user_id, notification_id) 联合主键记录「谁读过了哪条通知」，两者构成 1:N。
• transit_rules 与 llm_profiles 是两张配置表，前者存转场缓冲分钟数、后者存可切换的 LLM 供应商配置，均不与业务主数据直接外键耦合，删除/切换配置不影响论坛与报名数据。

设计原则。

1. 论坛主数据按数据包入库：forums.json 的 170 场论坛写入 forums，forum_id 连接人物、报告、报名与通知；day 由开始时间派生，不单独冗余实体。
2. 单角色同库：当前角色在 users.role，主席绑定在 users.forum_id，角色变更记入 role_audit；每个账号同时只有一个角色。
3. 统计用 SQL 现算：参会人数按报名去重、报名人次按行数，不在表里冗余计数字段。
4. 翻译与业务数据分离：UI 文案在 app/locales、内容译文在 app/content，数据库不存翻译表。
5. 冲突实时计算、不落库：应用层解析带时区 ISO 时间、按半开区间算重叠；转场分钟读 transit_rules，不在代码里写死。

表结构清单。

关键设计决策。

1. 选用 SQLite 单文件：在全量数据不过千级、写入以报名/通知为主的场景下，SQLite 足够且零运维；单文件极适合 Docker 挂卷持久化（./data/cncc.db）与离线迁移，不必为一条数据库单独起一个容器。
2. 单角色模型：每个账号在 users.role 里只存一个角色，分论坛主席通过 users.forum_id 绑定其管辖论坛，而不是做一张用户—角色多对多表。这样「办会身份不可报名」「主席只能看自己论坛」等口径能在一个字段上单点收敛，避免多角色叠加带来的判定漂移。
3. 时间统一带时区存储：起止时间均以 ISO 8601 带 +08:00 落库，应用层统一解析后再比较；冲突用半开区间 [start, end) 判定，转场缓冲（同室 0 / 同馆 10 / 跨馆 20 分钟）由 transit_rules 驱动，规则值与判断逻辑分离。
4. 统计不冗余、实时现算：人数类指标一律用 SQL 在查询时现算——去重计数得到「人数」、行数得到「人次」，表中不维护任何计数字段，从根本上避免报名增删后计数器失真的老问题。

表名	作用	记录量级	关键字段 / 约束
forums	论坛主数据	170	forum_id（PK）、name、theme、forum_type、start_time/end_time、day、venue、room、description
sessions	报告场次	758	forum_id→forums、speaker_name、title、start_time/end_time、abstract
people	主席/主持/嘉宾	1196	forum_id→forums、name、affiliation、role
users	账号与角色	61	email（UNIQUE）、password_hash、role、forum_id、title、created_at
role_audit	角色授予/撤销审计	随操作增长	user_id→users、from_role、to_role、forum_id、operator_id、created_at
registrations	报名关系	150+	UNIQUE(user_id, forum_id)、created_at
notifications	通知	6+	forum_id、title、body、urgent、author_id、created_at
notification_reads	通知已读	随操作增长	user_id、notification_id、read_at（联合主键）
transit_rules	转场缓冲配置	3	scope、minutes（0/10/20）
llm_profiles	LLM 模型配置	0+	name、provider、protocol、base_url、api_key、model、timeout、is_active

索引与约束。

表	索引 / 约束	目的
users	idx_users_role(role)	按角色过滤
role_audit	idx_role_audit_user(user_id)	按用户查审计记录
sessions	idx_sessions_forum(forum_id, start_time)	按论坛 + 时间取报告
forums	idx_forums_day(day)、idx_forums_theme(theme)	日报 / 主题筛选
people	idx_people_forum(forum_id, role)	按论坛取人员
registrations	UNIQUE(user_id, forum_id)、idx_reg_forum(forum_id)	防重复报名 + 按论坛统计
notifications	idx_notif_forum(forum_id, created_at)	按论坛取通知

数据一致性与统计口径。

• 分论坛人数 = COUNT(registrations WHERE forum_id = X)；大会人数 = COUNT(DISTINCT user_id FROM registrations)——用户 A 报 2 个论坛、B 报 1 个时，大会人数为 2 而非 3。
• 重复报名由 UNIQUE(user_id, forum_id) 与 INSERT OR IGNORE 兜底。
• 角色即时生效：每请求从 users 读角色；授予办会身份时清空其历史报名，避免办会角色同时挂在参会者名册。
• 通知可见性按身份过滤：全站公告人人可见、论坛通知仅已报名该论坛者可见，已读状态独立存表。
• 冲突与转场不在数据库冗余：冲突实时算，转场分钟读 transit_rules。

数据安全与隐私。

• 口令绝不落明文：密码一律经 werkzeug 哈希后写入 users.password_hash，登录仅做哈希比对。
• LLM 密钥全程掩码：api_key 虽写入 llm_profiles，但列表与详情接口只回传掩码（如 sk-••••••••••••ab12），不暴露明文；数据库里某条配置 Key 为空时，运行时回落到容器环境变量，避免「空 Key 覆盖好 Key」。
• 授权审计可追溯：role_audit 记录操作人（operator_id）、被操作人（user_id）、从什么角色改到什么角色、以及操作时间，管理端的每一次授权/撤销都有据可查。
• 越权在数据层收紧：名单、统计、通知发布等管理接口按角色作用域过滤——大会主席看全局、分论坛主席只看自己绑定的论坛、秘书只维护本论坛名单，越界请求直接 403，而不是前端藏一下按钮了事。

10.6 用户体验（4'）

操作便捷性。

• 注册即完成报名：注册表单内嵌分论坛多选与关键词搜索，勾选时实时提示所选场次之间的时间重叠，一次流程同时完成「创建账号 + 报名」，无需注册后再跳去报名页二次操作。

• 信息直达：首页顶部全局搜索回车直达结果；AI 推荐页输入自然语言后回车即发送，推荐卡片可一键跳转论坛详情或直接报名，减少中间点击。

• 一目了然的「我的参会」：已报名论坛按日期分组展示，配合日程与时间冲突一览，当天要听哪几场、有没有撞场一眼看清；取消报名带二次确认，避免误触拆票。

• 通知上手即用：通知中心提供未读计数、单条已读与全部已读，收到的分论坛推送与站内信同源展示，用户不用切换多个入口。
  防错与反馈。

• 半开区间冲突判定[start, end) ：一场刚好在另一场结束时开始不判为冲突，减少误报。

• 转场软提示：不冲突但间隔过短时，按同会议室 0 分钟、同场馆 10 分钟、跨场馆 20 分钟给出转场缓冲提示，只提醒不阻断操作。

• 状态即时回滚：报名、取消、切换语言等操作失败时提示错误并回滚本地状态，避免界面与后端漂移。
  个性化与智能。

• AI 分论坛推荐：按自然语言兴趣返回带理由的推荐与可直接跳转的场次，结果区显式标注来源与耗时，用户知道是 AI 生成还是本地匹配。

• 6 种语言即时切换，切换后记住选择、刷新不丢，海外参会者无阅读障碍。
  性能体验。

• 首屏立体化提速：首页图片统一转 WebP，轮播只挂载当前与前后各一张、其余按需加载，首屏不再并发拉取 10 张大图。

• 柔滑的黏土玻璃视觉：统一设计令牌 + 微动效（磁吸按钮、卡牌高光、入场动画），操作反馈细腻，不只是「能用」，还有「好用」的质感。
  无障碍与跨端。

• 移动端分档布局：窄屏侧栏收起为抽屉、表单加min-w-0 防横向溢出，手机上不跑版。

• 图标按钮补aria-label 与title 、交互元素键盘可聚焦，兼顾屏幕阅读与键盘操作。

  10.7 服务器部署（6'）

• 部署环境：Linux 云服务器 + Docker；容器内 Python 3.12 + Flask 3.1 + gunicorn；SQLite 单文件数据库挂卷持久化（./data/cncc.db）

• 部署方式：容器化离线部署——Windows 侧 docker compose build 构建镜像并 docker save 导出 tar，服务器侧 docker load + docker compose up -d --no-build，不依赖 Docker Hub；deploy/load-and-up.sh 自动校验 SHA256、启动并轮询健康检查

• 在线地址：https://cncc-system.zviolin.online/

---

十一、附加功能

11.1 多语言支持（上限 10'）

• 支持语言：中文简体（zh-CN）、中文繁体（zh-TW）、英语（en）、日语（ja）、德语（de）、法语（fr），共 6 种；界面文案 6 种全量，会议内容包覆盖繁/英/日/德四种，法语会议正文保留官方中文原文
• 实现方式：资源包 + 统一接口——UI 文案按 key 组织在 backend/app/locales/{lang}.json（共 416 key），前端只调用 t(key)，语言包由 /api/i18n 与 /api/i18n/<lang> 下发，切换到哪种语言就加载哪份 JSON；业务代码中不出现 if (lang === 'zh') ... 这类硬编码，新增语言只需新增一份资源包并在语言列表注册

11.2 个人参会日程与冲突检测（上限 10'）

• 日程生成：根据已报名分论坛自动生成个人日程，按日期分组展示
• 冲突判定：采用半开区间 [start, end)，A.start < B.end 且 B.start < A.end 才算重叠；首尾相接不算冲突（同会议室 0 分钟背靠背）。不重叠时按地点计算转场缓冲：同会议室 0 分钟、同场馆不同房间 10 分钟、跨场馆 20 分钟，间隔不足只做黄色软提示、不阻断报名
• 动态更新：报名/取消报名后即时重算；论坛时间变更时只对已报名该论坛的用户重检，并只通知新增冲突，避免重复提醒；硬冲突报名需二次确认，确认后带 force=true 提交

---

十二、总结与反思

整体回顾。项目从需求拆解走到可部署系统，最终落地 10 张表、170 场论坛、758 场报告、1196 位讲者的数据模型，基础功能（浏览、注册报名、报名管理、人数统计、名单获取、通知发布与推送）全部可用，附加功能覆盖六语言切换、个人日程冲突检测与转场提示、LLM 智能推荐。前后端同源打包进 Docker，容器内 gunicorn 3 worker 监听 4995，对外经 HTTPS 反向代理访问。

协作收获。一是把「评审 + 合并」当作固定环节而不是形式：分支提交先走 MR，由组长统一评审后再合入 master，核心模块的改动都留下了可追溯的提交记录。二是坚持文档与代码同口径：文案里的统计数字、语言数量、接口路径全部回库或回代码核对，发现并修正了多处以讹传讹的旧口径。三是把 AI 的输出当作待验证的草案：AI 给的区间判定、召回策略、启动命令都经过测试与人工修正才采纳，拒绝了两项收益为零的「优化建议」（Redis 缓存、ECharts）。

不足与改进。其一，合并与验收窗口预留不足，收尾阶段仍在处理集成，说明应在功能完成后提前冻结代码、留出至少半天的合并与回归时间，而不是把所有分支压到最后统一处理。其二，部分成员的功能分支与 master 上的等价实现并行存在，最终靠人工比对统一，反映出分支拆分时应先对齐接口与负责人，避免重复开发。其三，自动化检查仍以本地脚本为主，下一步应把冒烟测试与多语言自检接入 MR 流水线，让问题在合并前暴露，而不是在验收时才发现。

如果再有一次。我们会先冻结接口清单与数据口径，再并行开发；每位成员的功能分支必须绑定一个明确的 MR 和验收人；截止前预留完整的回归窗口，把「能不能合」提前变成「什么时候合」。

---