mono 是一个为 Claude Code 设计的记忆外骨骼系统，通过 markdown 文件和 Git 工作流自动捕获项目中的所有洞察、决策和上下文，让 AI 搭档拥有跨越会话的持久记忆。
mono 是一个为 Claude Code 设计的记忆外骨骼系统，通过在项目根目录建立 memory 文件夹，把所有灵光一闪、踩过的坑、做的决定都写成 markdown 文件存起来。它像一个永不失忆的编程搭档，让每个新的 Claude 实例都能瞬间继承之前的上下文，不用每次都从头解释需求。
系统采用扁平化文件结构配合 wiki 链接，用日期前缀给记忆打时间戳，提供二十多个斜杠命令实现从目标设定、方案探索、代码审查到项目切换的全流程自动化。
最狠的是它把 Git 工作流也包了进去，每次操作自动切分支、自动提交，让你专注思考而不用操心版本管理。
这是一个用 Claude 开发出来、又用来开发自己的自举式工具，证明了 AI 辅助编程不仅能写代码，还能重塑整个工作流。
为什么你的 AI 搭档需要一块外置大脑
想象一下这样的场景：你熬到凌晨三点，终于跟 Claude 讨论清楚了一个超级复杂的架构设计，你们一起推敲了十二个边界情况，排除了三个潜在坑点，确定了最终方案。第二天你睡眼惺忪地打开终端，准备继续干活，却发现 Claude 一脸茫然地看着你："你好！今天想写什么代码？"那一刻你想砸键盘的心情我懂。这就是 mono 诞生的原因——它要给 Claude 装上一块外置硬盘，让所有那些"我们昨天不是已经讨论过了吗"的瞬间彻底消失。
mono 这个名字本身就很有意思，在英文里是"单一"的意思，但在这个项目里它代表的是一种"单一真相源"的野心。开发者 ltOgt 想要创造一个记忆层，这个层凌驾于所有具体项目之上，像一个巨大的知识海绵，吸干每一次对话中的精华。不管你是做网站、写脚本还是搞数据分析，只要你在 mono 的框架里工作，所有的洞察、决策、踩过的坑都会被自动归档。这不是一个简单的笔记系统，这是一个工作流的自动化引擎，它的核心哲学是"先捕获，后整理"，宁可存一堆以后可能用不上的东西，也绝不让任何有价值的思考随风而逝。
捕获优先于整理的人生智慧
mono 的设计哲学里有一句话特别戳人："重建'该死我记得前几周讨论过这个'比'好吧这些我都不需要'要难得多"。这句话道出了一个残酷的真相：人类的大脑，以及 AI 的上下文窗口，都是极其不靠谱的存储介质。你今天觉得不重要的细节，三个月后可能就是解开某个 bug 的关键线索。所以 mono 采取了一种近乎偏执的囤积策略——全都给我存下来！而且是用最朴素的 markdown 格式，存成纯文本文件，没有数据库，没有复杂的 schema，就是一堆扁平化的文件躺在 memory 文件夹里。
这种设计看起来简单粗暴，实则蕴含深意。markdown 是人类可读的最小公分母，五十年后的程序员依然能打开这些文件看懂内容。扁平结构避免了过早的分类焦虑，你不用纠结这个知识点应该放在哪个子文件夹的哪个子目录里，直接扔进去就行。配合 wiki 链接语法 [[like this]]，文件之间又能自然地建立关联，形成一个有机的知识网络。更妙的是整个系统搭在 Git 之上，这意味着你不仅有当前状态的快照，还有完整的历史时间线。删掉的文件可以找回，修改的记录可以追溯，甚至你能看到三个月前的自己是怎么一步步掉进某个坑里的。
项目管理的俄罗斯套娃结构
mono 的物理结构就像一套俄罗斯套娃。最外层是 mono 本身，它包含自己的 memory 文件夹和 .claude/commands 文件夹。里面藏着一个 repo 文件夹，这里才是你真正的项目栖身之所。project-a、project-b、project-c 各自安家，每个子项目又有自己独立的 .claude 配置和 memory 记忆库。这种设计解决了一个痛点：当你有十几个项目同时推进时，怎么让 Claude 知道你现在想聊的是哪个？
答案是一系列斜杠命令。/change-project 让你在不同项目间瞬移，/default-project 设置默认主场，/detect-project 甚至能自动检测当前该搞哪个项目。当你切换项目时，mono 会自动处理一系列脏活：切到对应的功能分支、把 memory 文件夹的上下文切换到当前项目、准备好相关的指令集。你在 mono 的框架里发号施令，Claude 在子项目的代码库里埋头苦干，Git 在后台默默记录每一次变更。这种分层架构让你既能享受单一代码库的简单，又能管理多个项目的复杂性。
时间戳命名的记忆考古学
走进任何一个 mono 项目的 memory 文件夹，你会看到一堆带着奇怪前缀的文件：2026-01-24-0430-architecture.md、2026-01-23-2100-bug.md、2026-01-22-1500-reflect.md。这种 yyyy-mm-dd-hhmm 的时间戳命名法不是强迫症发作，而是一种面向时间旅行的设计。当你想回顾"上周三下午我们讨论过什么"时，文件名本身就是最直观的索引。
mono 定义了一整套文件类型，每种都有特定的前缀语义。architecture 是代码架构的快照，记录当前项目的技术版图；bug 是 bug 报告，.capture 那些让人抓狂的错误；codereview 是带优先级的代码审查报告，告诉你哪些债务该还了；consistency 像是一个尽职的审计员，检查未关闭的待办、不一致的内容；drift 则盯着文档和代码的背离，防止"文档写着要做 A，代码却做了 B"的 classic 悲剧；goal 记录问题和偏好（虽然开发者承认这名字起得不好，应该叫 problem）；next 收集下一步可以做的事；plan 是复杂变更的实施蓝图；proposal 是动手前的方案建议；reflect 是从反思中提取的教训；research 是网络搜索或本地检索的结果；session 是聊天记录导出；spec 是技术规格；todo 和 solved 则是待办和已完成的 dance。
还有一类不带日期的文件，用于存放更持久的知识：c 代表概念性的主张，用散文体记录；idea 是灵感和头脑风暴；learning 是从反思中升华的洞察；meta 是系统和工作流本身的配置；moc 是内容地图，尝试建立层次化的索引（虽然开发者说这块还没深挖）；problem 是识别出的问题；question 是要探索的疑问。这套分类法不是死板的规则，而是经过实战检验的最佳实践。你可以完全无视它，也可以根据自己的需要扩展新的类型。
二十三个斜杠命令组成的瑞士军刀
mono 的真正威力体现在它的斜杠命令系统里。这些命令不是简单的文本替换，而是编排复杂工作流的脚本。它们可以分为六大类，总共二十三个命令，每一个都解决一个具体的痛点。
在冲刺和规划工作流这一类，/sprint-start 是一个大招，它会自动串联起目标设定、方案探索、规格定义、计划制定这一整套流程，像流水线一样帮你把模糊的想法变成可执行的蓝图。/goal 捕获问题、期望结果和偏好；/proposal 探索各种解决路径和决策点；/spec 定义需求、约束和开放问题；/plan-continue 让你能随时回到之前未完成的计划继续推进。
分析和快照类命令是项目的体检仪。/reflect 分析文件，提取教训、任务和不一致之处；/consistency 检查项目结构的违规和冲突；/drift 检测文档意图和当前状态的 divergence；/architecture 创建代码库结构的快照；/code-review 进行带严重等级评定的代码质量分析；/next 收集、存储并展示接下来该做什么。这些命令本质上是在回答"我们现在在哪"和"我们偏离了多远"这两个灵魂问题。
知识和研究类命令扩展了 Claude 的信息 gathering 能力。/research 通过网络搜索或本地资源研究并记录主题；/todo 快速从输入或文件中提取创建待办文件。子项目管理类命令 /detect-project、/change-project、/default-project 前面已经提过，它们是多项目管理的导航仪。
导出和转换类命令解决了"对话结束后的知识沉淀"问题。/done 结束会话并导出记录，还能提议合并；/tomd 把对话导出为 markdown；/toscript 把代码块导出为脚本文件（虽然开发者标注了未测试）；/toclaude 提取教训更新到 CLAUDE.md 等配置文件；/tomanim 甚至能把 markdown 转换成 manim 动画视频（work in progress）。最后一个命令特别 wild，它意味着 mono 不仅管理代码，还开始涉足内容创作的工作流。
工具类命令处理各种杂务：/process 处理文件内的提示块；/human-sort 重新组织 human.md 的章节而不修改内容；/showrules 切换是否在每次响应前引用规则（虽然开发者说这个调试工具目前坏了）；/toskill 从对话中创建新技能。这套命令系统的野心很明显：把重复性的工作流决策交给自动化，让人类专注于真正需要创造力的部分。
一个典型的工作会话长什么样
让我们走进一个真实的使用场景。你打开 VSCode，进入 mono 文件夹，Claude 自动加载 INIT.md 和 .PROJECT 文件。如果没有默认项目，Claude 会问："要不要为检测到的项目收集上下文？"这就像是每天早上助理给你递上今天的日程表和背景资料。
你输入 /consistency，Claude 开始执行一套编排好的舞蹈：先检查当前 Git 分支，如果在 main 分支上就创建一个 task/consistency-report 功能分支。然后扫描 memory 目录，分析所有文件，生成一份包含 12 个问题的报告，保存为 memory/consistency-2026-01-24-0430-12-issues-found.md，并自动提交。整个过程你不需要敲一个 git 命令，不需要想该用什么提交信息，mono 全包了。
报告生成后，Claude 告诉你发现了 12 处不一致，横跨 72 个文件，然后问你想要处理哪些。你说"2.1 和 3"，Claude 立即修复这些问题，再次提交，更新报告，加入 wiki 链接指向修复结果。最后问你要不要合并到 main 分支。你说 /done，Claude 把整段对话导出为 memory/session-2026-01-24-0440-consistency-report-and-fixes.md，提交，合并到 main，会话干净利落地结束。
这个流程的优雅之处在于状态的完全透明。任何时候你都能清楚地知道：现在在哪个分支、有哪些提交、改了什么文件、解决了什么问题。所有的决策点和执行步骤都被记录在案，三个月后回看这份 session 文件，你能完整复现当时的思考过程。这就是 mono 承诺的"知识捕获"——不是捕获代码，而是捕获决策的脉络。
自举开发的元循环
mono 项目最迷人的地方在于它的诞生方式。
开发者 ltOgt 在 disclaimer 里轻描淡写地说："mono 是在几天内有机地开发出来的，用的就是 mono 本身。"这句话背后是一个美丽的元循环：用 Claude Code 开发一个帮助 Claude Code 更好地工作的工具，然后用这个工具来改进自己。 repo 里几乎所有的文档都是 Claude 用 mono 写的，这意味着这个系统不仅是一个工具，还是它自己的第一个用户和测试者。
这种自举式开发带来了一个独特的优势：mono 解决的是真实的、开发者自己每天面对的痛点。每一个斜杠命令、每一种文件类型、每一个工作流程都经过了实战的磨练。不是那种坐在象牙塔里想象出来的"最佳实践"，而是凌晨三点调试代码时真切感受到的 friction 的解药。开发者坦承子项目集成和本地 Claude 规则冲突解决还不够完美，还在大量实验中，但这反而增加了项目的真实感和可信度——这是一个活着的、还在进化的系统，不是一份僵死的规范文档。
扁平文件与 wiki 链接的极简美学
在技术实现上，mono 选择了一条少有人走的路：拒绝数据库，拒绝复杂的层级结构，就是简单的 markdown 文件加 wiki 链接。
这种极简主义有深刻的实用考量。
首先，markdown 是程序员最熟悉的格式，不需要学习成本。
其次，扁平结构消除了"我该把这个文件放在哪里"的决策疲劳，所有文件平铺在 memory 文件夹里，找东西用文件名搜索，关联内容用 [[wiki links]]。
这种设计借鉴了 Obsidian、Roam Research 等现代笔记工具的理念，但把它嵌入到了编程工作流中。
wiki 链接的语法很简单：双方括号包裹文件名 [[like this]]。mono 会自动处理这些链接，让你在浏览一个文件时能跳转到相关的上下文。配合时间戳命名，你能轻松地建立"这个问题在三个月前的架构讨论中有伏笔"这样的跨时间关联。开发者提到还需要更多地利用 MOC（Maps of Content，内容地图）来建立层次化的索引，这说明这个系统还有很大的进化空间，目前的扁平结构是刻意为之的简单起点，而非终点。
Git 作为时间机器的集成
mono 对 Git 的集成不是简单的版本控制，而是把工作流完全建立在 Git 的分支模型之上。每次执行一个命令，mono 会自动检查当前分支，如果在 main 上就会创建功能分支，操作完成后自动提交，最后还能自动合并。这种设计把 Git 从"备份工具"升级成了"工作流引擎"。
开发者特别提醒用户先用玩具项目测试，因为 mono 会自动操作 Git。这种警告背后是对自动化力量的敬畏。一旦你把 Git 操作交给脚本，就意味着要信任它的决策逻辑：什么时候切分支、提交信息写什么、什么时候合并、冲突了怎么办。mono 目前的实现是每次操作一个提交，保持粒度的精细，但开发者承认在子项目集成和规则冲突解决上还有改进空间。这种坦诚的态度反而让人更放心——开发者知道系统的边界在哪里。
从个人工具到通用框架的野心
虽然 mono 起源于个人需求，但它的设计明显有着更大的野心。二十三个斜杠命令构成的命令体系、标准化的文件命名约定、可扩展的技能创建机制（/toskill），这些都在暗示这是一个可以生长、可以定制的框架。开发者鼓励用户用 /research 命令研究 mono 本身，然后用 mono 来修改 mono，这种递归的自我改进理念是开源精神的最佳体现。
在 Future 部分，开发者提到要用 /research 探索 @arscontexta 发现的关于自我指涉的 mindblowing 内容。这个神秘的引用暗示了 mono 的进化方向：不仅仅是存储记忆，而是让 AI 能够反思、学习、甚至重新设计自己的工作方式。从"外部化记忆"到"自我改进的元认知"，mono 似乎正在走向一个更激进的愿景：一个不仅能帮你写代码，还能帮你思考如何写代码的伙伴。
使用门槛与入场建议
mono 不是那种开箱即用的工具，它要求你改变工作方式，接受一套新的约定。开发者建议先用副本仓库测试，熟悉工作流后再上真家伙，或者干脆从新的玩具项目开始。这种建议很实在，因为 mono 确实会改变你和 Claude Code 的互动模式。你不再是在一个孤立的对话窗口里工作，而是在一个持续积累的知识库里协作。
要开始使用 mono，你需要把它克隆到本地，把你的项目放进 repo 子文件夹，然后在 VSCode 里从 mono 根目录打开工作区。之后就是通过 /change-project 或 /default-project 来切换上下文。这个过程需要一点 setup，但一旦跑起来，你就会体验到那种"Claude 居然记得三个月前那个决定"的魔法时刻。对于那些管理多个项目、厌倦了每次都要重新解释上下文的开发者来说，这个初始投入绝对值得。
情感爆点：当 AI 真正记住你的时候
想象一下这个场景：六个月后，你重新打开一个已经搁置的项目，心里忐忑不安，因为连你自己都忘了当时为什么要那样设计。
你输入 /architecture，Claude 瞬间调出最新的架构快照，附带一系列 wiki 链接指向相关的设计决策、踩过的坑、和当时的权衡考虑。你看着屏幕，突然感到一种被理解的温暖——这个 AI 搭档不仅记得代码，还记得你的思考过程。
这就是 mono 带来的情感价值。在这个信息过载的时代，我们每天都在产生大量的数字碎片，却很少有系统能帮我们把这些碎片编织成连贯的故事。mono 做的不仅是技术层面的上下文管理，它在创造一种连续性，一种跨越时间对话的可能。当你看到 /reflect 命令从过去的代码中提取出你自己都没意识到的模式时，当你用 /drift 发现文档和代码的背离避免了未来的灾难时，当你用 /next 清晰地看到前进的方向时，那种掌控感和 clarity 是无价的。
更深层地说，mono 代表了人机协作的一种新范式。它不再把 AI 当作一个随用随弃的工具，而是作为一个有记忆、能积累、会成长的伙伴。每一次对话都在丰富这个共享的知识库，每一次提交都在构建你们共同的数字记忆。这种关系的建立需要时间，需要信任，需要共同经历的积累，但一旦建立，它就会成为你编程生涯中最宝贵的资产之一。
mono 给 Claude Code 装上外置大脑让 AI 记住你们聊过的每一个深夜让代码项目拥有永恒记忆