C 端移动端 AI 生产力 / 个人记录工具-浮签

1.立项背景和目标
碎片化的灵感、待办、情绪往往转瞬即逝——用户常在"想记"到"打开 App 写完"的过程中就忘了或丢失了一部分。传统记录工具打开成本高（需选分类、填表单），进一步加剧丢失。
浮签立项旨在打造一款极低门槛、无压力的 C 端碎片记录工具：系统级快捷磁贴秒开即写、写完即走，后台由 AI 异步把碎片转化为结构化认知资产。

2.软件功能与核心模块
产品为移动端应用（Flutter Android App + 系统级快捷磁贴双入口），后端 Spring Boot 模块化单体（12 模块 / 42 端点 / 22 表）。核心模块：
记录与同步（note/sync） ：主 App 与 Android 原生磁贴双路径提交，离线队列加密回放，解决弱网/瞬时丢失。
AI 洞察（ai） ：双 LLM 编排——LLM1 SMALL 一次产出六维评分（情绪/深度/话题/意图/重要度/紧急度）+ 意图识别；命中白名单则 LLM2 MEDIUM 抽取意图细节。模型配置免重启热刷新。
积分计费（gamify） ：签到、积分流水、TCC 预扣 + Token 公式计费框架（为付费铺垫，当前未计费）。
标签（tag） ：AI 自动打标 + 手动全量编辑 + 标签筛选。
账号（user/security） ：短信/微信登录、JWT 双 Token、头像、注销。

3.业务流程与功能路径
【记录→AI 洞察主链路】 用户下拉磁贴或打开 App 写碎片 → 提交触发 NoteCreatedEvent → 监听器 @Async 虚拟线程异步处理 → 同步串行：LLM1 生成六维+意图 → 路由定级 → 命中意图白名单则 LLM2 生成细节 → 落库并计算优先级/四象限/紧急度衰减 → 返回降级或完整结果。书写全程不被 AI 阻塞。
【积分预扣链路】 LLM 调用前 reserve（FOR UPDATE 行锁 + CAS 冻结/真扣）→ LLM 成功即 confirm 结算 → 失败则 release；清道夫兜底崩溃遗孤。（当前免费，预扣额度为 0，框架预留。）

1.整体架构与设计思路、技术栈
浮签是 C 端 AI 碎片记录 SaaS，采用"前端 + 单体后端 + 独立管理端"三端架构，部署于 2C2G 单实例，拒绝 Redis/MQ/Caffeine 等中间件，以纯 MySQL + JDK 并发原语实现缓存/限流/幂等。

2.我的负责模块与结果
AI 集成实现和落地，DynamicModelFactory + AiModelRegistry，实现模型配置免重启热刷新（SQL 指纹探测 + 60s 轮询 + 事件唤醒），api_key AES 密文落库；支撑双 LLM 编排
工程基础设施：Flyway迁移治理，2C2G 下将 JVM 稳定控制在 -Xmx1g、常驻余量 200–300M

3.难点、坑与解决方案
Spring AI 1.1.8 手工装配的隐性坑
坑：options 为整体替换语义，请求传参会顶掉默认配置；旧模型 Bundle 热刷新会切断在途请求。
解：统一用 AiCallOptions.merge() 合并；旧 Bundle 延迟 60s 关闭（> read timeout）；注册表用 AtomicReference 快照 + 单线程刷新者保证无并发构建。
JPA 一级缓存导致余额错乱
坑：bulk CAS 更新后持久化上下文仍是旧值，getTotal() 读到 stale 值，且整行 flush 会冲掉增量。
解：余额一律用标量投影 findTotalPointsById 读取，禁止加载实体后 getTotalPoints()；User 不设 @Version，以 CAS 条件 UPDATE 防负余额。
资金双扣/资损风险
坑：乐观锁 + @Retryable 对"写"有双扣风险，且余额不足时重试无意义。
解：改用 FOR UPDATE 串行化 + TCC 预扣/确认/释放 + 唯一索引；确认/释放均为状态 CAS，失败可安全重试。
2C2G 拒中间件下的可靠性
坑：无 Redis 缓存、无 MQ 削峰，配置热刷新与限流无现成方案。
解：缓存用 ConcurrentHashMap + 60s 全量刷新；配置中心用 60s 轮询 + 事件双通道（轮询为基线）；AI 洪峰靠外部 API 限流降级 + DB 连接池超时兜底，不做并发准入。