从论坛报名到智能推荐：CNCC-SmartHub 的 LLM × CodeArts 团队实战

目录

第一部分：项目实现与团队协作

1. 项目入口与目标

• 项目仓库：404NOTFOUNND · CodeArts。
• 运行入口：CNCC SmartHub

CNCC-SmartHub 面向参会者、会议主席、分论坛主席和秘书，提供论坛查询、报名管理、参会统计、通知接收和智能推荐。系统围绕一条连续的参会路径组织功能：浏览论坛或描述兴趣，查看推荐与详情，选择报名，再通过消息中心和个人日程持续了解已报名论坛。

项目使用用户提供的 CNCC 2026 数据包。数据核对记录显示，导入资料包含 170 场论坛，其中大会论坛 3 场、专题论坛 167 场。大会论坛与专题论坛共用论坛模型，避免为相似业务维护两套接口。

注册与管理角色登录

注册入口只能注册普通用户（参会者）。管理角色使用以下账号登录：

2. 模块分工

每位成员负责对应模块的页面、接口、验证和交接材料。公共组件和接口由负责人提供，各业务模块完成接入。

3. 技术架构与数据库设计

前端采用 Vue 3、TypeScript、Vite、Element Plus、Pinia 和 Vue I18n；后端采用 Python、FastAPI、Pydantic 和 SQLAlchemy；数据库为 PostgreSQL 17，通过 Alembic 管理迁移。系统围绕统一的 /api/v1 接口组织业务，响应使用 {code, message, data, requestId}，前端通过统一请求客户端处理鉴权和错误。

3.1 设计目标与数据组织

数据库以“用户—论坛—报名”为业务主线：用户选择论坛形成报名，统计、通知和日程读取同一份有效报名。认证数据管理身份和会话，论坛数据承载会议事实，推荐模块读取真实论坛并记录调用配额。各模块围绕明确的数据归属协作，报名状态与论坛资料的变化能够传递到相关页面。

数据库围绕以下关系组织：

注册与首次报名在同一事务中完成。论坛无效、报名写入失败或事件写入失败时，账号、用户角色关联、报名和事件一起回滚，避免出现“账号创建成功但首次报名失败”的半完成状态。

统计直接读取有效报名：一名用户报名多个论坛，在大会人数中只计一次，在对应论坛中分别计数。个人日程也从有效报名与论坛时间生成，减少不同页面各自维护数据后产生的不一致。

数据库迁移按统一前驱关系串联，推荐模块接入后的 head 为 20261104_0004。各模块在同一迁移链上演进，集成环境通过 Alembic 升级数据库结构。

3.2 核心表与关键字段

业务实体主要使用 UUID 标识；用户与论坛、用户与通知等关联通过外键建立。时间字段采用带时区类型，接口统一输出 UTC，页面按大会时区展示。下表列出支撑主要流程的字段。

权限扩展结构还包含 permissions 和 role_permissions，分别保存权限标识及角色关联。当前业务授权结合服务端角色和论坛归属检查：论坛主席访问具体论坛时，需要同时具备角色与对应的 forum_chairs 绑定。

3.3 表关系如何支撑参会流程

例如，一名用户报名 A、B 两场论坛，数据库保存两条有效报名。大会统计对用户去重后为 1，两个论坛各计 1；消息中心查询 A、B 的通知；日程关联论坛表取得最新时间与地点。用户取消 B 后，报名记录的 is_active 变为 false，后续统计、通知和日程查询共同采用这一变化。

论坛信息保存在 forums，各模块通过关联查询取得标题、时间和地点。这样，主办方修改论坛资料后，详情、日程和推荐详情读取的都是同一条记录。五语言界面资源和论坛译文通过前端资源包维护，数据库继续保存论坛原始业务资料。

3.4 约束与索引：将业务规则落实到数据层

主键和唯一约束保证实体及关联的唯一性，外键保证引用对象存在，检查约束限制时间、类型和序号的有效范围。

