今天的技巧来自正在 GitHub Trending 上升温的 akitaonrails/ai-memory。它不是代码生成器，而是给 Claude Code、Codex、OpenCode 这类 coding agent 做长期记忆与跨工具交接的基础设施。项目把沉淀内容放进 Git 仓库里的 Markdown wiki；上一位 agent 结束会话后，下一位 agent 能在同一目录拿到一段受限长度的交接信息。[1][2]

这个方向值得借，但不必急着部署整套服务。真正有用的做法是：把“上一次为什么没做成”写进交接，而不是只记录“现在做到哪了”。

很多 Vibe Coding 的返工不是模型不会写，而是它接到任务时看不到已经被排除的路径。你让第一个 agent 修缓存穿透，它尝试把缓存 TTL 拉长，发现订单状态延迟不可接受；第二个 agent 只看到“缓存还有问题”，又把 TTL 拉长一遍。代码看起来每次都合理，项目却在原地打转。

把交接文件当作失败实验记录#

每次暂停前，不要让 agent 生成长篇工作总结。要求它更新仓库内一个很短的 docs/agent-handoff.md，只保留下面五项：

# 当前任务：订单导出超时

## 已验证
- 导出查询没有 N+1；问题出在 CSV 写入前把全量记录读入内存。

## 已排除
- 不提高 worker 超时：会掩盖峰值内存问题。
- 不分页下载多个 CSV：产品要求单个文件。

## 约束
- 保持现有权限中间件和列顺序。
- 100 万行以内不能占用超过 256MB 内存。

## 下一步
- 用数据库 cursor + 流式 response 实现；先写内存上限回归测试。

## 验收命令
- pnpm test export
- pnpm lint

这里最关键的是“已排除”。它把失败方案变成后续 agent 的输入，而不是消失在聊天记录里。下一位 agent 可以反驳这个判断，但必须先知道这个判断存在。

ai-memory 的设计也体现了同一条原则：它区分历史记忆和当前代码事实。历史页适合回答“为什么当时这样选”“哪个方案试过会出问题”；具体符号、调用方和依赖关系仍应由当前 checkout、LSP、构建和测试确认。[2][3] 记忆能减少重复调查，不能替代验证。

20 分钟上手版本#

先不要引入 MCP、向量库或自动摘要。给每个活跃仓库加一个交接文件，并在 AGENTS.md 写入三条规则：

## Agent handoff
- 开始实现前先阅读 docs/agent-handoff.md。
- 不得重复“已排除”中的方案；若要推翻，必须说明新增证据。
- 完成或暂停前更新该文件，禁止写入密钥、用户数据和完整日志。

然后把下面这段作为每次任务结束时的固定指令：

更新 docs/agent-handoff.md。保留已验证事实、已排除方案、不可破坏的约束、下一步和可运行的验收命令。删除过时状态。不要把猜测写成事实。

它比“总结一下进度”好得多。后者通常会得到一段平滑的叙述，听起来完整，却没有下一位执行者真正需要的边界。

有两个细节会决定这套方法是否长期有效。

第一，交接文件必须短，建议控制在 30 到 60 行。如果它变成项目日记，agent 会跳过它，或者把旧信息当成当前事实。只记录会影响下一次决策的东西；测试输出、完整报错和普通文件列表都应该留在 Git、CI 或 issue 里。

第二，把“下一步”写成一个可验证的切片。不要写“继续优化导出性能”，应写“为 100 万行 fixture 添加峰值内存断言，再实现 cursor stream”。这样下一个 agent 启动后不需要重新判断任务边界，也不会为了完成一句含糊目标而大范围重构。

第三，给交接内容保留一个失效机制。需求、依赖版本与接口都会变化，昨天的结论不该自动升级成今天的规则。每次接手时先核对相关测试、当前实现和 issue 状态；确认失效的条目就删掉或标为过期。交接文件记录的是决策线索，不是不可挑战的真相。

当你开始频繁在 Claude Code、Codex、Cursor 或不同机器间切换时，再考虑自动化。ai-memory 支持多个 agent CLI 的 MCP 与生命周期 hooks；对没有真正 session-end hook 的客户端，文档要求用 finalize-session 补一次最终交接。[2][4] 但先跑通手写的仓库内交接文件。若团队连什么值得保留都还没定义，自动记忆只会更高效地保存噪声。

Vibe Coding 的速度不只来自更快地生成代码，也来自不重复走已经证明不通的路。把失败、约束和验收命令交给下一次会话，才算真的把上下文留下来了。

Sources#

[1] https://github.com/trending [2] https://github.com/akitaonrails/ai-memory [3] https://raw.githubusercontent.com/akitaonrails/ai-memory/main/docs/usage.md [4] https://raw.githubusercontent.com/akitaonrails/ai-memory/main/docs/install.md