知识编译完了，然后呢？

编译产物躺在Obsidian的wiki/目录里，要发飞书文档得手动复制粘贴，要更新多维表格得自己去填，要通知团队得自己去发消息。编译是自动化了，但从知识到执行之间还有一条断裂的沟。

然后3月28日，飞书开源了CLI。

装上之后我才反应过来：CC（Claude Code）+ Obsidian + 飞书CLI，这三个东西拼在一起，才是真正的全链路。

编译完的概念条目可以一条命令同步到飞书知识库。选题排期可以直接写进多维表格。写完的文章可以自动创建飞书文档发给团队review。审核通过后的内容可以自动通知到群聊。

3.0不是终点，3.0+飞书CLI才是完全体。

01 先说清楚飞书CLI是什么

飞书CLI（lark-cli）是飞书2026年3月28日正式开源的命令行工具，MIT协议，GitHub发布首日1000+ Star。

一句话解释：装上之后，Claude Code可以直接操作飞书——发消息、查日历、写文档、建多维表格、发邮件、搜知识库。你跟AI说一句话，它自己去飞书里把事情办了。

安装就两行命令：

npm install -g @larksuite/cli

npx skills add larksuite/cli -y -g

然后手机扫码授权，消息、文档、日历、多维表格、邮箱、任务的权限一次开通。

之后在Claude Code里直接说人话就行。比如"帮我查一下今天的日程"，Claude Code自己会调用lark-cli calendar +agenda去飞书查。

关键点：飞书CLI支持Markdown和飞书文档双向转换，而且保留格式。 这意味着Obsidian里的Markdown文件可以无损同步到飞书文档，这是整个链路能跑通的基础。

02 原来的3.0架构长什么样

先快速回顾饼干哥哥的3.0系统。核心就两件事：

第一，目录结构。 raw/存原始资料只读不改，wiki/存LLM编译产物。你往raw/塞文章，LLM编译到wiki/。

第二，三步编译法。 浓缩（只留核心结论+关键证据）→ 质疑（检查前提假设是否成立）→ 对标（跨领域找类似现象）。比Karpathy原版多了质疑和对标两步，解决了"摘要只压缩不生成新知识"的问题。

一篇原始文章编译后会产出7个Wiki文件：1篇编译摘要、3个概念条目、1个全局索引更新、1条操作日志。下次再编译相关文章时，AI会读取已有条目，增量更新，标注矛盾。

这套系统的天花板在哪？ 知识编译到wiki/之后，所有产出都锁在本地Obsidian里。要协同、要分发、要执行，全靠人工搬运。

03 加上飞书CLI之后，架构变成了什么样

升级后的完整目录结构：

我的Obsidian仓库/

├── 02_Research/

│   ├── raw/

原始资料（只读）

│   │   ├── articles/

│   │   ├── reports/

│   │   └── competitors/

│   └── wiki/

编译产物（LLM维护）

│       ├── summaries/

│       ├── concepts/

│       ├── methods/

│       └── indexes/

│           ├── index.md

│           └── log.md

├── 03_Content/

│   ├── drafts/

文章草稿

│   ├── published/

已发布归档

│   └── schedule.md

排期表（同步到飞书多维表格）

├── 04_Feishu_Sync/

🆕 飞书同步配置

│   ├── sync-rules.md

哪些内容同步到飞书

│   └── team-review.md

团队审核流程

└── CLAUDE.md

编译规则+飞书CLI指令

核心变化就是多了04_Feishu_Sync/目录和CLAUDE.md里的飞书CLI指令。但这个小变化打通了整条链路。

04 CLAUDE.md里加什么飞书CLI规则

在原有编译规则的基础上，追加这段（直接复制）：

飞书同步规则

当用户说「同步 {概念/文章}」时：

1. 读取 wiki/ 下对应的编译产物

2. 用 lark-cli docs +create 在飞书知识库创建/更新文档

- Markdown自动转飞书文档格式

- 保留标题层级、表格、代码块

3. 如果涉及选题排期，用 lark-cli base +records-create

写入飞书多维表格

4. 如果需要团队review，用 lark-cli im +messages-send