• 账号唯一性：邮箱具有唯一约束，并建立 lower(btrim(email)) 的唯一索引，将去除首尾空白、忽略大小写后的邮箱作为一致的账号标识。
• 报名唯一性：(user_id, forum_id) 复合主键覆盖有效及已取消记录。恢复报名更新原记录，重复请求沿用同一关联。
• 角色与已读唯一性：(user_id, role) 唯一；notification_reads 使用用户和通知的复合主键，支持重复标记已读。
• 论坛资料有效性：大会与论坛均要求 start_at < end_at；论坛类型限制为 PLENARY、TOPICAL；version > 0；同一大会的 (title, start_at) 组合唯一。
• 通知序号有效性：sequence 唯一且大于 0，计数器值非负，计数器行固定为 id = 1。

索引围绕实际查询方向配置：

这些索引分别服务于本人查询、管理查询和增量读取，匹配模块已有的筛选与排序条件。

3.5 事务、并发与时间一致性

注册与首次报名原子提交。 用户、参会者角色关联、首次报名和报名事件共用事务。任何一步失败都回滚整组写入，成功响应对应一组完整的注册结果。可组合的报名服务接收调用者 Session，便于注册流程复用事务边界。

报名写入按用户加锁。 新增、取消和批量调整先锁定用户行，再执行报名操作。同一用户的写入按统一锁顺序处理，数据库复合主键保障关联唯一。批量替换先完成去重、论坛存在性、大会归属及时间校验，校验通过后整体提交。

论坛维护使用乐观锁。 维护请求携带 version。服务端检查当前版本后更新资料；过期请求返回版本冲突，避免旧页面覆盖新资料。简介发生变化时，论坛更新与通知发布在同一事务中完成。

通知发布维护提交顺序。 发布事务锁定 notification_counter，分配序号并写入通知，再统一提交。后续发布者等待该锁，使客户端可以按序号推进增量游标。BIGINT 序号通过十进制字符串传输，前端使用 BigInt 比较，保持整数精度。

模型调用采用短事务。 推荐服务在调用模型前完成配额记录事务，外部 HTTP 请求期间释放数据库连接。配额通过 PostgreSQL 中的用户关联记录协调，支持多个服务进程共享限流状态。

时间冲突统一使用半开区间 [start_at, end_at)，判断条件为：

A.start_at < B.end_at AND B.start_at < A.end_at

9:00—10:00 与 10:00—11:00 首尾相接，可以连续参加；9:00—10:30 与 10:00—11:00 存在重叠。报名服务检查新选择，日程查询基于有效报名和论坛最新时间重新计算冲突，覆盖主办方改时后的情况。

3.6 统计查询、迁移与验证

大会人数统计按有效报名用户去重。下面的查询表达了实际统计口径：

SELECT COUNT(DISTINCT r.user_id)
FROM registrations AS r
JOIN forums AS f ON f.id = r.forum_id
WHERE f.conference_id = :conference_id
  AND r.is_active = TRUE;

论坛统计从论坛表出发左连接有效报名，将有效状态条件放在连接条件中，使零报名论坛也能出现在结果里。秘书名单先取得符合大会和论坛条件的去重用户集合，再分页读取用户业务资料；返回字段限定为用户标识、显示名、邮箱和报名论坛，密码散列与会话数据留在认证模块。

数据库通过 Alembic 统一迁移，模型共用 SQLAlchemy metadata。已有迁移保留为版本快照，结构变化通过后续 revision 演进；各成员的迁移整合到单一前驱链，便于新环境按顺序建立相同结构。

这一设计让报名成为统计、通知和日程共同依赖的业务事实，论坛成为各页面共享的信息来源。约束保证数据关系，事务保证写入完整，索引支持查询路径，迁移与测试则让八个模块围绕同一套数据库持续协作。

4. 功能实现

4.1 论坛展示与报名

会议与论坛页面展示议题、主席、开始和结束时间、地点及简介。参会者注册时选择论坛，登录后在个人报名页查看和调整报名；列表、详情与推荐入口复用报名接口。

当前主线已加入重叠报名校验：前端提示冲突并禁用相应选项，后端在统一报名服务再次验证，防止绕过页面提交。时间区间采用 [开始, 结束)，一个论坛结束时另一个恰好开始，不算冲突。

