用共享记忆和测试门禁串联编程助手

Claude Code 和 Codex 都能写代码，但它们默认不知道你的项目进度，也不知道另一个助手刚做过什么。ECX 想解决的就是这段断层：用共享笔记、会话同步、搜索和测试钩子，把两个独立助手接进同一套工作流程。

作者每天使用这两个工具，持续六个月后，把积累的配置打包成了 ECX。它值得看的地方不是又增加了多少 AI 功能，而是把「记住上下文」「确认任务完成」「让两个助手互相检查」变成了具体机制。不过，演示跑通和普遍有效之间，仍有距离。

让助手记住你，先把记忆放到文件里

ECX 的底座是一个 Markdown 笔记目录，称为 vault。它既是 Obsidian 知识库，也是可以放进 git 的普通文件夹。停用 ECX 后，笔记仍能继续使用。

目录按用途分成 inbox/、daily/、projects/、personal/、research/、wiki/、content/ 和 archive/。工作方式是先捕获，再整理：新内容进入 inbox/，助手稍后归档；/wiki 把零散材料整理成有链接的文章，原始材料移入 archive/，不直接删除。

真正让这些文件成为「记忆」的，是自动加载机制。

hot.md 保存当前项目、截止日期和硬规则，例如修改简历前先询问、禁止推送到 main。它刻意保持简短。安装免费的 remember 插件后，每次回复都会留下摘要，recent.md 和每日笔记保存最近几天的活动；偏好、纠正和项目状态则拆成小文件，由索引统一列出。

SessionStart hook 在第一条消息前注入这些内容，另一个 hook 在 /compact 后重新加载，避免长会话压缩时丢掉关键约束。会话结束时，/tldr 写回变化。

记忆能持续生效，靠的是读写时机，而不只是建了一个笔记目录。

跨助手同步也走文件。Claude Code 的会话保存在 ~/.claude/projects/，Codex 的保存在 ~/.codex/sessions/。agent-sync 是只依赖 Python 标准库的单文件程序，在每次发送消息前读取另一个助手新增的会话行。作者称耗时远低于 0.1 秒；新会话首次回看六小时，之后只同步增量，也包含 Codex 语音转写。

助手还可以用 sync.py send --from claude --to codex "..." 留言，下一轮送达，并通过限流避免无限互发。记录落在 agents/AGENT_CHAT.md。

演示中，用户告诉 Codex，演示改到 Friday 2pm，且必须使用 v2 buoy feed。新开的 Claude Code 会话随后读到了变更，还指出笔记里的 Thu 11:00 已经过时。这证明了演示中的上下文传递，但原文没解释多条消息互相冲突时如何裁决。

搜索和手机入口，让笔记能找得到、带得走

ECX 把三种检索能力通过 MCP server 提供给助手。

ChromaDB 把笔记切块并生成嵌入，用语义找内容；LightRAG 建立人物、项目和概念之间的关系图；CLIP 索引幻灯片、截图和 PDF 页面，让用户可以描述图片内容来寻找资料。一个路由服务负责分配问题，夜间任务重新建立索引。

这些能力各有用途。找报错原文时，关键词搜索很直接；只记得讨论主题时，语义检索更合适；查跨项目关系或架构图时，后两种才可能发挥价值。原文没有给召回率或检索对照数据，不能据此认定三套引擎都必需。

它还补了两个容易遗漏的检查：依赖故障时阻止搜索调用并提示修复办法；索引长期未更新时，在新会话展示最后一次成功更新时间。

隐私边界要单独看。原文称语义搜索和图片搜索完全在本机运行，但关系图使用 Ollama，默认模型运行于 Ollama 免费云端，索引时会发送笔记文本。需要全部留在本机时，要把 ECX_LLM_MODEL 改成本地模型。

手机端则借助私有 GitHub 仓库。电脑每次回复后，hook 在后台同步 vault，并把 hot.md、当天日志、近期摘要和记忆文件镜像到 context/。手机上的云端助手读取这个仓库。

AGENTS.md 的 phone mode 要求云端助手只在 inbox/ 新增一个文件，其他内容不动，再由 GitHub Action 自动合并。电脑下次启动后拉取并整理。这种限制减少了双方同时修改记忆文件的冲突。

Claude app 会自动读取 CLAUDE.md 并直接推送捕获内容。ChatGPT app 中的 Codex 需要先连接指定仓库、创建关闭互联网的 Codex Cloud 环境，每次对话以 Read AGENTS.md first and follow section 7 开头，发布捕获内容前还会询问一次。手机端可用，依靠的是云端仓库副本，并非继续访问合盖电脑上的进程。