发消息到指定群聊，附文档链接

当用户说「发布 {文章路径}」时：

1. 读取 03_Content/drafts/ 下的文章

2. 用 lark-cli docs +create 创建飞书文档

3. 用 lark-cli im +messages-send 通知审核群

4. 审核通过后，移动到 03_Content/published/

5. 更新 schedule.md 和飞书多维表格的状态

当用户说「周报」时：

1. 读取 wiki/indexes/log.md 本周的操作记录

2. 统计：新增概念条目数、更新条目数、编译文章数

3. 用 lark-cli docs +create 生成飞书周报文档

4. 用 lark-cli im +messages-send 发到团队群

05 实操：一篇文章从编译到飞书发布的全流程

拿一个真实场景。我剪藏了一篇TikTok Shop选品策略的文章。

第一步：编译。 对Claude Code说：

编译 02_Research/raw/articles/2026-04-tiktok-shop-选品策略.md

Claude Code执行三步编译法，产出7个Wiki文件。跟原来的3.0一样。

第二步：同步到飞书。 对Claude Code说：

把刚才编译出来的「TikTok Shop选品」概念条目同步到飞书知识库

Claude Code执行：

lark-cli docs +create \

--title "TikTok Shop选品 - 概念条目" \

--markdown "$(cat wiki/concepts/tiktok-shop-选品.md)" \

--folder-token "xxx"

30秒后，飞书知识库里就多了一篇格式完好的文档，标题层级、表格、交叉引用链接全部保留。

第三步：更新选题排期。 对Claude Code说：

基于这篇编译结果，帮我在选题排期表里加一条：下周写一篇TikTok Shop选品实操

Claude Code执行：

lark-cli base +records-create \

--app-token "xxx" \

--table-id "xxx" \

--records '[{"fields":{"选题":"TikTok Shop选品实操指南","状态":"待写","来源":"wiki/concepts/tiktok-shop-选品.md","计划日期":"2026-04-21"}}]'

飞书多维表格里自动多了一行排期。

第四步：写完文章，发团队review。 文章写完后说：

发布 03_Content/drafts/tiktok-shop-选品实操.md 到审核群

Claude Code执行：

创建飞书文档

lark-cli docs +create \

--title "TikTok Shop选品实操指南【待审核】" \

--markdown "$(cat 03_Content/drafts/tiktok-shop-选品实操.md)"

通知审核群

lark-cli im +messages-send \

--chat-id "oc_xxx" \

--text "新文章待审核：TikTok Shop选品实操指南\n请在飞书文档评论区写修改意见\n文档链接：https://xxx"

团队成员在飞书文档里直接写评论，Claude Code可以读取评论并自动改稿——这是飞书CLI原生支持的能力。

全程你做了什么？说了四句话。

06 多账号场景下飞书CLI的价值

如果你跟原文作者一样管理多个公众号，飞书CLI的价值更大。

原来的痛点：4个公众号的选题排期分散在不同的Markdown文件里，要靠人工汇总。

加飞书CLI之后：所有排期写在一张飞书多维表格里，按账号分视图。Claude Code编译完新资料后自动判断跟哪个账号相关，自动追加到对应的排期里。

在CLAUDE.md里加一段：

多账号排期规则

编译新文章后，根据内容主题自动判断适合哪个账号：

- AI技术类 → 饼干哥哥AGI

- 商业增长类 → 第二曲线增长

- 跨境电商类 → 跨境实操号

- 通用方法论 → 同时推荐到多个账号

判断后，用 lark-cli base +records-create 追加到选题排期多维表格，

字段包括：选题、推荐账号、来源概念条目、建议角度、优先级

07 每周健康检查也同步到飞书

原来的健康检查结果只在Obsidian本地生成报告。现在加一步：

健康检查 + 飞书同步

每周健康检查完成后：

1. 在 wiki/indexes/ 生成 health-report-{日期}.md

2. 用 lark-cli docs +create 同步到飞书

3. 如果发现冲突或孤岛页面超过5个，

用 lark-cli im +messages-send 发告警到团队群

4. 用 lark-cli base +records-create