报名入口负责拦截重叠选择，日程页面负责呈现已有报名的时间关系。主办方修改论坛时间后，日程重新计算冲突，参会者据此取消或调整报名。

4.2 管理统计与秘书查询

会议主席查看大会及论坛人数，分论坛主席仅查看负责论坛的数据，秘书通过分页和筛选获取参会者信息。权限在服务端检查，页面入口与按钮显隐配合角色控制。

在已有真实浏览器联调中，一名用户报名两场论坛，大会去重人数为 1，对应论坛人数分别为 1；取消全部报名后统计归零、秘书名单为空；重新报名后人数恢复。这条路径验证了报名写入和统计读取使用相同的有效状态。

4.3 通知发布与接收

分论坛主席和秘书发布论坛通知，参会者通过消息中心读取当前已报名论坛的信息。系统采用 HTTP 增量轮询，支持未读提示与已读操作；页面可见时默认约每 15 秒检查新消息。

取消报名后，服务端停止返回该论坛的通知；前端同时重置相关缓存和游标。切换账号时取消旧请求并忽略晚到响应，避免上一账号的消息或发布草稿出现在新账号页面。

最新主线还补充了论坛简介更新通知：论坛简介真实变化后，在同一事务中写入通知；通知写入失败时，论坛修改一起回滚。该功能对启用后的新修改生效。

4.4 基于 LLM 的智能论坛推荐

用户输入研究方向、兴趣或参会需求后，系统先从当前大会的真实论坛中召回候选，再将候选资料交给模型排序和生成理由。

推荐流程包括：

1. 对标题、议题和简介进行加权匹配，最多召回 30 个正分候选。
2. 向模型提供候选 ID 及必要资料，要求返回论坛 ID 和推荐理由。
3. 校验返回结构，过滤不存在、跨大会、重复和超量的论坛 ID。
4. 由真实论坛详情接口提供标题、时间和地点，用户主动点击后调用报名接口。
5. 超时、无密钥、网络错误或非法响应时，明确展示关键词降级结果及原因。

例如，输入“我对大语言模型和软件工程感兴趣”，系统围绕相关候选论坛生成推荐理由。论坛详情提供确定的时间和地点，参会者确认后再执行报名。

推荐验证覆盖模拟模型响应、结构过滤、异常处理和真实会话下的无密钥降级。外部模型通过服务端的 LLM_BASE_URL、LLM_API_KEY 和 LLM_MODEL 接入，真实供应商调用列入部署验收。

4.5 五语言与个人日程

系统支持简体中文、繁体中文、英语、日语、法语。语言资源按模块组织，通过注册表和统一取词接口接入；新增语言主要扩展资源包。Element Plus 与日期组件同步使用当前语言。

论坛业务内容采用独立内容包、按语言加载，并增加数字、缩写、段落和占位符校验。校验报告将 93 条简介列入人工抽检清单，检查数字、缩写和段落对应关系。

个人日程按大会展示有效报名的论坛、时间、地点和详情，并支持取消报名。报名或论坛时间变化后重新获取数据，另外提供手动刷新、窗口恢复焦点刷新及约 30 秒轮询，覆盖跨页面和跨客户端的更新。

5. CodeArts 协作与提交记录

5.1张王昊提交记录：

5.2程群提交记录：

5.3程杰提交记录：

5.4庄剀涵提交记录：

5.5郭昱祺提交记录：

5.6李泉毅提交记录：

5.7关欣提交记录：

5.8曾俊涛提交记录：

6. 运行截图

CNCC 2026 数据、时间地点、主席与简介

注册和个人报名

报名冲突

管理统计与秘书名单

参会者消息中心

智能推荐

五语言

个人日程

7. 每位成员遇到的困难与处理

8. AI Coding：从任务约束到可验证实现

我们选取五语言架构、报名事务和通知并发三个任务，展示团队如何引导 AI 完成跨模块开发。三个案例分别解决资源组织、数据提交和异步时序问题，每个案例都按照任务目标、关键 Prompt、AI 输出、方案取舍和验证结果展开。

