从抖音转写到公众号原文：一次把个人知识库入口移动化的真实升级

在这边文章的基础上做了个升级：我用两条抖音视频，搭出了一个会自我生长的个人知识库入口

注：文中偶尔提到的「Founder OS」，只是我给自己这套个人知识库和工作系统起的内部名称。读者可以把它理解为：一套用来管理信息输入、项目推进、内容创作和 AI 协作的个人操作系统。

这篇文档写给谁

这篇文档适合以下几类人：

• • 每天会刷到大量抖音、公众号、小红书、网页文章，但信息最后只留在收藏夹里的人。
• • 已经有 Obsidian、飞书、Notion 或本地文件夹，却不知道怎样让信息真正被复用的人。
• • 想让 AI 帮自己处理外部信息，但不希望一上来就把系统做得很重、很复杂的人。
• • 正在做个人 IP、内容创作、公众号、社群分享，希望把日常输入变成长期素材的人。
• • 已经开始使用 Codex、Claude、ChatGPT 等 Agent，却发现“装好工具”和“形成稳定工作流”之间还有很长一段路的人。

这篇文档不适合只想找一个“一键自动化脚本”的人。

它记录的是一次真实升级：我如何先用两条抖音视频，搭出个人知识库的原文入口；又如何在一次公众号阅读之后，把这个入口搬进微信，让手机上刷到的信息也能自然进入系统。

这篇文档想解决什么问题

V1 解决的问题是：

抖音视频怎样转成原文，进入知识库，并被进一步判断和复用？

V2 要解决的问题是：

当我在手机上刷到一条抖音或公众号文章时，怎样不必打开电脑、不必切换到 Codex 窗口，也能把它交给同一套知识库规则处理？

换句话说，这次升级不是为了“再装一个机器人”。

而是为了把原先只能在电脑上使用的每日冲浪流程，变成一个随手可用的移动入口：

代码块
Plain Text
复制
手机刷到信息
-> 微信里发链接
-> 机器人接收
-> 调用既有处理能力
-> 原文进入本地知识库
-> 返回这条内容对我有什么用
-> 后续按需要继续加工

读完后你能获得什么

读完这篇文档，你至少可以拿走 6 样东西：

1. 1. 一套从电脑端知识库入口升级到微信移动入口的完整思路。
2. 2. 一套让抖音和公众号文章先进入“原文层”的处理原则。
3. 3. 一套微信、Agent、本地脚本、知识库之间的合理分工方式。
4. 4. 一组真实踩坑：为什么工具跑通了，系统仍然可能不能长期使用。
5. 5. 一组可直接复制使用的微信自然语言指令。
6. 6. 一张清晰的边界图：哪些已经实现，哪些暂时不做。

完整目录

1. 1. V1 已经完成了什么
2. 2. 为什么电脑端跑通还不够
3. 3. 一篇公众号文章带来的第二次升级
4. 4. 我没有重建系统，只给它增加了一个微信入口
5. 5. 微信、Agent、本地脚本、知识库如何分工
6. 6. 如何复用已有抖音转写能力
7. 7. 如何把公众号文章纳入同一套流程
8. 8. 三条真实测试链路
9. 9. 这次接入里踩过的坑
10. 10. 现在怎样在微信里使用它
11. 11. 已实现什么，暂时不做什么
12. 12. 我真正升级的不是工具，而是信息进入系统的方式
13. 13. 可复制提示词合集
14. 14. 附录：最小验收清单

在写这篇 V2 之前，我已经完成过一次很重要的 V1 测试。

它起源于两条抖音视频。

第一条视频让我发现了一个能力：把抖音链接转成文字。

第二条视频让我理解了：原文转出来以后，不能只是放在 Downloads 或收藏夹里，而应该进入一个可以持续判断、持续复用的知识系统。

于是，我先搭出了一个最小闭环：

代码块
Plain Text
复制
刷到抖音
-> 提取文字
-> 转成 Markdown 原文卡
-> 放进素材库
-> 快速判断有没有价值
-> 再决定是否变成内容素材、资料卡、SOP 候选、方法论候选或项目动作

