★ FEATURED ARTICLE 如果你同时用好几款终端型AI编码工具大概都遇到过同一种尴尬上午叮嘱某个工具“这个项目里禁止用单引号”下午换另一个工具时它又规规矩矩把单引号写满整个文件。不是你记性差也不是模型变笨了而是大部分 AI 编码工具天然不知道你的个人偏好你随口说过的话只会留在那一次会话里。要让它们长期记住你的口味就得靠用户级别的记忆文件。所谓用户级记忆文件就是放在用户目录下、每次启动都会自动加载的那一坨 Markdown 或规则配置。相比项目里的记忆文件它不限定在某个仓库内生效而是贯穿你所有项目专门记录你个人的编码习惯、常用技术栈、输出风格和安全边界。Claude Code、OpenCode 这类工具虽然界面和主打方向不一样但都支持这种全局记忆机制只是文件名、放置路径和优先级细节各不相同。这篇文章不打算在纸上谈兵就直接把我自己折腾这套用户级记忆文件的内容、踩过的坑以及维护流程全盘托出你拿过去就能照着抄。1. 用户级记忆文件到底放在哪里不同工具的加载逻辑又差在哪1.1 Claude Code 的路径和记忆层级Claude Code 对记忆文件的划分比较清晰分成了用户级、项目级和子目录级三层。用户级的那份通常放在~/.claude/CLAUDE.md只要这个文件存在每次新开会话它就会被自动读进上下文像是给你所有的项目提前铺了一层“个人底色”。项目级的放在仓库根目录的CLAUDE.md子目录级则放在对应子目录里。加载时的合并逻辑很直白用户级内容作为最基础的全局上下文项目级内容只在进入那个项目时叠加子目录再进一步细化。这种层级设计有个天然好处你可以放心把“永远不变”的东西写到用户级把“只有这个项目需要”的写到项目级两边互不污染。不过需要注意用户级、项目级、子目录级并不是简单的“后加载覆盖前加载”而是全部拼接在一起进入上下文。意味着如果三处对同一件事的表述不一致模型会同时看到互相打架的指示最终很可能选择其中某一条或者干脆两边都不完全执行。所以我在实际使用里用户级文件只写那些确定无疑的个人约定项目级只覆盖与该仓库强相关的约定能不去重复就尽量不重复。1.2 OpenCode 的全局规则模式OpenCode 的用户级记忆机制看起来不像 Claude Code 那样有一份直观的 Markdown 文件而是把配置放在了全局配置文件里。常见路径是~/.config/opencode/下的一系列配置里面可以声明全局规则、默认模型、按键映射以及每次按住对话时都要塞给模型的个人偏好设定。如果你是从 Claude Code 转过来的不要急着找一个同名CLAUDE.mdOpenCode 不认这个文件名至少不会自动读它。它更习惯你通过在全局配置文件里的rules或instructions之类的字段把个人偏好写成数组或文本块加载顺序通常也是在项目配置之前。部分版本也兼容AGENTS.md这种跨工具规范但我建议不要赌这个以你当前版本的实际参数为准。这里要说一句实在话不同工具对全局文件的读取机制并不完全一致甚至同一个工具的不同版本都有差异。我见过的做法是在全局配置里尽量用“纯文本规则”不要依赖某个工具特有的结构化字段这样将来迁到别的终端工具时损失最小。1.3 记忆文件加载优先级别让它们互相打架搞清楚优先级是为了知道冲突发生时该信哪个。以我实际观察到的通用逻辑来说大多数工具的加载顺序是用户级全局文件先读入项目级文件叠加在它后面子目录级再叠加。越具体、越靠后的声明越容易压过前面的同主题内容。但这里有个反直觉的点优先级并不等于“后者完全替代前者”。模型读进上下文后是在所有提示词里自行权衡而不是做一个简单的字符串覆盖。你如果在用户级写“始终使用双引号”在项目级又写了“本项目必须使用单引号”那模型可能在某段代码里用双引号在另一段里用单引号看它的理解状态而定。这种不稳定比“完全没记忆”更让人头疼。所以我个人给优先级排序定了一条铁律用户级只写与项目无关、不可能需要单独推翻的习惯项目级负责推翻或补充用户级的通用约定子目录级再去处理更局部的情况。三层之间不要出现方向相反的表述只允许“项目级在用户级基础上做减法或加法”。这句话建议你用笔抄下来因为后面绝大多数记忆失效问题都出在层级冲突上。2. 该写什么不该写什么我的用户级记忆文件四层清单2.1 第一层个人编码风格与审美用户级记忆文件最值得放的内容就是那些你跨项目都不变的口味。例如变量命名偏好、缩进风格、是否偏好早期返回、注释该用中文还是英文、函数长度要不要控制、喜欢用类还是函数式等等。这些东西写进项目级的话每个项目都要复制一遍纯属浪费写进用户级以后所有项目第一次交流就知道你的口味。举个例子我在用户级文件里明确写过“默认使用 TypeScript类型推导足够时不要手工堆砌多余类型标注”“缩进使用两空格”“组件文件命名用 PascalCase普通工具函数用 camelCase”。这些话看起来特别基础但平时你不主动告诉模型它就会按训练数据里的主流习惯来未必是你喜欢的风格。写清楚之后至少我自己在不同项目里的代码观感统一多了不用每次都在 prompt 里临时加一句“注意一下命名风格”。还有一类很容易漏的是文档和提交信息的风格。比如我习惯在 commit message 里用 conventional commits 前缀还喜欢在代码注释里写“为什么这样实现”而不是“这段代码做了什么”。这些都不是模型天然会想的事属于典型的用户级记忆内容。如果你不写它给你生成的 PR 描述和注释就会非常“学术腔”看着是那么回事其实一句有用的都没说。2.2 第二层跨项目的技术栈与目录习惯如果你长期只折腾一两种技术栈那就把常用的依赖管理方式、目录结构偏好、测试框架选择都写进用户级记忆文件。比如“新项目优先考虑 pnpm”“单仓库结构下 packages 下按领域划分”“测试统一放tests目录测试文件用 describe/it 组织”等。这些信息能让模型在你让它初始化新项目时直接产出你熟悉的结构而不是生成一套标准脚手架再靠你手工调整。但这里有个度要把握好只记录那种“你希望所有项目都默认这样”的偏好不要记录某个具体项目才有的目录布局。比如你某电商项目里约定src/modules/order下放订单模块这是项目级的事放进用户级文档会污染别的项目。道理很简单全局记忆是为了减少上下文噪音不是让你把整个工作经历都倒进去。以我自己的记忆文件为例目录结构部分只会写“工具库代码放 src/lib页面代码放 src/pages可复用 UI 组件放 src/components”剩下那些具体业务的路径规划全留在项目文件里。这样无论打开哪个新仓库模型都能有个大概的骨架认知但又不会拿某个旧项目的细节去硬套新项目。2.3 第三层输出格式与沟通习惯不少终端型 AI 工具不只是帮你写代码还会承担解释报错、整理方案、生成周报之类的杂活。如果用户级记忆文件里写明了你喜欢的沟通方式和输出格式使用体验会明显提升。比如我喜欢让工具先给出结论再展开分析不要一上来就是一大段背景铺垫遇到危险操作时希望它先说明影响范围再问是否继续给出代码建议时尽量展示 diff而不是整块整块地复制。这些看起来很小但正是决定工具“像不像你的搭档”的关键。有人可能会问这些偏好不是每次在 prompt 里说一句就行了吗何必占用记忆文件问题是你换新项目、开新会话的时候prompt 里那一次性的约定根本传不过去。用户的记忆文件能持续存在它才是塑造模型对你这个人认知的长效手段。我在实际工作中还会把“语言习惯”也写进去明确要求中文回答、技术术语保留英文原文。很多朋友会忽略这一点结果模型一看用户级文件是英文写的就开始全程英文输出沟通效率大打折扣。别指望模型自动判断你的语言偏好直接写进记忆里最稳。2.4 第四层安全边界与行为红线记忆文件不仅是“告诉它你喜欢什么”也是“告诉它你不喜欢什么”。如果你不想让 AI 工具未经确认就执行某些高风险操作比如删除文件、强制推送、改写锁文件、修改全局配置那就把这些边界写进用户级记忆文件。对于重复出现的危险动作这比每一次都在 prompt 里反复强调要可靠得多。我会写的内容包括“批量删除或重命名文件前必须列出清单并等待确认”“不要主动修改依赖锁文件除非我明确提到”“涉及密钥或敏感信息的输出要打码处理”“不要在默认分支上执行强制推送命令”。这些内容不涉及某个项目的特定细节属于通用安全习惯所以放用户级非常合适。另外一个容易被忽略的安全项是“不要假设我没有看过某些文件”。模型有时候会自作主张修改一个看起来“明显有问题”的配置但那个配置可能正是你故意的。我在用户级写了一句“在修改已有配置之前先说明你打算改哪里、为什么改等我对齐再动手”就是把主动权拉回到自己手里。这是一种比较简单的交互约束但它确实省掉了我很多次被迫 review 的烦恼。2.5 答案雷区哪些内容千万别写进用户级与内容清单同样重要的是反向的“不要写”清单。第一类不要写的是临时状态比如“本周我在调试某个支付回调”“昨天发现某个依赖出现兼容问题”。这类信息只对当前时间点有效下周一打开工具时早就过期了放在记忆文件里只会污染上下文让模型以为这些事仍然存在。第二类是项目特定的绝对路径。有些朋友图方便在用户级文件里写死了一堆/home/某用户/workspace/某某项目/src一旦换机器或者换了目录结构这些路径就成了废铜烂铁。如果确实要记项目路径请放进项目级记忆文件至少路径跟着项目走。第三类是情绪化、模糊的要求比如“写代码要认真一点”“永远不要写烂代码”。这类话模型没法落地读了也只会让上下文更杂。真正有效的是可验证、可执行的规则比如“代码里不要出现 console.log 的调试残留”“所有对外接口都要写 JSDoc”。规则越具体模型越容易执行。3. 记忆文件让我脱轨的三个隐形坑冲突、膨胀与太精确3.1 冲突规则引发的“随机执行”你以为记忆文件写一次就能一劳永逸实际根本不是。我踩过的第一个大坑就是冲突规则。有一次我在用户级文件里写了“统一使用 pnpm 作为包管理器”但某个项目级文件里又留了一句“这个项目比较老继续用 npm”。结果模型在同一段对话里一会儿用 pnpm 装依赖一会儿又提示我用 npm 跑脚本全程靠猜。排查了半天才发现模型不是不理解规则而是它同时看到了两条指向不同工具的规则它每次可以从中任选一个作为输出依据。这里你没法指望它像人类一样自动判断“旧的用 npm新的用 pnpm”因为你压根没告诉它按什么维度切换。经过这次教训我给自己定了两个习惯。一是所有互相冲突的规则必须在其中一侧声明“我覆盖另一条”明确句式比如“该项目内以本项目级文件为准忽略用户级对包管理器的一般偏好”。二是一旦发现某次输出行为诡异第一反应不要怪模型先去全文搜索记忆文件中是否存在同一主题的多处表述往往一查一个准。3.2 上下文膨胀内容越多反而越不敏感记忆文件不是越大越好。我见过有人把用户级文件写成了三千多字的个人百科全书里面连“我家里养了一只猫不要在回答里提到猫”这种内容都有。问题在于模型的注意力分配是有偏好的太长的全局记忆会让后面的项目级指令相对权重变低。也就是说你塞了大量噪音进去真正重要的规则反而容易被淹没。这就像一个饭桌上所有人同时讲话声音最大的内容不一定是你最想听的那句而是你耳朵对那个频率敏感的。模型也一样它的输出通常更重视靠近当前任务的那部分信息。如果你的用户级记忆文件里塞了五百行无关紧要的内容那一句“不要修改锁文件”的真实存在感就被稀释了。我的做法是用户级文件控制在 100 到 150 行之间每一条都要能回答“这条内容在未来三个月内还会不会影响我”。如果一个规则只在某几天内有效就让它待在当天的 prompt 里而不是污染长期记忆。定期清理和重写记忆文件和梳理自己的代码一样重要。3.3 太精确的目标值反而让模型失去判断力写记忆文件时我们往往会倾向于越精确越好。但实际上有些精确是没有必要的甚至有害。比如我以前写过“所有函数行数不得超过 30 行”结果模型为了硬凑这个数字把一段 28 行的逻辑拆成两个半吊子函数可读性反而更差。后来我改成“函数应保持短小和职责单一超过 30 行时先考虑拆分”语气变软了行为反而更贴合我的真实意图。另一个例子是语言偏好。如果你写“代码注释里最多只能出现 20 个汉字”这会让模型陷入机械计数的状态而不是真正理解注释该写什么内容。“优先使用中文注释若必须保留英文术语则给出简短中文说明”这种表达显然更有可操作性。所以写规则时要想清楚你是想要一个可验证的形式指标还是想要一个可执行的意图。如果是前者精确数字没毛病如果是后者给模型留一点判断余地会更可靠。这也是我反复调整很多轮才领悟到的一点。4. 从 Claude Code 到 OpenCode全局记忆的迁移与适配4.1 迁移时先分清“文本规则”和“结构化配置”在 Claude Code 上写习惯以后迁移到 OpenCode 并不是直接把文件复制过去就行。Claude Code 最典型的是纯 Markdown 记忆文件里面用自然语言写规则。而 OpenCode 这类工具通常同时支持全局配置文件和规则文件它可能要求你以 JSON 或 YAML 格式把规则分字段写清楚。这时候不要无脑把所有 Markdown 原文塞进某个字段否则行内格式容易乱也会影响模型读取。我的迁移做法分成三步。第一步先梳理原有 Markdown 记忆文件里的每一条规则按“风格偏好、工作流、安全边界、输出格式”归类。第二步将每一类填到目标工具的全局规则配置里能对应哪个字段就用哪个字段没有对应字段的再用自由文本段承载。第三步跑一个最简单的测试项目故意让模型做一件违反某条规则的事看它有没有真的记住。OpenCode 还有一个特点就是它的全局配置通常负责的是工具行为和模型参数而不是纯记忆内容。换句话说你想让它“记住命令别名”和你想让它“每次用某种方式展示 diff”这在 OpenCode 里可能是两套不同的配置项。不要指望一条全局文本规则能解决所有细节最好花点时间把配置文档里的字段翻一遍。4.2 不同终端工具的上下文窗口差异决定了记忆文件写法不同工具给用户级记忆文件分配的上下文窗口大小是不一样的。Claude Code 会把CLAUDE.md几乎是稳定地放进主上下文而其他某些工具可能只在发起请求时才注入全局记忆这就导致全局内容的长度限制更严。如果一份用户级记忆文件有一千行在一个工具里可能还能勉强运行在另一个工具里可能直接挤占任务上下文的配额造成核心逻辑处理能力下降。这也是我不建议任何规则都堆进全局记忆的另一个原因。迁移到 OpenCode 时我明显感觉它对长全局文本更敏感宁可把每条规则写得更紧凑也不要靠大量说明性文字来增加负担。同样一条“优先使用 pnpm”写在 Claude Code 里可以是一句话写在 OpenCode 里最好提炼成“包管理器: pnpm”这类更短的形式让它在全局配置里占的空间更少。如果你有多个工具并行使用建议以“最小公倍数”的方式来维护记忆内容。也就是只保留所有工具都能理解和执行的通用规则那些只有某个工具才支持的专有语法尽量移出用户级记忆文件放进该工具对应的项目配置里。这样维护成本会低很多。4.3 项目级文件如何适配所有工具如果你会在多个工具之间切换同一个项目那项目级记忆文件的写法就需要比用户级更克制。项目级里写的东西如果带上了某个工具特有的语法另一个工具就不会读取或者读到了也无法解析。我的经验是项目级记忆尽量采用纯 Markdown 或通用规范比如考虑用AGENTS.md这种跨工具约定再去各个工具里配置让它读取该文件。还有一点容易被忽略项目级文件往往会引用用户级规则。如果你在项目里写了“按我的全局风格来”但用户级在不同工具里内容不一致那就等于把一个不稳定变量引入了项目。所以我更倾向于在项目级文件里直接写明项目需要的具体规则不到万不得已不引用全局内容。哪怕稍微多写几个字换来的是行为一致性。5. 把记忆文件当活档案管理我的迭代与验证工作流5.1 每次会话结束后花两分钟更新记忆用户级记忆文件不是写一次就躺在那里睡觉的它应该像项目里的 README 一样随着你的认知变化而更新。我以前犯过毛病一遇到模型反复做错某件事只会当场在 prompt 里纠正等下一次会话又全部归零。后来改成每次这种“归零”体验出现就立刻把那条规则补进用户级文件。具体操作不难。准备一个固定的复盘路径当一条纠正信息出现两次以上就把它转化成通用规则写入记忆当一条规则连续两周没有实际发挥作用就考虑删除或改写当新增规则与旧规则有交叉关联就检查二者是否冲突。这套流程听起来像维护文档其实本质上是维护你的数字化工作习惯。这里我会给所有规则加一个简单的“适用范围”备注比如“适用于所有项目”“仅适用于不涉及外部数据库的普通 Node 服务”。这样下次迁移到新工具、或者新项目打开时模型也能更准确地理解哪条规则该被激活。5.2 怎么验证记忆真的被读到了光写完不验证等于白写。验证用户级记忆是否生效有一个最简单的方法开一个新会话问工具“在你当前的系统上下文里我有哪些全局编码偏好”它如果回答得出来说明记忆文件被正常加载如果它只会说一些通用套话那你就要检查放置路径和配置文件格式了。再进一步我会在工作流里故意制造一个“偏好探测题”。比如我有一条规则是“默认使用中文注释”就会让它在没有任何额外 prompt 的情况下生成一小段函数看注释语言是否自动变成中文。这个方法很土但非常有效能直接暴露加载失败、优先级冲突、文本被截断三种问题。还有一种比较隐蔽的验证方法同时开两个不同工具的会话问同一个关于用户级记忆文件里的偏好问题对比二者回答的差异。如果差异明显基本可以断定是工具之间读取机制不同而不是记忆内容本身有错。这时候再逐项核对配置通常能找到问题。5.3 记忆文件失效后的降级策略即便写好了用户级记忆文件某些极端情况下它也会莫名其妙失效工具升级改了路径、配置文件格式做出调整、或者你把新增规则写在了文件末尾但模型上下文被其他内容占据等等。遇到这种场景不要慌先做三件事第一确认文件路径没有被环境变量或工作目录变化影响第二把记忆文件裁剪到最小可测试状态确认加载机制本身正常第三再逐步加回规则看看是否是某条特殊规则触发了解析异常。我自己的经验是有大概三分之一的问题出在“文件没被读到”另有三分之一出在“规则之间互相冲突”剩下三分之一是“工具版本更新后原来的字段不生效了”。排查的时候千万别一条路走到黑。比如我曾在 OpenCode 上遇到全局规则怎么改都不生效最后发现是全局配置文件里写错了字段层级导致一整段规则都没有被当作规则解析。这时你就算把文本写得天花乱坠也没用。最后再分享一个维护小技巧给用户级记忆文件建立版本历史不用太复杂就用 Git 记录每次改动。每次更新后跑一轮测试如果行为变差了可以用git diff回退到上一个可用版本快速定位是哪一条新规则惹的祸。这样既保留了迭代空间也不会把记忆文件越调越乱。
阅读完成 · 觉得有帮助？
