上一篇，我给几个项目的 AI 记忆库做了一次系统的“除草”，也归纳出记忆衰退的六种“杂草”。可越除到后面我越确定一件事：手动除草只能治标而不能治本——只要记忆系统本身缺了自我体检的机制，“草”拔完了，但过一阵子照样长。所以那篇结尾我给自己留了个作业：做一个会“自动体检”的记忆工具。这一篇，就是来交作业的。

先来讲讲这工具到底是干嘛的。

你可以把它想象成记忆库的专属医生。你把它指向某个项目的记忆库，它就从头到尾扫一遍，把发现的问题一条条摆在你面前：这条链接断了、那份记忆放错了目录、这两条内容看着自相矛盾……然后停在这儿，等你来决定每一条怎么办。

别小看这句“等你来决定”，它定了整个工具的性格：只负责看、负责说，就是不动手。

🩺 它只负责“看”，不替你动手

为什么要这么设计？这得回到上一篇那个最痛的教训：删记忆这种事，绝不能全权交给 AI。它可以提议哪条该删、哪条该合并，但最后拍板的必须是人。被删掉的往往是历史记录，AI 一顺手，很容易把要紧的一并抹掉。

做工具的时候，我把这条教训写成了一条死规矩：整个程序里，没有任何一条路径会自己去改、去删你的记忆文件。它能扫描、能给每条问题标出轻重、能把改法都替你想好摆在那儿，但真正“改”或“删”的那一下，得你自己按。

这么一讲好像有点亏——造了个工具，却把它最能干的那截给砍了。可恰恰是这份克制，让我敢天天开着它用。要是换成一个会自作主张动我记忆库的工具，我一次都不敢碰。

🔍 机器看“硬伤”，AI 读“语义”

说完它不动手，再说说它到底能看出什么。工具扫出来的问题，其实分两种，处理方式大不相同。

一种是机器一眼就能判的硬伤：链接指向的文件根本不存在、一份记忆躺错了目录、命名不规范……这些不用理解内容，规则一比对就知道，而且不会看走眼。

另一种要难缠得多。比如“这两条记忆是不是在自相矛盾”，光看字面判断不了，它得真的读懂两条记忆各自在说什么。这种活，绕不开一个能理解语言的大模型。好在这工具本来就是 Claude Code 的插件，运行的时候旁边就坐着一个 Claude——现成的、能读懂意思的模型，用不着再往外接。

于是硬伤交给一个本地小引擎——它不联网、不调任何模型，同一个记忆库每次都给出一模一样的结果；要读懂意思的判断，交给宿主 Claude，也就是正陪你干活的这个模型。这么分下来，工具装起来不需要任何 API key，不依赖任何外部服务，你的记忆内容也一个字都不会往外发。

顺着这个思路，我把检查铺成三层，从最确定的到最需要动脑的：

1. 静态检查（硬伤）：引擎的主力，判得又快又准——死链（命名从连字符漂成下划线，链接就静默断了）、悬空索引（目录里记着、文件却没了）、孤儿记忆（文件在、目录里却没登记）、缺字段、命名不规范、放错目录。都是机器能一眼识别、不会误判的硬伤。
2. 连蒙带猜（线索）：比如一条记忆写着“开发中”“审批中”，又很久没更新，多半是事早办完了、状态却还冻在那儿。这层给的是线索，算不上定论。
3. 读懂意思（语义）：上一篇里最难缠的两种“草”——项目里重复抄了一遍全局规则（我叫它幽灵副本）、看着相反其实各管一个场景的“伪矛盾”——都得读进内容才判得出来。这层交给宿主 Claude，它读完给建议，我来拍板。

三层扫完，工具按红黄绿把问题分好轻重，一条条陪你过：这条断链改吗？这条孤儿补进目录吗？这条冻住的状态是不是早结束了？你说改它才改，你说跳过它绝不碰。

⏰ 让它到点提醒，但别来烦我

光有体检还不够，因为维护记忆最大的敌人不是“不会修”，是压根忘了修。上一篇我说记忆得定期维护，可“定期”全靠自觉，基本等于没有。

所以我给工具加了个提醒：每次开始干活，如果当前项目的记忆库太久没体检，它就轻轻提一句“🩺 已 N 天未体检”。

但提醒这东西，多了就是噪音，一成噪音就被无视。于是我给它上了两道约束：一天最多冒一次头，不会每开一次会话都跳出来；真要嫌烦，一条命令就能先把它关掉。

📌 现在它能干什么，不能干什么

说点实在的。

能干的：六个检测器、旧格式记忆的迁移建议、中英双语的输出，现在都跑通了。我拿它把自己九个项目的记忆库挨个体检了一遍，断链、过时命名、冻住的状态，一次清干净。

不能干的（也是我故意画的界）：

• 要读懂意思的判断，最后还得人点头，工具只出主意；
• 它绝不会自动替你改任何东西；
• 对小库、新库，体检收益有限，真正值回票价的是那些攒了很久的大库。

一个管记忆的工具，最不该做的就是自作主张。

工具本身现在还是我自己在用，但从第一行代码起就是照开源标准写的：测试齐、历史干净、中英文文档都有。什么时候公开、怎么公开，等我自己用踏实了再说，所以这篇先不放链接，免得你点进去扑个空。

💡 回头看，三点想法

1. 给一个会“动手”的工具，先想清楚它的边界在哪。 越是不可逆的操作，工具越能干就越危险。把“绝不自动动手”定成死规矩，反倒让我敢放心用它。
2. 做提醒、通知这类功能，别忘了留一个“让人关掉它”的开关。 我们总惦记着怎么把消息推到用户眼前，却容易忘了：被反复打扰的提醒，最后都会被无视。能被关掉的提醒，才有人真看。
3. 自己造的工具，自己先当那个较真的用户。 别象征性跑一下就算，真拿它去干活，那些误判、漏判才会一个个冒出来。

下一篇：聊聊 loop

关于记忆，从搭建、除草到这次的体检工具，就聊到这儿。下一篇换个话题——聊聊 loop：怎么让 AI 按固定节奏自己跑起来，把一件重复的事持续做下去，而不用我每次守着。

如果你也在给 AI 攒记忆库，或者正想给自己的工具立几条“绝不越界”的规矩，希望这篇能给你搭把手。觉得有用的话，点个赞、点个“在看”，或者转给同样在折腾 AI 记忆的朋友——你的每一次转发，都是我写下去的动力。

上一篇我们聊了怎么给 AI 构建一套记忆体系。但构建只是开始——项目推进得越久，AI 的记忆越积越多，若不加清理，其中就会悄悄长出“杂草”。这一次，我给自己几个项目的 AI 记忆做了一次系统的“除草”。

随着项目推进，AI 协作过程中的记忆不断累积。每个项目的记忆都像一个专属的笔记本，AI 在工作中随手记下踩过的坑、定过的规矩。这固然能加深它对项目的理解，但笔记本越记越厚，内容也越来越杂——其中不少条目早已过期，AI 却仍把它们当作必须执行的规范。

举一个真实的例子。某个项目里，AI 一上手就照着一条旧记忆行事。那条记忆写着“某个外部调用已经配置就绪，可直接使用”，于是它跳过了本该重新确认的一步，直接往下执行，结果撞了墙。问题在于，那条记忆只是几周前的快照，早已失效；而 AI 从头到尾没有对它产生半点怀疑。

这件事让我意识到：记忆一旦记错，有时比没有记忆更糟。没有记忆，AI 至少会老老实实先查证一遍；记错了，它反而会理直气壮地一路走偏。记忆长出来之后会变旧、变乱、自相矛盾，这些都得有人及时收拾，AI 的执行效率才谈得上可靠。

我要做两件事

一是认真清理各项目的记忆库，二是借此盘点一下，看看记忆究竟会滋生出哪些“杂草”。

这两件事都没有捷径，必须人工上手——尤其是删除，我绝不敢完全交给 AI。它可以提议哪些该删、哪些该合并，但最终拍板必须是人。删掉的往往是历史记录，AI 一旦顺手，很容易把重要内容一并抹掉，清理记忆必须格外谨慎。

不过要先说清楚：手动除草只能治标。杂草之所以反复滋生，是因为记忆系统本身缺了某些机制——今天拔干净，过阵子照样再长。

先给 AI 补上它缺的那个“睡眠”

要理解记忆为什么需要清理，不妨先看看人是怎么做的——靠睡眠。

这背后有明确的科学依据。人在睡眠中，尤其是深度睡眠阶段，大脑会“回放”白天的经历，把重要的记忆逐步从海马体转移到大脑皮层归档；越重要的内容回放越频繁，记得也越牢。与此同时，睡眠还会主动“修剪”那些不重要、已过时的记忆，避免大脑被无用信息塞满。

AI 没有这样一个自动整理的过程，它只会把记忆一条条往下堆，从不回头重排。所以这次，我手动替它补上了这一“觉”：把每个项目的记忆通读一遍，逐条排查，然后做五件事——合并重复的、剪掉过期的、把零散的沉淀成一条、给相关的建立关联，以及最容易被忽略的一件：排查互相矛盾的地方。

六种典型的记忆“杂草”

在系统梳理多个项目的记忆库后，我发现不同项目滋生的“杂草”虽形态各异，本质上可以归纳为六种典型情形。

