索引数据会不会丢，换机器怎么办开发者对工具的数据安全有两种焦虑：一是"我的数据会不会丢"，二是"换台机器是不是从零开始"

索引数据会不会丢，换机器怎么办

利益声明：本文作者参与了 wescode 的开发。文中涉及 wescode 的技术描述基于内部测试数据；涉及其他工具的描述基于各家公开文档和社区反馈。

开发者对工具的数据安全有两种焦虑：一是"我的数据会不会丢"，二是"换台机器是不是从零开始"。这篇把 wescode 的数据存储、备份和迁移全讲清楚。

Q: wescode 的数据存在哪里？

wescode 的所有持久化数据存在本地文件系统的一个目录下：

~/.local/share/wescode/                # Linux
~/Library/Application Support/wescode/  # macOS

├── hypervisor.db                  # Cell 注册表（哪些 workspace 打开过）
├── cells/ws-{hash}/               # 每个 workspace 一个 Cell 目录
│   ├── meta.db                    # Cell 元数据
│   ├── sessions.db                # 对话历史、消息记录
│   ├── state.db                   # 运行时状态、token 用量追踪
│   ├── index/                     # CKG 代码知识图谱索引
│   ├── knowledge/                 # 项目知识库文件
│   └── skills/                    # 已安装的 Skill 包
├── db/wescode_auth.db             # 登录凭证（跨 workspace 共享）
└── logs/                          # 日志文件

全部是标准格式： SQLite 数据库 + 普通文件目录。没有加密、没有私有格式、没有"只有 wescode 才能读"的黑盒。你可以用任何 SQLite 工具（比如 sqlite3 命令行或 DB Browser for SQLite）直接查看和导出数据。这是一个有意的设计选择——你的数据永远不应该被工具绑架。 即使 wescode 明天停止更新，你的对话历史、记忆、知识库都可以被标准工具读取和迁移。

一个重要设计：1 workspace = 1 Cell。 每个 workspace 的数据在物理上完全隔离——项目 A 的对话历史、CKG 索引、记忆偏好不会跟项目 B 混在一起。Cell ID 由 workspace 路径确定性派生（sha256(path)[:4] → ws-a1b2c3d4），同一个项目路径永远映射到同一个 Cell。

Workspace Cell 隔离架构

Q: 数据会不会丢？

wescode 的数据持久化使用了多层保护：

SQLite WAL 模式。 所有数据库使用 Write-Ahead Logging，写入操作是原子的——要么完整写入，要么完全不写入。进程崩溃不会导致数据库损坏。wescode 还显式禁用了 mmap（PRAGMA mmap_size=0），消除整类 SQLITE_IOERR_MMAP 故障。

三层数据库分离。 元数据（meta.db）、会话（sessions.db）、运行状态（state.db）是独立的数据库文件。sessions.db 损坏不影响 state.db，反之亦然。单层损坏不扩散——这是引擎层的硬约束。

引擎层自动恢复。 如果某个数据库文件真的损坏了（比如磁盘故障），Cell 启动会降级而不是崩溃——损坏的层被标记为 Degraded，其余功能继续可用。损坏的文件会被归档到 corrupt/ 目录供诊断，不会被直接删除。

损坏后的恢复情况一览：

数据	损坏后果	可否重建	重建方式
CKG 索引（`index/`）	代码导航暂时不可用	✅ 自动重建	重新打开项目，几秒到几分钟
Skill 包（`skills/`）	已安装的 Skill 丢失	✅ 重新安装	`cell.Skills().Install()`
运行状态（`state.db`）	token 统计等非关键数据丢失	✅ 自动恢复	新的 Run 会重新生成
对话历史（`sessions.db`）	聊天记录和上下文丢失	不可恢复	必须从备份恢复
记忆（`sessions.db` 内）	AI 学到的偏好丢失	不可恢复	需要重新教 AI
知识库（`knowledge/`）	自定义文档丢失	⚠️ 取决于原始来源	从原始文件重新导入

结论：真正不可恢复的只有 sessions.db——你跟 AI 的对话历史和记忆偏好。建议定期备份。

Q: 怎么自动备份？

一个简单的定时备份脚本：

#!/bin/bash
# wescode-backup.sh — 每天备份对话历史和记忆数据