在「知识库健康」多维表格追加本周数据

这样你在飞书多维表格里就能看到知识库健康度的趋势图——概念条目增长速度、冲突修复率、孤岛页面数量变化。数据驱动而不是凭感觉。

08 这套系统的完整链路长什么样

画出来就是：

原始资料（Web Clipper剪藏）

↓

Obsidian raw/（只读存储）

↓ Claude Code 三步编译法

Obsidian wiki/（概念条目+索引）

↓ 飞书CLI 自动同步

飞书知识库（团队共享）

飞书多维表格（选题排期+健康数据）

飞书群聊（审核通知+周报+告警）

↓

公众号发布（审核通过后）

短视频脚本（一鱼多吃）

Obsidian是知识编译引擎，飞书是协同和分发层，Claude Code是中间的执行者。 三者各司其职，你只负责两件事：往raw/塞资料，和审稿点发布。

09 为什么是飞书CLI而不是飞书MCP

飞书同时有CLI和MCP Server两种接入方式，为什么选CLI：

第一，认证方式。 CLI支持OAuth个人登录，操作的是你自己的飞书账号。MCP用App ID+Secret，操作身份是应用机器人。个人工作流场景，用自己的身份才自然。

第二，文档能力。 CLI支持Markdown和飞书文档双向转换并保留格式。MCP处理飞书文档只能拿到纯文本，丢失所有格式。这对内容创作系统来说是致命差别。

第三，AI原生设计。 CLI的错误提示专门为AI优化——出错时告诉Claude Code怎么修复，不只是报个错码。缺权限时自动引导补授权。这些细节让Claude Code调用的成功率远高于直接调API。

10 一句话总结

饼干哥哥的3.0解决了"知识怎么编译"的问题。飞书CLI解决了"编译完怎么用"的问题。拼在一起，才是从原始资料到团队协同到内容发布的完整闭环。

2.0让一个人当一个内容团队。

3.0让一个人当一个知识公司。

3.0+飞书CLI，让这个知识公司真的能运转起来。

知识编译完了，然后呢？

编译产物躺在Obsidian的wiki/目录里，要发飞书文档得手动复制粘贴，要更新多维表格得自己去填，要通知团队得自己去发消息。编译是自动化了，但从知识到执行之间还有一条断裂的沟。

然后3月28日，飞书开源了CLI。

装上之后我才反应过来：CC（Claude Code）+ Obsidian + 飞书CLI，这三个东西拼在一起，才是真正的全链路。

编译完的概念条目可以一条命令同步到飞书知识库。选题排期可以直接写进多维表格。写完的文章可以自动创建飞书文档发给团队review。审核通过后的内容可以自动通知到群聊。

3.0不是终点，3.0+飞书CLI才是完全体。

---

01 先说清楚飞书CLI是什么

飞书CLI（lark-cli）是飞书2026年3月28日正式开源的命令行工具，MIT协议，GitHub发布首日1000+ Star。

一句话解释：装上之后，Claude Code可以直接操作飞书——发消息、查日历、写文档、建多维表格、发邮件、搜知识库。你跟AI说一句话，它自己去飞书里把事情办了。

安装就两行命令：

npm install -g @larksuite/cli

npx skills add larksuite/cli -y -g

然后手机扫码授权，消息、文档、日历、多维表格、邮箱、任务的权限一次开通。

之后在Claude Code里直接说人话就行。比如"帮我查一下今天的日程"，Claude Code自己会调用lark-cli calendar +agenda去飞书查。

关键点：飞书CLI支持Markdown和飞书文档双向转换，而且保留格式。这意味着Obsidian里的Markdown文件可以无损同步到飞书文档，这是整个链路能跑通的基础。

---

02 原来的3.0架构长什么样

先快速回顾饼干哥哥的3.0系统。核心就两件事：

第一，目录结构。raw/存原始资料只读不改，wiki/存LLM编译产物。你往raw/塞文章，LLM编译到wiki/。

第二，三步编译法。浓缩（只留核心结论+关键证据）→ 质疑（检查前提假设是否成立）→ 对标（跨领域找类似现象）。比Karpathy原版多了质疑和对标两步，解决了"摘要只压缩不生成新知识"的问题。