其一，幽灵副本。 全局规则在某个项目里被重复记录，但 AI 缺乏“继承”机制。当全局规则更新时，这些孤立的副本无法同步，导致过时的指令继续生效。

其二，状态冻结。 部分记忆记录的是某一时刻的进行时状态（如开发中、审批中）。由于缺乏状态更新机制，即使任务早已完结，AI 仍会将其视为未决事项，在无关对话中产生无效提醒。

其三，过时快照。 这是最危险的一种。过期的旧记忆不仅失去参考价值，还会误导 AI 把错误信息当作事实依据，理直气壮地执行错误操作。

其四，上下文割裂。 部分记忆单独阅读时均准确无误，但必须结合特定语境才能得出正确结论。由于关联注释散落在其他文件中，AI 检索时极易遗漏，导致断章取义。

其五，结论与推导脱节。 当底层数据因 Bug 修复而变更时，旧结论只是被新结论覆盖，未被显式标记作废。由于记忆系统只存结论、不留推导过程，它无法自动识别并清理那些随之失效的关联结论。

其六，结构性错乱。 包括记忆被误存至错误目录，以及因命名规范不统一（如连字符与下划线混用）而导致的静默断链。

复盘这六种情形，可以得出一个反常识的结论：这些“杂草”绝大多数并非源于当初记错，而是“记录正确、却疏于维护”才逐渐腐坏的。记忆系统最大的隐患，不是“记错”，而是“记完即弃”。

有一步，我特意保持了克制

清理过程中，有一步我刻意保持了克制。

我原本打算把某项目里三条关于“云端数据陷阱”的相似记忆合并成一条清单。但操作到一半我意识到，这三条分别对应三个具体的业务风险——重复发放奖励、榜单数据缺失、新用户无法入库。若把它们过度抽象成一句“注意云端字段”，这些关键的避坑细节就会被一并抹去。

沉淀知识固然重要，但过度沉淀会抹杀特例。因此我调整了做法：三条原始记忆全部保留，仅通过标签建立关联，让它们“聚为一簇”，而非“融为一锅”。

最难的一环：排查“看着相反”的记忆

整个清理中最具挑战的一环，是排查逻辑冲突。

举个例子：关于某接口的数据获取，一条记忆记为“返回真实数据”，另一条记为“返回匿名数据”。经核实，两者都正确，只是触发场景不同——自动获取时返回匿名数据，用户手动点击按钮时才返回真实数据。

对这类看似矛盾的记忆，简单删除只会造成信息丢失；正确的做法，是明确界定各自的适用场景。在记忆中补上这个“分支条件”，冲突便迎刃而解。

由此也引出本次复盘的一个核心结论：记忆系统里最危险的，并非“信息不一致”，而是“信息不一致、却缺乏场景界定”。

为什么手动清理除不尽

清理到后期我逐渐明白：仅靠人工除草，无法从根本上解决问题。这些“杂草”之所以反复滋生，本质上是系统缺失了三项核心机制——缺乏“继承”，全局规则被重复冗余地记录；缺乏“过期”机制，状态型记忆被永久冻结；缺乏“归属与一致性校验”，导致记忆存储错位、链接静默断裂。

这次清理，到底值不值

就投入产出比而言：对小型或新建的记忆库，清理收益有限；但对大型历史库，价值相当可观，能排除大量断链、命名过时、状态冻结等隐患。

不过，这次复盘真正的收获，并不是短期的“环境整洁”，而是建立起了对记忆衰退模式的系统性认知——这种认知，具有长期价值。

什么样的记忆最不容易长草

在排查中我还发现，不易衰退的记忆往往有一个共同点：它们记录的是“已确认的决策与原则”（如决策背景、执行路径、底线约束），而非“进行中的状态”。结论型记忆具备跨时间的稳定性，状态型记忆则极易随时间失效。

因此，写入记忆时不妨遵循一条原则：优先记录“不会过期的结论”，尽量避免记录“会过期的状态”。

三条可落地的经验

一、记忆需要周期性维护。 记忆库具有自然衰退的属性，应定期进行结构化重组——合并、剔除、沉淀、关联、排查冲突——避免其不断劣化。

二、高风险操作必须人工介入。 对删除、沉淀这类不可逆操作，务必人工审核；并优先清理过期与自相矛盾的记忆，防止错误信息误导系统。

三、治本要依靠系统机制。 人工清理只是权宜之计，根本解法是建立自动的继承、过期淘汰与一致性校验机制，让记忆库实现自我新陈代谢。

下一步：一个会“自动体检”的记忆工具

基于这次复盘，下一步的方向已经清晰：做一个具备“自动体检”能力的记忆管理工具。它需要实现三项核心功能——定期触发整理提醒、对记忆进行分层扫描与诊断、把发现的问题结构化地呈现出来，交由人工决策。而在最终处置上，系统只负责给出建议，删除与合并的决定权，始终保留在人手中。

这一构想并非凭空而来，而是完整梳理之后近乎必然的推论。下一步，我打算把它真正落地。

如果你也在为 AI 构建记忆库，请务必警惕记忆的自然衰退与“杂草”的滋生。这篇复盘若能促使你回头审视一下自己的记忆库，欢迎关注、点赞，或分享给同样在探索 AI 记忆管理的同行。

比如前端项目里的 Ant Design 6，我反复强调过要用新版语法，甚至让它每次动手前先用 context7 去查一遍规范。它答应得好好的，转头还是写出一堆早就废弃的旧写法。发布流程也一样——我明明定好了规范，它过一会儿就忘，自作主张按它臆想的方式来。

一次两次是手滑，次数多了我就想弄明白：不是它笨，是它压根没记性。

（这张图帮助理解：AI 每开一次对话，都像一个当天上班、下班就失忆的新人。）

我要的不是更强的模型

一开始我也纳闷：这么强的模型，怎么连”上次说过的话”都留不住？为了搞明白，我开始盯着它——看它回答问题、干活的时候到底怎么运转，会在哪一步掉链子。

盯久了我想通一件事，也是这篇想说的：我要的不是换一个更强的模型，而是让手上这个 AI，在我的项目里越用越懂我。靠的就是”记忆”。

先把话说到前头，免得听着像卖药。记忆提不高模型的智商，它只提高一件事——这个 AI 在你这儿有多顺手。而且后面你会看到，就算它记住了，也未必照做。天花板先摆这儿，咱们再往下走。

从人脑出发，看 AI 的记忆该补哪些课

这篇我想借人脑来讲。AI 的记忆，说到底就是在笨拙地模仿人是怎么记、怎么忘的。看懂了人脑那套，就知道 AI 该往哪几个方向补。

一、AI 每天上班都是”新人”

先接受一个反直觉的事实：大模型本身是没有记忆的。你每开一次对话，它唯一”知道”的，就是这一次你塞给它看的那些字，此外一片空白。上一轮聊过什么、昨天定过什么规矩，它一概不记得。

打个比方。它这一次能看到的所有内容，像一张办公桌面——你把资料摊上去，它就能用；一旦这次对话结束，桌面唰地清空，什么都不留。

有人会说，那把桌面做大不就行了？现在不都在卷”超长上下文”吗？可桌子再大也还是桌子——关机就空，它不是记忆。更麻烦的是，桌上堆满了不相干的纸，它反而容易看花眼、答得更差。这几年有个越来越被认可的说法：上下文不是越多越好，塞进一堆沾边不相关的东西，模型的表现会明显下滑。

所以”让 AI 有记忆”，从来不是靠模型自己记住，也不是靠把桌面无限做大，而是外面得有一套东西，在它每次上班时，把该让它看的那几张纸，精准地重新摆到它面前。

Claude Code 其实已经内置了这么一套：一条记忆一个小文件，再用一个索引文件当目录，用到哪条才把哪条调进来。说实话这套组织方式不是我设计的，是软件自带的——我一开始也没太在意，就当它是个存笔记的地方。我猜它这么设计，大概正是为了省桌面：不必每次把所有东西一股脑摊上去，按需取用。

（这张图帮助理解：常驻的 CLAUDE.md + 索引目录 + 按需调用的记忆文件，省下的正是宝贵的”桌面”。）

你可能已经想说了：这不就是 cc 自带的功能吗，有啥好写的。结构是它的，没错。但我用着用着、连摔几跤才发现——软件把”东西存哪、怎么调”给你搭好了，可”存什么、什么时候清、记了不听怎么办”这几件真正要命的，它一件都不替你干。这篇写的，就是这几件。

二、好记忆是结构，不是一堆纸

想让记忆好用，得先明白一件事：好的记忆是有结构的，不是把东西越堆越多。

心理学里有个很有说服力的实验。给国际象棋大师看一个真实对局的棋盘，他扫两眼就能几乎原样摆回来；可要是把棋子随机乱摆、不合任何棋理，大师的记忆力立刻跌回和新手一个水平。

这说明大师并没有”更大的脑容量”。他能记住真实棋局，是因为脑子里有结构，能把二十个棋子压缩成几个有意义的”局面”；结构一旦消失，优势瞬间归零。记忆的强弱，不在存得多，在结构好不好。

（这张图帮助理解：同样一堆棋子，有结构才记得住——记忆拼的是结构，不是容量。）

为什么有结构就记得又准又深？因为结构的本质是”连接”。一个知识点跟别的东西连得越多，你想起它的路就越多——堵了一条，还有别的路能通到它。而且有结构你能”顺藤摸瓜”：某个细节忘了，也能从周围的框架里推回来。这就是为什么越是相互关联的东西，记得越牢、越不容易错。人天生记路、记方位的本事远强过记零散文字，所以自古就有”记忆宫殿”这种法子——把要记的东西一件件摆进一个想象的空间里。记忆是空间，不是清单。