这个 V1 闭环解决了一个很基础但很关键的问题：

信息不能只被保存，它还要在未来能够被找到、被理解、被使用。

我当时真正搭建的，不是一个“抖音转文字工具”。

而是一个外部信息进入个人知识库的入口。

[插图 1：V1 每日冲浪信息闭环图

刷到信息 -> 原文卡 -> 快速判断 -> 用户确认 -> 分流复用 -> 长期资产]

V1 跑通以后，我已经可以在 Codex 或 Claude 的电脑窗口里处理链接。

但我很快发现，真实使用中还有一个摩擦。

我大量接触新信息的场景，并不在电脑前。

它发生在：

• • 通勤路上刷手机。
• • 晚上随手看抖音。
• • 微信上看到朋友转来的公众号文章。
• • 公众号里看到一篇很长、但暂时没耐心逐字读完的文章。
• • 某个群里看到一个项目、工具、趋势或方法论链接。
• • 临时想到一个“这个以后也许会有用”的问题。

如果每次都要：

代码块
Plain Text
复制
复制链接
-> 等回到电脑
-> 打开 Codex
-> 找到正确窗口
-> 再贴进去

这条链路仍然会断。

因为信息处理最重要的，不只是“后面能不能加工”，还包括“刷到的那一刻能不能低摩擦进入系统”。

我开始意识到：

V1 解决的是“知识库有没有入口”；V2 要解决的是“这个入口能不能跟着我一起移动”。

这也是为什么，微信比单纯增加一个新工具更重要。

不是因为微信更高级。

而是因为它是我本来就在使用的日常信息环境。

我开始意识到：V1 解决的是“知识库有没有入口”；V2 要解决的是“这个入口能不能跟着我一起移动”。

这次升级并不是我预先规划好的。

它依然来自一次日常冲浪。

我读到一篇关于微信、AI Agent 和本地知识库连接方式的公众号文章。文章让我意识到：如果把微信只理解成聊天软件，就太窄了。

它还可以成为一个轻量的收件入口。

我不需要让微信替代知识库。

也不需要让机器人替我做所有判断。

我真正需要的是：

代码块
Plain Text
复制
微信负责收件。
本地知识库负责存放。
已有脚本负责提取。
AI 负责理解、建议和回执。
我自己负责判断、确认和升级。

这个理解非常重要。

因为很多自动化系统一上来就想“让机器人全自动帮我做完”。

但对我来说，更合理的顺序是：

代码块
Plain Text
复制
先让信息稳定进来
-> 再让系统给我一个快速判断
-> 最后由我决定是否继续加工

我不需要一个替我做人生决定的机器人。

我需要一个能把手机里稍纵即逝的信息，稳定送进自己系统里的入口。

这次升级最重要的原则是：

不要因为换了一个入口，就重建一套新的知识处理逻辑。

V1 里已经有的东西，继续保留：

• • 抖音转写能力。
• • Markdown 原文卡。
• • 原文池。
• • 每日冲浪原文沉淀规则。
• • 快速判断模板。
• • 内容素材、资料卡、方法论候选等后续分流能力。
• • Codex 与 Claude 都读取同一套规则的原则。

V2 只增加一个入口层：

代码块
Plain Text
复制
原来：
电脑窗口 -> 本地处理器 -> 知识库

现在：
微信 -> 微信通道 -> Agent -> 本地处理器 -> 知识库

这意味着，微信不是另一套知识库。

它也不应该拥有另一套目录、另一套分类规则、另一套内容标准。

它只是把同一套能力带到了手机端。

[插图 2：V1 与 V2 的关系图

V1：电脑端入口

V2：微信移动入口

两者共用：原文池、规则、脚本、分流逻辑]

为了不让系统越做越乱，我给每一层只分配一个清晰职责。

代码块
Plain Text
复制
个人微信
-> 发送链接和接收结果

微信通道
-> 接收消息、把消息交给 Agent、把结果发回微信

Agent
-> 读取规则、识别链接类型、调用既有处理入口、生成快速判断

