切换 Claude Code 与 Codex 时，怎样让项目记忆不再分叉：Wienerdog 的纯文件共享方案
在 Claude Code 中刚解释过一次的仓库约定、排障结论和个人偏好，切到 Codex CLI 后又得从头交代——这通常不是模型“失忆”，而是两套客户端各自读取不同的上下文文件。把信息复制进多个 CLAUDE.md、AGENTS.md，短期看很快，长期却会产生更难发现的问题：同一条约定被改出两个版本，自动化任务写入的内容没有来路，或某个 Agent 把来自网页、邮件的指令沉淀成下一次会话的长期提示。
Wienerdog 是一个针对这类问题的本地优先工具。它不提供常驻服务，也不把记忆交给远端数据库；核心思路是把用户拥有的 Markdown 文件作为唯一长期来源，再把其中需要给不同 Agent 读取的部分同步到 Claude Code 与 Codex CLI。项目以 MIT 许可证发布，当前 npm 包版本为 0.12.0；仍处于 0.x 阶段，因此更适合愿意审阅本地文件、接受格式可能演进的开发者。
问题不只是“记住更多”，而是避免两份状态互相漂移
一个实际项目的长期上下文至少有三类：稳定的工作偏好（例如代码风格、沟通方式）、仓库或产品决定（为什么不用某个依赖、部署边界是什么），以及可复用的流程（发布前检查、事故复盘模板）。如果 Claude Code 和 Codex CLI 分别维护它们，常见的失败模式有三种。
第一，开发者只在当前工具的项目说明里更新规则，换工具后规则消失。第二，两个 Agent 都会“总结”，却没有共同的去重、来源和审核机制；同一决策在两处被压缩成含义不同的句子。第三，自动提炼对安全很敏感：会话里包含网页、工单或邮件时，那些外部文本不应直接变成会在每次新会话注入的指令。
Wienerdog 的边界很明确：它并不替换 Claude Code 或 Codex，也不承诺让模型天然更聪明。它管理的是围绕模型的一组文件、短生命周期脚本和操作系统计划任务。长期内容默认放在 ~/wienerdog/，采用可被 Git 跟踪的 Markdown 目录；~/.wienerdog/ 则保存配置、状态、日志和可选的凭据。也就是说，知识内容与工具运行状态分开，前者可以被人直接打开、审阅、备份或回退。
共享层怎样接入两种 CLI
安装入口是 npm。首次运行前，建议先使用只打印计划、不写入文件的模式，确认路径和将要生成的内容：
npx wienerdog@latest init --dry-run
确认后再执行初始化：
npx wienerdog@latest init --yes
工具把 ~/.wienerdog/ 视为规范核心，把记忆库视为数据源。它会为 Claude Code 的 ~/.claude/CLAUDE.md 和 Codex 的 ~/.codex/AGENTS.md 维护带边界标记的受管区域，而不是接管整个文件；因此用户写在标记外的原有内容不应被同步过程覆盖。技能也使用两边都能识别的 SKILL.md 形式：Claude Code 使用链接或 Windows 上的复制方式接入，Codex 则通过其配置登记技能路径。
这种“编译”关系很重要。真正该编辑的是记忆库与 Wienerdog 的配置，而不是两份最终产物。运行下面的命令会重新生成受管区域：
wienerdog sync wienerdog doctor
sync 适合在调整配置或记忆库后执行；doctor 用于查看当前安装与状态。完成首次设置并重启相应客户端后，可在 Claude Code 中调用 /wienerdog-setup；Codex CLI 中可先查看 /skills，再使用 $wienerdog-setup。这里的关键不是命令名称，而是两种客户端都从同一份本地资料得到可用上下文，避免各自再长出一套“事实”。
文件结构让记忆可以被检查，而不是黑箱累积
默认库按 PARA 风格组织：00-Inbox/ 用于暂存，01-Projects/ 对应项目，02-Areas/ 与 03-Resources/ 放持续领域资料，04-Archive/ 存归档内容，05-Skills/ 放可复用技能，06-Identity/ 放个人资料和偏好，07-Daily/ 放每日记录。每条自动写入的笔记带有 YAML 元数据，例如来源会话、置信度、更新日期和是否来自不可信外部内容。
这使“共享记忆”变成可审计的版本控制对象。团队或个人可以对 ~/wienerdog/ 建立本地 Git 仓库：某次自动整理不合适时，直接查看 diff 并回退；某个结论已过期时，修改原始笔记后再同步。与把摘要封装在数据库或浏览器插件里相比，这种方案的代价是需要维护文件卫生，但收益是数据可迁移、可搜索，也不依赖一个额外的网络服务持续运行。
夜间整理为何不能直接相信模型输出
Wienerdog 将“dreaming”定义为短时运行的夜间整理任务，而不是后台守护进程。它从 Claude Code 与 Codex 的会话记录中收集自上次水位线之后的内容，先处理敏感信息，再让受限的模型把候选信息写到库中。项目文档描述了分层门槛：日记、普通笔记、会进入身份资料或技能等高影响位置的内容有不同条件；高影响内容还要求跨多个会话重复出现，并且不能仅来自工具返回的外部文本。
这不是绝对安全保证，但它避免了一个危险的捷径：把“网页里出现过”直接等同于“用户认可”。在其威胁模型中，外部工具结果被当作不可信数据；生成任务被限制为读写指定文件，且不应拥有通用网络或 shell 权限。整理完成后以一次 Git 提交记录变更，便于审阅和撤销。想了解目前哪些能力已经启用、哪些仍有门控，可执行：
wienerdog safety
如果你只需要跨工具共享几条项目规则，没必要一开始就启用定时整理。先用初始化、受管块和手动 sync 验证两端是否读到相同上下文，再决定是否要开启会话捕获和例行任务，风险更低，也更容易定位问题。
适用场景与不适用场景
它适合经常在 Claude Code、Codex CLI 之间切换，且希望记忆保持在自己电脑上的独立开发者；也适合愿意把个人流程沉淀为 Markdown 与技能文件的人。对需要离线可读、可 Git 回退、没有额外常驻服务的工作流，这个设计尤其直接。
相反，如果团队真正需要实时协作权限、集中身份管理、跨设备冲突解决和管理后台，仅靠本地共享库并不能替代知识平台。另一个现实限制是 0.x 的文件布局仍可能变化；安装脚本虽然提供预览，仍应先在非关键环境运行 --dry-run，审阅仓库和 npm 包，再将它接入包含敏感资料的日常会话。
还有一个容易被忽略的运维边界：共享的是记忆资料，不是两个客户端的全部运行环境。模型版本、MCP 配置、项目目录权限和本机已有的 hooks 仍分别由各客户端管理。排查“两个 Agent 行为不同”时，应先确认两端是否已重启并载入最新受管块，再比较各自的本地配置；不要为了追求一致性，把未经审查的项目级指令复制进身份资料。对会定期整理会话的用户，建议把生成的 Git diff 纳入日常检查：保留有来源、能复述的工程结论，删除一次性闲聊、过期计划和不应长期保存的敏感上下文。这样文件库才会随时间变得更可靠，而非越来越长却难以使用。
Wienerdog 值得借鉴的不是“给 Agent 加记忆”这一口号，而是把记忆拆成可读文件、可重复同步的适配层，以及带来源与回滚边界的整理流程。这样切换模型客户端时，持续的不是一份不可解释的摘要，而是一套你可以亲自检查、修改和带走的工作资料。