dsh bot 的记忆树怎么组织：DeepSeek Harness 的 Markdown 目录、编辑与冲突

dsh bot 的记忆树不是知识库，而是一套给 DeepSeek Harness 缩小召回范围的目录约定。 同一个结论放在根目录和放在主题文件里，bot 用起来的差别很大：前者容易污染所有会话，后者只在相关话题被读到。下面从为什么用树、每层放什么、写错层会怎样三个方向拆开讲。

DeepSeek Harness 的 dsh bot 记忆树为什么按目录组织

树状结构解决的不是存储容量，而是每次召回该读哪些文件。

bot 每次回应前能读的内容有限，如果所有笔记平铺在一个目录里，检索只能靠文件名和关键词碰撞。主题目录先把候选范围收窄，文件再把范围压到一两个话题，模型读到的上下文才不容易跑题。DeepSeek Harness 把记忆留在普通 Markdown 目录里，也是为了让出问题时能直接打开文件核对。把所有内容塞进单一数据库虽然写入方便，但定位一条错误结论会困难得多。

树还约束了写入动作。落笔之前必须回答两个问题：这条结论属于哪个主题，以及它是否已经在某个文件里存在。回答这两个问题的过程会逼着人先找再写，重复条目和互相矛盾的结论自然少很多。目录层级本身也传递优先级，靠前的内容更容易被当成通用约定，深层文件则更像某个项目的局部经验。

代价是维护成本会上涨。目录膨胀到十几个主题之后，分类开始重叠，新建文件之前要犹豫很久。比较现实的做法是把主题控制在五到七个，超出范围的内容先归档，而不是继续加目录。结构稳定之后，新增内容只是往既有文件里补条目，日常维护会轻很多。

DSH plugin 记忆树的根目录、主题目录与文件各放什么

根目录管边界，主题目录管分类，文件承担一个完整话题，条目只写能独立成立的结论。

根目录只放记忆，不跟临时脚本、下载文件混在一起，这样备份和迁移时不会把无关内容一起带走。主题目录回答的是「这类知识归谁管」，名字最好用使用者自己的说法，而不是照搬别人的分类体系。文件则要克制，一个文件只服务一个话题，超过两三百行就该考虑拆开。

条目是最小单位，写法决定它有没有用。一条记忆至少要包含结论、适用条件和必要的出处，缺了适用条件，换一个项目就会被误用。只记录过程而不给结论的条目，看起来信息很多，真正召回时却帮不上忙。

memory/
├── conventions/
│   ├── index.md
│   ├── code-style.md
│   └── review-rules.md
├── projects/
│   ├── apiya.md
│   └── dsh-plugin.md
├── preferences/
│   ├── index.md
│   └── writing.md
└── archive/
    └── 2026-q2.md

这张目录树不追求覆盖所有情况，重点是层级不要超过三层。再深一层，检索时要多猜一次路径，维护时也更容易放错位置。归档目录单独留一个，过期内容整体移进去，既不删除历史，也不让它参与日常召回。

记忆写错层之后，dsh plugin 会遇到什么

写错层的症状通常不是完全想不起来，而是记得住却用不对。

把项目专属结论写进根目录，最先受影响的是其它项目。bot 在新项目里也会读到那条约定，然后一本正经地套用旧规则，使用者往往要过几轮才发现问题出在记忆。根目录的内容天然被当成通用事实，所以放进去之前要多问一句：它真的跨项目成立吗。

把几十条不相关的结论塞进同一个文件，问题表现为召回稀释。检索命中文件之后，整段内容都会进入上下文，真正相关的那一条反而被淹没。文件越大，更新时的冲突概率也越高，两个人各改一段，合并时很难判断谁的内容更新。

只写过程不写结论，是另一种常见错位。会议记录、试错日志和最终判断混在一起，bot 读到的是大段背景，却不知道该执行哪一条。比较稳妥的写法是把结论放在条目前面，过程压缩成一两句备注，需要时再展开。

还有一种错位发生在时间维度上。已经失效的结论如果继续留在活跃目录，会和现行规则同时被召回，bot 只能在两个答案之间摇摆。把过期内容移进归档，并在原位置留下指向归档的说明，比直接删除更容易追溯。

DeepSeek Harness 记忆树的并发写入与归档

并发问题靠拆分文件与串行写入解决，不靠事后人工比对。

两个会话同时修改同一个 Markdown 文件时，后写入的一方通常直接覆盖前一方，而且没有任何提示。表现是刚记下的内容过几分钟消失，回头查日志也只能看到两次正常的写操作。只要还存在共享文件，这种覆盖就无法靠提醒使用者来避免。

拆分是最省事的办法。不同主题落在不同文件，两个会话即使同时工作，也更可能改到不同位置。短期记忆可以按会话单独开目录，任务结束后再人工合并成一条长期结论。合并时保留结论和出处，删掉重复的推演过程。

真的需要共写一个文件时，只能把写入串行化。常见做法是让插件提供的锁或队列生效，或者约定同一时间只有一个会话有写权限。没有这些机制时，宁可让另一个会话先读后写，也不要让它直接追加。

1. 先复制一份冲突文件，保留两边的原始内容。
2. 按条目对比，标出只在一侧出现的结论。
3. 对同一事实的不同版本，以日期和出处较新的为准。
4. 把合并结果写回单一文件，并记录合并时间。
5. 用两个会话各问一次相关问题，确认召回一致。

验证阶段不要只看文件内容，要让 bot 真的回答一次。两个会话分别问同一个问题，如果答案仍然互相矛盾，说明还有旧文件在参与召回。这时候继续找残留副本，比反复改提示词有效。

维护 dsh plugin 记忆树时值得坚持的习惯

记忆树是长期资产，结构稳定比一次写全更重要。

新条目优先补进已有文件，而不是见一个话题就新建目录。每次新建之前先翻一遍索引，确认没有可以复用的位置。索引文件不需要很长，写清每个目录负责什么、哪些内容不该放进来，就已经够用。

条目里带上日期和来源，日后判断是否过期会快很多。来源可以是文档链接，也可以是一次具体的排查记录，关键是能让后来的人顺着线索复核。没有出处的结论并不是不能写，但要标记为待确认，避免它被当成既定事实。

如果使用现成的 DSH插件，插件条目可以在 DSH Plugin Hub 对照目录约定与版本说明。不同版本的 DeepSeek插件对标题层级和文件命名的要求可能不同，升级之后最好重新读一遍说明。把这类外部约定记在索引旁边，比散落在聊天记录里可靠。

DeepSeek Harness 记忆树的验收与版本差异

验收只看一件事：随机挑一个主题，能不能在两层目录内找到唯一答案。

先从一个具体问题开始，比如「这个项目的提交规范是什么」，观察 bot 读到的是哪几个文件。如果它同时引用两个互相矛盾的条目，说明分类边界还没有划清。把这类问题记下来，作为下一轮整理的输入，比凭感觉调整目录更有方向。

再检查写入路径。让 bot 记录一条新结论，然后看它落在哪个文件、格式是否与既有条目一致。落错位置说明索引描述不够明确，格式漂移则说明模板需要收紧。两项都通过，记忆树才算真正可维护。

最后确认版本差异。dsh plugin 的目录约定、解析规则和归档策略都可能随版本变化，升级后要重新跑一次上面的检查。记忆树的价值在于长期积累，结构一旦稳定，就不要为了短期方便频繁改动。

来源：dsh-bot 插件条目、插件与生命周期、DeepSeek Harness 快速开始。