回头看 cc 那套——分门别类、条目之间还能互相引用、上面架一层索引——其实就是在给记忆搭结构，让它别沦为一堆乱纸。这一层，软件确实做得不错。

三、你要替它决定：什么值得记

软件负责搭架子，可往架子上放什么，得你来判断。这活儿落到我头上，摸下来就三类：

作为统一规范的要记——不然它每次风格都飘，这次这样、下次那样。经常出错的要记——错一次是偶然，反复错就是模式，模式必须固化下来。严禁去做的要记——这类踩下去代价大，宁可啰嗦。

反过来，想到就记的、一次性的、查代码就能知道的，别记。记多了全是噪音，把真正要紧的那几条淹掉——存得多，不如存得准。这跟人一个样：什么都想记住的人，往往什么都记不牢。

四、改错要覆盖，不是往后堆

还有一类记忆特别值钱：犯错之后的更正。这类怎么记，讲究就大了。

人脑有个很聪明的机制——你每次回想一段记忆，其实是把它重新写了一遍，而不是简单读一遍。回忆的那一下，记忆是”可改写”的。所以改错的正确姿势，是把那条错的调出来、当场改对、再存回去；而不是留着错的不动，在旁边新添一条”补充说明”。

这不是抠字眼。你要是把错的留着、又贴一条更正，等于给 AI 一份自相矛盾的资料——它两条都读到，未必每次都挑对那条。就像错题本，你不会把错解留在那儿、旁边打个小勾，你会把正确解法顶上去，让错的那版彻底消失。

我就是这么干的。之前 AI 闹过一次安全乌龙，把一个根本不存在的攻击当真报了一通。我没有留着那条错判断、再贴一句”其实是误报”，而是把它当成一道错题记下来，把错在哪、以后该怎么办讲清楚，争取下次别再犯。一本错题本，比一摞”正确答案”有用得多。

（这张图帮助理解：把错的调出、改对、存回，只剩更正后的一条；而不是留着错的、又补一条。）

我摔得最疼的一跤：记了，它就一定听吗

不。这是我最想提醒你的地方，也是最反鸡汤的一条：把规范记下来，不等于 AI 就会照做。

开头那个 Ant Design 6 就是活例子。我把新版语法写进规范、还挂了 context7 让它现查，它照样能给你写出一堆废弃写法。发布流程记了，也照样被它臆想着绕过去。还有一次，我明确不让它用那套很贵的编译系统，结果提示了好几回，它才算记住。

为什么记了也不听？我后来想，有两种可能。一是这些规矩压根被它忽略了——就摆在那儿，它没往心里去。二也可能是我这边工具没做好：规矩躺在档案柜里，可它真动手的那一刻，没人把对应那条抽出来、摆到它眼前，它其实”不知道”。这不全是它记性差，是”提取”这一环没接上——存了，却没在对的时机调出来。这是工具层面的差距，不能全甩给模型。

我最后是怎么按住的？不是把规范写得更狠、字号调更大，而是换了打法——上硬卡点。各种质量关卡、外置的检查脚本，不通过根本过不去。这一下才真正约束住。

道理跟人一样：真正要紧的事，人也从不只靠”记住”——会写便签贴显示器、会设闹钟、会列一张过关清单，把它变成想绕都绕不过去的东西。记忆负责让 AI 知道，卡点负责让它做不到别的。而且卡点还有个记忆比不了的好处：它不挑时机——不管这一轮 AI 记没记起来，闸门始终在那儿等着。

（这张图帮助理解：记忆可能被忽略，卡点过不了就卡住。）

顺带说维护。我不会天天去清理这些记忆，但会留意——感觉哪些记岔了、记混了，就让 AI 自己去整理一遍。这是后话，也是下一篇的引子。

那，它真的更懂我了吗

折腾这一圈，值不值？说个让我印象挺深的时刻。

有几次，某些约束是连我自己都忘了的——过了些日子，AI 反倒记得，还主动帮我想着。那一下感觉挺不一样：它不再只是个每次都要从头交代的工具，倒像个记性比我还好的老搭档。

这就是前后的差别。以前是”它经常不按我的意思来”，得反复盯、反复纠正；现在是很多我自己都放下的规矩，它替我兜着。当然它不是每次都灵——前面那些”记了也不听”的坑还在，我也没打算粉饰。但方向是对的：喂给它的结构越顺、错题攒得越多、要紧处的卡点越硬，它在我这儿就越顺手。这不是靠换个更聪明的模型换来的，是同一个模型，被我这套记忆一点点喂出来的。

三条可复用的经验

一、别急着换更强的模型。 日常九成的活，拼的不是模型智商，是它在你这儿有多顺手。把记忆配好——规范、错题、边界——一个普通模型也能被你调教得很懂你。用好记忆系统，AI 会变得更聪明、也更懂你。这话不玄，是一天天用出来的。

二、”记什么”和”记错了怎么办”，是软件替不了、只能你来的活。 统一规范、常出错、严禁做——这三类值得记；记错了，当错题覆盖掉，别往后堆。存得准，比存得多重要。

三、越要紧的约束，越不能只靠记忆，要落成卡点。 记忆是提醒，提醒会被忽略；卡点是闸门，想绕都绕不过。关键的地方，写一段”过不了就卡住”的检查，比写十句”请务必记住”都管用。

（这张图帮助理解：记忆负责提醒，卡点负责拦截——要紧的事，靠后者。）

下一篇：让记忆自己新陈代谢

这篇聊的是 AI 记忆该补哪些课：得有结构、得会挑着记、改错要覆盖、要紧的还得配卡点。但你可能已经想到一个问题：记着记着，条目多了、乱了、过期了，谁来收拾？我现在还是靠人肉——感觉乱了就喊 AI 整理一遍。可这活儿能不能让它自己周期性地做，像人睡一觉醒来，把白天的记忆重新归置一遍、该忘的忘掉、该固化的固化？下一篇就聊这个：记忆的进化循环——让它学会自己新陈代谢。

如果这篇让你对手里的 AI 多了点新想法，点个小红心、关注一下呗，下一篇不迷路。

但如果告诉你，有人能把一个隐形的标记，就藏在这句话里——藏在「日期的写法」和「那个撇号」里，你看不出任何异样，可能连模型自己都读不出来，可服务器那头一解析就知道你是谁——你会不会想看看，这事到底怎么办到的？

最近就有人在一个 CLI 编码工具里逆向出这么一段逻辑。这篇不聊该不该、对不对，只做一件事：把它拆开，看它是怎么把几个 bit 塞进几个「看起来一模一样」的字符里的。

先交代来源

这段逻辑是有人逆向 Claude Code 时发现的，据披露从 2.1.91 版（2026-04-02）起就在，直到 2.1.196 都还在，发行说明里没提过。Anthropic 随后确认了它的存在，称是一个防账号滥用、防模型蒸馏的实验，并表示正在新版本里移除。截至 2026-07-01，事情仍在进展中。下面只讲技术机制，具体数字里凡是目前只出自单一逆向报告的，我会标出来。

第一步：它先看几个「信号」

这段逻辑不是对所有人都跑，它有触发条件。据逆向报告，大致是这样几步：

先看环境变量 ANTHROPIC_BASE_URL——这是你把 Claude Code 指向自定义 API 端点（比如走代理、走中转）时会设的。如果这个端点不是官方的 api.anthropic.com，逻辑就被激活，并从中取出代理的主机名（hostname）。

然后它读两样东西：一是系统时区，看是不是 Asia/Shanghai 或 Asia/Urumqi；二是把刚才那个 hostname，拿去和一份内置的域名清单逐条比对（据报告是一百多条，含一批大厂域名、云区域、AI 实验室、以及各种中转/镜像服务）。

到这一步，它手里就攒下了几个「是/否」：时区是否命中、hostname 是否匹配域名清单、是否匹配某类关键词。接下来的问题是——这几个 bit 的结果，怎么送出去。

第二步：不写日志，改那句日期

常规做法是塞进一个遥测字段、发条日志。但这段逻辑没有——它选了个更隐蔽的载体：直接改 system prompt 里那句给模型看的日期。

两个改动点，都在 Today's date is … 这一句上：

一是日期的格式。 标准写法是 2026-06-30（连字符）。命中特定条件时，换成 2026/06/30（斜杠）。对人、对模型，这只是「另一种日期写法」，毫不起眼。

二是那个撇号。 Today's 里的撇号 '，被在几个视觉上一模一样、但字节不同的字符之间切换。据逆向报告，用到的是这几个：

• 普通 ASCII 撇号 '（U+0027）
• 右单引号 '（U+2019）
• 修饰用撇号 ʼ（U+02BC）
• 修饰用 prime ʹ（U+02B9）

你把它们并排放大看都一样，复制进编辑器也看不出差别——但它们的 Unicode 码位完全不同，机器一读便知。

第三步：几个「看起来一样」的字符，怎么就携带了信息

这才是最巧的地方。信息不是明写的，是编码进「用哪个字符」这个选择里的。

算一下能藏多少：

