这是「Claude Code 工作流」系列第三篇，也是最后一篇，对应 deck 的 Part 3（第 13-16 页）。下方嵌入了可交互的完整 deck，按方向键翻页，按 O 出缩略图多任务视图。

移动端 iframe 体验有限，可点此全屏查看 deck。

P13 · Part 3 目录：Claude Code 内置功能

Part 3 共 2 节：3.1 agents view + 3.2 /insights。这两个是 Claude Code 自带能力，不需要额外装 skill 或 MCP，但很多人要么没用过，要么用错了。

P14 · 3.1 agents view：一屏管所有后台会话

是什么

claude agents 命令开一个总览屏，一屏看到所有 Claude Code 会话：在跑的、等你输入的、已完成的。任意一个都能 /resume 恢复，上下文完整保留。

解决的痛点

• 以前：关掉终端 = 会话没了，上下文丢
• 以前：同时跑多个任务没法切换，得开多个终端窗口手动记
• 以前：想知道「那个长任务跑完了没」只能回去翻历史
• 现在：一屏总览 + 一键 /resume + 状态实时可见

六种状态（图标颜色 = 会话状态）

三种形状（图标形状 = 进程是否存活）

颜色独立于形状，形状表示进程状态——这是官网文档里容易忽略的点：

顺带一提：/goal + /bg 组合

• /goal — 设一个条件，Claude 跨多轮自主拆解、持续推进直到条件达成
• /bg — 把当前会话切到后台继续跑，释放终端
• 组合用法：/goal 设目标 + /bg 后台跑 = 长任务无人值守推进，在 agents view 里看进度

参考：code.claude.com/docs/en/agent-view

P15 · 3.2 /insights 正确用法

是什么

/insights 生成一份分析 Claude Code 会话的报告。覆盖：项目分布、交互模式、摩擦点（friction points）。读的是 ~/.claude/projects 下的历史记录。输出是一个 HTML 文件，存在当前工作目录。

为什么用

• 看消耗在哪
• 识别浪费的 token / cache / subagent 调用
• 纠正低效的 prompt 模式

常见误区

• ❌ 不是实时遥测 — 读历史记录，不是监控当前会话
• ❌ 不是聊天总结 — 生成 HTML 文件，不是返回聊天里的总结
• ❌ 依赖会话记录 — 空目录无输出

正确姿势

1
2
3

/insights 7d
→ 看报告里的异常发现
→ 调整 prompt / 拆分 skill / 优化 subagent 调用

典型发现 → 优化方向

• skill 反复调 40% token → 合并步骤
• subagent 重读同一文件 → 加 memory 缓存
• 长 prompt 拆短 cache ↑ → 拆 system/user 块利用 prompt cache

参考：code.claude.com/docs/en/commands

/insights 不是看一眼就完——要落地改 prompt，不然下次还是同样的浪费。

P16 · Thanks

Q & A 时间
Obsidian × Notion × Databricks × Claude Code

系列三篇到此结束。三篇都配了可交互的 deck 嵌入，翻一翻 deck 看视觉，读一读文字看细节。

回到本专栏首页：Claude Code 使用分享。
系列导航：第一篇 知识库 · 第二篇 Databricks · 当前篇

这是「Claude Code 工作流」系列第二篇，对应 deck 的 Part 2（第 09-12 页）。下方嵌入了可交互的完整 deck，按方向键翻页，按 O 出缩略图多任务视图。

移动端 iframe 体验有限，可点此全屏查看 deck。

P09 · Part 2 目录：Claude Code × Databricks

Part 2 共 3 节：2.1 两种连接方式对比 + 选型 / 2.2 测试工作流（Jobs 模式）/ 2.3 实战示例。

核心问题：Claude Code 怎么连 Databricks？答案是——不要走第三方 MCP Server，直接用官方 CLI + markdown Skills。

P10 · 2.1 两种连接方式对比 + 选型结论

方式一：远程 MCP Server

架构：Claude ⇄ MCP 协议 ⇄ 第三方 Server ⇄ Databricks API

• 依赖：找/装第三方 Server
• 能力：受限于 Server 暴露的工具
• 拓展：改 Server 源码重启
• Azure 中国：看社区实现，不一定可用

方式二：本地 CLI + Skills ✓（选型结论）

架构：Claude ⇄ Bash ⇄ databricks CLI ⇄ Databricks API

• 依赖：官方 CLI + markdown Skills
• 能力：全 CLI 子命令 + REST
• 拓展：直接调子命令
• Azure 中国：官方原生支持

配合的 skill

• databricks-core — 日常 CLI 操作、auth、profile、bundle
• databricks-pipelines — Lakeflow Spark Declarative Pipelines（原 DLT）
• ddl-to-data-dictionary — DDL 翻数据字典

选型结论：本地 CLI + Skills

四个理由：

