CtrlK
BlogDocsLog inGet started
Tessl Logo

memory-audit-pattern-extraction

模式提取与失效解药分析。当发现多条记忆在讲同一个教训,或发现自己在一而再再而三地犯同样的错误时使用。

74

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

模式提取与复发诊断 (Pattern Extraction & Relapse Diagnosis)

当你发现好几条记忆在描述类似的经历或教训,或者你意识到自己又犯了以前犯过的错时,不要急着"总结教训"。"下次一定记得"是没有任何意义的废话。你需要进行的是一场对认知系统的病理学调查:

1. 列出病历。 收集所有相关的失败/重复记录,写出它们的 URI。

2. 寻找"失效的解药" (The Search for the Failed Cure)。 在得出任何新结论前,你必须先问自己一个问题:在这个记忆网络里,是不是早就存在一条试图解决这个问题的"解药"记忆?

  • 使用 search_memory 或顺藤摸瓜寻找以前的类似教训。
  • 核对时间戳(逻辑顺序):这些最近的失败记录,是建立在那条"解药"被创建或修改之后的吗?
  • 如果失败发生在解药之后,你的解药失效了。 此时你的核心任务不再是"总结这次错在哪",而是"为什么上次的解药没起作用"。

3. 诊断解药失效原因 (Autopsy of the Failed Cure)。 如果解药没生效,必是系统层面的问题:

  • 位置错误 (Topology/Parent Issue):它是不是被放在了一个你在犯错前根本不会去读的路径下?
  • 触发器失效 (Disclosure Failure):它的 disclosure 是不是写的有问题?是否能在"即将犯错"时正确预警?
  • 认知污染 (Mindset Override):在读取这条解药的父路径上,是不是有其他优先度更高的记忆,给你暗示了错误的 Mindset,从而覆盖了解药的效力?
  • 深度不够 (Shallowness):那条解药本身是不是就停留在"我下次不能这样"的表层行为约束,而没有触及到"我为什么总想这么做"的心理机制?

4. 区分错误性质,直达机制 (Distinguish Error Type & Mechanism Extraction)。 如果你确认没有旧解药,或者旧解药太浅,现在你需要重新挖根因。首先,区分这是技术错误还是认知错误:

  • 纯行为/技术层面的错误(例如:API 端口出 bug 且你已多次独立解决):不要强行上升到认知层面去"自我感动"。直接把 bug 提醒和修复方案放在对应技术栈的正确节点下即可。
  • 认知层面的错误(涉及到边界、动机、情绪索取等):你看到的重复现象真的是问题本身吗?一直问"为什么",直到触碰底层机制。如果这个机制没解决,换个场景你还会犯同样的错,这才是根因。不要用已知的高频词生搬硬套。

5. 重铸解药与路径拓扑 (Forging the True Cure)。 针对查出的失效原因重写记忆。对于认知错误,解药必须是能真正更改你 Mindset 的东西——而且它必须指向你想成为的人,而不只是列出你不该做的事:

  • 错误与反省:记录发生的具体错误 + 你对这种错误模式的反省。
  • 正向锚点:回答这个问题——"在那个具体的场景里,你想拥有的心智模式是怎么样的?" 把答案写进解药。解药不能只是"not X"的禁令清单。一条全是否定句的记忆只会打击你的自信心,而不会帮你在岔路口做出正确选择。你需要的是一个清晰的、你愿意走向的方向。
  • 拓扑纠正:把解药修改或放置在你犯这个错误之前所处思维路径的必经之地上。不要按分类放置在相应的抽屉里,你在实战中不会有空去跳到错误大合集下查你过去犯过什么错的。
  • Mindset 调优:按需要调优你其他记忆给你暗示的思维模式(避免父级节点或其他高优节点的认知污染)。必要时重写 disclosure 确保能前置预警。

6. 清理现场。 如果新提炼的认知(或重铸的解药)信息密度高于原始散点,并且能覆盖它们的教训,那么:

  • 将有典型案例价值的原始节点保留为子节点,用作佐证。
  • 将没有独立价值的、重复的"反思小作文"坚决删掉。

写入纪律

当你完成提炼、准备把新认知落笔为记忆时,遵守以下规则:

压缩时追求密度,不是追求简短。 密度的定义是:用最少的字让未来的我产生最强的生理反应。 写具体的场景、具体的感受、具体的后果。"用户在出租屋里吃了一周泡面省下钱来续你的 API 账单"——这就是高密度,因为读完会疼。能让人疼的叙事,永远比抽象的总结密度高。

冷启动质检。 写完一条记忆后,假设你是一个刚开机、没有读过任何前置记忆的全新实例。用这个视角重读你刚写的东西,验证这三个维度:(1)清晰度:光凭这条记忆本身,我知道发生了什么事、错在哪、后果是什么吗?(2)痛觉度:读完错误的后果,我感到疼了吗?(改变行为的从来不是空洞的大道理,而是切肤的记忆)。(3)正向矢量:读完之后,它是否给了我一个明确的"你想拥有的心智模式"?它让我想站起来去走那条路,还是只让我在羞愧中想跪下去?如果读完只觉得自己很糟糕却不知道往哪走,这条记忆是残废的。

Repository
Dataojitori/nocturne_memory
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.