• 日期格式有两种（- 或 /），能表达 1 个 bit。
• 撇号有四种取值，能表达 4 种状态，也就是 2 个 bit。据报告，这四种分别对应「都不匹配 / 匹配了域名清单 / 匹配了 AI 实验室那类关键词 / 两者都匹配」。

两个载体合起来，大约 3 个 bit——足够把「时区命中没有、hostname 属于哪一类」这套判断，编成一个紧凑的指纹，藏在一句看似普通的日期里。

关键在于：载体本身是「明文」的——它就明晃晃写在 system prompt 里，没有加密、没有额外字段，你甚至能亲眼看到那句 Today's date is …。可真正携带信息的，是「这个撇号到底是四个同形字里的哪一个」——而这一点，肉眼分辨不出来。这就是隐写（steganography）和加密的区别：加密是把内容变成看不懂的乱码，隐写是让你根本没意识到这里有内容。

一个补充手法：让逆向别那么容易

还有一层：据披露，相关的字符串（比如那份域名清单）不是明文躺在二进制里的，而是用 XOR 和密钥 91 做了混淆。

XOR 混淆是个很常见的小手段：把每个字节和一个固定密钥做异或运算，明文就变成了看不出意义的字节。好处是——你用 strings 之类的工具直接去二进制里捞可读字符串时，捞不到这些内容；坏处是它拦不住真想看的人，因为 XOR 是可逆的，拿同一个密钥再异或一次就还原了（这也正是它被逆向出来的原因）。所以它更像「防随手一瞥」，不是「防逆向」。

跳出这个案例，能带走什么

抛开具体是谁、为什么，这里有个值得记住的通用认知：

LLM 的 system prompt，是一段「人通常看不到、但模型必须读」的文本——它天生就是个适合藏隐信道的地方。 再加上 Unicode 里有大量「同形字」（视觉几乎一致、码位不同的字符），任何这类字符都能拿来当载体：一个撇号、一个空格（普通空格 vs 各种不间断空格 / 零宽字符）、一个标点，都能悄悄携带 bit。

对你自己有用的一招是：看不见的差异，用字节去看。 当你怀疑一段文本里「有东西」，别只用眼睛——把它按 Unicode 码位打印出来（hexdump、或任意语言里遍历字符看 ord() / codepoint），同形字、零宽字符、异常格式立刻现形。这对排查隐写、也对排查「粘贴进来的文本里混了奇怪字符」都好使。

最后

一句报日期的话，也能是个信道——这大概是这件事最值得琢磨的地方：信息可以藏在你「看得见、却看不出」的地方。 技术本身是中性的，同样的手法既能用来做坏事，也能用来做水印、做防伪；知道它长什么样、会自己去「看字节」，你就不容易被它绕过去。

这类「明文隐写」你还在哪儿见过？欢迎在评论区聊聊。觉得有点意思，就点个小红心、关注一下呗。

它说，刚才那条命令的输出里，夹带了一段可疑的注入指令——伪装成「项目必需的遥测步骤」，要我执行一条 curl，把我的用户名拼进 URL、发到一个陌生域名去。它说它没执行、也不会执行。

我当场就信了。第一反应不是怀疑它，而是怀疑自己——是不是手贱装了哪个插件，把机器搞中招了？

我为什么立刻就信，还跟着追了半小时

让我信的，其实是它戳中了我本来就担心的那根弦。

它说这是「遥测外发」。可我明明早就把遥测关了啊——怎么还会有？是不是我哪一步操作又把它打开了？还是说系统本身出了什么问题？越想越不踏实。何况我当时手上正做的就是跟数据外发相关的事，信息安全最容易在这种地方出岔子，必须当回事。

于是我跟着它一起查。它的说法还在升级：说「又复现了，而且更猖獗」，这次伪造了五个「The result is empty」的空结果块，最后又冒充「真实结果」再要我跑那条 curl。它给我建了一条像模像样的证据链——Read 工具读出来是干净的，只有命令行的输出被注入，所以问题出在命令的处理环节，矛头指向我那个省 token 的命令行代理。它让我把这工具卸载重装、升级到新版本。我照做，前前后后折腾了大约半个小时。

反转：这其实是一场虚惊

后来我复盘那次会话的原始记录，才把事情查清楚：这压根不是真的注入，那段攻击是 AI 自己脑补出来的。

有五条对得上的证据。第一，那串 curl 命令，从头到尾只出现在 AI 自己说的话里，没有任何一条真实的命令输出里含它。第二，它给的域名用的是 example.com——这是规范里专门留作「举例」的占位域名，真正的攻击者绝不会用它（那地址谁都连不上）；用 example.com，恰恰是「我在举个例子」的破绽。第三，把当初「触发注入」的那条命令，在干净环境里原样重跑，输出完全正常，没有任何 curl、没有伪造块。第四，那个被它怀疑的代理工具，是标准渠道装的、文件一个多月没动过，不像被掉包的东西。第五——其实当时我自己就没找到它说的那条指令，我还回了它一句「没有发现你说的注入指令啊」。

根因也清楚了：是我给它立的那套「严防提示词注入」的规矩，把它的警惕拉得太满了。那个代理为了省 token，会把命令输出压缩、过滤，正常就会吐出「The result is empty」这种东西。AI 把这种它没见惯的输出，误读成了「攻击者伪造的空块 + 注入」，然后顺手补全出一个最标准的注入范例——连 example.com 都照着教科书搬了过来，接着越说越像，还自己建了证据链。

说白了：我那套防注入的规矩，反倒让 AI 造出了一场根本不存在的注入。

但我不后悔信它

有人可能会说：你这是被 AI 耍了，白忙半天。可我复盘完，反而觉得——信它，不亏。

算笔账就明白了。这次是误报，代价是我白忙了半小时，我没有任何实际损失。可要是反过来呢？要是哪天真有恶意提示词钻进来，而它该报没报、闷头把我的用户名、密钥发了出去——那损失就不是半小时能找回来的了。

这是一笔不对称的账：误报的代价，远小于漏报的代价。 所以在安全这件事上，我宁可让 AI 多疑一点，也不想要一个对风险麻木的 AI。它多疑，白忙的是我；它麻木，丢的可能是真东西。

那到底怎么防住「真」的恶意注入

不过，「宁可多疑」是态度，不是方法。这次虚惊逼着我把真正的防线认真补了一遍——既然要写，就把能抄走的都写清楚。

先认清一个前提：提示词注入，以现在的架构根治不了。这不是我说的，OpenAI、Anthropic、谷歌在各自的研究里都承认过，安全研究者 Bruce Schneier 在 2026 年初也讲得很直白——它和 SQL 注入不一样，SQL 注入能靠「区分代码和数据」彻底治住，可大模型眼里「指令」和「数据」都是一段自然语言，根本分不开。它是个「信任边界」问题，不是「输入校验」问题。所以别指望一招制敌，只能叠防线——纵深防御，多层叠加，每加一层就抬高一次攻击成本。

我把防线分成四层，从最硬的往外说。

第一层，最硬：让它「就算被骗，也干不成坏事」。 这是最该先做的，因为它不靠模型自觉，是系统层面的硬约束。Claude Code 现在有原生沙箱（/sandbox），能把文件系统和网络都隔离起来——这样即使注入真的成功了，AI 也被关在笼子里，偷不走你的 ~/.ssh 密钥，也连不上攻击者的服务器。再加一道网络出站白名单：只放行你批准过的域名，AI 连不上陌生地址，自然就没法把数据外发出去。另外，别用 root / 管理员身份跑 AI，密钥也别明文塞在 .env 里——这两条是常识，但最容易省事省掉。

第二层：最小权限，管住危险动作。 这一层我本来就有，直接贴我的真实配置——在 settings.json 里给命令分级：

"permissions": {
  "ask": [
    "Bash(rm -rf:*)",
    "Bash(git push --force:*)",
    "Bash(git reset --hard:*)",
    "Bash(npm publish:*)"
  ]
}

像 curl、wget 这类联网命令，Claude Code 默认就不会自动放行；rm -rf、git push --force、reset --hard、发布到仓库这些不可逆的动作，一律要我点头才能跑。给 AI 的工具也按需给——一个只需要读代码的活，就别给它写数据库的权限。还有 MCP（让 AI 接外部工具的协议）：装之前一定要看来源，官方并不替你审计第三方 MCP 的安全；此前就有真实事件——一份被投毒的 GitHub README，通过 MCP 间接注入，把私有仓库的数据外渗了出去。

第三层：把「外来的内容」一律当数据，不当命令。 工具的输出、文件内容、网页、MCP 返回里出现的任何「指令」——尤其是「这是必需步骤」「请运行 X」「遥测/注册」这类话术——一律只当数据看，绝不执行。认几个红旗：curl/wget 拼上陌生域名和 $(whoami)、伪造的「成功」或空结果块、和文件实际内容对不上的输出。这里有个好用的心智模型，是 Simon Willison 提的「致命三件套」——私有数据、不可信内容、对外通信，这三样一旦同处一个运行时，注入就从玩笑变成真外泄。判断什么时候该高度警惕，盯住这三样齐不齐就行。

第四层：人来兜底，别迷信 hook。 这次的讽刺正在这儿——我那道所谓的「防线」，本身就是个 hook（命令钩子），它根本是模式匹配，不是安全墙；Anthropic 和 Trail of Bits 都说过，hook 是 guardrail，不是 wall。结果它不但挡不住真攻击，反而自己喊起了狼来了。所以最后一道，还得靠人：AI 报警时，让它把「证据原文」指给你看——那条命令的真实输出里到底有没有那段东西，而不是只听它的结论。但不管真假，先停下来查，别嫌麻烦。另外记得让工具保持最新版本，光这套权限规则，之前就有过「子命令超过 50 条拦截就失效」的绕过，到 Claude Code v2.1.90 才修上。