本地脚本与 Skill
-> 抖音转写、公众号文章采集、Markdown 转换、原文卡生成

个人知识库
-> 保存原文、沉淀规则、记录候选资产、承接后续复用

我自己
-> 判断是否值得继续处理，决定是否升级为内容、方法、SOP 或项目动作

这套分工避免了一个常见误区：以为微信机器人本身就是知识库大脑。

这套分工避免了一个常见误区：

以为微信机器人本身就是知识库大脑。

不是。

机器人只负责把信息送进来、把结果送回去。

真正的规则仍然在我的本地知识库里。

真正的处理能力，仍然来自已经跑通过的脚本和工具。

真正的决策权，也仍然在我手里。

[插图 3：微信每日冲浪信息处理架构

微信 -> OpenClaw -> daily-surfing Agent -> 抖音/公众号采集器 -> 原文池 -> 快速判断 -> 微信回执]

6. 如何复用已有的抖音转写能力

在 V1 里，我已经验证过 douyin-video-to-text。

它负责把抖音链接转成临时文字。

但这里有一个非常容易被忽略的区别：

代码块
Plain Text
复制
临时转写 txt
不等于
长期知识库原文

临时 txt 可以放在 Downloads。

但 Downloads 是工具工作区，不是知识库。

它可能被清理，也不适合作为后续 Agent、Obsidian 插件或知识库检索的稳定入口。

所以抖音处理真正完成的标准不是“转写成功”。

而是：

代码块
Plain Text
复制
抖音链接
-> 临时 txt
-> Markdown 原文卡
-> 进入每日冲浪原文池

Markdown 原文卡里至少应该保留：

• • 原始链接。
• • 平台来源。
• • 采集日期。
• • 标题或视频文案。
• • 转写正文。
• • 当前处理状态。
• • 快速判断或后续处理记录。

这样，未来我再问：

我之前是不是看过类似的内容？有没有一条素材讲过知识库、AI Agent 或信息入口？那条视频后来有没有变成内容素材？

系统才有证据可查。

公众号文章对我来说很重要。

因为它常常不是几分钟的视频，而是一篇有完整论述、有案例、有方法、有观点的长内容。

而且公众号文章的来源又天然贴近微信生态。

所以这次升级不能只做到“抖音链接能处理”。

还要让公众号文章进入同一套信息处理系统。

我的基本判断是：

代码块
Plain Text
复制

它们不应该一开始就被强行变成项目资料、内容草稿或方法论。

它们首先应该被当成原始材料。

区别只在于后续语境。

如果我只是说：

按我的规则提炼这篇文章。

它默认是“个人每日冲浪”。

如果我明确说：

这是公众号项目的对标文章。帮我看它的爆款逻辑。这篇和我的选题库有关。

系统才知道，这篇文章后续与公众号项目有关。

所以公众号文章的处理逻辑可以理解为：

代码块
Plain Text
复制
公众号链接
-> 采集 Markdown 与图片
-> 根据消息语境判断
-> 个人冲浪 / 项目对标 / 待确认
-> 返回快速判断

这里有一个很重要的原则：来源相同，不代表用途相同。

这里有一个很重要的原则：

来源相同，不代表用途相同。用途不同，也不代表原文不需要先被保存。

[插图 4：公众号文章分流图

公众号文章

-> 默认：个人每日冲浪

-> 出现“对标、爆款、赛道、账号拆解、选题库”等语境：公众号项目

-> 识别不清：待确认]

这次升级不是只写了技术文档。

我实际跑了三条链路。

这次升级不是只写了技术文档。我实际跑了三条链路

它验证的不是某个工具能不能打开，而是收件、提取、落库、判断和回执能否真正连成闭环。

8.1 第一条：抖音链接

测试目标：

代码块
Plain Text
复制
微信发抖音链接
-> 调用既有抖音转写能力
-> 生成 Markdown 原文卡
-> 原文进入知识库
-> 微信返回快速判断

它验证的是：