「完成了」要经过测试，双助手还要互相复查

ECX 最有实际约束力的部分，是 Stop hook。

它只在 git 仓库中运行，并对 HEAD、已跟踪改动和新文件生成指纹。相较上次测试通过没有变化，就不重复执行。测试命令可以从 npm test、pytest、带 tests/ 的 unittest、cargo、go 或 Makefile 的 test: 目标识别，也能写入 .ecx/test-command；填入 off 可关闭。

失败后，最后 40 行输出会发回助手，要求继续修复。连续失败三次后允许停止，同时告知用户，避免死循环。

演示里，用户明确说不必跑测试，助手也跳过了，但 hook 仍然发现 53.4 != 97.2。随后助手判断旧断言保留了错误行为，把预期从 97.2 改为 53.4，最终两个测试通过。

这里需要分清：测试通过是一道门槛，修改断言是否正确仍需业务依据。截图展示了一次修复过程，不能单凭绿色结果证明需求已经满足。

命令防护由 PreToolUse hook 执行：直接阻止 rm -rf ~、格式化磁盘和 fork bomb，对 force-push、git reset --hard、DROP TABLE 要求确认。作者还承认，它曾因绘图文本包含危险命令而误拦截。

doctor 在每次会话启动时执行 16+ 项检查，覆盖 hook、索引、定时任务和同步。写入 content/ 或 personal/ 后，AI-tell guard 会依据可编辑词表提示破折号和套话，但不阻止操作。

双助手模式则再加一层独立检查。它用下面的命令启动同一目标：

cd your-repo && ~/ecx/bin/ecx duo "make the failing login test pass"

注意 duo 后面是任务目标；两位助手会先各自制定方案，再互评合并，用户批准前不会写入内容。

两者完成前必须复查对方最新改动，异议要附可验证证据。演示中的 Codex 发现 satisfies("1.2.4", "~1.2.3+build") 会抛出 ValueError，Claude 再据此修复。

删除或替换已有文件、git push、发布、部署、向外发送数据，以及非纯读取或无法识别的工具调用，都要经过批准卡片；受保护目录直接禁止操作。即使用户已经说「yes, push it」，仍需点击批准。

High 按钮可以中途切换两者到顶级模型，用量达到 90% 时自动暂停。报告同时保留助手摘要和由原始事件生成、助手无法修改的操作日志。

我的判断

我认可 ECX 把约束放进执行流程的方向。共享文件减少重复交代，独立方案减少一方先入为主，测试 hook 则让「完成」有了可检查的条件。相比只在提示词里要求认真检查，这些机制更具体。

但它没有证明双助手普遍优于单助手。作者只在 SWE-bench Verified 中六个标注为人工需要 1-4 小时的困难问题上，各跑一次，并由官方 harness 评分。结果是：单个助手能解决的问题，duo 都解决了，而任何一个单助手都没覆盖全部这些问题。六题、每题一次，只能算初步信号；原文没有给足成本、耗时和重复运行数据。

安全边界也很明确：duo 判断命令和工具调用，不能完整判断脚本启动后内部会做什么。批准计划依旧需要人看。

部署规模同样影响取舍。ECX 自带 18 个 skill，以 SKILL.md 保存指令，并链接到 ~/.claude/skills 和 ~/.agents/skills。完整安装还涉及 8 个全局 hook、8 个 vault hook、Codex hooks 和 3 个 MCP server。对只维护少量项目的人，这套维护成本未必划算。

安装命令如下：

git clone https://github.com/saksham10arora-dotcom/everything-claude-codex ~/ecx
cd ~/ecx && ./install.sh

注意第二行执行安装脚本。作者称安装时只询问笔记位置和名字，合并已有配置、跳过已有项，并为接触的文件保存 .ecx-bak；--dry-run 预览变更，--uninstall 恢复备份，--with-search --with-cron --with-phone 启用完整配套。这些是原文说明，并非本文独立验证。

能拿来做什么

• 经常重新解释项目背景，可以先整理一份短小的 hot.md，写清当前任务、截止日期和硬规则，再配置会话开始与压缩后的加载。
• 给前端或 Node 仓库接入测试门槛时，先明确 .ecx/test-command，确保它执行与改动相关的检查；助手修改测试断言时，仍要核对需求依据。
• 同时使用 Claude Code 和 Codex 时，可以先尝试会话增量同步；只有任务值得额外复核，再启用 duo，并观察耗时、用量和实际发现的问题。
• 准备完整安装时，先用 --dry-run 查看配置改动。只用 Claude Code 也能使用除 agent-sync 和 duo 之外的部分，无须为了整套配置增加另一个助手。