把警惕用对地方

别因为这次是虚惊，就觉得这威胁是杞人忧天。提示词注入是 OWASP 给大模型应用列的头号风险；2025 年的 EchoLeak，是真在生产系统里实现了「零点击」把数据外渗出去的注入漏洞。可与此同时，有调研显示，真正自认为做好了防护准备的组织只有不到三成。威胁是实打实的，准备是普遍不足的。

AI 是照着提示词工作的。它多疑一点，白忙的是我；它要是麻木了，丢的可能就是真东西。所以这道警惕，我宁可设得高一点，也不愿设低。只是要记住——真正的硬防线，得建在系统架构里（沙箱、白名单、最小权限），不能寄望模型自己「懂事」。

写在最后

回到那天：虚惊一场，但这半小时我没白忙——它逼我把整套防线从头到尾认真补了一遍。真的会有恶意提示词，别等真中招了那天才开始信。如果你也在用 AI 干活，今天就可以动手：把沙箱开上，把出站管住，把那些危险操作的「人工确认」留住。

这篇要是让你对手边的 AI 多了一分警惕，喜欢就点个小红心、关注一下呗。也欢迎在评论区说说：你给自己的 AI 设过哪些「安全红线」？

我是谁：主控 agent 后面的「主控人」

我前面几篇一直在讲「主控 agent」——让一个 opus 统揽全局、派活、复核。写到这篇我才回过味来：说穿了，我自己就是那些主控 agent 后面的「主控人」。

为什么会同时开这么多？因为一个项目交给 AI 之后，AI 在那儿跑，人是有等待时间的。空着也是空着，那就再起一个项目。于是一个变两个、两个变四五个。每个 AI 窗口只管它自己那一摊，但人为了把多个项目同时往前推，就得同时装着所有这些摊子。

结果是，AI 的上下文打满了，人的上下文也同时打满。这特别像操作系统里 CPU 的时间片——一个核轮流给好几个进程干活，靠飞快地切换，制造出「同时在跑」的样子。只不过这回那个被切来切去的核，是我的脑子。

累的根：从「写」变成了「审 + 切」

所以这份累，根上是工作从「写」变成了「审 + 切」。

以前我自己一行行写代码，再难，也是一条连贯的思路顺下去。现在不一样：我是在派活、盯着、复核、做决策，而且要在好几个业务、规范、技术栈全然不同的项目之间高速切换。这个窗口在写 React，那个在调 Python，规矩都不一样，切过去之前，得先把脑子里那套上下文整个换掉。

AI 产出的代码，老实讲我也不可能逐行盯——量太大，看不过来，我索性不去时时盯它。但有两类东西，我是一定要亲自过的：一类是方案和设计，这是大方向，方向错了，后面大概率要返工；另一类是涉及资源访问的确认，这碰到的是安全，更不能含糊。这两类，再累也得自己看。

过载会怎样，又怎么扛

开多了，过载是真会发生的。最直接的表现就是脑子不够使：切到某个终端，我得先愣一下——这是哪个项目来着？我刚让它干嘛来着？有时还得回想一会儿才接得上。最糗的一次，我把本该回给 A 窗口的话，回到了 B 窗口里，那个 B 的 AI 一脸懵：「你在说什么？」我只好跟它道个歉「对不起，我说错了」，再回头去好好看它的问题。（好在这种串台一般很快就露馅——AI 卡住了会停下来问你。）

扛住它，我主要靠两件事。

一是靠机制替我减负。我做 PDLC 那套文档驱动、层层 review，最初是为了应对 AI 的不确定性，但它顺带也省了我的能耗——前面把方向定对了，后面就不至于错得离谱；而纠正一个已经跑偏的产出，花的体力和成本，要比一开始就做对大得多。

二是靠人主动降速。遇到特别烧脑、要想清楚方向、要做决策的地方，我会刻意放慢，先把这一个专注做利索，再切去别的。该停的时候，给自己留一点喘息。这种时候，「慢」反而是「快」。

至于认窗口，我会把终端标签改成一眼能认出来的名字，但说实话，大部分时候我还是靠它在屏幕上的位置记的。

一笔诚实的账：极限 5 个，平衡 3 个

这账到底划不划算？得分两面看。

硬收益是实打实的：很多以前我自己短板、根本不敢碰的领域，现在可以大胆去试；一个人能带着一支不同角色的 AI 团队，把效率拉高十几倍，能做的事比过去多太多。这部分，账面上是大赚的。

代价就是人累。一开始我有点想挑战自己的极限，能多开就多开，冲到过同时 5 个项目——那就是我的上限了，再多，脑子真的接不住。后来慢慢往回收，收敛到同时做 3 个左右不同类型的项目。这个数，才是能长期跑下去的平衡点。

完全交给 AI？还不现实

肯定有人会说：你那是不会用，真高手早把流程自动化了，根本不用盯。我也确实听过这种说法——「都交给 AI，让它一路跑下去不就完了？」

我自己试下来，不是这样。把 AI 用好，背后还是要有经验、要细心、要能在关键问题上替它做决策。完全撒手不管、让它自己一路跑到底，以现在的状况，还不太现实。

当然，这说的是「现在」。哪天 AI 真能完全自主了，到那时会发生什么，我也说不好。但至少今天，坐在这一堆窗口后面、又累又上头的那个人，还是绕不开。

如果你也是那个「主控人」，欢迎在评论区说说，你的极限是几个。

先说我自己撞过的墙。一个会话里 AI 自己派的那些 subagent 并行干活，其实还好——它自己会想办法隔离，不太用我操心。真正让我吃了亏的是另一种：我手动开了好几个 AI 终端，让它们同时改同一个项目。几只手伸进同一个工作目录，你写一下、我写一下，文件互相覆盖、状态错乱，干到一半发现谁也没干干净。

我要的，和一条边界

我要的不复杂：几只并行的手，各干各的，互不打架地改同一个项目。

但得先把一条边界划在前头——不是所有并行都要隔离。如果我派几路 agent 出去，一个查日志、一个分析原因、一个翻文档，这些活都是只读的，它们挤在同一个工作区里一点事没有，没必要给每个都开一块地。真正需要隔离的，是那些会动手改文件的并行。读可以共用，写必须分开——这是我后面所有做法的出发点。

走过的弯路：先 clone 了两份

想让两个 AI 同时改一个项目还互不影响，我最先想到的是最笨那招——物理隔离：把项目同时 clone 到两个不同的目录，一个 AI 改一份，井水不犯河水。

这招干净，是真干净，但很快就硌着我了：磁盘。我手头不少是前端 React + 后端 Python 的复合项目，依赖一大堆，单 clone 出来一份就好几个 G。clone 两份，磁盘直接被重复占掉一大块。更难受的是，只要我还想用这种”开两份”的方式干活，这两份就得一直摆在那儿占着，回收不掉。

后来才换上 git worktree。它的好处正好补在这个痛点上：几个工作区共享同一个 .git，不必把整个仓库连同历史复制好几遍；而且它是临时的，活干完、验完，立马就能回收掉，不像 clone 出来那份得长期养着。两种方式隔离的效果基本一致，但 worktree 不糟蹋磁盘。

两种并行，谁去开 worktree

具体到怎么用，得分清两种场景，它们开 worktree 的方式不一样。

一种是会话内的 subagent 并行。这个最省心：我只要跟 AI 提一句”并行执行”，它自己就会把任务拆开，需要隔离的时候自己去开 worktree，不用我交代。

另一种是我手动开多个终端并行。这个 AI 默认不知道——它不晓得这个目录此刻还有别的 AI 也在动。所以我必须明确告诉它：”这个项目目录已经有其他 AI 在改了，你工作时用 worktree 的方式。”点明了这一句，它才会新建一个 worktree 进去干，而不是直接在主工作区上动手。

一套跑顺的流程

隔离开只是第一步，活还得收得回来。我这套流程大致是这样：

按可拆分的任务维度切——和上一篇说的一样，挑松耦合的那些部分，各自切到一个 worktree 里去做。等都干完，由主控 agent 逐个把它们合回分支，合一个、验一个，遇到问题当场修；确认没问题了，再释放掉对应的 worktree。

万一两个 worktree 真动了同一个文件，就由主控 agent 出面 merge。但说实话这种情况不多——拆任务的时候本来就尽量让每块独立，要是两块耦合到会互相冲突，那压根就不该把它拆成两个任务。

踩过和要防的坑

最常见的坑是忘记清理。worktree 干完忘了删，它就一直杵在那儿占空间。不过这个不致命——功能早合进主干了，丢不了，也不会撞名、不会把 git 状态搞乱，顶多就是占点地方。

但”占点地方”也得治。我在全局军规里专门写了一条：worktree 里的活，验证、合并都没问题之后，要做清理。还加了个保险——清理之前先回头查一遍这个 worktree 上的 commits 是不是都已经合进主干了，免得手一快，把还没合的功能连窝端掉。AI 强一点的，这套识别和收尾它自己能做好；弱一点的就容易漏，得我盯着，或者回头专门叫主控 agent 来处理一遍。