以下 Prompt 摘自仓库开发记录；输出与测试结果按对应开发阶段整理。我们用接口规范限定生成范围，用代码审查确定采纳内容，再用具体业务场景检查实现。

案例一：统一五语言架构，并建立业务译文校验流程

任务目标与引导方式

八人并行开发时，论坛、统计等模块已经采用了不同的资源结构：有的使用 messages.ts，有的使用扁平 JSON。直接合并资源会让同名键互相覆盖；集中维护一个文件又会增加分支冲突。这个任务的目标是让五种语言共享统一入口，同时保留各业务模块的独立维护能力。

成员 7 将现有写法、协作人数和扩展要求一并交给 AI，先比较架构方案：

仓库现有三套文案写法：论坛用 messages.ts 命名空间、统计用扁平 JSON、即将合并的模块又是另一种。要求：8 人并行不冲突，新增语言只加资源文件，不许出现 if (locale === ...)。给方案并说明取舍。

这条 Prompt 将评判标准放在资源隔离和扩展方式上。AI 需要解释如何接入现有模块，以及多人开发时会共同修改哪些文件。

AI 输出摘要与方案选择

AI 提出了集中单文件、模块自治加注册表、混合组织三种方案。我们采用“模块自治加注册表”：资源保存在各模块目录，应用入口统一注册，业务键按命名空间隔离，公共导航与按钮使用共享资源。

选择依据来自实际资源结构。forum、conference 在不同模块中分别对应字符串和对象，原先的浅合并会覆盖同名键。将统计文案放入 statistics.* 后，同名业务概念可以在各自模块中保持独立。公共 common.* 则提升到全局，供导航、按钮和通用交互复用。

针对已有页面的迁移成本，成员继续要求：

现有 148 处 t('...')，不想全改。能不能让页面只换一行初始化，键名保持原样？

AI 提出 useScopedT(namespace)：common.* 透传全局，其他键自动增加模块前缀。我们采纳该方案，最终通过调整 8 个文件的初始化方式接入 148 处取词调用。页面保留原有键名，资源组织获得模块边界。

必要迭代：从“有译文”到“译文可检查”

业务内容涉及论坛标题、议题和简介。成员将质量要求转换为另一条任务：

170 场论坛的标题、议题、简介要翻成五种语言，不能失真。给我可执行的校验规则，不要只靠模型自觉。

AI 给出数字、缩写、段落、长度比、结尾、自述、重复和占位符等八类规则，并落实为 validate.mjs。我们在此基础上增加序数归一化，让“第二届”和“2nd”等表达能够按相同语义检查。

翻译通道出现限流和部分原文回显后，成员进一步限定重试范围：

公共翻译接口限流了，还有涉政内容会原样返回中文。不要整批重跑，只处理有问题的条目。

AI 据此将流程拆成校验与定点重试：校验器输出包含语言和论坛 ID 的 report/retry.json，重试脚本处理清单中的条目，已有译文保留。

我们拒绝将全部简介放进主包，改为按语言加载；拒绝运行时实时翻译，采用可检查的内容包；也没有整体放宽校验规则，而是针对具体误报修正规则。采纳与修改围绕维护成本、加载方式和信息保真三个目标展开。

检查、验证与最终效果

先用小规模冒烟测试确认 import.meta.glob 在 Vitest 中可用，再采用自动发现的资源注册方式。验证同时覆盖资源结构、内容完整性、质量规则和实际页面：

这个案例的关键成果是将国际化拆成独立资源、统一调用和可执行校验。AI 提供架构和脚本，成员通过资源冲突、占位符损坏及序数误报等具体问题调整方案，使新增语言和修复译文都能沿用同一流程。

案例二：实现统一报名服务，验证事务与并发边界

任务目标与关键 Prompt

报名贯穿注册、论坛列表、个人中心和推荐页面，写入结果又影响统计、通知及日程。这个任务要求多个入口共用业务服务，并保证重复请求、批量调整和异常回滚具有一致行为。