一篇原始文章编译后会产出7个Wiki文件：1篇编译摘要、3个概念条目、1个全局索引更新、1条操作日志。下次再编译相关文章时，AI会读取已有条目，增量更新，标注矛盾。

这套系统的天花板在哪？知识编译到wiki/之后，所有产出都锁在本地Obsidian里。要协同、要分发、要执行，全靠人工搬运。

---

03 加上飞书CLI之后，架构变成了什么样

升级后的完整目录结构：

我的Obsidian仓库/

├── 02_Research/

│   ├── raw/

原始资料（只读）

│   │   ├── articles/

│   │   ├── reports/

│   │   └── competitors/

│   └── wiki/

编译产物（LLM维护）

│       ├── summaries/

│       ├── concepts/

│       ├── methods/

│       └── indexes/

│           ├── index.md

│           └── log.md

├── 03_Content/

│   ├── drafts/

文章草稿

│   ├── published/

已发布归档

│   └── schedule.md

排期表（同步到飞书多维表格）

├── 04_Feishu_Sync/

🆕 飞书同步配置

│   ├── sync-rules.md

哪些内容同步到飞书

│   └── team-review.md

团队审核流程

└── CLAUDE.md

编译规则+飞书CLI指令

核心变化就是多了04_Feishu_Sync/目录和CLAUDE.md里的飞书CLI指令。但这个小变化打通了整条链路。

---

04 CLAUDE.md里加什么飞书CLI规则

在原有编译规则的基础上，追加这段（直接复制）：

飞书同步规则

当用户说「同步 {概念/文章}」时：

1. 读取 wiki/ 下对应的编译产物

2. 用 lark-cli docs +create 在飞书知识库创建/更新文档

- Markdown自动转飞书文档格式

- 保留标题层级、表格、代码块

3. 如果涉及选题排期，用 lark-cli base +records-create

写入飞书多维表格

4. 如果需要团队review，用 lark-cli im +messages-send

发消息到指定群聊，附文档链接

当用户说「发布 {文章路径}」时：

1. 读取 03_Content/drafts/ 下的文章

2. 用 lark-cli docs +create 创建飞书文档

3. 用 lark-cli im +messages-send 通知审核群

4. 审核通过后，移动到 03_Content/published/

5. 更新 schedule.md 和飞书多维表格的状态

当用户说「周报」时：

1. 读取 wiki/indexes/log.md 本周的操作记录

2. 统计：新增概念条目数、更新条目数、编译文章数

3. 用 lark-cli docs +create 生成飞书周报文档

4. 用 lark-cli im +messages-send 发到团队群

---

05 实操：一篇文章从编译到飞书发布的全流程

拿一个真实场景。我剪藏了一篇TikTok Shop选品策略的文章。

第一步：编译。对Claude Code说：

编译 02_Research/raw/articles/2026-04-tiktok-shop-选品策略.md

Claude Code执行三步编译法，产出7个Wiki文件。跟原来的3.0一样。

第二步：同步到飞书。对Claude Code说：

把刚才编译出来的「TikTok Shop选品」概念条目同步到飞书知识库

Claude Code执行：

lark-cli docs +create \

--title "TikTok Shop选品 - 概念条目" \

--markdown "$(cat wiki/concepts/tiktok-shop-选品.md)" \

--folder-token "xxx"

30秒后，飞书知识库里就多了一篇格式完好的文档，标题层级、表格、交叉引用链接全部保留。

第三步：更新选题排期。对Claude Code说：

基于这篇编译结果，帮我在选题排期表里加一条：下周写一篇TikTok Shop选品实操

Claude Code执行：

lark-cli base +records-create \

--app-token "xxx" \

--table-id "xxx" \

--records '[{"fields":{"选题":"TikTok Shop选品实操指南","状态":"待写","来源":"wiki/concepts/tiktok-shop-选品.md","计划日期":"2026-04-21"}}]'

飞书多维表格里自动多了一行排期。

第四步：写完文章，发团队review。文章写完后说：