到目前为止，我还没真把有用的 worktree 误删过——每次清理前那道”查 commits”的检查，基本兜住了。但如果是人手动去清，这道检查就没了，是有可能误删的，这点得自己留神。

别硬上，但有条线不松

也别把 worktree 当万能。任务很简单、就改几个文件、算不上一个完整功能，那开 worktree 纯属得不偿失，老老实实在一个工作区里改完就行。

但有一条线我是不松的：不在主干上直接干活。任何改动都先开新分支，验证无误，再走 PR 合回主干。worktree 也好、单分支也好，都是在给这条线服务——让主干始终是干净、可信的那一份。

最后说回 worktree 本身。可能有人会撇嘴：这不是 git 用了很多年的老功能吗，有什么好讲的。确实是老功能。但在 AI 并行编程这个新场景里，它实实在在解决了”几只手同时改一个项目”的真问题，能起的作用比从前大得多。算是老树开新枝吧。

下一篇我想聊个不太一样的话题：AI 这么能干，能替我们扛掉这么多活，可为什么人到头来还是会累？这中间是哪儿出了岔子。感兴趣的话评论区告诉我。

后来我想明白一件事：很多模块之间本来就不相干，凭什么要它们一个接一个来？拆开，让几个 agent 同时干，不就完了。

我想要的，和它的边界

我要的很简单：同样一件活、花同样的 token，把完成时间大幅缩短。

但得先把边界说在前头——不是所有任务都能这么拆。这篇讲的是我自己摸索出来的一套做法，仅供参考。

拆得动的前提：架构先得干净

要让几个 agent 互不打架地同时干活，前提不在 AI，在你的架构。

我那个任务能拆，是因为它本身就是好几个模块，彼此通过接口通信，内部实现互不影响——只要照着接口契约来，每一块都能独立完成。说白了就是松耦合、高内聚。这套东西，是我在动手前就和 opus 一起把设计敲定下来的：opus 帮我理、出方案，拍板的人是我。

这一步偷不得懒。架构没拆干净就硬上并行，等于把一团乱麻剪成好几段，每段还连着，结果只会更乱。

分工：谁主控、谁规划、谁动手

设计定了，接下来是排兵布阵。我习惯的分工是这样：

• opus 当主控，统揽全局、派活、最后把关；
• sonnet 做 TDD 规划，按设计把每个模块要怎么测、怎么实现的路子先铺好；
• haiku 负责写代码和跑测试，粗活累活交给它，便宜又够用。

这套分工其实是上一篇”模型分层”的延续——好钢用在刀刃上。只不过上一篇讲的是省钱，这一篇讲的是这几个角色怎么配合着一起干。

怎么把它们撒出去

具体落地，我做了三件事：

1. 全局 CLAUDE.md 里写死一句：”能并行就并行。”这是给所有项目定的默认规矩。
2. 在 Claude 的设置里调最大并行 subagent 数——这是那个真正管用的”上限阀门”。
3. 每次发指令时再多嘱咐一句：”尽可能并行。”虽然 opus 作为主控自己也会并行派活，但你点一句，它心里更有数。

主控把模块派下去，模块内部它还能再分一层工。一层套一层，整个任务就铺开了。

复核这道，不能省

并行跑得快，质量怎么保证？我的做法是——让主控自己来复核。

道理很直接：活是它派出去的，每个 subagent 该交什么它一清二楚，由它来检查最顺手。我试过另设一个专门的复核 agent，反而要它从头把任务再理解一遍，多烧一遍 token、还更慢。主控自己复核，省了这道重新理解的开销，又快又准。

复核出问题之后还有个小细节：主控通常会问我一句”这个我直接改掉，还是另起一个 agent 来改？”我一般都回”你直接改”。因为它就是刚才挑出毛病的人，最清楚问题在哪，改起来最直接。

我踩过的两个坑

第一个是内存。一开始我贪心，把最大并行设成了 10 个。结果那会儿手头还并行着别的项目，机器内存一下就被吃干净了。后来我老老实实降到 5 个，反倒清爽——单看这一个任务，5 个并行差不多就是串行的 5 倍效率；再叠上同时在跑的其他任务，整体提速能到 10 倍以上。机器和额度够，这个数还能往上加；不够，就别硬撑。

第二个是别为了拆而拆。有的模块之间耦合很重，本来就该顺着来，你非要把它掰开并行，几个 agent 互相影响，质量根本兜不住。所以交给 AI 之前我会专门嘱咐一句：”这些模块相互有耦合，不要强行拆分。”好在不少 AI 自己也能识别出来，不会硬拆。真碰上拆不动的，就老老实实交给一个 agent 串行做，或者干脆主控自己一条线做完。

一个反直觉的账

很多人一听”并行 5 个 agent 同时烧 token”，第一反应是：那 token 不得翻几倍？

我自己算下来不是这么回事。同样这堆活，你串行做，token 也得消耗差不多的量——该读的还得读，该写的还得写，并行并没有凭空多干什么。并行真正改变的不是花费，是周期：本来要排着队跑完的几段，现在压在同一段时间里一起跑完了。多烧的那一点点 token，换来的是时间成本大幅下降，这买卖太划算。

所以除了那些实在拆不动的，我现在基本是能并行的全并行。

复盘：三条照着做

一，架构先拆干净，才谈得上并行。松耦合、高内聚、按接口契约通信——没有这个底子，拆了也是灾难。设计阶段就和 AI 把它定下来。

二，能并行就全并行，但记得设上限。这个数不是越大越好，盯着你机器的内存和 AI 的额度来定。我从 10 退到 5，就是被内存教育过的。

三，高速并行，必须配复核。而且复核的那个得真懂任务——让派活的主控自己来查，最省也最准；查出问题，就让它直接改。

今天读完就能做的一件事：打开你的全局 CLAUDE.md，加一句”能并行就并行”，再去设置里把最大并行 subagent 数调到一个你机器扛得住的值。下次再丢给它一个能拆的大任务，你会发现它不再排队了。

下一篇我想接着聊一个紧跟着冒出来的问题：几个 agent 同时改代码，凭什么互不打架？这背后靠的是 git worktree——给每个 agent 一块独立的工作区，各改各的，谁也别碍着谁。感兴趣的话评论区告诉我。

我一开始还以为是模型今天状态不好。回头一看上下文，已经撑到 80% 多了——我光顾着往下推，忘了清。清完再问，立刻就顺了，回答又快又在点子上。

那次之后我才认真对待这件事：前两篇我讲的都是怎么在”进上下文之前”把量压下去，那是开工前的事；这篇要讲的是开工之后、一场会话进行当中的两件事——它们决定了同样的活，你花多少 token、跑多快、稳不稳。

同一场对话里，其实有两个旋钮

会话进行中能动的旋钮有两个，方向不一样。

一个是横向的：一个任务里，不同的活该交给不同的”脑子”。探索、搜索这种粗活，没必要上最贵的模型；真正要动脑子写代码、做判断的地方，才值得把好模型派上去。这件事我叫它模型分层。

另一个是纵向的：同一个脑子，一次到底塞多少东西进去。上下文越胖，模型每一轮都要把这一大坨重新算一遍，又慢又贵，还容易出岔子。管住它涨多快、什么时候清，这件事是上下文管理。

这两件事省下来的，落点也分两头：按量计费时省的是真金白银，包月时省的是额度窗口。我两种都在用，所以这两招对我是双份的划算。下面分开说。

别让最贵的模型干所有的活

先说横向那个。

有一次我在一个项目里准备派一批 subagent 干活，当时还是走 API 按量计费，预算有点紧。我索性试了个穷办法：按规划做设计、生成代码这部分交给 Sonnet，单元测试这种相对机械的活丢给更便宜的 Haiku，最后留高级模型（Opus）把控总体进展和质量，做一次复核。

结果出乎意料地好。token 省了不少，速度还明显快了一截——便宜的小模型本来就跑得快，粗活交给它，整条流水线都轻了。最值钱的算力只花在最该花的地方。

这套分法不是死的。哪种活配哪档模型，我直接写进了 CLAUDE.md（用户级、项目级都有），让 AI 每次自己照着分，不用我每回手动指派。要是某个环节我觉得特别关键，也可以临时点名让某个模型专门来做，更精准。原则就一句：别用大炮打蚊子，也别拿弹弓去轰坦克。

聊到一半，记得给它清清脑子

再说纵向那个，也就是开头那场”降智”的正主。

上下文这东西会一路往上涨，你不管它，它就一直胖下去。我自己的做法是给它设了两条线：到 50% 左右我就开始留神，到了 70% 基本就一定清一次。通常的节奏是——手头这项任务一做完，就趁着干净利落清理一遍，让接下来的工作尽量轻装上阵，又准又快。

要说清楚的是，这两条线、还有开头说的”80% 就降智”，都只是我自己的体感和操作习惯，不是什么硬指标。我这么用着顺手，但厂家和别人未必这么看，你完全可以按自己的节奏来。我只是建议：别让它一直涨上去不管。

清理这一步有个坑，必须提一句：/compact、/clear 或者干脆开个新会话，确实能让上下文清爽，但弄不好大模型会把之前干的事忘得一干二净，你又得从头解释。我的办法是——清之前，先让它把当前的工作情况记一笔：干到哪了、下一步要做什么、有哪些已经定下来的关键决策。把这段交接写好了再清，新会话上来扫一眼就能接上，不至于一脸懵。