成员 3 先要求 AI 阅读规范、确认负责文件、接口和外部依赖，再给出后端实现约束。关键 Prompt 摘录如下：

在 server/src/modules/registrations/ 下实现报名模块，严格遵守 docs/01-接口统一方案.md：

• 所有写入口先 SELECT ... FOR UPDATE 锁 users 行，再改 registrations，锁顺序统一；
• 批量替换必须是单事务：任一 forum 未知或跨大会整批 422，一行都不写；去重后才判断 500 上限；
• 事务由 service 控制，repository 不许 commit；
• 复用 CamelModel、Page 与论坛模块的 to_forum_out。

同时给成员 1 一个可以在他事务内调用的 ensure_registrations_in_transaction。

这条任务将锁顺序、提交位置、批量失败语义和复用接口写入输入，AI 生成的代码因此可以直接对照这些条件审查。报名记录在主线整合后统一采用 is_active 有效状态，取消与恢复继续复用同一写入口。

AI 输出摘要与代码审查

AI 生成了 router、service、repository、schema、模型和相应路由注册，并提供供注册流程组合调用的服务。审查时，我们沿着“鉴权—参数处理—加锁—写入—提交”检查调用链，集中调整了三个问题。

第一，初版 router 再次使用 async with session.begin()。鉴权依赖已经在同一个 Session 执行查询，真实请求触发 A transaction is already begun on this Session。我们拒绝该写法，改由业务层统一完成提交和回滚，数据层执行查询和写入。独立报名请求由业务服务收口事务，注册组合服务复用调用者事务。

第二，批量选择的上限需要作用于去重后的论坛集合。我们检查“501 条输入但全部是同一个 ID”的边界，将数量判断放到 service 的 unique_ids 之后，使重复输入和真实超量得到不同处理。

第三，返回列表需要遵守声明的 DTO。初版查询返回元组列表，随后改为逐行调用 to_registration_out(row.forum, row.registered_at)，并将时间参数明确为 datetime，让接口结构与类型检查一致。

前端任务另外要求成功后派发 cncc:registrations-changed，组合式函数处理请求等待、重复点击和错误映射。AI 生成报名 API、个人报名页及开关组件后，我们将报名开关放入 ForumListPage 的 agenda-item__actions，保留详情页对通用卡片的复用。

必要迭代：让并发测试真正产生竞争

针对数据库行为，成员给出明确测试任务：

补测试，必须用真实 PostgreSQL。要覆盖：8 个并发重复 PUT 只留一行、add/remove 交错、批量替换校验失败回滚、ensure_registrations_in_transaction 不自行 commit、跨大会 422 不部分写入、不影响其他大会、去重后 500 放行 501 拒绝、未登录 401、非 ATTENDEE 403。

AI 生成接口与并发测试后，成员检查测试客户端和会话的创建方式，发现初版共用客户端的执行路径没有形成预期竞争。修改为独立客户端、独立 Session 后，再检查数据库最终状态。验证目标同时包含返回值和持久化结果，例如八次重复请求结束后，有效报名保持一条。

注册整合进一步使用失败注入检查组合事务。账号、参会者角色关联、报名和变更事件共用一个事务；分别触发无效论坛、唯一约束及事件写入失败，随后从独立会话检查新增记录。

检查、排错与验证结果

报名模块开发阶段的接口及并发测试 20 项通过；前端阶段测试 18 项通过，类型、ESLint、格式与构建检查通过。注册组合事务迭代使用真实 PostgreSQL 验证，后端 48 项、前端 19 项通过。后续正式浏览器联调覆盖注册选报、登录、取消、人数归零和恢复。

运行环境验证还定位了 Windows 事件循环问题：Psycopg 异步连接需要 SelectorEventLoop，而实际 Uvicorn 启动配置会影响事件循环选择。团队检查启动链路并提供显式 Windows 入口，再通过运行中的服务验证论坛读取、注册和登录。数据库测试与真实 HTTP 验证分别检查持久化行为和服务启动后的调用路径。

