1. 从 dsh-obsidian 能读到知识库开始召回回归测试前先固定 TaoToken 模型出口在 DeepSeek Harness 里把 Obsidian 接上之后真正让我停下来的是召回回归用例没法稳定复现dsh-obsidian 已经能读取 vaultobsidian-knowledge-evolution技能也能被斜杠匹配到但项目 D 的召回状态一改不同会话给出的待召回列表偶尔会漂。为了让“唯一待召回项目”这个断言可重复我先去 TaoToken 官网拿 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-intro Base URL 固定写成 https://taotoken.net/api Key 在本地先用YOUR_API_KEY占位。这样后面不管是让外部 CLI 读SKILL.md还是在 DeepSeek Harness 会话里执行知识召回模型出口都是同一套回归结果不会因为供应商切换而变。这篇不写“Obsidian 跑起来了”的安装爽文而是站在回归用例设计者的位置把项目 D 改成false检查待召回列表是否只剩“召回回归测试”再正式跑召回核对更新产物。整条链路可以拆成四层本地 Obsidian vault → dsh-obsidian 插件 →obsidian-knowledge-evolution技能 → TaoToken 提供的模型出口。下面每一步尽量给可复制命令、可检查文件、可断言的输出避免“看起来跑通了”但无法回归。先给一个总览断言后面所有操作都围绕它展开输入项目 A、B、C、D 已存在C、D 曾经完成召回项目 D 的副本被改成 knowledge_recallfalse。 执行新会话加载 obsidian-knowledge-evolution触发知识召回状态扫描。 预期待召回集合长度 1且唯一元素 召回回归测试。 最终正式召回后召回回归测试.md 状态翻转为 true日志追加召回记录项目 C/D 主文件不被重复更新。2. 回归用例设计把项目 D 复制成“召回回归测试”并改成 false先准备测试 vault。原文里的运行目录可以继续用例如D:\source\Obsidian-Harness-Test。为了不破坏已有知识库建议把 A、B、C、D 四个项目文件复制进测试 vault而不是直接在原库上改。复制完成后目录大概是这样D:\source\Obsidian-Harness-Test\ ├─ .dsh\ │ └─ skills\ │ └─ obsidian-knowledge-evolution\ │ └─ SKILL.md ├─ 项目A.md ├─ 项目B.md ├─ 项目C.md ├─ 项目D.md └─ 召回回归测试.md四个项目的状态要提前定义清楚否则回归断言会含糊。可以按下面理解项目 A纯人工维护没有走过知识召回但也不应进入本轮待召回。项目 B半人工维护知识召回状态有特殊标记不应被本轮误判。项目 C较早轮次已经完成召回knowledge_recalltrue。项目 D较早轮次已经完成召回knowledge_recalltrue作为对照保留。召回回归测试从项目 D 复制出来的副本唯一被改成knowledge_recallfalse的条目。项目 D 的原始 front matter 可以写成类似这样字段名以你实际技能约定为准--- project: 项目D knowledge_recall: true recall_version: 3 last_recall_at: 2026-01-15 tags: - 项目 - 已召回 ---复制一份为召回回归测试.md然后只改副本不动原项目 D--- project: 召回回归测试 knowledge_recall: false recall_version: 0 source_project: 项目D tags: - 项目 - 待召回 ---这里有一个容易踩的坑如果原项目 D 也保持false待召回列表就会有两个条目回归用例直接失败。所以原项目 D 必须是true副本才是false。这就是“项目 D 改 false”的可复现含义改的是项目 D 的副本不是把原项目 D 的状态弄乱。写完 front matter 后不要急着启动 Harness。先本地做一次静态检查确认只有召回回归测试.md的knowledge_recall为false。PowerShell 可以这样扫$vault D:\source\Obsidian-Harness-Test Get-ChildItem $vault -Filter *.md | ForEach-Object { $head Get-Content $_.FullName -TotalCount 20 -Encoding UTF8 $flag ($head | Select-String -Pattern knowledge_recall:\s*(true|false)).Matches.Value [PSCustomObject]{ File $_.Name RecallFlag $flag } } | Format-Table -AutoSize预期输出里项目 A、B、C、D 不应出现knowledge_recall: false只有召回回归测试.md出现knowledge_recall: false。如果这里就不唯一后面模型再稳也没用因为输入已经错了。3. 在 DeepSeek Harness 里加载 obsidian-knowledge-evolution 技能并断言唯一待召回项环境准备可以按原文思路走但命令要按你自己的机器路径调整。Windows 下先确认 NVM、Node、pnpm 可用nvm version nvm install 22.22.3 nvm use 22.22.3 node -v npm install -g pnpm pnpm -v接着进入 DeepSeek Harness 的运行目录安装依赖并启动 Webcd D:\source\DeepSeek-Harness pnpm install pnpm approve-builds pnpm exec dsh webpnpm approve-builds中途会让选择依赖包按提示全选后继续即可。启动后浏览器会自动打开 Harness 页面。如果这里出现红字不一定是安装失败先看提示是不是“构建脚本未执行”按pnpm approve-builds处理。然后安装 dsh-obsidian 插件。先停掉 Web 服务再执行pnpm exec dsh plugin --profile web add dsh-obsidian插件安装完成后找到 Harness 的 profile 配置文件。不同机器的用户名不同不要死记C:\Users\admin可以用%USERPROFILE%定位notepad $env:USERPROFILE\.dsh\profiles\web\cordis.patch.yml把里面的空数组替换成 Obsidian 配置注意vaultPath要指向测试 vault- id: obsidian config: vaultPath: D:\source\Obsidian-Harness-Test useCli: false保存后重新启动pnpm exec dsh web新建一个命令行窗口在 vault 里创建测试笔记确认插件能读到Set-Content -Path D:\source\Obsidian-Harness-Test\插件连通性测试.md -Value # 插件连通性测试nn这是一条由命令行创建的笔记。 -Encoding UTF8回到 Harness 会话里让它读取知识库。如果能列出插件连通性测试.md说明 dsh-obsidian 已经挂上。接下来迁移技能。技能目录放在 vault 的.dsh\skills下mkdir D:\source\Obsidian-Harness-Test\.dsh\skills xcopy C:\Users\admin\.workbuddy\skills\obsidian-knowledge-evolution D:\source\Obsidian-Harness-Test\.dsh\skills\obsidian-knowledge-evolution\ /E /I /Y notepad D:\source\Obsidian-Harness-Test\.dsh\skills\obsidian-knowledge-evolution\SKILL.md打开SKILL.md后把旧平台名统一替换成DeepSeek Harness其他地方不要改。保存后新开一个会话用/加关键字模糊匹配技能例如输入/obsidian或/knowledge看能不能命中obsidian-knowledge-evolution。命中后先问它一句请确认你当前加载的技能名称、技能目录以及你能访问的 vault 绝对路径。预期回答里应该包含obsidian-knowledge-evolution和D:\source\Obsidian-Harness-Test。如果路径不对回到cordis.patch.yml检查vaultPath不要继续跑召回。技能加载正常后触发召回状态扫描。提示词尽量限定输出结构避免模型自由发挥请基于当前 Obsidian vault 执行知识召回状态扫描。 规则 1. 只扫描 knowledge_recallfalse 的条目。 2. 忽略纯人工项目和半人工项目。 3. 输出 JSON不要输出解释。 格式 {pending:[条目名1,条目名2]}此时期望输出是{pending:[召回回归测试]}如果输出里出现项目C、项目D先去检查它们的 front matter 是不是被误改成false。如果输出为空检查召回回归测试.md的字段名是否和技能约定一致例如技能读的是knowledge_recall你写成了knowledgeRecall就会漏掉。如果输出格式不是 JSON在提示词里再加一句“只输出合法 JSON不要 Markdown 代码块”。到这一步回归用例的核心断言已经成立项目 D 的副本改false后待召回列表唯一且唯一项就是“召回回归测试”。4. 正式召回后的可复现产出状态翻转、日志追加、项目 C/D 不动确认唯一待召回项后再正式执行知识召回。不要在同一会话里直接追加“继续召回”建议新开会话重新加载技能避免上下文残留影响结果。提示词可以写成请对当前唯一待召回项目“召回回归测试”执行知识召回。 要求 1. 读取 召回回归测试.md。 2. 在 vault 中检索相关项目资料。 3. 更新 召回回归测试.md 的 knowledge_recall 为 true并递增 recall_version。 4. 在召回日志中追加一条记录包含时间、项目名、召回来源、更新文件列表。 5. 不要修改 项目C.md 和 项目D.md 的主文件内容。 6. 输出变更摘要 JSON。执行完成后按下面清单核对。这里不要只看模型说“完成了”要看文件系统。检查项预期结果检查方式召回回归测试.mdknowledge_recall从 false 变 true打开 front matter 查看recall_version从 0 增加到 1 或更高查看 front matter召回日志新增一条记录查看recall-log.md或技能约定的日志文件项目C.md主文件未被重复更新对比修改时间或 Git diff项目D.md主文件未被重复更新对比修改时间或 Git diff输出摘要列出更新文件不包含项目 C/D 主文件看会话最后一条 JSON可以在召回前后做一次文件快照Get-ChildItem D:\source\Obsidian-Harness-Test -Recurse -File | Select-Object FullName, LastWriteTime, Length | Sort-Object FullName | Export-Csv -Path D:\source\Obsidian-Harness-Test\before-recall.csv -NoTypeInformation -Encoding UTF8召回后再导出after-recall.csv对比两次快照。合理的变化应该集中在召回回归测试.md和日志文件项目 C、项目 D 的主文件不应该因为这次召回被重写。如果项目 D 的主文件也被改了说明技能可能把副本和源项目混淆了需要检查source_project字段是否被技能当成“递归更新源”。召回结果本身也要看内容质量召回回归测试.md 里是否补上了项目背景、关键决策、依赖约束、历史踩坑日志里是否记录了“为什么这次召回只更新了一个项目”。如果只是把false改成true但没有知识内容增量那只是状态翻转不是有效召回。回归用例通过标准可以定为扫描阶段待召回集合长度严格等于 1。集合元素唯一项等于“召回回归测试”。召回阶段状态从 false 翻转为 true。隔离阶段项目 C、项目 D 主文件没有被重复更新。日志阶段日志新增记录且包含本次召回的依据和文件列表。这五条都满足才算“TaoToken 陪 DeepSeek Harness 跑完”召回回归测试。5. 把 TaoToken 接入 Claude Code、Codex 与 CC Switch 三件套的配置写法DeepSeek Harness 本身负责 Obsidian 插件和技能调度但模型出口可以来自外部 CLI 或兼容端点。为了不让回归测试每次都被供应商切换影响建议把 TaoToken 配置固化。先明确一件事Claude Code 和 Codex 的配置字段不一样不要把ANTHROPIC_*套到 Codex 上。Claude Code 用settings.json或环境变量。settings.json可以这样写{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY } }如果你更习惯临时环境变量在 PowerShell 里这样设置$env:ANTHROPIC_BASE_URL https://taotoken.net/api $env:ANTHROPIC_API_KEY YOUR_API_KEYCodex 用config.toml不要写ANTHROPIC_*。可以这样配置model 按控制台可用模型填写 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY对应环境变量$env:TAOTOKEN_API_KEY YOUR_API_KEYCC Switch 里可以维护“三件套”配置项填写内容说明供应商地址https://taotoken.net/api工具配置 Base URL不加 UTMAPI KeyYOUR_API_KEY从 TaoToken 控制台创建不要提交到 Git默认模型按控制台可用模型选择不要照抄别人截图里的模型名创建 Key 和管理 Key 去 TaoToken 官网控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-config-fixed 。如果你要直接创建 Key走这个 deep linkhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-cta-keys 。配置固化后再跑一次召回回归测试。如果结果和之前一致说明模型出口切换没有引入漂移。如果结果不一致优先检查三处Base URL 是否写成了https://taotoken.net/apiKey 是否替换了YOUR_API_KEYCodex 是否误用了ANTHROPIC_*。6. 其余技能回归清单知识扫描、低风险更新、人工确认、复盘、健康体检召回回归只是技能回归的一部分。既然环境已经跑通可以把其余功能按同一套方法过一遍。每个测试都新建会话重新加载obsidian-knowledge-evolution避免上下文串场。测试项操作预期知识扫描新会话加载技能触发扫描不直接改已有知识但新增候选知识低风险知识自动更新提供一条项目事实类低风险知识项目事实被更新高风险项进入人工确认记录人工确认模拟审批高风险知识审批后更新 SOP日志追加人工审批结果阶段性知识复盘触发复盘更新日志和项目资料不重复更新 SOP知识库健康体检触发健康体检报告符合预期能列出缺失字段和孤立条目知识扫描没有直接改知识、但加了候选知识这是合理的因为扫描和写入应该分离。低风险自动更新测试里项目事实可以自动更新涉及流程、权限、线上配置的高风险知识必须落到人工确认记录。人工确认测试要检查两点SOP 是否被更新日志里是否出现审批人和审批结论。阶段性复盘测试要检查是否重复更新 SOP如果上一轮已经更新过这一轮只更新日志和项目资料就是正确行为。健康体检测试则看报告是否稳定不要出现每次跑都随机变化的“假问题”。这些测试都依赖同一套技能文件和同一个模型出口。如果中间调整过 TaoToken 的 Key、Base URL 或默认模型建议回到召回回归测试重新跑一遍唯一待召回断言。回归用例的价值就在这里它把“模型出口变化”和“知识库状态变化”隔离开只让该变的项目变。7. 文末 CTA从模型对话、Coding Plan 到创建 Key 与 Claude Code 文档如果你也想在自己的 DeepSeek Harness Obsidian 环境里复现这条召回回归链路建议按下面顺序走一遍先看模型对话确认可用模型和输出风格https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-cta-chat如果你准备长期跑 coding 和知识库自动化看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-cta-plan创建 API Key并保存到本地环境变量或settings.json、config.tomlhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-cta-keys如果要接 Claude Code按文档配置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEYhttps://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-cta-claude-code回到这次回归本身项目 D 的副本被改成knowledge_recallfalse后扫描结果唯一指向“召回回归测试”正式召回完成后该文件状态翻转、日志追加、项目 C/D 主文件保持不动。对回归用例设计者来说这比“环境能跑”更重要因为它意味着下一次改 Key、换模型、迁移技能目录时你都有一个确定的断言可以复跑。TaoToken 在这个流程里的位置很明确官网拿 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentrecall-regression-cta-home Base URL 固定为 https://taotoken.net/api Key 先用YOUR_API_KEY占位配置进 Claude Code 的settings.json、Codex 的config.toml或 CC Switch 三件套。然后回到 DeepSeek Harness新开会话加载obsidian-knowledge-evolution复跑那条唯一待召回断言。只要“召回回归测试”仍然是唯一待召回项且召回后状态正确翻转这条召回回归用例就算真正跑完了。