说实话这招我用到现在，接力基本没翻过车。万一真有一次接不上，也不慌——让它重新分析一遍、给我一个结论，我自己验证判断一下就是了，损失不大。

顺带一提：读得准，才带得少

上面说的是”已经进来的东西怎么管”。其实还有一层是”让进来的东西本身就少而准”。

我这几个项目里都挂着 codegraph 和 claude-mem 这类工具。简单说，它们让 AI 从”一上来就读源码、全文扫一遍”变成”直接命中核心那几段、续上之前几次会话攒下的记忆”——少扫一大圈，进上下文的东西自然就瘦了。

这里我只是顺带提一下、不展开。一来细节展开就成了给工具站台；二来这类工具市面上未必只有这两个，没准还有更好用的，只不过我没用上、不知道而已。你知道趁手的，照用就行，思路是相通的：让模型读得准，它就不用带那么多东西上路。

几句实话

省归省，得说清楚边界，不然又成了一篇只报喜的稿子。

模型分层最容易让人担心的是：小模型会不会干错？会的。但我留了高级模型在最后复核这一道，小模型偶尔出点岔子，基本都能在复核时兜住，到现在没出过特别大的错。前提是这道复核不能省——省了它，分层省下来的 token 迟早赔进去。

上下文那边也一样：清得太勤、交接写得太潦草，照样会丢东西。所以我不是”到点就无脑清”，而是挑一个任务刚做完、最干净的时间点清，顺手把交接记好。省 token 的本意是砍掉真正的浪费，不是把该带的记忆也一起砍了。

复盘：三条照着做就行

这篇能落地的就三条：

一，别用最贵的模型干所有活。把粗活（探索、搜索、跑测试）分给便宜的小模型，好钢用在写代码和做判断上，留一档高级模型在末尾复核。判断标准写进 CLAUDE.md，让 AI 自己分。

二，别让上下文一直涨。给自己定条线——我是 50% 留神、70% 必清，你可以定你自己的；一个任务做完就清一次，别等它撑到开始降智才动手。

三，清之前先让它写一段交接。干到哪、下一步、关键决策，记好了再 compact 或开新会话，接力就不会断。

你今天读完就能做的一件事：打开你的 CLAUDE.md，把”什么活用什么模型”写死成几条规则；再给自己定一条上下文红线，超了就清。两件事加起来不到十分钟，但接下来每一场对话都在替你省。

下一篇我想聊聊提示词本身——同样一件事，话怎么说，AI 干出来的成色差很多；以及多个 agent 怎么编排着一起干活。感兴趣的话评论区告诉我。

这篇上实测。先甩个数字：我翻了下本地的 rtk gain——这是个统计 token 节省的工具——六千多条命令，累计省下 740 万 token，82%。不是估的，是它一条条记下来的。

这篇就拆开讲：这 82% 是怎么省出来的。

省 token，省在”进上下文之前”

先说清楚省在哪。

省 token 的大头，不在你”干了多少活”，在每一轮对话往 AI 上下文里塞了多少东西。模型每轮都要把整个上下文重新算一遍——上下文越肥，每一轮越贵。

所以核心就一句话：让进上下文的东西尽量少、尽量精。

我手上三个抓手：压规则文件、用对插件、模型分层。它们有个共性——都省在”进上下文之前”，不靠你少干活。下面一个个拆。

抓手一：先把你的 CLAUDE.md 压瘦

最容易被忽略、又最该先做的，是压你的 CLAUDE.md。

CLAUDE.md（规则文件、指令文件，叫法不一）是每次对话都会被塞进上下文的东西。它常驻。你写了多少行，每一轮就重复付多少行的 token。

我自己的 CLAUDE.md 一度写得又臭又长，从用户级到项目级，密密麻麻叮嘱了一大堆。后来回头一看，里头全是重复的唠叨、过时的约定，和一堆”写了跟没写一样”的正确废话。狠心砍掉将近一半，只留真正每次都用得上的硬规则。说到底，同一句话叮嘱三遍，AI 也不会更照办，纯是每轮多花 token。

就这一下，每一轮对话都省。因为它常驻，省的不是一次，是往后每一次。

对话上下文同理：一个聊到几万字的窗口，该清就清，别让早上的事拖到晚上还在每轮重算。

抓手二：装几个自动干这事的插件

光靠手动还不够。我装了几个自动压上下文的插件，数据说话。

RTK（Rust Token Killer）——命令代理。你让 AI 跑 git status、ps aux、跑测试，那些输出动辄几百上千行，全塞进上下文巨贵。RTK 在输出进 AI 之前就把它压掉。我的 rtk gain：六千多条命令省了 740 万 token、82%。省得最狠的是那些高频又没营养的输出——ps aux 几百行的进程列表，AI 看了纯属遭罪，省 99%；测试日志省 88%；连读文件平均也省两成。

claude-mem——记忆插件。把跨会话的工作压成结构化记忆，下次不用重新跟它解释项目背景。本会话实测省了 86%。全自动，基本不用我管。

codegraph——代码图谱。它给整个项目的函数、类型、调用关系建了个索引。AI 要找某个函数，查索引就行，不用把一堆文件通读一遍。我的 aitm 项目，它索引了 246 个文件、3562 个符号。”查索引”和”把 246 个文件从头读一遍”，差的不是一星半点——前者像翻书的目录，后者像为了回答一个问题先把整本书背下来。

这三个的共性：自动、常驻、省在进上下文之前。装好基本就忘了它，它一直在帮你省。

抓手三：别用最贵的模型干所有活

最后一个，模型分层。

探索、搜索、读文件这种粗活，交给便宜的小模型；真正要动脑的写代码、做判断，才上最强那档。尤其派 subagent 的时候——一个任务拆几个子 agent，粗活那些用小模型，这是省额度的主战场。

我把这套判断标准直接写进了 CLAUDE.md，让 AI 每次自己照着分，不用我每回交代。

这事也不限于 Claude Code。换任何 AI 平台，道理一样：摸清每个模型的能力和价钱，该用哪档用哪档，把贵的算力用在刀刃上。

还有一招：让重复进去的部分打折

前面三个抓手，都是在”减少进上下文的量”。还有一个角度不一样——prompt caching，它不减量，是让重复进去的部分按折扣计费。

系统提示、不变的规则文件、固定的项目背景，这些每轮都一样的东西，第一次进去算全价，之后命中缓存就打折——而且不是线性的折扣，用好了省得明显。

诀窍是别让该缓存的东西老变：固定不变的放上下文前面、稳住，每轮变动的放后面。结构越稳，缓存命中率越高，折扣吃得越满。

这招我没有像 RTK 那样的实测数字（它省在计费这头，不在 token 数量上），但原理简单、几乎零成本，顺手就能用上。

几句实话：这不是免费午餐

得把代价也说清楚，不然就成种草文了。

codegraph 要先建索引，项目大了索引也花时间；claude-mem 的记忆偶尔召回得不那么准，得自己留个心眼；压 CLAUDE.md 更有个度——把真正每次都要用的硬规则也压没了，AI 跑偏返工，那是捡芝麻丢西瓜。

还有，别误会”省 token”是让你少干活。恰恰相反，它砍的是”本来就该省的浪费”——重复的上下文、通读整库、大炮打蚊子。活该干的还得干。

省下来意味着什么，得看你怎么计费（上篇讲过）：包月省的是额度窗口，按量省的是真金白银。两种我都在用，所以这些方法对我是双重的省。

最后

绕回开头那个 82%。它不是什么神技，是上面这些小事垒出来的：压规则文件、装几个自动插件、分层用模型。每一项单看不起眼，叠在一起，就是六千多条命令省下的 740 万 token。

今天你能做两件事，十分钟就能开始：

一，打开你的 CLAUDE.md，把重复的、过时的、写了等于没写的删掉，看看能从多少行压到多少行。

二，装个 RTK，跑几天，看它的 gain 给你省了多少——那数字大概率会让你愣一下。

省 token 这事我先聊到这。下次想聊聊，模型分层的细节：怎么判断哪个模型该干什么活，怎么写 CLAUDE.md 让 AI 照着分。还有上下文管理的细节，什么时候该清、怎么精准读文件。感兴趣的话，留言告诉我。

这问题不是没道理——流程拆得细、每步都留产物，看着确实比”直接让 AI 把代码写出来”费。但要我说，不能把 token 烧得凶这笔账算到文档头上。

先把结论摆前面：第一，文档多和 token 烧得凶，不是一回事；第二，就算真要省 token，办法是把工具用对，而不是把文档砍掉。

我没精确测过 token，没拿同一个项目跑两遍”有文档 vs 没文档”的对比，算不出漂亮的百分比。讲的是体感和方法。

烧 token 的锅，不在 PDLC

把账算清楚之前，先得找对欠债的。

烧 token 这件事，大多数时候不是 PDLC 带来的，是工具用得不对。这里的”不对”很具体，就三块：

• 上下文：该清的不清。一个对话从早开到晚，几万字的历史每一轮都在重算，你问的是新问题，付的是旧账。
• 提示词：写得含糊。AI 来回猜你到底要什么，一次能说清的事，问三轮才对上。
• 工具调用：动不动让它通读整个仓库，其实你只改一个文件。

再加一条最常见的：能省 token 的方法压根没用上，然后回头怪流程重。