发布 03_Content/drafts/tiktok-shop-选品实操.md 到审核群

Claude Code执行：

创建飞书文档

lark-cli docs +create \

--title "TikTok Shop选品实操指南【待审核】" \

--markdown "$(cat 03_Content/drafts/tiktok-shop-选品实操.md)"

通知审核群

lark-cli im +messages-send \

--chat-id "oc_xxx" \

--text "新文章待审核：TikTok Shop选品实操指南\n请在飞书文档评论区写修改意见\n文档链接：https://xxx"

团队成员在飞书文档里直接写评论，Claude Code可以读取评论并自动改稿——这是飞书CLI原生支持的能力。

全程你做了什么？说了四句话。

---

06 多账号场景下飞书CLI的价值

管理多个公众号，飞书CLI的价值更大。

原来的痛点：4个公众号的选题排期分散在不同的Markdown文件里，要靠人工汇总。

加飞书CLI之后：所有排期写在一张飞书多维表格里，按账号分视图。Claude Code编译完新资料后自动判断跟哪个账号相关，自动追加到对应的排期里。

在CLAUDE.md里加一段：

多账号排期规则

编译新文章后，根据内容主题自动判断适合哪个账号：

- AI技术类 → 饼干哥哥AGI

- 商业增长类 → 第二曲线增长

- 跨境电商类 → 跨境实操号

- 通用方法论 → 同时推荐到多个账号

判断后，用 lark-cli base +records-create 追加到选题排期多维表格，

字段包括：选题、推荐账号、来源概念条目、建议角度、优先级

---

07 每周健康检查也同步到飞书

原来的健康检查结果只在Obsidian本地生成报告。现在加一步：

健康检查 + 飞书同步

每周健康检查完成后：

1. 在 wiki/indexes/ 生成 health-report-{日期}.md

2. 用 lark-cli docs +create 同步到飞书

3. 如果发现冲突或孤岛页面超过5个，

用 lark-cli im +messages-send 发告警到团队群

4. 用 lark-cli base +records-create

在「知识库健康」多维表格追加本周数据

这样你在飞书多维表格里就能看到知识库健康度的趋势图——概念条目增长速度、冲突修复率、孤岛页面数量变化。数据驱动而不是凭感觉。

---

08 这套系统的完整链路长什么样

画出来就是：

原始资料（Web Clipper剪藏）

↓

Obsidian raw/（只读存储）

↓ Claude Code 三步编译法

Obsidian wiki/（概念条目+索引）

↓ 飞书CLI 自动同步

飞书知识库（团队共享）

飞书多维表格（选题排期+健康数据）

飞书群聊（审核通知+周报+告警）

↓

公众号发布（审核通过后）

短视频脚本

Obsidian是知识编译引擎，飞书是协同和分发层，Claude Code是中间的执行者。三者各司其职，你只负责两件事：往raw/塞资料，和审稿点发布。

---

09 为什么是飞书CLI而不是飞书MCP

飞书同时有CLI和MCP Server两种接入方式，为什么选CLI：

第一，认证方式。CLI支持OAuth个人登录，操作的是你自己的飞书账号。MCP用App ID+Secret，操作身份是应用机器人。个人工作流场景，用自己的身份才自然。

第二，文档能力。CLI支持Markdown和飞书文档双向转换并保留格式。MCP处理飞书文档只能拿到纯文本，丢失所有格式。这对内容创作系统来说是致命差别。

第三，AI原生设计。CLI的错误提示专门为AI优化——出错时告诉Claude Code怎么修复，不只是报个错码。缺权限时自动引导补授权。这些细节让Claude Code调用的成功率远高于直接调API。

---

10 一句话总结

解决了"知识怎么编译"的问题。飞书CLI解决了"编译完怎么用"的问题。拼在一起，才是从原始资料到团队协同到内容发布的完整闭环。

2.0让一个人当一个内容团队。

3.0让一个人当一个知识公司。

3.0+飞书CLI，让这个知识公司真的能运转起来。

---

完整的CLAUDE.md模板（含编译规则+飞书CLI指令+多账号排期规则）放在了「果实学跨境」星球里，复制就能用。