先说结论如果你长期用 AI 编码代理做大任务早晚会在某个下午亲眼看到它“失忆”。我经历过三次第一次是在一个推进到第三周的跨平台重构项目里会话已经长到滚动条都懒得动了。然后工具弹出一句“上下文窗口接近上限即将执行压缩”下一秒它就开始了那种熟悉但又让人心里发毛的退化——忘了我们本周初敲定的命名规范开始引用三天前就废弃的目录结构甚至反过来跟我确认一些两周前就拍板的兼容层去留问题。那一刻我觉得它像电影《记忆碎片》里的主角短期记忆每过十分钟就重置一次而外部世界以为他还记得。这个事故有一个很形象的名字也就是你们在讨论里常说的“20 万 token 脑叶切除术”。20 万 token 的上下文窗口听起来不少实际换算成中文大概十几万字用来盖一个小型项目的聊天记录绰绰有余但架不住长会话里塞满了方案讨论、错误来回、临时修改和粘贴进去的大段代码。一旦触顶工具会开始有损压缩最旧的内容用三句话概括掉原本两千行对话里沉淀的全部决策。AI 不是变蠢了是它的“工作记忆”被人为拿掉了而它自己甚至不知道。我后面花了很长时间找解法最后真正救了我的是两个听起来跟编程毫无关系的灵感Unix 的 init.d 启动机制和诺兰那部《记忆碎片》构建的外部记忆系统。思路收拢成一句话把 AI 编码代理当成一个每十分钟失忆一次的人来设计工作流——所有关键信息都必须“纹”在磁盘文件里每次新会话启动时像开机自启脚本一样重新读一遍。做完这套改造之后我最直观的感受是上下文压缩从“灾难事故”变成了“无感事件”它压它的我这边该干嘛干嘛。下面把整套思路、踩过的坑和可以直接抄走的配置都写出来。1. 先搞清楚“脑叶切除”是怎么发生的20 万 token 的容量陷阱1.1 上下文窗口不是记忆是“工作台”很多人在用 AI 编码代理时会下意识把“上下文窗口”理解成 AI 的长期记忆这是最大的误区。上下文窗口更像一张物理工作台台面上能摊开多少图纸取决于桌子多大。你摊开得越多后续每一次推理能“看到”的内容就越多但桌子的面积是固定的。现代大模型用的是注意力机制理论上窗口开多大就能看多广但工程实现往往没那么浪漫超过一定长度后精度会下降成本会爆炸所以工具层面必须做取舍。20 万 token 的窗口大概是什么概念如果你的项目有 20 到 30 个核心文件把它们全部塞进去且不做精简光代码就能吃掉一大半。剩下的空间要放用户对话、AI 的中间推理、临时生成的计划、以及那些“错了再试”的纠错记录。一个协作密度很高的半天对话内容就能轻松超过 10 万 token。所以你会发现一个残酷的规律任务越正经、协作越深入越大概率在关键时刻触顶。这种时候你会收到压缩通知或者干脆毫无征兆AI 说着说着就开始“不认人”了。我用一个词形容这种状态工作台被强制清空而清空后 AI 不会像人类那样去记忆里翻找它只记得权重参数里的“世界常识”完全忘了你们这个项目独有的临时约定。1.2 压缩那一刻到底发生了什么1.2 压缩那一刻到底发生了什么不同的工具压缩策略不完全一样但大体逃不出三种手段第一种是滑动窗口直接把最旧的一批消息从上下文中剔除第二种是摘要替换用一个自动生成的话题列表替代原始对话第三种是混合策略先给旧内容打重要性分分数低的先被“回收”。这三种方式对 AI 的影响程度各不相同。滑动窗口最粗暴旧讨论不是被总结而是直接消失AI 的记忆断片感最强摘要替换稍好一点但摘要本身是有损的一个“关于适配层去留的讨论结论”能被概括成一行字那一行字丢了细节AI 就只能靠猜混合策略的伤害最隐蔽压缩后 AI 表现得还很自信张口闭口都在用“我记得约定过……”但你顺着它的话去核对会发现它记的版本跟现实有偏差这就是在错误摘要上进行的“自信发挥”。我个人印象最深的一次事故是压缩后 AI 主动给我的代码提了个“优化建议”建议里提到有个适配层文件“看起来冗余”可以清理。问题是那个文件是当天早上刚决定保留的唯一兼容入口理由是旧平台用户还在跑。它当时的态度极其笃定笃定到差点让我产生自我怀疑。后来我翻了对话记录才确认是压缩引发了记忆偏差而不是我真的订了相反的方案。从那时候起我就明白只要还在依赖“对话里的内容”作为关键知识来源就早晚会被这种有损压缩反噬。1.3 为什么说这是“设计好的失忆”如果用工程视角看AI 工具的上下文压缩不算是 bug它是为了在有限算力下维持长会话不得不做的妥协。但在设计上它默认了一个前提会话时间越长旧消息里的信息权重应该越低或者认为摘要足够替代原文。这个前提放在闲聊场景没问题放在编码代理场景就会出事因为编码任务的很多关键约束恰恰隐藏在“旧消息”里——比如你曾明确反对某种写法、某个接口的边界条件、某个决策背后涉及的兼容性考量。所以我把这类压缩称为“设计好的失忆”。它不是为了惩罚你而存在它只是不知道什么对你重要。既然工具不知道那责任就落在你身上你得把那些“重要到不能被压缩掉”的东西搬到不会被压缩的地方去。这个地方不是对话历史而是文件系统。这让我想起了那个经典的分布式系统原则任何可能崩掉的进程都要具备从持久化存储中恢复状态的能力。会话可以被压缩进程可能被杀掉但磁盘上的文件不会凭空消失。把 AI 协作的关键状态推给磁盘就是给工作流装上了一个“断电保护”。2. 向《记忆碎片》偷师外部化记忆的生存法则2.1 这部电影给我们的硬核启示《记忆碎片》里主角 Leonard 患了一种罕见失忆症只能记住约十分钟内的事情。为了延续生活他发展出一套极端的外部记忆系统关键信息写在便签上、拍照存证、甚至把最重要的几条直接纹在身上。他每天早上醒来不靠脑内记忆判断“该做什么”而是靠这些外部物证重建当下的行动依据。你发现没有AI 编码代理在上下文被压缩之后的状态跟 Leonard 一模一样每次请求都是它新生命的开始除了模型权重里的通用知识它唯一的“记忆”来源就是你能摊在它面前的内容。区别是 Leonard 作为人类知道自己在失忆会主动去翻便签而 AI 不知道它只会在每次请求时尽力用“当下能看到的全部信息”来作答。所以你必须替它做好这套外部记忆系统让它每次“醒来”时眼前自动摊着一张写满了“你是谁、项目是什么、哪些约定不能违背”的纹身纸条。2.2 “纹身”级信息的筛选标准外部记忆不是什么都记Leonard 不会在手上纹“我今天吃了午饭”他只会纹那些遗忘后会导致灾难的信息。放到 AI 编码协作里我总结出几条筛选标准符合标准的才值得写进记忆文件第一遗忘代价高。比如接口签名、命名规范、模块边界一旦 AI 忘了并在代码里跑偏重写的成本可能是几小时甚至一天。第二共识类信息。那些你和 AI 已经来回讨论过并且最终拍板的事比如“保留适配层但仅当 legacy 开关开启”这类共识在对话里散落各处压缩后最容易被总结歪。第三反模式列表。AI 反复踩过、你已经纠正过多次的坑比如“不要用某旧函数”“生成代码必须带错误处理”收集成禁用清单比每次重新纠正高效得多。第四过程状态。现在做到哪一步了、下一步是什么、哪些检查已经通过这部分是让 AI 在压缩后能无缝续接任务的关键。凡是满足以上任一条的信息经过提炼后都应该“纹”到文件里那些一次性的闲聊、临时抱怨、灵感碎片就不值得占用宝贵的记忆空间。筛选的本质是在做一次信息降维把几千行混乱对话压缩成几十行高密度约束这件事做得越勤快AI 的“失忆”越不致命。2.3 与 AI 协作的新人设它是“实习生”你是“备忘录狂”建立外部记忆系统之后我最大的心态转变是不再把 AI 当作一个“记性很好的同事”而是把它当作一个“非常勤奋但每十分钟失忆一次的实习生”。你越早接受这个设定工作起来越顺。你永远不会指望一个失忆实习生凭聊天记住你上周吩咐过的事你只会把要求写进文档、贴在他工位上并且每次碰面时提醒他再看一遍。这个心态转变还有个隐藏好处它逼着你把项目里那些“只可意会不可言传”的东西正式化。以前我们依赖对话上下文来维持默契现在你会发现自己被迫把架构决策、编码约定、当前进度、故障历史全部文档化。这些文档不仅 AI 在用你自己和新同事也在用。换句话说这套为“防压缩”构建的记忆体系顺带把项目的知识沉淀做起来了。3. 从 Unix init.d 偷师让每次会话都能“重启恢复”3.1 init.d 到底在做什么它能救我们什么Unix 系统中的 init.d 目录存放着一堆启动脚本系统每次开机时内核完成最底层初始化后会按脚本编号依次拉起网络、文件系统、日志服务、应用进程。这套机制的关键点不是脚本本身写得多华丽而在于两点第一每次开机都会重新执行全套流程绝不依赖上一次运行时残留在内存里的“手感”第二脚本是幂等的重复执行不会造成叠加副作用因为它的目标状态是明确且可重新到达的。把这个哲学迁移到 AI 编码代理场景你会得到一个关键的认知反转不要试图让会话跨越压缩继续存在而是接受每次会话都可能被截断或重置然后让整个工作流具备“全新启动即可恢复全部状态”的能力。就像你不能要求系统内存带数据跨重启但你可以要求硬盘上的配置和数据完好无损。会话是易失内存记忆文件是持久化存储。这个切入点非常实用它甚至消解了我对压缩的恐惧反正每次都能拉起重启压缩就不再是“事故”而是“常规操作”。3.2 把“开机自启”迁移到 AI 工作流init.d 给我们的第二个启示是启动机制的“程序化”。系统不会指望管理员开机后手动敲几十条命令恢复环境它把恢复步骤固化成了可重复执行的脚本。对应到 AI 工作流就是要在每个新会话启动时自动、按顺序、完整地把关键记忆文件装载到 AI 的可见上下文中。我的做法是三层结构。最底层是工具自带的项目指令文件比如 AGENTS.md、CLAUDE.md或者其他同类机制它们的作用相当于 init 进程本身指定“启动后必读的文件顺序”。中间层是一组编号记忆文件按依赖关系排列后加载的文件可以引用前加载文件里的概念这部分相当于 rc*.d 里的各类服务脚本。最上层是会话开局命令也就是你新开一个会话后给 AI 的那第一段话我通常固定成一个简短模板直接提示它“启动流程开始先按顺序读取 .agent-memory/ 下的文件然后向我确认你理解的项目现状与当前任务”。你可能会觉得这套流程每次都重复很繁琐。但正是这种“重复”确保了可恢复性。系统开机不会嫌脚本重复而跳过网络配置AI 会话也一样重复加载记忆不是浪费是会话语义连续性的保险。3.3 幂等性设计同一段上下文反复注入也不出错init.d 脚本还有个隐藏属性幂等性。你把网络脚本跑十遍不会配出十个不同的网络配置因为脚本只会把系统朝同一个目标状态收敛。AI 记忆文件承载的信息也必须满足类似要求不管 AI 在第几次会话读到它得到的解释应该是一致的、无歧义的最好还能经得起与代码现实反复对照。为了让记忆文件具备幂等性我给自己定了几条写作纪律每一条约定都要写清“条件、行为、原因”三要素而不是只写结论涉及代码的约定尽量附带一个文件路径或代码片段示例每条决策记录后标注时间和触发场景避免新会话把旧决策错误套用到新场景。举个例子与其写“不要删除适配层”不如写“适配层路径src/legacy_adapter.rs在配置项 legacyon 时必须保留用于兼容旧平台流量删除前需与用户确认迁移完成度”。后者的描述是自包含、无歧义的无论 AI 在哪个会话哪一轮读到都能得出相同的推理结果。幂等性还有一个实际收益当压缩发生后AI 重新读取记忆文件时它不会因为上下文里残存的半截旧讨论而把文件内容“修正”成另一种理解。文件的措辞足够明确就能作为最高的证据优先级来压制对话历史中那点模糊残留。4. 动手搭一套“上下文免疫系统”目录结构、文件规范与自动加载4.1 记忆库设计.agent-memory 的目录结构理论部分说了那么多现在给可以直接照抄的配置。我在项目根目录下建了一个.agent-memory/目录内部只用编号加短横线命名编号决定了 AI 读取的依赖顺序.agent-memory/ ├── 00-session-brief.md # 本次会话导读、全局状态一句话 ├── 10-architecture.md # 当前架构描述、模块地图 ├── 20-conventions.md # 编码规范、命名约定、禁用清单 ├── 30-decisions.md # 关键决策记录最多保留 5 条收尾后归档 ├── 40-progress-log.md # 按时间追加的进度日志最近五条 ├── 50-current-task.md # 当前任务、当前步骤、阻塞项、下一步 └── 90-glossary.md # 项目黑话与缩写解释文件数量不多但每个文件的职责边界非常清晰。为什么不用一个大文件装全部内容因为 AI 在处理任务时需要“选择性召回”大而全的文件反而会让关键约束淹没在噪音里。按主题拆开后新会话启动时可以全量读一遍平时任务中也可以让 AI 只针对性重读某个文件比如改架构时读10-architecture.md写代码时重点看20-conventions.md。还有一个细节编号留了跳跃00、10、20这样隔开是为了以后在中间插入新文件不至于全面重编号。你在.agent-memory/里加一个15-api-contract.md也不会破坏排序这套命名习惯我直接参考了 rc.d 脚本的 K/S 编号设计。4.2 引导文件的写作规范如果记忆目录是“纹身”那根目录下的AGENTS.md按你用的工具也可能是其他项目指令文件就是把纹身露出来的方法。它的内容决定了 AI 开机后第一件事是背纹身还是逛花园。我的 AGENTS.md 写得非常直接核心段落长这样# 项目指令与启动流程 ## 会话启动必读 每次会话开始严格按照编号顺序读取 .agent-memory/ 目录下的全部 .md 文件。 读取完成后向用户复述以下内容当前任务、关键约束、上一步进度、下一步建议。 若遇到上下文压缩或长会话导致记忆混乱 1. 停止当前推理 2. 重新读取 .agent-memory/00-session-brief.md 与 50-current-task.md 3. 根据记忆文件内容重建你的认知再继续回答。 ## 信息冲突时的裁决规则 如果对话历史中的内容与 .agent-memory/ 中的记录冲突**以记忆文件为准** 并提示用户注意冲突点。记忆文件代表相对正式、可留档的状态。 ## 记忆更新纪律 - 每完成一个子任务更新 40-progress-log.md 与 50-current-task.md - 每做出一个影响架构或接口的决策更新 30-decisions.md - 若发现新的编码约束、禁用模式或项目黑话主动建议更新对应文件。这里有一个踩过的坑要提醒很多工具支持“自动读取项目指令文件”但读取频率并不是每次请求都触发有的只在会话开头生效。所以“压缩后让 AI 重新读记忆文件”这件事不能全依赖工具自动做得写进指令里让 AI 自己知道要去重读。我把那句“若遇到上下文压缩……重新读取”写进去之后实测下来 AI 在对话断片时会有明显的“自我纠偏”动作。4.3 让工具在每次会话启动时自动加载不同 AI 编码工具对“项目级指令文件”的支持各不相同但近两年的主流工具基本都支持某种规则文件。你只需要确认两件事第一这个规则文件放在哪个路径会被自动识别常见的有项目根目录的 AGENTS.md、CLAUDE.md、.cursorrules或特定规则目录第二规则文件里能否引用项目内的其他文件路径让 AI 去主动读取。如果不支持多文件加载也有一个土办法直接在 AGENTS.md 里内联最关键的三条记忆摘要比如当前任务、核心约束、最新决策再标注“完整版在 .agent-memory/ 对应文件中需要时读取”。这样即使工具只能加载一个文件最关键的信息也在口袋里更完整的版本作为备选弹药。顺便提供一个开头提示词模板每次新会话第一句话就发这个请执行启动流程按编号顺序读取 .agent-memory/ 目录下的全部记忆文件 然后用一个清单向我确认你理解的内容——包括当前任务、关键约束、待办进度。 确认完成后等待我的下一条工作指令。实测下来这段固定流程每次大约消耗几千 token相比它在压缩时救下的信息量这点成本微不足道。4.4 会话中的写入纪律什么时候该更新记忆光有读取没有写入系统就是单向的。记忆文件的更新时机直接决定了压缩恢复能恢复到什么程度。我执行的更新纪律可以浓缩成三类触发点第一里程碑触发。每完成一个子任务比如某模块重构通过测试、某个接口联调完成立即更新40-progress-log.md和50-current-task.md。进度日志不需要详细复盘只要写清“完成了什么、验证结果如何、下一个入口在哪”。这条是压缩后“无缝续接”的命脉。第二决策触发。只要你和 AI 就某个方案进行了比较、否决了某个方向、确定了某个取舍就让 AI 在30-decisions.md里追加一条决策记录。决策记录模板我固定用五段式背景、候选方案、结论、原因、影响面。这五段写完即使 AI 以后完全忘了那次讨论也能通过记录还原完整的推理链。第三纠错触发。当你发现 AI 用了旧风格、踩了老坑、或者生成的方式不符合项目预期在你纠正它的同时顺手让它把这一条写进20-conventions.md或90-glossary.md。这条执行得越狠AI 后面犯同类错误的概率越低因为它不用靠“记得”来避开而是每次开工前都会“读到”你不让它做的事。写入纪律的另一个好工具是自定义命令或快捷键。如果你的 AI 工具支持斜杠命令给它定义一个/remember让它自动执行“汇总当前会话中所有应当记录的决策、进度、约束更新到对应记忆文件”我每次用它就是在给项目状态做一次安全快照。5. 实战复盘一次被“脑叶切除”后依然能续上任务的全过程5.1 那个注定会压缩的项目为了让这套方案经得起检验我特意在一个“注定会撑爆上下文”的项目上重新跑了一遍完整流程。项目是一个跨平台的数据迁移系统代号模拟项目X涉及三个代码仓库新旧两套数据模型还有一个必须保留的兼容层。任务复杂度足够高单次会话要处理的代码摘要、错误日志、方案比对加起来15 万 token 轻松打底越到后期越接近 20 万上限。这在改造前就是我噩梦的来源每次压缩都带来一次方向漂移光“要不要动兼容层”这个问题就被 AI 来回翻转了三次。改造前我遭遇的那次事故就是 AI 在压缩后主动建议“清理看起来冗余的适配层”它甚至引用了自己压缩前生成的过时架构图。那一次我被迫花了半小时翻聊天记录最后发现真正决策在很靠前的位置早已经被摘要吞掉了。这也促使我下决心把整个记忆体系搭起来。5.2 压缩前把关键状态完整“纹”下来改造后在预计要触及上下文上限的前一个多小时我停了手上的功能开发专门带着 AI 做了一次“记忆纹身”。流程分四步先让它把整个项目的当前架构浓缩进10-architecture.md要求包含模块关系、关键文件路径、兼容层存在条件然后把本周所有的决策撞成三条写入30-decisions.md其中第一条就是“适配层保留条件为 legacy 配置开启删除前必须与用户核对迁移进度”接着更新40-progress-log.md列出已经完成的三块重构和两块待验证最后在50-current-task.md里写明当下正在做的事和清晰的下一步入口。整个纹身过程用时不到二十分钟产出的是六七个高度浓缩的文件。更重要的是我修改了 AGENTS.md把“遇到压缩时必须重读记忆文件”的裁决规则加塞了进去。这样即使压缩发生在一个无人看守的时段AI 也知道先“开机自检”而不是直接凭着残破记忆硬答。5.3 压缩后AI 如何“失而复忆”第二次运行时压缩如约而至。这回我没有像以前那样立刻伸手去翻聊天记录而是先观察 AI 的行为。第一轮回答它没有暴雷反而在回复开头引用了记忆文件里的原话“根据 30-decisions.md 的记录适配层保留条件为 legacy 配置开启……”那一刻我知道这套机制生效了。它在“醒来”后的第一件事是通过重新读文件重建了项目心智而不是试图从对话碎片的废墟里考古。期间也有一小段插曲AI 在大约三轮对话之后开始把旧平台和新平台的接口细节混在一起原因是那段信息只存在于被压缩掉的聊天里记忆文件里写得不够细。我发现后立刻让它读90-glossary.md那里记录了新旧平台各自的接口路径与差异点它重新读完又恢复了正常。这次小偏差正好验证了一个观点记忆文件的价值不在于替代所有对话而在于给每个关键信息找到可靠的信息源信息源不全的地方就快速补上而不是依靠“再聊一次来找回默契”。压缩后的恢复成本从改造前的半天纠偏降到了大约一首歌的时间。这个转变让我坚信方案是成体系可行的。6. 常见问题与排查技巧实录6.1 记忆文件越写越大挤占有效上下文这是最容易掉进去的坑。记忆文件本来是来救场的但你写太多每天新会话启动就有两三万 token 花在读旧文件上活跃任务反而没有多少空间了。我现在给每个记忆文件定了硬上限00-session-brief.md不超过 200 字30-decisions.md只保留最近五条超过的归档到decisions-archive.md且不参与自动加载。每次会话结束时顺手看一眼记忆总字数如果超过五千字就说明已经积累成“知识库”而不是“启动缓存”该做一次精简了。6.2 记忆与现实脱节反而误导 AI记忆文件一旦陈旧负面影响比没有记忆还大因为 AI 会拿着过时架构去设计新代码。这个问题的根因通常是“只写不改”或“写的时候没附带日期”。我的解法是给每个文件顶部加“最后核对时间”并且在 AGENTS.md 里规定当 AI 发现记忆文件内容与代码现实不符时必须停下来提示用户更新而不是强行圆场。平时我也会在改完一个模块后主动让 AI 同步刷新10-architecture.md让架构图永远比代码晚一步过期。有个小技巧很实用在更新架构类记忆文件时让 AI 顺手用git diff或代码里最新的类型定义来校验描述如果它能引用真实行号说明文件内容是随着代码走的而不是停留在纸面想象。6.3 AI 不按约定更新记忆怎么办规则写在 AGENTS.md 里但 AI 忙着干活时就是会忘记更新。我的兜底方案是“外部触发”如果你用的工具支持自定义斜杠命令或 Hook给记忆更新绑定一个高频操作的手动入口比如提供一个/remember命令随时手动触发如果支持自动化 Hook也可以监听保存文件、任务完成这类事件让 AI 在事件触发时自动执行“记忆写入”动作。没有自动化也没关系最简单的做法是把“每完成一个子任务更新 50-current-task.md”写进你的每段工作指令里多提醒几次之后AI 也会形成路径依赖。我自己的经验是把记忆更新的动作变成一个固定台词“好这步完成后更新一下记忆文件再进入下一步。”这句话出现频率高了整个工作流的可靠性会肉眼可见地提升。6.4 常用问题速查表我把平时最常遇到的故障和解决手法整理成了一张表放在手边排查用症状可能原因排查与解法压缩后 AI 忘掉命名规范规范只存在于对话中未写入记忆将规范固化到20-conventions.md并由 AGENTS.md 指明启动必读AI 恢复后引用了旧架构架构描述文件未随代码更新先核对代码与现实再更新10-architecture.md并刷新“最后核对时间”AI 不写记忆文件缺少明确指令和触发机制增加/remember命令或任务收尾提醒把更新写进工作指令模板记忆文件占 token 过多文件内容冗余、未归档精简模板决策记录只留五条其余进归档文件多个记忆文件加载顺序混乱无编号或工具不支持多文件使用 00/10/20 编号把核心摘要内联在 AGENTS.md压缩后 AI 变得自信但错误摘要替换导致信息偏差强制它在压缩后重读.agent-memory/00-session-brief.md与50-current-task.md并以文件为最高裁决依据这张表并不能覆盖所有情况但已经足以应对绝大多数“压缩后遗症”。如果你遇到表中没有的症状大概率问题还是出在某个关键信息没有找到合适的外部载体顺着“这个信息如果丢了会怎样”的思路去找很快就能定位漏洞。7. 说点掏心窝子的免疫不是靠运气是靠工作流这套方案真正跑通后我对 AI 编码协作的心态发生了很大的变化。以前每次长会话推进到后期我都会下意识焦虑什么时候压缩、压缩后会不会翻车、要不要提前把任务拆小。现在这些顾虑基本消失了因为我默认每次会话都可能是“最后一次”所谓免疫不是让压缩不发生而是让压缩发生后项目状态依然可以从磁盘上重建。最后分享一个我在实际配置中最受用的小技巧给“压缩恢复”设计一个最短咒语。我的版本是六个字——“重读记忆续跑”在 AGENTS.md 里写死在每次意外断片时直接丢给 AI。因为足够短我会真的去用它而不是嫌麻烦跳过恢复步骤。你完全可以设计你自己的版本但关键是让它短到成为条件反射。这六个字配合良好的记忆文件习惯就是我在 20 万 token 层级的“脑叶切除术”里活下来的真正原因。