这个案例中，AI 加快了接口、页面和测试骨架的生成；成员通过事务归属、输入语义、组件职责和真实并发四类检查，使多入口报名保持同一套规则。

案例三：实现通知增量轮询，验证消息顺序与账号隔离

任务目标与关键 Prompt

通知功能需要把分论坛变更送达已报名用户，同时支持未读、已读和发布权限。成员 5 的任务输入为：

开发分论坛主席、秘书的通知发布页；关联论坛；实现消息中心、未读标记、消息详情；以轮询或实时连接推送已报名论坛信息。

验收围绕四个具体行为展开：已报名论坛的消息可见，新消息能够及时出现，取消报名后停止接收，发布者具备对应权限。成员先让 AI 对照统一接口、认证和有效报名结构实现，再补充数据库并发与页面异步状态验证。

AI 输出摘要与架构选择

AI 辅助实现沿用团队 HTTP 轮询、Bearer 会话和 PostgreSQL 事务结构，交付通知发布、消息历史、增量读取、已读接口和 Vue 消息中心。页面可见时定期查询增量，成功读取后推进游标；服务端根据当前有效报名过滤消息。

我们采纳轮询方案，因为它能复用现有请求客户端、会话和部署结构，并支持通过事件和定期重查处理报名变化。通知发布与序号分配集中在数据库事务中；页面则统一管理请求生命周期和账号状态。

方案审查重点落在“下一次请求从哪里继续”。普通自增序号按分配顺序增长，而事务可能以另一顺序提交：事务 A 先取得较小序号但尚未提交，事务 B 取得较大序号并先提交。如果客户端将 B 的序号作为最高水位，A 提交后便可能落在游标之后。

我们据此采用单行计数器锁。发布事务先锁住计数器，再分配序号、写入通知并提交；后一个发布事务等待前者释放锁。序号分配和通知写入由同一事务完成，使增量读取沿提交顺序推进。

必要迭代：数据范围和页面状态一起更新

通知范围随报名变化。服务端在历史、增量和已读校验中读取当前有效报名；前端监听报名变更，清理消息缓存并重置游标，同时定期重新获取历史，处理其他客户端产生的取消操作。

页面检查又发现，账号切换时私有发布草稿和晚到的发布结果需要一起清理。我们要求将请求生命周期与会话状态对应起来，最终采用 AbortController 取消旧请求，并以代次检查识别旧响应。已读操作成功后保留本地成功集合，协调轮询结果与页面交互。

这些调整分别处理数据库提交顺序、业务授权范围和浏览器异步时序。每次迭代都以具体失败条件检查 AI 辅助实现，并将调整落实到对应层次。

检查与验证：从并发事务到延迟响应

数据库测试使用真实 PostgreSQL 的两个并发事务，观察第二个发布事务等待计数器行锁，检查提交后的增量序列。这样可以验证锁的实际行为，以及客户端读取游标是否跨过尚未提交的消息。

接口测试覆盖发布权限、当前有效报名范围、取消后的可见性、已读幂等和大整数序号。页面测试主动延迟旧响应，在请求尚未完成时退出或切换账号，检查旧消息、旧草稿和旧发布结果是否被清理。

模块阶段记录为后端 25 项单元/API 测试、3 项真实 PostgreSQL 集成测试通过；页面专项修复 4 项通过；最终前端检查 16 项通过，类型检查与生产构建通过。

主线后续将论坛简介更新接入同一通知发布流程：简介变化与通知写入在同一事务提交，通知失败时一起回滚。相关论坛与通知回归共 38 项通过，覆盖有效报名可见、取消者隔离、重复保存、越权、版本冲突和事务回滚，验证了通知机制在实际信息维护中的复用。

该案例体现了 AI Coding 的审查重点：把“能显示消息”细化为顺序正确、范围正确、会话状态正确，再分别用数据库、接口和页面测试给出判断依据。

跨模块参考：推荐页面的需求细化与分阶段确认记录。

跨模块参考：推荐页面的界面调整与桌面、手机浏览器验证记录。

9. 贡献分配

10. 个人 PSP 表