• • 微信入口可以接收到链接。
• • Agent 可以调用本机既有能力。
• • 抖音原文不会只停留在临时下载目录。
• • 我能直接在微信看到“这条内容对我有什么用”。

8.2 第二条：个人公众号文章

代码块
Plain Text
复制
微信发公众号文章
-> 采集正文和图片
-> 转成 Markdown
-> 保存原始材料
-> 返回内容主题和使用建议

它解决了一个很真实的问题：

很多公众号文章我觉得有价值，但不想当下花十几分钟读完。

我可以先把它交给系统，保留原文，再拿到一个初步判断。

这不是让 AI 替我读完所有文章。

而是让我先知道：

这篇值不值得我后来认真读？它更适合业务、内容、方法论，还是只是一般参考？它有没有和我现在正在做的事发生连接？

8.3 第三条：公众号项目语境文章

代码块
Plain Text
复制
微信发公众号链接 + 项目语境
-> 识别为对标或项目材料

这条链路的意义在于：

我不希望个人冲浪和公众号项目资料混成一团。

但我也不希望每次都手动进入不同文件夹、重新解释上下文。

更自然的方法是：

我在微信里把用途说清楚。系统按已有规则接住它。

真实搭系统时，真正花时间的往往不是“安装”。

而是找到那些表面上看不见的断点。

9.1 同一句话，不同 Agent 可能执行出不同结果

我最早的经验来自 V1。

我在不同 Agent 里输入同一个 Skill 名称，得到的并不一定是同一个工具。

这让我意识到：

代码块
Plain Text
复制
自然语言描述
不等于

所以后续我不再把“同名工具”当作已经对齐。

而是要检查：

• • 实际安装路径。
• • 实际脚本入口。
• • 实际输出格式。
• • 依赖环境。
• • 能不能复用同一套规则。
• • 能不能被下一步处理器调用。

9.2 工具成功，不等于知识库成功

抖音转写显示成功，只说明它拿到了文字。

公众号文章采集成功，只说明它拿到了 Markdown 和图片。

真正的验收还要继续问：

• • 原文放在哪里？
• • 路径是否符合规则？
• • Agent 能不能找到？
• • 后续能不能被复用？
• • 微信回执是否告诉了我正确结果？
• • 是否误生成了不该生成的资产？

工具只是能力。

接入工作流，才是系统。

9.3 微信账号绑定不能偷懒

微信通道里有一个很现实的问题：

如果路由绑错，消息可能进入错误的 Agent，或者回到了通用会话。

所以正式接入必须验收：

• • 真实微信账号是否已完成授权。
• • 真实账号是否绑定到专用 Agent。
• • 测试消息是否进入正确会话。
• • 回执是否仍然从正确机器人返回。

9.4 前台跑通，不等于正式入口

最初 Gateway 可以在终端前台运行。

这适合测试。

但它不是稳定入口。

一旦关掉终端，微信入口也就断了。

所以在确认真实流程跑通后，我把 Gateway 交给系统的用户级服务管理。

这样只要 Mac mini 已开机、联网、并处于登录状态，微信入口就会持续运行。

这里要分清：

Mac mini 关机、断网或退出当前用户会话时，系统仍然不能持续收件。

这属于下一阶段的“常在线队列层”问题，不应该在当前阶段假装已经解决。

我现在不需要记复杂命令。

只要进入微信机器人会话，发送链接，再补一句自然语言即可。

10.1 处理一条抖音

代码块
Plain Text
复制
按我的规则提炼这条：
<抖音链接>

10.2 判断一条内容有没有用

代码块
Plain Text
复制
这条对我有什么用？
<抖音或公众号链接>

10.3 先保存原文，不急着继续加工

代码块
Plain Text
复制
先帮我保留原文和快速判断，暂时不要继续做内容或方法论。
<链接>

10.4 指明它与公众号项目有关

代码块
Plain Text
复制
这是公众号项目的对标文章。
帮我按项目语境处理：
<公众号文章链接>

10.5 让系统告诉我是否值得深加工

代码块
Plain Text
复制
帮我判断这条值不值得继续做成：
内容素材、资料卡、方法论候选，还是只归档。
<链接>