WESCODE_DATA="$HOME/Library/Application Support/wescode"  # macOS
# WESCODE_DATA="$HOME/.local/share/wescode"               # Linux

BACKUP_DIR="$HOME/backups/wescode/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

# 备份所有 Cell 的 sessions.db（对话历史 + 记忆）
for cell_dir in "$WESCODE_DATA"/cells/ws-*/; do
  cell_id=$(basename "$cell_dir")
  if [ -f "$cell_dir/sessions.db" ]; then
    # 使用 SQLite 的 .backup 命令确保一致性（不是简单 cp）
    sqlite3 "$cell_dir/sessions.db" ".backup '$BACKUP_DIR/${cell_id}-sessions.db'"
    echo "✅ 备份 $cell_id sessions.db"
  fi
done

# 备份登录凭证
if [ -f "$WESCODE_DATA/db/wescode_auth.db" ]; then
  sqlite3 "$WESCODE_DATA/db/wescode_auth.db" ".backup '$BACKUP_DIR/wescode_auth.db'"
fi

# 备份 hypervisor（Cell 注册表）
if [ -f "$WESCODE_DATA/hypervisor.db" ]; then
  sqlite3 "$WESCODE_DATA/hypervisor.db" ".backup '$BACKUP_DIR/hypervisor.db'"
fi

# 清理 30 天前的备份
find "$HOME/backups/wescode" -maxdepth 1 -type d -mtime +30 -exec rm -rf {} +

echo "备份完成: $BACKUP_DIR"

为什么用 sqlite3 .backup 而不是 cp？ SQLite 在运行时可能有 WAL 文件（-wal）和共享内存文件（-shm），直接 cp 可能拷到不一致的状态。.backup 命令会等待写入完成再拍快照。

配置 cron 每天自动执行：

# 每天凌晨 3 点备份
echo "0 3 * * * /path/to/wescode-backup.sh" | crontab -

Cell 隔离与数据安全

Q: 换机器怎么迁移？

最简方案：直接复制数据目录。

# 旧机器上——打包整个数据目录
tar czf wescode-data.tar.gz ~/Library/Application\ Support/wescode/

# 新机器上——先安装 wescode，再覆盖数据目录
tar xzf wescode-data.tar.gz -C ~/Library/Application\ Support/

迁移后的状态：

数据	迁移效果	说明
对话历史	✅ 完整保留	所有 workspace 的聊天记录
AI 记忆	✅ 完整保留	学到的代码风格偏好等
已安装 Skill	✅ 完整保留	Tier C 用户 Skill
项目知识库	✅ 完整保留	导入的自定义文档
CKG 索引	⚠️ 需重建	索引包含绝对路径，新机器路径可能不同
登录状态	⚠️ 需重新认证	安全设计——token 不跨设备有效
Provider API Key	⚠️ 需重新配置	Key 不在数据目录里明文存储
项目级规则	✅ 跟着 Git 走	`AGENTS.md`、`.cursor/rules/` 在项目仓库里

CKG 索引重建是自动的——打开项目时 wescode 会检测到索引路径不匹配，自动触发重新索引。

换电脑的完整迁移清单

如果你从旧 Mac 换到新 Mac，按这个清单操作：

# 换电脑迁移清单

必须拷的:
  - sessions.db（每个 Cell 的对话历史和记忆）
  - wescode_auth.db（登录凭证，省去重新认证）
  - hypervisor.db（Cell 注册表，省去重新打开项目）
  - skills/ 目录（已安装的自定义 Skill）
  - knowledge/ 目录（导入的项目知识库文档）

不需要拷的（会自动重建）:
  - index/ 目录（CKG 索引，打开项目自动重建）
  - state.db（运行时状态，新 Run 自动生成）
  - logs/ 目录（日志，新机器从头开始）

需要重新配置的:
  - Provider API Key（安全考虑，不随数据目录迁移）
  - 代理设置（如果你用了 HTTPS_PROXY）

配置目录的完整路径（迁移时需要知道）：

系统	数据目录	配置目录
macOS	`~/Library/Application Support/wescode/`	`~/.config/wescode/`
Linux	`~/.local/share/wescode/`	`~/.config/wescode/`

config.yaml 在配置目录里，也建议一起拷过去——省去重新配置 Provider 的 base_url 和模型列表。

Workspace Cell 隔离保证数据独立

Q: 多台机器之间能同步吗？