10.1成员 1：工程、认证权限与部署（张王昊）

合计比预计增加 85 分钟。测试和集成投入高于预计，工作集中在原子注册回滚、Windows 事件循环适配及公共迁移整合。

10.2成员 2：会议与论坛（程群）

合计比预计增加 28 分钟。模型关系与论坛维护校验增加了设计和测试投入；统一公开接口减少了资料交接时间。

10.3成员 3：报名与个人中心（程杰）

合计比预计增加 60 分钟。事务边界调整、批量替换校验和独立会话并发测试增加了编码与验证投入。

10.4成员 4：管理后台与参会统计（庄剀涵）

10.5成员 5：通知与消息中心（郭昱祺）

合计比预计增加 85 分钟。通知序号并发、账号切换清理和晚到响应处理增加了测试投入。

10.6成员 6：LLM 智能推荐（李泉毅）

合计比预计增加 65 分钟。候选过滤、模型异常分支及多语言交互增加了设计和验证投入。

10.7成员 7：公共界面与五语言（关欣）

实际超出预计 185 分钟。个人记录将主要原因归于翻译通道、占位符处理、校验规则和统计页样式排查。

10.8成员 8：个人日程与验收协调（曾俊涛）

合计比预计增加 38 分钟。论坛改时、跨页面刷新和取消报名后的状态同步增加了边界测试投入。

第二部分：选题后的再思考与具体行动

11. 我们想重新回答的问题

老师问：“你们如何训练 AI？”

我们使用现有的大模型 API，重点是让模型在我们的项目里完成具体任务。比如用户想拆分任务，模型负责理解用户说的话，程序负责控制步骤、保存进度和处理失败。我们通过测试发现问题，再调整提示词和流程，让整个系统更稳定。

老师问：“你们和豆包有什么区别？”

我们把日常减压中的具体活动做成了可以直接操作的功能。比如用户想整理今晚要做的事情，可以进入任务拆分，一步步列出任务、确定重点、拆出第一步，最后得到一份清晰的行动清单。用户不用自己反复组织提示词，界面和程序会引导他完成整个过程。这个过程，就是我们需要开发和验证的核心价值。

12. 新的思考与已经采取的行动

第一，我们开始思考：自己觉得有用的功能，用户是否真的需要？

选题时，我们主要从团队的兴趣和日常感受出发，认为陪伴、减压和信息搜集可以结合起来。进一步讨论后，我们意识到，同样是“有烦恼”，不同用户的需求可能差别很大：有人希望被倾听，有人希望得到建议，也有人只想尽快把眼前的事情处理好。产品需要先理解用户希望获得什么帮助，再提供合适的功能。因此，我们准备从具体经历入手验证需求，找到最值得优先解决的场景。

具体行动：

• 邀请不同背景的目标用户交流，请他们描述最近一次遇到烦恼的经历、当时的处理方式，以及仍未解决的困难。
• 将反馈按场景分类，结合出现频率、困扰程度和开发可行性，选择首版重点解决的问题。
• 围绕选定场景制作简单原型，请用户独立操作，记录卡住、退出或需要解释的位置，再修改设计。

第二，我们开始思考：功能做得多，是否就代表产品做得好？

我们希望产品覆盖更多需求，但功能增加也意味着开发、测试和协作成本上升。如果每个功能都只完成一部分，用户仍然难以获得完整体验。因此，我们准备把关注点放在“用户能否顺利完成一件事”上。例如任务拆分功能，需要帮助用户从一堆杂乱的待办事项中确定重点，形成可以执行的第一步；同时，还要考虑输入不完整、操作中断和接口失败时如何继续。

具体行动：

• 重新排列功能优先级，将功能划分为首版必须完成、后续完善和暂缓开发三类，集中精力完成核心流程。
• 为核心功能制定可检查的验收标准，例如用户能否独立完成操作、是否得到明确结果、失败后能否重试，并明确负责人和完成时间。
• 每周组织一次完整流程演示，由其他成员模拟用户操作，记录问题并安排修复；根据实际进度及时调整范围。