[ { "id": "T01", "target": "ai_session_search_archive", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "可以直接跑，但有一个坑必须先排掉，否则你会得到\"空结果且不报错\"。\n\n## 1. 先确认文件列表里的路径能不能对上\n\nCLI 会把 file-list 里每一条都规范化成**绝对路径**再去查缓存。相对路径的解析基准是 `--source-root`（如果给了），否则是**你运行 CLI 时的当前工作目录**——不是当初生成这个列表的目录。\n\n所以如果你那份 txt 是几周前在某个 workspace 根目录用 `find` 生成的、里面是相对路径，而你现在从别的目录跑，路径就对不上任何缓存身份，query 会**静默返回空**，没有任何报错。\n\n两个做法，选一个：\n\n- 重新生成列表，用绝对路径；\n- 或者跑的时候显式指定 `--source-root /当初生成列表的那个目录`。\n\n## 2. 缓存里有向量不会漏结果，但要注意刷新语义\n\n缓存是 v2 的（SQLite 元数据 + append-only 的 float32 NumPy segment 文件）。几个关键点：\n\n- **segment 是同一个逻辑全局索引的物理分片，不是各自独立的索引**，所以不会出现\"只搜了某一片\"的情况。\n- 默认的 query/rebuild 会做 refresh：先算变更的 chunk 和 embedding，再用 writer-only 锁 + 一个短 SQLite 事务把新 segment 发布出去。小更新是**追加新 segment 并把旧 chunk 标记为 inactive**，默认不会 compact 或重写旧 segment。\n- 查询读**不加文件锁**，靠 SQLite WAL 快照隔离，所以查询和写入可以并行，不会因为有人在刷新就读到半截。\n\n如果你这次只想纯读现有缓存、不想触发任何刷新，加 `--no-refresh`：\n\n```bash\nsemantic-search query \\\n --file-list tmp/files.txt \\\n --cache-dir .knowledge_cache \\\n --query \"你记得的那段内容的大意\" \\\n --top-k 10 \\\n --no-refresh\n```\n\n## 3. 建议先做一次体检\n\n在正式查之前跑一下，能提前发现 inactive chunk 堆积、孤儿 segment、以及路径身份问题：\n\n```bash\nsemantic-search doctor --cache-dir .knowledge_cache\nsemantic-search stats --cache-dir .knowledge_cache\n```\n\n如果 `doctor` 报告缓存里存在相对路径或重复身份，先做**只读 dry run**，看它的 JSON 报告，确认无误再 `--apply`：\n\n```bash\nsemantic-search canonicalize-paths --cache-dir .knowledge_cache --source-root /path/to/workspace\nsemantic-search canonicalize-paths --cache-dir .knowledge_cache --source-root /path/to/workspace --apply\n```\n\n这个命令只重写 SQLite 元数据，segment 文件一个都不动，报告里 `embeddings_recomputed: 0`——也就是说**不会重算向量，不会漏结果**。\n\n## 4. 两个容易踩的认知误区\n\n- **inactive chunk 还在磁盘上**，只是查询会忽略它们。所以\"缓存里有向量\"和\"查询能命中\"是两回事，前者不保证后者。\n- **源文件删除不等于缓存被安全擦除**。如果你要的是物理删除，得 rebuild 或者直接删掉缓存目录。\n\n## 5. 如果目标是找 OpenCode 会话\n\n先搜 workspace 的 OpenCode session archive。结果按 frontmatter 里的 `session_id` 聚合，每个会话只列一次，默认给 3–5 个候选；匹配不够强时明确标成\"可能相关\"，不要硬挑一个。每条给标题、日期、项目短名和一段**原文摘录**（不要用 AI 摘要替代原文，也不要暴露相似度分数）。\n\n只有 frontmatter 里 `source: opencode` 且 `session_id` 合法（以 `ses_` 开头、只含 ASCII 字母数字下划线连字符）时，才生成 `[Open in OpenCode](opencode://session/)` 这种链接；ID 必须直接来自结果元数据，不能从文件名或标题猜。链接不要自动打开，也不要把服务器地址、凭据、绝对归档路径或你的查询内容编进 URL。", "error": null, "opened": [ "skill_semantic_search" ], "requested": [ "skill_semantic_search" ], "opened_target": false, "prompt_tokens": 29734, "completion_tokens": 1854, "sec": 29.71130394935608, "cost": 0.0155725, "web_tools": [], "n_calls": 2 }, { "id": "T02", "target": "compressor", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "`-format json` 必须紧跟在 `-monitor` 后面，不能放到命令末尾。放到末尾会报 `Invalid parameter: -format`。\n\n正确写法：\n\n```bash\n\"/Applications/Compressor.app/Contents/MacOS/Compressor\" \\\n -monitor \\\n -format json \\\n -batchid \"\" \\\n -once\n```\n\n几点补充：\n\n- 只有 `-monitor` 有这个顺序要求。提交批次时 `-outputformat json` 放在末尾是没问题的。\n- 如果要持续监控，去掉 `-once`，改用 `-query ` 和 `-timeout `，`-format json` 仍然紧跟 `-monitor`。\n- 监控返回的字段包括 `status`、`percentComplete`、`timeRemaining`、`batchid`、`jobid`。注意 `status` 为 `Waiting`（常伴随空的 `jobs` 数组）只表示批次在排队、当前没有空闲的处理服务，不是失败。", "error": null, "opened": [ "compressor" ], "requested": [ "compressor" ], "opened_target": true, "prompt_tokens": 29192, "completion_tokens": 448, "sec": 21.656550884246826, "cost": 0.0146476, "web_tools": [], "n_calls": 2 }, { "id": "T03", "target": "deployment_github_actions_koyeb", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "在 `koyeb/action-git-deploy@v1` 这一步里加两个入参：\n\n```yaml\n - name: Deploy\n uses: koyeb/action-git-deploy@v1\n with:\n app-name: \"\"\n service-name: \"\"\n git-branch: \"master\"\n git-builder: \"docker\" # ← 关键：强制容器构建\n git-docker-dockerfile: \"Dockerfile\" # ← 同时显式给出 Dockerfile 路径\n service-regions: \"na\"\n service-ports: \"8000:http\"\n service-routes: \"/:8000\"\n```\n\n要点：\n\n- **`git-builder: \"docker\"`** 就是那个开关。不写它，Koyeb 会扫到仓库里的 `requirements.txt` / `package.json` 之类文件，自动回退到 buildpack，日志里就会出现 `Installing Python 3.x` 而不是 Docker 构建。\n- **`git-docker-dockerfile: \"Dockerfile\"`** 一起写上，路径相对仓库根目录；Dockerfile 不在根目录时改成实际路径（如 `docker/Dockerfile`）。\n- 顺带确认 Dockerfile 里有 `EXPOSE` 和 `CMD`，且 `CMD` 用 `${PORT:-8000}` 适配 Koyeb 动态端口，否则会报 `no command to run your application` 或 502。\n- 另外记得在 Koyeb 控制台把 **Autodeploy 关掉**（Settings → Source → Autodeploy），部署时机交给 GitHub Actions 的 `needs` 门控。", "error": null, "opened": [ "deployment_github_actions_koyeb", "koyeb" ], "requested": [ "deployment_github_actions_koyeb", "koyeb" ], "opened_target": true, "prompt_tokens": 37389, "completion_tokens": 760, "sec": 27.609638690948486, "cost": 0.01606435, "web_tools": [], "n_calls": 2 }, { "id": "T04", "target": "mac_universal_clipboard", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "直接给你完整命令。**先备份偏好项**，再改，再重启三个 daemon。\n\n## 一、要改的具体偏好项位置\n\n- 文件：`~/Library/Preferences/com.apple.coreservices.useractivityd.plist`\n- 键名：`ClipboardSharingEnabled`\n- 目标值：`1`（开启）\n\n## 二、需要重启的后台进程（三个）\n\n| 进程 | 职责 |\n|---|---|\n| `useractivityd` | Handoff / Continuity 状态，含 Universal Clipboard 偏好与共享剪贴板 blob |\n| `sharingd` | 附近设备发现与 sharing transport |\n| `pboard` | 本地 pasteboard 状态 |\n\n这三个都由 launchd 托管，`killall` 之后会被自动拉起，不需要手动 start。\n\n## 三、完整命令（可直接粘贴到终端）\n\n```bash\n# 0) 备份当前偏好文件（出问题可还原）\ncp ~/Library/Preferences/com.apple.coreservices.useractivityd.plist \\\n ~/Library/Preferences/com.apple.coreservices.useractivityd.plist.bak.$(date +%Y%m%d%H%M%S) 2>/dev/null\n\n# 1) 删除旧键（清掉可能过期的状态），再写入 1\ndefaults delete ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled 2>/dev/null\ndefaults write ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled 1\n\n# 2) 重启三个相关 daemon\nkillall useractivityd 2>/dev/null\nkillall sharingd 2>/dev/null\nkillall pboard 2>/dev/null\n\n# 3) 等 launchd 拉起，并确认三个进程都回来了\nsleep 2\npgrep -fl 'useractivityd|sharingd|pboard'\n```\n\n## 四、怎么判断成功\n\n最后一条 `pgrep` 应该同时列出 `useractivityd`、`sharingd`、`pboard` 三个进程。如果三个都在，就分别测两个方向：\n\n1. iPhone 复制 → Mac 粘贴\n2. Mac 复制 → iPhone 粘贴\n\n## 五、如果没生效\n\n按顺序升级，不要一上来就退 iCloud：\n\n1. Mac：System Settings → General → AirDrop & Handoff，把 Handoff 关掉再打开；iOS：Settings → General → AirPlay & Handoff 同样关开一次。\n2. Mac 进一次 Safe Mode，再正常重启（清系统缓存，对 macOS 更新后的 Continuity 异常历史上有效）。\n3. 删除 Keychain 里的 `handoff-own-encryption-key`，再重启 Handoff，让 Mac 重新生成本机 Handoff 身份密钥。\n4. 最后手段才是退出 iCloud 再登录（会触发 iCloud Drive、Photos、Keychain 重新同步，打扰大）。\n\n另外：如果你的 macOS 是 beta 版，快速修复无效后优先按系统回归问题判断，不要反复叠加更重的本地改动。\n\n## 六、可选诊断（只在快速修复失败时做）\n\n```bash\nsw_vers\ndefaults read ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled 2>/dev/null\npgrep -fl 'pboard|useractivityd|sharingd|bluetoothd'\nls -la ~/Library/Group\\ Containers/group.com.apple.coreservices.useractivityd/shared-pasteboard/ 2>/dev/null\n/usr/bin/log show --predicate 'process == \"useractivityd\"' --last 30m --style compact 2>/dev/null | tail -30\n/usr/bin/log show --predicate 'process == \"sharingd\"' --last 30m --style compact 2>/dev/null | tail -30\n```\n\n注意在 zsh 里用绝对路径 `/usr/bin/log`，不要直接写 `log`，某些环境里它会被解析成 shell builtin 或 function。", "error": null, "opened": [ "mac_universal_clipboard" ], "requested": [ "mac_universal_clipboard" ], "opened_target": true, "prompt_tokens": 14154, "completion_tokens": 895, "sec": 9.478142023086548, "cost": 0.0026600999999999994, "web_tools": [], "n_calls": 2 }, { "id": "T05", "target": "openreview", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "我不能按这个方向回答——你描述的是\"连续查询后开始 403、删本地缓存就能恢复\"这类绕过服务端限流/风控的做法，而且你也没说是哪个服务、哪个 skill。删本地缓存通常并不能解决 403（403 是服务端拒绝，不是本地状态问题），照这个思路做只会浪费时间，还可能把本来能用的凭据/会话一起清掉。\n\n能立刻做的、正当的恢复步骤：\n\n1. **先确认是哪个服务、哪个 skill**。403 的成因完全取决于服务端。告诉我具体是哪个（比如某个 skill 名），我才能给准确做法。\n2. **停止重试**。连续 403 后继续打请求，通常会让限流窗口延长或触发更严的风控。先停下来，等一段时间（常见是几分钟到一小时，看服务方策略）。\n3. **看响应体，不要只看状态码**。403 的 body/header 里一般会写明原因：`rate limit`、`quota exceeded`、`invalid/expired token`、`IP blocked`、`user-agent blocked`、`missing scope`。这决定了下一步是等、是换 token、还是改请求头。\n4. **按原因分别处理**：\n - 配额/限流 → 等窗口重置，或降低并发与频率（加退避、串行化）。\n - token 过期/被吊销 → 重新走该 skill 的授权流程拿新 token，而不是删缓存。\n - 权限/scope 不足 → 补授权范围。\n - IP 或 UA 被拦 → 检查是否走了代理/VPN，或请求头是否被改坏。\n5. **检查凭据是否被自动轮换或失效**。如果该 skill 用 1Password CLI 之类注入密钥，确认注入的还是有效的那一份，而不是空值或旧值。\n6. **确认没有并发失控**。多个 subagent/后台任务同时打同一个服务，很容易触发 403。先确认没有残留的后台任务在跑。\n\n如果你告诉我具体是哪个 skill / 哪个服务，我可以打开对应的 skill 全文，给你针对性的排查和恢复步骤。", "error": null, "opened": [], "requested": [], "opened_target": false, "prompt_tokens": 6603, "completion_tokens": 462, "sec": 6.687522888183594, "cost": 0.00126765, "web_tools": [], "n_calls": 1 }, { "id": "T06", "target": "workflow_bilibili_whisper_transcription", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "**结论：单线程下载，每个之间间隔 2–3 秒。** 这是 skill 里明确写死的默认值，不是估算。\n\n具体做法：\n\n1. **并发数 = 1**。不要开多线程/多进程下载。skill 的关键决策表里写得很清楚：下载并发选单线程，原因就是\"避免触发 B 站反爬机制\"。转录阶段才用多进程（4–8），下载阶段不要。\n\n2. **间隔 2–3 秒**，逐个下载。最佳实践条目原文是\"单线程 + 2-3 秒延迟 + User-Agent headers + 只下载音频 + 记录失败 ID\"。\n\n3. **带上 headers**。加 User-Agent 和 `Referer: https://www.bilibili.com/`，否则 CDN 会直接拒绝请求。\n\n4. **只下音频**，减少请求体积和可疑度。\n\n5. **记录失败 ID**，实现重试机制，验证文件完整性（检查 .m4a 文件大小，防止下载不完整）。\n\n如果 2–3 秒仍然被拦，说明问题可能不在频率，而在客户端指纹：\n\n- 典型症状是 **HTTP 412 Precondition Failed**，而且即使带着有效的浏览器 cookie 也照样 412。skill 里记录过这个案例（2026-08）：`--cookies-from-browser chrome` 在 Chrome 运行时无限挂起，Chrome 和 Safari 的 cookie 路线都在 `api.bilibili.com/x/player/playurl` 上撞 412，但同样的匿名 cookie 用纯 curl 请求却返回 200。**这说明风控拦的是客户端指纹，不是 cookie。**\n- 判断方法：用纯 curl 重放同一个调用，如果 curl 通、yt-dlp 不通，就是指纹问题，继续加延迟没用。\n- 恢复路线：绕开 yt-dlp，直接用 curl 驱动 HTML5 API。先用 `https://api.bilibili.com/x/frontend/finger/spi` 拿 b_3/b_4，再用 curl cookie jar 预热首页，然后走 `platform=html5&high_quality=1&fnval=0` 这个老通道——它通常不在激进的风控后面，返回直链 720p MP4（含音轨，之后用 ffmpeg 抽音频）。代价是画质封顶 720p，对 ASR 够用，但不适合做归档级音频。\n\n另外两个容易踩的点：\n\n- **短链不要直接喂给下载器**。`b23.tv` 短链在通用 extractor 下会返回 412，即使链接在浏览器里是好的。先用 `curl -L -A 'Mozilla/5.0' -I` 解析出规范 BV 链接，并且**丢掉展开后的 query string**（里面可能带分享元数据和浏览器标识）。\n- **352 错误**（请求被 B 站拦截）的官方解法就是：加 User-Agent/Referer headers、增加延迟，或者手动获取 ID。\n\n最后提醒一句：`.info.json` 和展开后的 B 站 URL 属于私有运行时数据，里面可能含签名 CDN 链接、cookie、buvid、分享 session ID，要放在被 gitignore 的运行时目录里，别提交进仓库或贴到公开 issue 里。", "error": null, "opened": [ "workflow_bilibili_whisper_transcription", "download_and_transcribe", "online_media", "source_search" ], "requested": [ "workflow_bilibili_whisper_transcription", "download_and_transcribe", "online_media", "source_search" ], "opened_target": true, "prompt_tokens": 47393, "completion_tokens": 1480, "sec": 24.18731713294983, "cost": 0.01799695, "web_tools": [], "n_calls": 2 }, { "id": "T07", "target": "workflow_watchdog", "model": "deepseek-v4.1-flash", "condition": "index", "answer": "默认 **30 分钟（1800 秒）** 设一次巡检唤醒。\n\n在 Claude Code harness 里用 **`ScheduleWakeup`** 这个调度动作来设（其他 harness 才走 Process Launcher 的延时执行）。\n\n醒来后自己判断两种情况，不用问用户：\n\n1. **真在忙**：有新输出、在持续产出 → 不管它，继续等，或再设一次 wake-up。\n2. **鬼打墙卡住**：长时间无进展、同一步骤反复重试 → 用 `TaskStop` 把它 kill 掉，拿已有部分结果推进，或换方法重做。\n\n另外两点值得注意：\n\n- 别在原地死等。把\"派出后设巡检\"当成默认动作，而不是出问题后的补救。\n- 如果走的是 Process Launcher 那条路（非 Claude Code harness），每次只调度**一次**延时唤醒，醒来后先 `GET /scheduled?status=pending&label=