1. 官方维护 — 不靠第三方，能力全集
2. Azure 中国 endpoint 原生适配 — 不用等社区实现
3. 加新能力直接调子命令 — 不改 Server 源码
4. 调试链路短 — 报错直接可见，不经过 MCP 协议层

远程 MCP Server 不是不能用，而是「能用多少看 Server 暴露多少」——这个不确定性对工作流是硬伤。

P11 · 2.2 测试工作流（Jobs 模式）

9 步闭环 · 不动现有 jobs 编排

1
2
3
4
5

1. export 云上 .py    →   2. Claude 改   →   3. import 回云
                                                       ↓
6. export-run    ←   5. run-now    ←   4. 建临时 job
       ↓
7. 解码 base64  →   8. Claude 分析   →   9. 回到 2 ↻

详细步骤：

1. 用户 export 云上 .py — 从 Databricks workspace 导出 notebook
2. Claude 改本地 .py — 在 workspace 编辑，迭代逻辑
3. 用户 import 回云 — 把改好的 .py 导回 workspace
4. 建临时 job — 不动现有 jobs 编排，新建一个临时 job 跑测试
5. Claude jobs run-now — 触发 job
6. Claude jobs export-run — 抓取执行结果
7. Claude 解码 base64+URL — export-run 输出是 base64+URL 编码
8. Claude 自主分析 — 看 stdout/stderr、数据样本、schema
9. 回到步骤 2 — 根据结果迭代，循环往复

踩坑点

• get-run-output 只收 dbutils.notebook.exit() — 想拿完整 cell 输出要用 export-run
• Azure 中国禁 /api/1.2/commands 端点 — 不能用旧版 commands API
• 输出是 base64+URL 双重编码 — 解码两层才能拿到可读文本

规则

• 不动现有 jobs 编排
• 不跑 workspace import/export（用户手动操作）
• 用 all-purpose cluster（不用 SQL Warehouse）
• 临时 job 跑完即弃

P12 · 2.3 实战示例（2026-07-29）

test job 配置

• job_id: 10761020612585
• notebook: /Shared/powerlink_warehouse/other/test
• cluster: all-purpose
• 2 cells: Python + SQL

执行结果 · 全链路通

• ✅ 18 秒跑完，无报错
• ✅ Python cell 设参数成功
• ✅ SQL cell 返回数据
• ✅ export-run 拿到全 cell
• ✅ base64+URL 解码成可读文本
• ✅ stdout / stderr 分离提取

自主抓取数据

Cell 0 (Python) — 设参数：

1

spark.conf.set("param.bizdate", "20260707")

Cell 1 (SQL) — 查数据：

1
2
3
4

select * from powerlink_prod.pw_ads.
  ads_pw_credit_metric_df
where dt='${param.bizdate}'
limit 10

结果：10 行 × 68 列完整数据，含 sap_code / company_name / company_paydex 等。

Claude 自主迭代

拿到数据后 Claude 不只是看一眼就完，会自主推断：

• dt 是分区列 → 自动加 where 条件避免全表扫描
• sap_code → 推断 SAP 主数据关联
• 10 行样本看 schema，不拉全量（省 token、省时间）

这个「样本看 schema，不拉全量」的能力是 9 步闭环的价值——Claude 不需要人告诉它怎么看数据，它自己会推断。

下一篇：Claude Code 工作流（三）：内置功能 — agents view + /insights — 一屏管理所有后台会话的状态体系，历史会话分析报告的正确用法与常见误区。

回到本专栏首页：Claude Code 使用分享。

这是「Claude Code 工作流」系列第一篇，原文是内部分享 deck，星露谷物语像素风。下方嵌入了可交互的完整 deck，按方向键翻页，按 O 出缩略图多任务视图。本篇文字版对应 deck 的 Part 1（第 02-08 页）。

移动端 iframe 体验有限，可点此全屏查看 deck。

P02 · Part 1 目录：知识库工具

知识库这块我用两套工具：Obsidian（本地 markdown + 双链）和 Notion（block + database + relation）。这套对比不是为了 PK 谁强谁弱，而是搞清楚两套范式各自擅长什么、我各自在用它们做什么。

Part 1 共 6 节：1.1 范式对比 / 1.2 OB 在用 / 1.3 Notion 在用 / 1.4 daily-todo-bot / 1.5 优劣对比表 / 1.6 分工。

P03 · 1.1 两种知识库范式对比

Obsidian：本地 markdown + 双链

OB 的核心是纯文本 .md 文件 + 本地存储。文件系统就是数据库，[[双链]] 把文档织成网，graph view 看全局互连。跨 vault 用 Python 读写毫无障碍——它就是个文件夹。

适合：个人知识沉淀、离线写作、隐私敏感。
痛点：无原生 DB、无自动化触达、协作要迁整个 vault。

“OB 织网 — 文档间互相关联”

Notion：block + database + relation

