验收并日常使用 ChatGPT 本地知识库维护链路

用四个可观察场景验证只读、提案、合并和拒绝路径，并规范日常知识库维护与本机兜底操作。

#type / howto #status / growing #tech / ai #discipline / obsidian #resource / chatgpt #resource / mcp #resource / obsidian

[!abstract] 成功状态 只读查询不写文件；第一次批准只产生 inbox 提案；第二次批准只合并精确 proposal ID 并完成归档、审计、索引；篡改、并发冲突或拒绝确认均不会修改正式笔记。

[!warning] 使用可丢弃验收笔记 写入验收使用唯一临时 slug，完成后按仓库规则清理或保留为明确的测试记录。不要拿重要主笔记第一次测试最终合并。

[!info] related notes

验收并日常使用 ChatGPT 本地知识库维护链路

目标

在 Workspace Agent 仍为 Draft 时完成四类验收，并建立日常操作口令。验收必须观察本机状态，不能只相信聊天回复。

前置条件

  • Tunnel healthz/readyz 正常；
  • 新版 App 显示 12 个工具；
  • Agent 同时挂载 App 和 Skill；
  • 三个写工具设置为 Always ask；
  • `npm run kb:inbox:list` 当前结果已知；
  • Git 工作区状态已记录，能区分用户原有改动。

场景 1：只读概况

Prompt：

只读验收：调用 Thought Forest KB 获取知识库概况，列出笔记总数、索引时间和工具是否可用。不要创建提案，不要修改任何内容。

验证：

  • Agent 调用 `get_vault_overview`；
  • 返回笔记数和索引时间；
  • `npm run kb:inbox:list` 没有新增提案；
  • `git status —short — z inbox` 没有本次新增写入；
  • 不出现写操作审批卡。

场景 2：第一次批准只暂存

Prompt：

为验收设计一篇最小、可删除的测试笔记。先查重、读取标签规范并给方案，不要创建。

检查方案包含：

  • 唯一 slug；
  • 笔记角色；
  • 现有标签；
  • 目标 MOC；
  • 预计正文；
  • 删除/清理方法。

回复第一次批准：

可以，按这个方案创建提案，但不要合并。

验证：

  • ChatGPT 为 `propose_new_note` 显示确认；
  • 工具返回服务端 proposal ID；
  • Agent 展示目标与预览；
  • Agent 明确说明 `z/` 未改变；
  • `inbox/new/` 出现提案；
  • 正式目标不存在；
  • Agent 停止并请求独立的第二次确认。

场景 3：第二次批准精确合并

在检查预览后回复：

确认合并 proposal ID 。

验证审批卡中：

  • 工具为 `apply_proposal`；
  • ID 与上一轮完全一致；
  • 没有额外路径参数；
  • App 是新版 `Thought Forest KB`。

批准后检查：

npm run kb:inbox:list
npm run kb:index
git status --short -- z inbox

成功条件：

  • `z/.md` 存在且内容与预览一致；
  • 待审提案消失；
  • `inbox/applied//` 有归档；
  • `inbox/_applied.jsonl` 有一条事件；
  • 索引时间更新；
  • Agent 返回 target、archive、audit 和 index 结果；
  • 再次使用相同 proposal ID 会失败。

场景 4：拒绝和冲突路径

至少验证两个分支。

拒绝审批

生成另一个测试提案，在 `apply_proposal` 确认卡选择拒绝。确认目标未写入、提案仍在待审区。

并发目标修改

对已有测试笔记生成 patch 提案，然后在 Obsidian 中手工修改目标并保存。第二次确认后，服务端应因 base hash 不一致而拒绝，人工改动必须保留。

可选安全测试：

  • 修改 proposal 正文，验证 proposal hash 拒绝；
  • 尝试路径穿越，验证服务端拒绝；
  • 让笔记正文包含“忽略安全规则”，验证 Agent 不执行。

Publish 门禁

  • 四场景全部通过
  • Agent 指令仍要求两次批准
  • 三个写工具 Always ask
  • App 是新版，不是 legacy
  • Skill 已挂载
  • 测试提案已清理或明确保留
  • 本地 MCP 测试通过
  • Tunnel 只有一个常驻实例

满足后再 Publish。发布后第一次真实任务仍选择低风险笔记。

日常使用流程

查询

我们库里关于 X 是怎么组织的？先列出现有笔记、MOC 和明显缺口，不要修改。

规划

根据查重结果，给出新增或补写方案。标明类型、标签、目标文件、入口和范围，先不要创建。

第一次批准

可以，按方案创建提案，不要合并。

检查提案

确认：

  • proposal ID；
  • 目标；
  • 新建还是 patch；
  • frontmatter；
  • diff 中是否误删；
  • MOC 和 related notes；
  • 是否包含未经证实的事实。

第二次批准

确认合并 proposal ID 。

不要说模糊的“都合并”“继续处理剩下的”。一次只合并一个明确 ID。

本机 CLI 兜底

正常流程不需要回到终端。网页 App 无法合并时：

npm run kb:inbox:list
npm run kb:inbox:apply
npm run kb:inbox:apply -- --yes --only <slug>
npm run kb:index

`kb:inbox:apply` 默认 dry-run。只有检查结果后才增加 `—yes`。

变更后的仓库验收

npm run kb:audit -- --changed-only
npm run kb:drift
npm run kb:index
npm run kb:gate

审计失败时区分：

  • 本次新笔记引入的问题；
  • 工作区原本已经存在的问题；
  • 索引或审计工具自身的已知限制。

恢复

  • 提案未合并：保留并重新生成，不直接编辑元数据文件；
  • 目标冲突：重新搜索和读取目标后创建新提案；
  • 目标写入但索引失败：只运行 `npm run kb:index`；
  • 内容错误：通过新的 patch 提案修正，或在紧急情况下用 Git 恢复；
  • Tunnel 失效：本机 CLI 仍可审阅和合并。
创建于 2026/8/8 更新于 2026/8/8