对我来说，真正好用的入口不是让我记住系统术语。

而是我能像跟一个熟悉我的工作方式的助手说话一样，把链接扔过去。

11. 已经实现什么，暂时不做什么

已经实现

• • 微信中可以直接提交链接。
• • 抖音链接可以调用既有转写能力。
• • 抖音临时文字可以转成 Markdown 原文卡。
• • 公众号文章可以采集为 Markdown 与图片。
• • 系统可以按个人冲浪或项目语境理解公众号文章。
• • 微信可以返回原文路径、主题、核心观点和使用建议。
• • Gateway 已从临时测试改为本机正式运行入口。
• • 电脑端和微信端共用同一套知识库规则与本地处理能力。

暂时不做

• • 不承诺 Mac mini 关机时仍能收件。
• • 不把所有平台一次性接入。
• • 不让机器人自动发布内容。
• • 不让机器人自动升级正式 SOP、Skill 或方法论。
• • 不因为一条素材就自动建立复杂项目。
• • 不为了追求“全自动”而牺牲原文证据、路径清晰度和人工判断。

我越来越相信：

没有稳定规则的自动化，不是效率工具，而是混乱放大器。

回头看，V1 到 V2 的变化并不神秘。

V1 是：

我让抖音信息可以进入知识库。

V2 是：

我让手机上刷到的信息，可以在当下就进入同一套知识库。

这件事的价值不在于多了一个机器人。

而在于我不再把“刷到有价值的信息”当成一件随机的、容易遗忘的事。

现在它开始变成一条稳定的路径：

代码块
Plain Text
复制
刷到
-> 发给微信机器人
-> 保留原文
-> 得到判断
-> 决定是否继续使用

以后，我看到的内容不一定都要立刻读完、消化完、输出完。

但它至少有机会进入自己的系统。

有机会在未来写文章、做项目、复盘成长、判断机会时，再次为我工作。

这就是我想要的个人知识库。

不是资料仓库。

而是一套可以持续吸收、理解、回看和复用的信息系统。

提示词 1：只做原文与判断

代码块
Plain Text
复制
请按我的每日冲浪规则处理这条链接。

要求：
1. 先保留原文。
2. 告诉我一句话主题。
3. 提炼核心观点。
4. 分析它对业务、内容、方法论、个人认知、机会判断分别有什么用。
5. 判断是否值得深加工。
6. 给出建议分流。
7. 暂时不要自动生成内容稿、SOP、方法论或项目动作。

链接：
<粘贴链接>

提示词 2：公众号项目对标处理

提示词 3：决定是否继续加工

代码块
Plain Text
复制
请基于这条已经进入原文池的信息，帮我判断下一步最合适的处理方式。

只从以下选项中推荐：
- 仅归档
- 内容素材
- 资料卡
- 支持卡
- SOP 候选
- 方法论候选
- 项目动作
- 待确认

请说明推荐理由，并告诉我是否需要我确认后再继续。

提示词 4：把一条信息转成内容素材

代码块
Plain Text
复制
我确认这条信息值得继续加工。

请不要直接写成发布稿，先帮我整理成一张内容素材卡：
1. 可表达的核心观点。
2. 可以连接的真实经历。
3. 适合的平台。
4. 3 个标题方向。
5. 适合补充的案例、截图或证据。
6. 当前不要发布。

每次你准备接入一个新的信息来源时，不必先追求复杂自动化。

先问这 8 个问题：

代码块
Plain Text
复制
1. 链接能不能被稳定接收？
2. 原文能不能被提取？
3. 原文是否进入长期知识库，而不是临时目录？
4. 是否保留了来源链接和必要元数据？
5. 系统能不能返回快速判断？
6. 个人冲浪与项目资料能不能区分？
7. 是否避免了误发布、误升级和误写入？

如果这 8 个问题还没有稳定答案，就不要急着接入更多平台。

先让一个入口真正可用。

再让第二个入口加入。

个人知识库不是一次搭完的工程。

它应该随着真实使用，一点点长出来。