Notion 的核心是 block-based，无限嵌套。block 是最小单位，paragraph / heading / toggle / callout 都是 block，可以拖拽组合。database + view + property 提供原生结构化能力，relation 把多个 DB 互相关联。云端，团队实时协作。

适合：结构化字段、多人协作、定时自动化。
痛点：离线不可用、导出受限、锁在云上。

“Notion 垒层 — 内容分层可折叠”

一句话总结：OB 织网，Notion 垒层——前者文档间互相关联，后者内容内部分层。

P04 · 1.2 Claude + OB：知识库使用方法

三个 vault

1. 项目变更记录 — 按天分区，操作变更记录-YYYY-MM-DD.md，原始数据层
2. 项目文档 — 按主题汇总，结构化层
3. llm-wiki — skill prompt 定义的三层结构（raw → wiki → index）

这套分层借鉴了数据开发思路：原始 → 结构化 → 索引。每日追加操作变更记录是原始层，项目文档按主题归档是结构化层，llm-wiki 是索引层。

Claude 怎么读写

• obsidian skill — vault 读写。macOS 沙盒（TCC）限制 ~/Documents/ 直接访问，用 Python heredoc 绕开
• karpathy-llm-wiki — 三层结构维护
• markitdown — 网页/PDF/Word 转 md 再扔进 vault

vault 结构示例

1
2
3
4
5
6
7
8

项目变更记录/
├── 操作变更记录/
│   └── 操作变更记录-2026-07-29.md
└── project/powerlink/
    ├── Claude Code 集成/
    │   └── 本地CLI与MCP连接方式对比.md
    ├── 数据接入/
    └── 数据字典/

Claude 工作流

每日追加 → obsidian skill → 结构化归档。每日一个 md，跨 vault heredoc 批量检索。

P05 · 1.3 Notion 当前在用

三个 database

1. 每日待办 DB — agent 模板 5 字段：项目名 / 模块名 / 截止时间 / 四象限 / 任务内容。新增流程：关键词 → 给模板 → 填充提交 → 更新 Notion
2. 项目模块 DB — 工作 + 个人两套库。PowerLink（工作）/ NightFall-Blog（个人），技术栈 / 上线日期 / 状态字段。relation：项目 → 子模块 → 每日待办（多对多）
3. daily-todo-bot — 9:00 / 18:00 推钉钉（详见下页）

配合的 MCP

notion MCP（mcp.notion.com/mcp，user scope）— 直连 Notion API，daily-todo-bot 自动化也走这条链路。

当前限制

• button 只读——MCP 暂不支持触发 Notion button
• select 受限——只能查不能改选项

P06 · 1.4 daily-todo-bot：Notion 待办推到钉钉

做什么

每天 9:00 和 18:00 自动把今日待办从 Notion 拉出来，推送到企业钉钉的工作通知。上午推清单，下午推完成复盘。

链路

1
2
3
4
5

Notion 待办 DB
   ↓ query API（filter: 截止日期=today AND 状态≠已完成）
Python main.py
   ↓ corpcommunication asyncsend_v2
企业钉钉工作通知

三端协作

部署

云服务器 root@47.103.65.110:~/daily-todo-bot/，cron 触发。

5 个开发坑

1. TCC 限制 — 服务器调试，本地 macOS 沙盒绕开
2. action_card — 必带 btn_json，否则钉钉拒绝（400）
3. 钉钉日上限 — 频控限流，合并推送
4. database_id ≠ data_source_id — 查询要用 collection:// 前缀
5. create-pages — 必须给 parent data_source_id，不能只给 database_id

“Notion 是数据源，钉钉是触达层 — 中间一段 Python 把两者缝起来”

P07 · 1.5 优劣对比表

P08 · 1.6 OB / Notion 分工：AI 读什么，人看什么

经过这轮对比，我的结论是不二选一，分工合作：

OB — 喂 AI，本地知识源

纯文本 .md + 双链织网，Claude 跨 vault 用 Python heredoc 直接读写。

• 渐进式披露 — AI 按需读，不必一次拉全量
• 结构灵活 — 文件路径就是 schema
• 隐私本地 — 敏感记录不离机

“OB 是 AI 的工作记忆 — 每日追加，跨 vault 检索”

Notion — 喂人，项目追踪层

block + database + relation，感官直接，一路折叠到底看全貌。

• 感官直接 — 层次分明，按需展开
• 团队协作 — 多人实时，加人无需迁库
• 项目追踪 — 状态/日期/owner 字段一等公民

“Notion 是人的仪表盘 — 一屏看全，一键深入”

联动：Notion 记录时参考 OB

更新 Notion 待办时，agent 可直接从 OB vault 读取历史记录/项目文档，结构化字段填入 DB — 一次写入，两端可用。

下一篇：Claude Code 工作流（二）：Claude Code × Databricks — 远程 MCP Server vs 本地 CLI + Skills 选型，9 步测试工作流闭环，10 行 × 68 列自主抓取实战。

回到本专栏首页：Claude Code 使用分享。