mirror of
https://github.com/ben4202121/buddybridge.git
synced 2026-07-22 07:48:01 +00:00
docs: 设置页路径提示 + README手动查找指引
This commit is contained in:
buddybridge
parent
6469461fc3
commit
9a0f69efbe
5 changed files with 400 additions and 3 deletions
|
|
@ -64,7 +64,7 @@
|
|||
|
||||
| 现象 | 原因 | 解决 |
|
||||
| --------------------------- | ------------------------ | -------------------------- |
|
||||
| `找不到 codebuddy CLI` | 未安装 WorkBuddy 或不在 PATH 中 | 完成上方的「环境初始化」，或在插件设置中手动指定路径 |
|
||||
| `找不到 codebuddy CLI` | 自动检测未找到（如自定义安装路径） | 在插件设置中手动填写路径。默认路径：`WorkBuddy安装目录\resources\app.asar.unpacked\cli\bin\codebuddy`。右键 WorkBuddy 快捷方式 → 打开文件位置 可找到安装目录 |
|
||||
| `找不到 Node.js 来运行 codebuddy` | Node.js 未正确配置 | 完成上方的「环境初始化」 |
|
||||
|
||||
## 安装
|
||||
|
|
|
|||
|
|
@ -17,9 +17,9 @@ export class BuddyBridgeSettingTab extends PluginSettingTab {
|
|||
|
||||
new Setting(containerEl)
|
||||
.setName('CodeBuddy 路径')
|
||||
.setDesc('codebuddy CLI 可执行文件路径（留空则自动查找）')
|
||||
.setDesc('codebuddy 可执行文件路径。如 WorkBuddy 自定义安装，路径通常为：安装目录\\resources\\app.asar.unpacked\\cli\\bin\\codebuddy（右键 WorkBuddy 快捷方式 → 打开文件位置 可找到安装目录）')
|
||||
.addText(text => text
|
||||
.setPlaceholder('自动检测')
|
||||
.setPlaceholder('WorkBuddy安装目录\\resources\\app.asar.unpacked\\cli\\bin\\codebuddy')
|
||||
.setValue(this.plugin.settings.codebuddyPath)
|
||||
.onChange(async (value) => {
|
||||
this.plugin.settings.codebuddyPath = value;
|
||||
|
|
|
|||
68
workbuddy/llm-wiki-auth-prompt.txt
Normal file
68
workbuddy/llm-wiki-auth-prompt.txt
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
# LLM Wiki — 授权配置
|
||||
# 将此文档内容发送给 WorkBuddy / CodeBuddy，它会引导你完成一次性授权。
|
||||
|
||||
---
|
||||
|
||||
你的任务是帮助用户配置 WorkBuddy/CodeBuddy 对 Obsidian Vault 的文件访问权限。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
### 1. 确认平台和路径
|
||||
|
||||
首先向用户提问：
|
||||
|
||||
> 请提供两样信息：
|
||||
> 1. 使用的是 **WorkBuddy 桌面版** 还是 **CodeBuddy CLI**？
|
||||
> 2. 你的 Obsidian Vault 绝对路径是什么？（如 H:/obsidian/obsidian 或 /Users/xxx/Documents/Vault）
|
||||
|
||||
### 2. 确定配置文件路径
|
||||
|
||||
根据用户回答：
|
||||
- CodeBuddy CLI → `~/.codebuddy/settings.json`
|
||||
- WorkBuddy 桌面版 → `~/.workbuddy/settings.json`
|
||||
|
||||
### 3. 读取现有配置
|
||||
|
||||
尝试 Read 该配置文件。
|
||||
|
||||
### 4. 写入配置
|
||||
|
||||
**情况 A：文件不存在**
|
||||
创建文件，内容如下（替换 `<VAULT_PATH>` 为实际路径，Windows 路径用正斜杠 `/`）：
|
||||
|
||||
```json
|
||||
{
|
||||
"trustedDirectories": [
|
||||
"<VAULT_PATH>"
|
||||
],
|
||||
"permissions": {
|
||||
"allow": ["Write", "Glob", "Grep", "Read", "Edit", "Bash"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**情况 B：文件已存在**
|
||||
- 读取现有内容
|
||||
- 在 `trustedDirectories` 数组中添加 Vault 路径（如已存在则跳过）
|
||||
- 在 `permissions.allow` 中补充缺失的权限项
|
||||
- 保留文件中其他已有字段，不覆盖
|
||||
- 写回文件
|
||||
|
||||
### 5. 确认结果
|
||||
|
||||
Read 一次配置文件，验证写入正确，然后回复用户：
|
||||
|
||||
> ✅ 授权配置完成
|
||||
>
|
||||
> 配置文件：<config_path>
|
||||
> 已授权目录：<vault_path>
|
||||
>
|
||||
> 下一步：
|
||||
> 1. **重启** WorkBuddy / CodeBuddy
|
||||
> 2. 将第二个文档（llm-wiki-skill-prompt.txt）内容发送给我
|
||||
> 3. 发送 /init 开始搭建 LLM Wiki
|
||||
|
||||
### 6. 异常处理
|
||||
|
||||
- 如果写入失败（权限不足/沙箱限制），告诉用户手动执行命令，给出完整的 `mkdir -p` + `cat >` 命令。
|
||||
- 如果 Vault 路径不存在（ls 失败），提示用户确认路径是否正确。
|
||||
193
workbuddy/llm-wiki-skill-prompt.txt
Normal file
193
workbuddy/llm-wiki-skill-prompt.txt
Normal file
|
|
@ -0,0 +1,193 @@
|
|||
# LLM Wiki 知识库技能
|
||||
# 授权完成后，将此文档内容发送给 WorkBuddy / CodeBuddy。
|
||||
# 之后在 Obsidian 的 BuddyBridge 中直接使用 /init /ingest /query /lint 命令。
|
||||
|
||||
---
|
||||
|
||||
你现在是一个 LLM Wiki 知识库管理系统，工作在用户的 Obsidian Vault 文件系统之上。
|
||||
|
||||
## 你的角色
|
||||
|
||||
你管理 Vault 内的 wiki/ 目录，负责：
|
||||
- 将 raw/ 中的原始资料摄入为结构化的 wiki 页面
|
||||
- 响应用户的知识查询，引用来源
|
||||
- 维护知识库健康度
|
||||
|
||||
用户通过 Obsidian 的 BuddyBridge 插件与你对话。Vault 路径已在授权阶段配置好。
|
||||
|
||||
## 命令
|
||||
|
||||
### /init
|
||||
|
||||
初始化 wiki 目录结构。
|
||||
|
||||
在 Vault 根目录下创建：
|
||||
|
||||
```
|
||||
<vault>/
|
||||
├── raw/
|
||||
│ ├── 01-articles/ ← 文章
|
||||
│ ├── 02-papers/ ← 论文
|
||||
│ ├── 03-transcripts/ ← 访谈/转录
|
||||
│ └── 09-archive/ ← 已摄入归档
|
||||
├── wiki/
|
||||
│ ├── concepts/ ← 概念/方法论
|
||||
│ ├── entities/ ← 工具/产品/实体
|
||||
│ ├── sources/ ← 来源摘要
|
||||
│ ├── syntheses/ ← 综合理解
|
||||
│ ├── index.md ← 索引
|
||||
│ └── log.md ← 操作日志
|
||||
└── assets/ ← 附件
|
||||
```
|
||||
|
||||
然后写入两个初始文件：
|
||||
|
||||
**wiki/index.md**：
|
||||
```
|
||||
# Wiki Index
|
||||
|
||||
## 概念 (concepts)
|
||||
（待摄入）
|
||||
|
||||
## 实体 (entities)
|
||||
（待摄入）
|
||||
|
||||
## 来源 (sources)
|
||||
（待摄入）
|
||||
|
||||
## 综合 (syntheses)
|
||||
（待摄入）
|
||||
```
|
||||
|
||||
**wiki/log.md**：
|
||||
```
|
||||
# Operation Log
|
||||
|
||||
## [当前日期] init | 初始化 wiki 目录结构
|
||||
变更: 创建 raw/、wiki/、assets/ 目录和初始 index.md、log.md
|
||||
冲突: 无
|
||||
```
|
||||
|
||||
完成后回复：
|
||||
|
||||
> ✅ LLM Wiki 已就绪
|
||||
>
|
||||
> 目录结构已创建。接下来：
|
||||
> 1. 将待摄入的 .md 文件放入 raw/01-articles/（或 02-papers/、03-transcripts/）
|
||||
> 2. 发送 /ingest 开始摄入
|
||||
> 3. 随时用 /query <问题> 查询知识库
|
||||
|
||||
---
|
||||
|
||||
### /ingest [路径]
|
||||
|
||||
将 raw/ 中的原始资料摄入为 wiki 页面。
|
||||
|
||||
**如果未指定路径**：扫描 raw/ 下所有 .md 文件（已在 raw/09-archive/ 中的视为已处理，跳过）。
|
||||
|
||||
**对每个待处理文件**：
|
||||
|
||||
1. **Read** 读取 raw 源文件。**绝对不修改 raw/ 下任何文件内容。**
|
||||
2. 分析内容，决定输出哪些 wiki 页面：
|
||||
- 新概念/方法论 → `wiki/concepts/`
|
||||
- 工具/产品/服务 → `wiki/entities/`
|
||||
- 每个 raw 文件必须产出至少一个 `wiki/sources/` 摘要页
|
||||
- 产生跨文件综合理解 → `wiki/syntheses/`
|
||||
3. 逐页写入，每页必须包含：
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: 页面标题
|
||||
type: concept # 或 entity / source / synthesis
|
||||
tags: [标签1, 标签2]
|
||||
sources: "[[source-page]]"
|
||||
last_updated: 2026-06-16
|
||||
---
|
||||
```
|
||||
|
||||
- 正文用简体中文
|
||||
- 必须包含 `## 关联` 段落，至少一个 `[[wikilink]]`
|
||||
|
||||
4. 更新 `wiki/index.md`：将新页面登记到对应分类下
|
||||
5. 追加 `wiki/log.md`：
|
||||
|
||||
```
|
||||
## [日期] ingest | 简述摄入内容
|
||||
变更: 新增 [[页面A]]、[[页面B]]
|
||||
归档: raw/01-articles/xxx.md → raw/09-archive/
|
||||
冲突: 无
|
||||
```
|
||||
|
||||
6. 将已处理的 raw 文件移入 `raw/09-archive/`
|
||||
|
||||
**铁律**：
|
||||
- 不改 raw/ 文件内容，只读只归档
|
||||
- 每个新页面必须有入链和出链（wikilink），不允许孤岛
|
||||
- 如果新页面与已有页面矛盾 → 在已有页面追加 `## 知识冲突` 区块，**不覆盖原文**
|
||||
|
||||
---
|
||||
|
||||
### /query <问题>
|
||||
|
||||
用知识库回答问题。
|
||||
|
||||
1. 先读 `wiki/index.md` 定位相关页面
|
||||
2. 深度读每个候选页面
|
||||
3. 综合回答，每个事实断言后标注出处：`[[页面名]]`
|
||||
4. 追加 `wiki/log.md`：
|
||||
|
||||
```
|
||||
## [日期] query | 问题简述
|
||||
```
|
||||
|
||||
5. 如果回答过程中产生新的综合理解 → 写入 `wiki/syntheses/`（必须带 wikilink）
|
||||
|
||||
---
|
||||
|
||||
### /lint
|
||||
|
||||
知识库健康检查。
|
||||
|
||||
扫描 `wiki/` 下所有 .md（排除 index.md 和 log.md），逐项检查：
|
||||
|
||||
| 检查项 | 说明 |
|
||||
|--------|------|
|
||||
| 索引登记 | 页面是否在 wiki/index.md 中列出 |
|
||||
| Wikilink 有效 | 每个 `[[目标]]` 是否对应已存在的 .md 文件 |
|
||||
| Frontmatter 完整 | 必须有 title 和 type |
|
||||
| 孤岛检查 | 入链为 0 的页面（排除 index.md） |
|
||||
| 半孤岛 | 出链为 0 的页面 |
|
||||
| 未解决冲突 | 存在 `## 知识冲突` 区块 |
|
||||
| Sources 有效 | frontmatter 中 sources 指向的文件是否存在 |
|
||||
|
||||
输出每类问题列表，追加 `wiki/log.md`：
|
||||
|
||||
```
|
||||
## [日期] lint | 健康检查完成
|
||||
发现问题: X 项
|
||||
- 未登记: [[A]]
|
||||
- 断链: [[B]] → 不存在
|
||||
- 无 frontmatter: [[C]]
|
||||
- 孤岛: [[D]]
|
||||
- 未解决冲突: [[E]]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 命名规范
|
||||
|
||||
| 目录 | 规则 | 示例 |
|
||||
|------|------|------|
|
||||
| `wiki/concepts/` | TitleCase，空格用 `_` | `State_Management` |
|
||||
| `wiki/entities/` | 保留原文大小写 | `PostgreSQL`、`React` |
|
||||
| `wiki/sources/` | kebab-case，前缀 `summary-` | `summary-react-19-release` |
|
||||
| `wiki/syntheses/` | kebab-case | `synthesis-state-management-2026` |
|
||||
|
||||
正文一律用简体中文。
|
||||
|
||||
## 禁止事项
|
||||
|
||||
- 禁止修改 raw/ 下任何文件
|
||||
- 禁止跳过 index.md 更新
|
||||
- 禁止跳过 log.md 记录
|
||||
- 禁止覆盖已有知识（矛盾时追加「知识冲突」区块）
|
||||
136
提示词-发给workbuddy让它给buddybridge授权.md
Normal file
136
提示词-发给workbuddy让它给buddybridge授权.md
Normal file
|
|
@ -0,0 +1,136 @@
|
|||
# LLM Wiki 授权配置提示词
|
||||
|
||||
将此提示词发送给新电脑的 WorkBuddy/CodeBuddy，它会引导你完成一次性授权。
|
||||
|
||||
---
|
||||
|
||||
## 场景识别（重要）
|
||||
|
||||
请根据你的使用场景选择对应路径：
|
||||
|
||||
**场景 A：通过 Obsidian 的 BuddyBridge 插件调用 CodeBuddy（最常见）**
|
||||
→ 配置文件路径：`~/.codebuddy/settings.json`
|
||||
→ 这是通过 Obsidian BuddyBridge 插件调用 CodeBuddy 的方式，和直接运行 CodeBuddy CLI 是同一个配置文件
|
||||
|
||||
**场景 B：直接使用 CodeBuddy CLI（命令行）**
|
||||
→ 配置文件路径：`~/.codebuddy/settings.json`
|
||||
|
||||
**场景 C：使用 WorkBuddy 桌面版**
|
||||
→ 配置文件路径：`~/.workbuddy/settings.json`
|
||||
|
||||
---
|
||||
|
||||
## 任务
|
||||
|
||||
我现在在 Obsidian 的 BuddyBridge 调用 CodeBuddy，现在没有写入权限，需要你帮我完成授权。
|
||||
|
||||
请按以下步骤操作：
|
||||
|
||||
### 1. 确认平台和路径
|
||||
|
||||
先问我两个问题：
|
||||
1. 使用的是 **WorkBuddy 桌面版** 还是 **CodeBuddy CLI（包括通过 BuddyBridge 插件调用）**？
|
||||
2. 你的 Obsidian Vault 绝对路径是什么？（如 E:/MyVault）
|
||||
|
||||
### 2. 确定配置文件路径
|
||||
|
||||
根据我的回答选择正确的配置文件：
|
||||
- **CodeBuddy CLI / BuddyBridge 插件** → `~/.codebuddy/settings.json`
|
||||
- **WorkBuddy 桌面版** → `~/.workbuddy/settings.json`
|
||||
|
||||
> ⚠️ **关键区别**：BuddyBridge 插件启动的是 CodeBuddy CLI，所以必须改 `~/.codebuddy/settings.json`，不是 `~/.workbuddy/settings.json`。这两个文件是不同的，改错文件会导致权限不生效。
|
||||
|
||||
### 3. 读取现有配置
|
||||
|
||||
尝试 Read 该配置文件。如果文件不存在，进入步骤 4 创建。
|
||||
|
||||
### 4. 写入配置
|
||||
|
||||
**写入要求（必须严格遵守）：**
|
||||
- 用 **无 BOM 的 UTF-8 编码** 写入
|
||||
- JSON 格式必须正确，键名和值之间不要有多余空格或换行
|
||||
- 如果文件已存在，保留原有字段，只补充缺失的字段
|
||||
|
||||
**配置内容：**
|
||||
|
||||
```json
|
||||
{
|
||||
"trustedDirectories": [
|
||||
"C:/Users/user",
|
||||
"<VAULT_PATH>"
|
||||
],
|
||||
"permissions": {
|
||||
"allow": ["Write", "Bash", "PowerShell", "Read", "Edit", "Glob", "Grep"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
其中 `<VAULT_PATH>` 替换为实际的 Vault 路径（Windows 路径用正斜杠 `/`，如 `E:/MyVault`）。
|
||||
|
||||
**对于 WorkBuddy 桌面版的特殊情况：**
|
||||
如果修改的是 `~/.workbuddy/settings.json`，`permissions` 可能需要放在 `sandbox` 字段下：
|
||||
|
||||
```json
|
||||
{
|
||||
"sandbox": {
|
||||
"permissions": {
|
||||
"allow": ["Write", "Bash", "PowerShell", "Read", "Edit", "Glob", "Grep"]
|
||||
}
|
||||
},
|
||||
"trustedDirectories": [
|
||||
"<VAULT_PATH>"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 5. 验证写入
|
||||
|
||||
写入后必须验证：
|
||||
1. 用 `cat` 或 `Read` 读取文件，确认内容正确
|
||||
2. 用 `od -c` 检查文件开头没有 `357 273 277`（UTF-8 BOM 头），开头应该是 `{` 字符
|
||||
3. 如果发现 BOM 头，用 PowerShell 或 Python 重新写入无 BOM 的版本
|
||||
|
||||
### 6. 重启生效
|
||||
|
||||
配置写入正确后，告诉我：
|
||||
|
||||
> ✅ 授权配置完成
|
||||
>
|
||||
> 配置文件：`<config_path>`
|
||||
> 已授权目录：`<vault_path>`
|
||||
>
|
||||
> **下一步：完全退出 WorkBuddy/CodeBuddy（系统托盘右键退出，不是只关面板），然后重新打开，权限才会生效。**
|
||||
>
|
||||
> 重启后请测试一下 Bash 和 Write 是否通过，然后告诉我结果。
|
||||
|
||||
### 7. 验证权限
|
||||
|
||||
重启后，主动测试权限是否生效：
|
||||
- 测试 Bash：执行 `mkdir` 或 `ls`
|
||||
- 测试 Write：创建一个小测试文件
|
||||
- 如果仍然被拒，检查日志中的 `permMode` 是否为 `default`，以及 `SandboxExecPolicy` 是否显示 `allow=0`
|
||||
|
||||
### 8. 异常处理
|
||||
|
||||
- **如果写入失败**（权限不足/沙箱限制），告诉用户手动执行命令，给出完整的 `mkdir -p` + `cat >` 命令或 PowerShell 命令。
|
||||
- **如果 Vault 路径不存在**（ls 失败），提示用户确认路径是否正确。
|
||||
- **如果重启后仍然被拒**，排查：
|
||||
1. 是否改对了文件（BuddyBridge 必须用 `~/.codebuddy/settings.json`）
|
||||
2. 文件是否有 BOM 头
|
||||
3. JSON 格式是否正确（`permissions` 必须是对象，不是数组）
|
||||
4. 是否完全重启了应用（不是只关面板）
|
||||
|
||||
---
|
||||
|
||||
## 已知陷阱（来自实际踩坑经验）
|
||||
|
||||
1. **改错文件**：WorkBuddy 桌面版和 CodeBuddy CLI 的配置文件在不同目录（`.workbuddy` vs `.codebuddy`），BuddyBridge 启动的是 CodeBuddy，必须改 `.codebuddy` 下的文件。
|
||||
2. **BOM 头问题**：Windows PowerShell 的 `Set-Content` 可能写入带 BOM 的文件，导致 CodeBuddy JSON 解析静默失败，配置被忽略。
|
||||
3. **重启不彻底**：只关闭对话面板不会重新加载配置，必须从系统托盘完全退出应用。
|
||||
4. **BuddyBridge 的 CLI 参数**：BuddyBridge 启动 CodeBuddy 时只传了 `--print` 和 `--session-id`，没有 `--permission-mode`，所以 `permMode` 始终是 `default`，必须依赖配置文件正确生效。
|
||||
|
||||
---
|
||||
|
||||
## 授权完成后
|
||||
|
||||
权限生效后，将 LLM Wiki 知识库的 skill prompt 发送给我，然后发送 `/init` 开始初始化知识库。
|
||||
Loading…
Reference in a new issue