06 · 决策记录与版本变化
分类严格区分：
【用户确认】 = 用户明确说「可以/同意/就这么做」或直接下达；
【用户提出】 = 用户提出方向但未最终拍板；
【AI 建议】 = 我提出、用户没有明确确认；
【已取代】 = 后来的要求覆盖了旧决定（旧记录保留，不静默删除）。
一、决策表
| ID |
时间 |
问题 |
用户原话/要求 |
最终决定 |
依据/原因 |
状态 |
| D-01 |
10-05 |
模型 Key 放哪 |
（AskUserQuestion 选择） |
Worker 统一转发，Key 不进前端直连 |
安全 |
【用户确认】仍有效 |
| D-02 |
10-05 |
检索方式 |
（选择） |
关键词匹配，不上向量库 |
零成本、够用 |
【用户确认】仍有效 |
| D-03 |
10-05 |
主动消息触发 |
（选择） |
页面打开/回前台时检查，不用 Cron |
无需定时任务 |
【用户确认】仍有效 |
| D-04 |
10-05 |
是否重构 |
「绝对不准重构我的代码结构，必须保留现有布局」 |
只做增量补丁，按区域改 |
用户在手机上操作，怕失控 |
【用户确认】仍有效，最高优先级 |
| D-05 |
10-19 |
默认人设 |
要求取消「小喵」默认人设 |
只用自定义人设；无则明确告知模型「未设定」 |
用户不想被内置角色绑定 |
【用户确认】仍有效 |
| D-06 |
10-17 |
深色模式 |
要求删掉入口 |
移除 UI 入口（CSS 变量残留） |
简化 |
【用户确认】仍有效 |
| D-07 |
10-14 |
手绘气泡 |
参照截图做装饰气泡 |
上线后中文乱码 → 回滚 |
atob 字节处理错误 |
【已取代】不再尝试 |
| D-08 |
10-24 02:55 |
后端总出错 |
「聊天记录没有就没有了……全部重新部署吧一个全新的」「我的意思是前后端全部都是新的」 |
新建 zhai-v2 + 新 KV chat_memory_v3（空库），旧 zhai/chat_memory_v2 保留不删 |
用户要干净环境；旧库留作退路 |
【用户确认】仍有效 |
| D-09 |
10-24 18:00 |
国内能不能用 |
「暂时先部署到 WorkBuddy 上面，后端那个记录的先不用」 |
国内直连版先不落库，只做代理 |
先验证可用性 |
【已取代】→ D-10 |
| D-10 |
10-25 04:40 |
后端迁哪 |
「理论上……迁移到阿里云？」→ 四方案 → 「你先试一下 C 吧」 |
C 方案：WorkBuddy + Node 垫片 + SQLite；先验证持久性 |
成本最低、改动最小 |
【用户确认】仍有效 |
| D-11 |
10-25 04:38 |
极端场景 |
「情况一跟情况二的话，你这两个你都考虑一下，然后做一个版本」 |
双快照三层防护：服务端每日快照（7 份）+ 设备每日快照（3 份）+ 手动导出导入 |
防平台清盘/手滑/换设备 |
【用户确认】已实现 |
| D-12 |
10-25 19:00 |
云端删除是假的 |
「我发现这个云端删除它不能真的云端删除」→ 选 A 根治 |
物理删除 + 墓碑防复活 |
兑现「本机和云端都删」的 UI 承诺 |
【用户确认】已实现 |
| D-13 |
10-25 18:32 |
灰度顺序 |
「这个改进的你先做那个 V2 的……万一跑不通怎么办？」 |
v2 先行验收，再 v1，再国内版 |
怕一次全改跑不通 |
【用户确认】已执行（v2→v1；国内版随代码自动生效） |
| D-14 |
10-25 22:32 |
500 是不是额度问题 |
「意思是…额度没了？你确定么」 |
复核证据：两库 list 同报 10048、读正常 → 确认是账户级 list 配额；修复=缓存+降级+干净 503 |
用户要求对质证据 |
【用户质疑→证据确认】已实现并部署 |
| D-15 |
10-25 23:23 |
审查范围 |
「立刻停止所有修改动作！进入只读审查模式」 |
只读审查三端，出报告，不改码 |
用户要决策依据 |
【用户确认】已执行 |
| D-16 |
10-26/27 |
交接 |
要求整理全部历史，给新 AI |
生成 10 份交接档案 |
换 AI 接手 |
【用户确认】本次执行 |
二、AI 提出但用户没有确认的建议（不要当成已定）
| ID |
建议 |
状态 |
备注 |
| S-01 |
图片存 R2（云端保留原图） |
未确认 |
涉及付费；当前图片只在本机 |
| S-02 |
用 Cloudflare Access / 登录态替换「令牌随页面下发」 |
未确认 |
P0-3 的推荐解 |
| S-03 |
记忆框架升级（Mem0 四态 + history / Graphiti 双时间戳 / Letta 预算） |
未确认 |
只有调研报告 |
| S-04 |
检索改读 msg:、停写 mem:（解决删除不彻底） |
未确认 |
P0-2 的方案 A |
| S-05 |
历史 279 条软删分批硬删 + 墓碑 |
未确认 |
需写配额预算 |
| S-06 |
轮换 v2 的 AUTH_TOKEN（因明文写在 index.html） |
未确认 |
换令牌后页面自动注入，无需改前端 |
| S-07 |
统一备份口径（v1/v2 也支持 schema:2 导入） |
未确认 |
P1-4 |
| S-08 |
删除设置里的「Worker 地址」输入（永远同源） |
未确认 |
P0-1 的方案 B |
| S-09 |
把 deploy-web/worker.mjs 改成构建时自动复制 |
未确认 |
P2-2 |
| S-10 |
阿里云 ECS / 国内 Serverless |
未采用 |
用户选 C |
三、版本与线上变化（可核对）
| 时间 |
版本/提交 |
变化 |
影响 |
| 10-05 |
基线 afa0aa4 |
初版全栈 |
— |
| 10-14 |
手绘气泡 → 回滚 |
乱码事故 |
用户看到「乱码」 |
| 10-16~17 |
08815a9、7702738 等 |
UI v2、PWA、安全 v2 |
46 项安全断言 |
| 10-19 |
9505597…b03a612 |
P0-1~P0-4 + P1 |
145 项断言 |
| 10-22 |
f02cc07 / 线上 51ac31d3 |
iOS 键盘最终版 |
用户确认「终于行了」 |
| 10-23 |
9ed08a6 / 线上 0114d69f |
删除+输入框修复 |
— |
| 10-24 02:59 |
867faee |
新建 v2（zhai-v2 + chat_memory_v3） |
空库 |
| 10-24 18:32~19:11 |
c007087、be64807、bd6a5af |
国内版三连修 |
sharecode/默认地址/人设 |
| 10-25 04:33~05:37 |
aa3998b…a32fe2e |
C 方案 1–3 批 |
SqliteKV、垫片、快照 |
| 10-25 09:01 |
5f61f81 |
第 4 批搬迁 606 条 |
国内版有数据 |
| 10-25 13:33~15:31 |
b885e6e、0f1007c、dfeff1d、32aa8a5 |
同源默认、403 修复、v1 令牌注入 |
v1 401 修复 |
| 10-25 18:48 |
83bc573 |
硬删+墓碑（先 v2 65bf6ef0） |
删除语义变更 |
| 10-25 20:36 |
5666a72 |
配额修复 |
缓存+降级 |
| 10-25 20:38 |
v2 8c6fe98a |
部署配额修复 |
— |
| 10-25 22:54 |
v1 a3ef2a33 |
部署配额修复 |
用户主入口恢复 |
四、被取代/撤销的旧决定（保留记录）
| 旧决定 |
取代者 |
说明 |
| 手绘气泡装饰 |
无 |
乱码后回滚，未再提 |
| 深色模式 |
无 |
用户要求删除入口 |
| 默认人设「小喵」 |
只用自定义人设 |
10-19 |
| 软删即「云端删除」 |
硬删+墓碑 |
10-25 |
| 国内版「不落库」 |
C 方案 SQLite |
10-25 |
| 单一 Worker |
v1 + v2 + 国内版 |
10-24 起 |
| Pages 静态托管 |
三端自托管页面 |
Pages 项目 chat-ui-beib 实为 10-03 的另一原型 |
deploy.sh 手工改产物 |
build.js 整体重生成 |
10-19 |
| 迁移只搬 v2 |
两库合并（v1+v2） |
用户 10-25 指出「搬错了有是 v1 的」 |
五、记录冲突（保留双方，标记待核实）
| 冲突 |
A 说法 |
B 说法 |
处理 |
| v1 库在 10-24 是否有数据 |
10-24 02:35 审计：msg:owner 仅 1 条、mem:owner 0 条、11 条旧 mem_* |
10-27 实测：4 个 msg:owner:* 抽样全部命中，含 217 条 local_ 前缀 |
结论：v1 在 10-24 之后被本机历史「云端同步」填充；具体是哪台设备/哪个入口触发待确认 |
| 搬迁数量 |
提交信息「606 条」 |
国内版实际：307 消息 + 299 记忆（312 mem 含后续新增） |
606 = 307+299，口径是「消息+记忆」，不是 606 条消息 |
| 国内版「搬错了」 |
用户：搬的是 v1 的数据 |
迁移工具设计：两库合并 |
事实成立：工具第 45 行同时读 0a4c 与 ec1a，v1 数据被一起带入；是否「错」取决于用户想要哪份 |
| v2 空库 |
我早期判断：搬迁失败 |
用户：全新部署，本来就空 |
以用户为准 |
DEEPSEEK_API_KEY |
wrangler.v1.toml 注释：secret 不随部署变动 |
代码只读 env.API_KEY |
死配置，见 07 P1-1 |
| 「前后端是一套」 |
我早期表述 |
用户：前后端分开且不一致 |
以用户为准：两份真源 + 两套寻址规则 |