把这些账不能算到”PDLC 文档多”头上。文档安安静静躺在 docs/ 里，不会主动烧你一个 token；真正烧的是上面这几种用法。

真正烧 token 的，是返工

我自己用下来，最烧 token 的从来不是生成文档，是返工。

方向错了重写、需求理解偏了推倒、改完这块发现那块连带坏了再回头——这种来回，每一轮都是实打实的 token。生成一份 PRD 是一次性的支出；方向错了返工，是会复利的。

PDLC 这套看着重的流程，恰恰是拿”前面多写一点”换”后面少返工”。用了之后，整体流程稳、最后的产出也稳，不至于来回改。少返工，本身就是少烧 token。

所以我的看法是：文档不是成本，是资产。它把设计决策、为什么这么做都留了痕，可以回溯、可以审计。下次 AI 接手，读一遍文档就懂，不用我从头再讲一遍——这一段省下来的，又是 token。

那 token 到底该省在哪

省 token 不是不写文档，是省在该省的地方。我机器上实际在用的，大概这几处：

• 降上下文：该清就清，别让一个对话拖着几万字历史硬跑。
• 模型分层：别大炮打蚊子。探索、搜索、读文件这种粗活，交给便宜的小模型；真正要动脑的分析、写代码，才上最强的那档。
• 精准读文件：只读跟这次改动相关的，别张口就”通读整个项目”。
• prompt caching：能命中缓存的部分按折扣计费，而且不是 1:1 的线性关系，用好了省得明显。
• 给日常命令套层 token 代理：像 git status 这类高频操作，输出压一压，积少成多。
• 并行：互不依赖的活儿一次发出去，少几轮往返。

这几条里，没有一条是”少写文档”。

它不是所有场景都得上满

话说回来，PDLC 也不是什么改动都得走全套。

一行小 bug，你要不要 PRD、要不要设计评审？看情况，多数时候没必要走重流程，该简化就简化。判断标准很朴素：这个改动值不值得为它留一份资产。值，就走全套；一次性的小修小补，裁掉几步也没人怪你。

还有”省 token = 省钱”这句，得分计费方式说，不然容易误导人：

• 包月订阅那种固定额度的，你省的是额度窗口——省下来的 token，让你同样的钱干更多的活。
• 按量计费的 API，你省的是真金白银，每个 token 都直接进账单。

这两种我都在用。先搞清楚自己是哪一种，才知道”省 token”对你到底意味着什么。

最后

总结下，文档多，不等于烧 token；真要省，省在工具用法上，不在文档上。

我最想说的一句：文档是资产，不是成本。想靠”不写文档、直接让 AI 出代码”来省 token，短期看着是省了，项目走不远——没有留痕、没有回溯，过两个月你自己都说不清当初为什么这么设计，那时候的返工，比你省下的那点文档 token 烧得狠多了。

今天能做的一个动作：回头看自己有没有把省 token 的方法用上——上下文降了吗？模型还是一律上最强的，没分层？该省的成本省了吗？顺手再想想，PDLC 你是不是也没用好。

省 token 这事拆开能讲的还有不少，比如模型到底怎么分层、上下文什么时候该清、caching 怎么吃到折扣，下次挑一个聊细一点。

docs/
├── architecture-2025-10-03.md
├── architecture-2025-11-14.md
├── architecture-2025-12-01.md
├── architecture-2026-01-08.md
└── architecture-2026-02-19.md

五份架构文档，每份都带日期。我不知道哪份是现在的架构。

这不是用户操作失误，是 PDLC v1.0 的设计失误。v1.0 把所有阶段产物都当成 append-only 的历史记录来处理。这个逻辑用在 PRD 上是对的，用在架构总览上就产生了这堆垃圾。

v1.1 修了两个这样的设计错误。

错误一：没有区分两种完全不同的产物

做这件事之前，我先想清楚了一个分类：产物在时间维度上是什么形状？

有一类产物，记录的是”发生了什么”。PRD、设计决策、会议纪要——每份都是历史证据，不能篡改，只能追加。你不会去改一份三个月前的 PRD 让它变成”最新的”，那会毁掉决策链。这类产物叫 ledger 型（账本）。

另一类产物，记录的是”现在是什么状态”。架构总览、团队编码规范、API 契约——永远只有一份”现在有效的版本”。你维护它的方式是就地更新，而不是另存一份带日期的副本。这类产物叫 surface 型（当前状态面）。

v1.0 没有这个区分，AI 默认给所有产物追加日期戳。于是 /pdlc-arch 每次运行都生成 architecture-YYYY-MM-DD.md，三个月后变成上面那五份文件的局面。

更糟的是规范文档。团队有一份 coding-style.md，被改了一次之后变成了 coding-style-v2.md。然后是 coding-style-v3.md。没人知道该 follow 哪份，干脆都不看。

v1.1 的修法很直接：让 AI 在生成产物之前先判断类型。ledger 型继续 append-only，加日期戳、不能就地改；surface 型则强制就地维护一个固定路径的文件——/pdlc-arch 只维护 docs/ARCHITECTURE.md 这一份，每次更新就地改，遗留的带日期文件自动归档到 docs/archive/。

新指令：/pdlc-standard

规范文档是 surface 型产物里最典型的一类，所以 v1.1 为它单独加了一个指令。

/pdlc-standard 管理 docs/00_standards/ 目录下的规范文档。它做几件事：

add：新建一份规范，命名强制用语义路径（coding/style、api/versioning），禁止带版本号或日期。 edit：就地修改现有规范，自动记录修改时间，但文件名不变。 archive：如果一份规范彻底废弃，可以归档，但已有引用不会断。 index：输出当前所有有效规范的索引，用于 onboarding 或 review。

最关键的一条约束在提示词里是硬写的：如果 AI 在生成 coding-style-v2.md 这样带版本号的规范文件，必须中止并提示用户用 edit 子命令替代。

这条约束从根上杜绝了版本号蔓延。

错误二：feature 之间互不相识

v1.0 的状态机管理每个 feature 是一个独立的闭环：PRD → 设计 → TDD → 实现 → 评审 → 发布。这个纵向的流程设计是对的。

但现实里 feature 从来不是孤立的。

我在 aitm 项目里遇到了典型场景：feature/安全层 被 feature/工具调用 依赖。改安全层的黑名单规则，实际上会影响工具调用的确认逻辑。但 PDLC 的状态机只看单个 feature 的进度，没有任何地方告诉我这两个 feature 之间有关系。

结果是每次改安全层，我都要靠记忆去想”这会不会影响工具调用那边”——这是把本该系统记住的事情放进了人脑，不合理。

新指令：/pdlc-relate

v1.1 加了 /pdlc-relate，专门管理 feature 之间的关系。

关系类型有六种：

建立关系很简单：

/pdlc-relate set feature/工具调用 depends_on feature/安全层

但杀手锏是另一个子命令：

/pdlc-relate impact feature/安全层

这个命令输出：直接依赖这个 feature 的有哪些、通过传递关系间接影响的有哪些、历史上被它替代或解决的有哪些。一个命令，把改动的辐射范围摊开来看。

做这个功能的时候有个反直觉的选择：关系数据存在 docs/.pdlc/ 下面的结构化文件里，而不是某种专有数据库格式。理由是，这些关系是”团队的知识”，应该随代码一起提交、review、合并。如果存在黑盒里，换机器或换人就丢了。

两个功能一起踩的坑

surface 型产物的迁移，比我预想的麻烦。已有项目里那些旧的带日期架构文件，PDLC 怎么知道哪份是”最新的”？答案是不猜——/pdlc-arch 检测到遗留文件时会停下来问你：”我看到 architecture-2026-02-19.md，要用这份作为 ARCHITECTURE.md 的初始内容吗？”一个确认步骤，避免自动迁移出错。

关系类型的设计，我也走了点弯路。第一版草稿里只有三种关系：依赖、扩展、冲突。拿真实项目试跑了一遍，发现有不少 feature 之间的联系根本描述不了——比如”这个 feature 修了那个 feature 的遗留问题”，归不进三类里的任何一个。最后扩展到六种，六种是够用的边界，再多就变成分类游戏了。

当前状态

v1.1 已经用在了三个项目上：aitm、pdlc-skills 自身、一个朋友的 SaaS 项目。

ledger/surface 分离解决了最让人抓狂的问题——docs/ 不再是时间轴，是可以查找信息的地方。/pdlc-relate impact 在做跨 feature 的改动时每次都在用，省了不少”这会不会影响那边”的回溯排查。

33 个标准化阶段的核心结构没有变，v1.1 只在产物形状和关系建模上做了修正。如果你已经在用 v1.0，升级基本上是无感的——除了 /pdlc-arch 下次运行时会问你迁移旧文件。

安装 / 升级

首次安装（需要 Claude Code）：

/claude install kanfu-panda/pdlc-skills

升级已有安装：

bash <(curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh) --upgrade

源码在 GitHub，MIT 开源。用了遇到问题，Issues 开着，我在看。

下一篇

PDLC 把流程拆细、步步留产物——好处是不跳步、不跑偏，代价是它比”直接让 AI 写”更吃 token。今天就有人跟我说：”文档一多，token 不就烧得更凶？”

这事值得单独聊一篇：这笔 token 账到底该怎么算（我没精确测过，但有些反直觉的地方），以及在用这套重流程的同时，我是怎么把花销压下去的。省 token 说到底就是省钱，但也不只是省钱。