目前 wescode 不提供内置的云同步功能。这是有意的设计——云同步引入的复杂度（冲突解决、部分同步、实时性）和数据所有权问题，在当前阶段的收益不足以覆盖代价。

你的选择：

方案 1：手动复制（推荐） 上面说的 tar 打包方式。适合偶尔换机器的场景。

方案 2：网盘同步（有风险） 把 wescode 数据目录放在 iCloud/OneDrive/坚果云同步的位置。注意：SQLite 在多设备同时写入时会冲突——坚果云和 iCloud 不理解 SQLite 的事务语义，同步工具看到 .db-wal 变化就传，可能拷到半截状态。建议只在确保同一时间只有一台机器打开 wescode 的情况下使用。

方案 3：配置跟着 Git 走（最佳实践） 把项目规则和团队配置提交到项目仓库：

your-project/
├── AGENTS.md           # 项目指令——AI 行为的最高优先级
├── .cursor/rules/      # 分模块规则文件（wescode 兼容 Cursor 格式）
└── .wescode/
    └── skills/         # 项目级 Skill（团队共享）

这些配置随 git clone 自动到位，不需要任何同步工具。这是我们推荐的"团队知识同步"方式——配置即代码，review 即审核。

Q: 从 Cursor 迁移到 wescode，数据怎么办？

Cursor 的对话历史和索引数据不能直接导入 wescode——两者的数据格式不同。但迁移成本其实很低：

代码和 Git 历史——不受任何影响，项目代码不在 Cursor/wescode 数据目录里
CKG 索引——打开项目自动重建，无需手动操作
快捷键和设置——wescode 兼容 VS Code 的 settings.json 和 keybindings.json
扩展——大部分 VS Code 扩展直接可用
.cursorrules——wescode 的 CSE 引擎兼容 .cursorrules 文件格式
对话历史——无法迁移，需要从零开始（这是唯一的实际损失）

诚实说： 对话历史的丢失是迁移的主要心理成本。但从实际使用来看，大部分对话的价值在产出（代码已经提交了），而不在对话本身。AI 的记忆系统会在几次对话后重新学到你的偏好。

Q: wescode 卸载后影响 VS Code 吗？

完全不影响。 两者使用独立的数据目录，互不干扰。

维度	wescode	VS Code
数据目录（macOS）	`~/Library/Application Support/wescode/`	`~/Library/Application Support/Code/`
配置目录	`~/.config/wescode/`	`~/.config/Code/`
扩展目录	`~/.wescode/extensions/`	`~/.vscode/extensions/`
进程名	`wescode`	`code`

卸载 wescode 不会动 VS Code 的任何文件。反过来也一样——卸载 VS Code 不影响 wescode。两者可以同时安装、同时运行，互不干涉。

甚至你的项目文件也不受影响。 wescode 不会在你的项目目录里创建隐藏文件（除非你手动创建了 .cursor/rules/ 之类的配置——那些跟着 Git 走，不属于 wescode 数据目录）。

Cell 隔离确保数据安全

Q: 如果要彻底删除 wescode 的所有数据？

# macOS
rm -rf ~/Library/Application\ Support/wescode/
rm -rf ~/.config/wescode/

# Linux
rm -rf ~/.local/share/wescode/
rm -rf ~/.config/wescode/

删完就是干净的。wescode 不会在别的地方留缓存、不会在系统注册表写东西（Windows 也不写注册表）、不会在你的项目目录里偷偷创建隐藏文件（除非你手动创建了 .cursor/rules/ 之类的配置文件，那些在项目仓库里，需要你自己 git rm）。

这跟 VS Code 的卸载逻辑一样：删除应用 + 删除数据目录 = 完全清除。没有"卸载残留"的问题。

验证清除是否干净：

# macOS 上确认没有残留
ls ~/Library/Application\ Support/wescode 2>/dev/null && echo "数据目录还在" || echo "✅ 已清除"
ls ~/.config/wescode 2>/dev/null && echo "配置目录还在" || echo "✅ 已清除"

一句话总结： wescode 的数据架构设计原则是「标准格式、物理隔离、用户全控」。你的数据是标准 SQLite（任何工具都能读），每个项目物理隔离（不互相干扰），全部在你的硬盘上（不依赖任何云端服务）。换机器直接拷目录，卸载不留残留，跟 VS Code 互不影响。