用ClaudeCode自动化生活

• 主持人 Peter Yang 开场把话题定调为一个很「凡尔赛」的烦恼：「现在我们都会碰到的最大的『第一世界烦恼』之一，就是到底该用 OpenClaw 还是 Claude Code 给自己配一个私人 chief of staff？」为此请来朋友、自动化玩家 Moritz Kremb，先逐条对比两套系统长短，再手把手讲「从他的文件夹结构一直讲到他用的那些 skill」。Moritz 专门做了一张对比图逐条过优缺点，理由是「两边都各有长处、各有短板」；Peter 会把图放评论区。一个诚实的「元吐槽」：Moritz 后面坦白，纠结用哪套「某种程度上几乎就是一种『假装在干活』（fake work）」——两套他其实都搭过。这句给整期定了调：工具之争别较真，动手搭才是正事。→ 详细

• Moritz 认为 OpenClaw 最大优点仍是移动端可用性：它「从设计上就支持接入一大堆不同的聊天应用，像 Telegram、Discord、Slack 等等」，「也是它当初能这么火的原因之一」——手机上发消息就能用。Claude Code 陆续补了类似能力（「某个版本做了 dispatch，最近又上了 Telegram 和 Discord 的插件」），但「体验上还是比不上你直接在这些聊天应用里用 OpenClaw 那种感觉」。Peter 附和：用 OpenClaw「感觉就像在 Telegram 里跟一个朋友聊天」，Claude Code 本质「写代码优先」，没那种发短信的感觉。Moritz 补 dispatch 痛点：「你就被锁死在他们的 app 里了」，Telegram/Discord 插件「给我惹了一堆麻烦」，这点仍偏爱 OpenClaw。→ 详细

• 中段赞助口播。Peter 介绍 Linear（项目/工单协作工具）：工程师用 Cursor、Claude Code、Codex 时「很多工作悄无声息发生」——一人可从 Slack 里一份 bug 报告一路做到修复上线，「整个过程在代码编辑器之外不留任何记录」，团队一大协作就难。Linear 的解法是直接和顶尖 agent 编程工具集成，「任何人都能看到某个 agent 正在做什么、是谁把任务派给它的」。OpenAI、Ramp、Block 等团队在用，Peter 自述「我自己也用 Linear 来打理我的创作者生意」，地址 linear.app/agents。→ 详细

• heartbeat（心跳）是让 OpenClaw 显得「永远在线」的关键：它「基本上就是默认每 30 分钟触发一次，OpenClaw 就『活』过来一次」，去跑一遍写在 heartbeat.md 里的任务，给它一种不用召唤、自己定时醒来干活的 always-on 特性。Claude Code 做了个 loops 想模仿，但 Moritz 认为「那其实是另一种用途」，且「只持续 3 天，过了就自动关掉」，「真正的 heartbeat 功能我觉得 Claude Code 里目前还没有」。他往 heartbeat 里放两件事：① 改善记忆（「一开始 OpenClaw 的记忆挺糟的」，故让它每次心跳「不停地检查会话、看我都做了些什么，然后存进我的每日记忆里」）；② 管理待办（希望待办「感觉像是会自己把任务勾掉的那种东西」，指令类似「去看看我都在忙什么，自己把待办清单上做完的勾掉」）。Peter 点头：把记忆放进 heartbeat 是个好主意。→ 详细

• cron job（按固定时间表自动跑的定时任务）在 OpenClaw 里「还是要容易得多，这绝对算个优点」，原因是它「本来就被设计成跑在一台独立设备上，或者云端某个 VPS 上」（VPS＝云上租的一直开机的电脑），一直在跑，「你只要说一句『创建一个 cron job』，它就跑起来了」。Claude Code 对应功能「最早好像叫 schedule，现在改名叫 routines 了」，但分「一个在本地跑，另一个放云上托管」两种，多一层选择门槛就高了点。Peter 替 Claude Code 找补：能在 app 里看到 routines 列表挺好，因为「我根本记不清自己到底设了哪些 cron job」。Moritz 点出 OpenClaw 的尴尬：查定时任务要么翻「那个特别难用的 dashboard UI」，要么翻 cron job 文件，「但它看起来就跟一堆代码似的」。→ 详细

• OpenClaw 第四个优点是 sub agent（子代理，主助理派出去干专项活的「小弟」）：「你可以很轻松地建一个 sub agent，然后让你的主 agent 跟它交互」。Claude Code「其实没这个能力」，绕法是「用一个叫 paperclip 之类的 app 配合」；Anthropic「最近发布了一个叫 Claude managed agents 的产品，方向是对的」但「更像是给开发者用的」。反共识提醒：Twitter 上一堆人吹「我内容这摊事全交给 sub agent」，但 Moritz 判断「对大多数人来说其实根本不需要」——「只要一个主 OpenClaw agent，然后在 Telegram 建几个群分别聊不同的事就够了」，他自己也这么用。sub agent 真正有意义是当你「真的想把上下文隔离开」（比如每摊业务配一个独立 agent），否则代价大：「你就得在所有这些 sub agent 之间不停地搬运上下文。」Peter 补一个自己在用的场景：起草内容后「专门弄一个 sub agent 来审」，这样它「不会因为『这内容是我写的』而带上偏见」——把审稿和起草拆成独立角色。→ 详细

• Claude Code 目前最大优点是可靠性：用 OpenClaw「到现在还是会动不动就崩——突然出个更新，某个东西就坏了，或者模型就直接不工作了」，「还是个挺『技术宅』的产品」。模型优势：「当初 Anthropic 把 OpenClaw 的访问权限给掐断的时候，我觉得很多人就是那会儿转过去的」，且「很多人说，OpenClaw 体验之所以这么好，全靠它当时用的是 Opus 模型」（Anthropic 最强档），所以「目前 Claude Code 用的模型大概还是更好的那个」。Peter 补踩坑：「GPT 5.4 配 OpenClaw 简直糟透了」，据说 GPT 5.5 更好，也据说「你其实还是能在 OpenClaw 里以某种方式用上 Claude 的 CLI」；Moritz 点出关键差距——之前那个模型「没有 Opus 那么主动（proactive）」。安全性：Claude Code「也更安全一些」，但代价是「动不动就来问你要不要批准某个操作」；他绕法是「把 bypass permission 模式设成一直开着」，但也承认「那样我猜安全性也会变得稍微差一点」——典型的「安全 vs. 顺手」取舍。→ 详细

• Peter 描述现状：「邮件管理、日历那些事，还有更新 Google Docs 之类的，我都还放在 OpenClaw 里」，而 Claude Code「我就纯拿来搭东西」。Moritz 给出定位总结：OpenClaw「有潜力变得更自主」，是「你应该放在云端某处、更像一个替你自主干活的员工」；Claude Code「更像一个我在主力机器上用的、实实在在地在增强我工作的工具」——OpenClaw 像「员工」，Claude Code 像「外挂」。可靠性是他「搬家」的直接动因：「我就是因为它更可靠，才把我很多 cron job 都搬到 Claude Code 上了」（前提「假设他们能把这个修好」，尽管它「老是宕机」）；也正因 OpenClaw 不靠谱，他「把我那套 OpenClaw 系统也在 Claude 里搭了一份」，双保险两套同时跑。说到这他正式开始演示自己的 Claude OS。→ 详细

• 演示在新出的 Claude Code 桌面版 app 里进行（Moritz 说「这是新出的桌面版 app，真的特别棒」）。在跳进架构细节前，他先用几个真实例子让大家「更直观地感受它实际是怎么工作的」。第一条 prompt 的原话大意是：「把这个视频（他随手粘了一个 Instagram 视频链接）的字幕扒下来，照着给我的产品写两份类似的脚本，然后把它们当成文档存到 G Drive 里那个叫 Claude content system 的文件夹里。」他特意提了一句因为在做演示，「不该泄露任何敏感信息」，所以挑了个安全的链接。
• Peter 好奇能不能自动从 Instagram 扒字幕，Moritz 拆解了背后的三步工具协作：① 扒字幕靠一个叫 talk script 的 MCP 工具（MCP＝一种让 AI 接外部工具的标准接口）；② 扒到字幕后，「用 Claude Code 本身的智能去写脚本」；③ 再「调用另一个工具去访问我的 G Drive，把文件建好、放进去」。文件最后被放进了 scripts 文件夹。
• 那「另一个工具」就是 Google Workspace 的 CLI（GWS CLI）。Moritz 给了它极高评价：「我得说，这大概是我现在用整套系统时最强大的一个工具。它一下子就解锁了好多可能，因为我能直接访问我的 Google Drive，基本上想拿它干啥都行。」他还说这一条只是想展示「你能多快地从某个网站上抓点东西、再传到 Google Drive 里」，并坦言这条 prompt 其实还能写得更好、或「把它做成一个 skill，让它去引用其他文件」。→ 详细

• Moritz 的偏好很明确：「我一直没接受那种纯靠本地空文件加 Obsidian 来管理一切的做法。我还是更喜欢把所有东西放在 Google Drive 里——它在云上，我手机上也能用。」（Obsidian 是流行的本地 Markdown 笔记软件，很多 agent 玩家用它当「第二大脑」；Moritz 反其道而行。）
• Peter 亲身验证同感：搭自己那套内容系统时，他「大部分东西都放在本地，但弄着弄着我就开始意识到，这其实不太舒服——所有东西都躺在某台机器的本地，想访问就更麻烦」，结论是「放在 Google Drive 里要顺手得多」。
• 这里牵出一个权限信任的差异。Peter 说：拿他的 OpenClaw 来说，「我不会给它整个 Google Drive 的访问权限。它有个单独的邮箱，我只跟它共享部分文件，因为我担心它会把东西搞砸」；而 Claude Code 这边「它用的就是我的主账号凭据」，因为他「对 Claude Code 更信任一些」。Moritz 顺势确认，Peter 答「对……它说不定也会搞砸，但目前为止我对 Claude Code 是更放心的」。→ 详细

• 第二条 prompt 的原话是：「把我以前用过的所有 API 找出来，整理到一个 Google Sheet 里，再传到我的云盘。」执行链路是：在本地文件系统里搜一遍「我在 Claude OS 里一直存下来的所有记忆」，把里面提到的 API 都翻出来，整理生成一个 Google Sheet，再用 GWS（Google Workspace CLI）传回云盘。最终把他「过去这几天打过交道的所有 API 都提取出来」放进表格——都是最近「提到过、或者研究过的那些」，「大概是从我的记忆文件里抓出来的」。
• Peter 问记忆有没有用花哨方案，原话是「你有没有用 Toby 那套 KMD 之类的东西，还是就单纯做搜索？」（KMD 指 Toby 提出的一种知识记忆方案）。Moritz 答得很实在：「目前还挺简单的。我基本上就是照搬了 OpenClaw 那套记忆系统，可能比 OpenClaw 的还要更简单点。到现在为止用着都挺好的。」但预判了瓶颈：「等文件多到一定程度、单个文件又很大的时候，它运转的效果迟早会撞到瓶颈。到那时候我大概就会用上 KMD 了。」
• 记忆机制的结构很简单：「我有一个 memory.md 文件，然后还有一个 memory 文件夹，里面放着每天的记忆文件。」Peter 笑称「好家伙，你这是在把 OpenClaw 重新造一遍啊」，Moritz 答「对，没错」。Peter 还提到一个悬而未决的点：Claude 自己「可能也有一套记忆机制」，每天结束时把东西存到某处，「但可能不在 Claude Home 里，可能是在普通版 Claude 里」——官方记忆能力散落在不同产品里，他俩也没完全摸清。→ 详细

• Moritz 的整套 Claude OS 取名 Claudia。它的 UI 层（他平时怎么操作它）主要靠新出的 Claude Code 桌面 app——「这应用上线大概才十天，在那之前我主要是在终端里用。但现在桌面应用出来了，我就在这上面用了」。他强调这版「提升太大了」，并指出侧边栏便利：「你可以在侧边把这些东西全都打开，能看文件、能看计划之类的。」Peter 补充桌面 app 还能「让你在这儿直接编辑 Markdown」。
• 终端只在边角场景用：「只有偶尔——比如有几个功能桌面版还缺，或者有时我得查点东西——我才会用终端。」
• Cursor / VS Code + Claude Code 插件专门用于「深度编辑文档」：「如果我真的想深入到那种编辑文档的状态，我就会用 Cursor 或者 VS Code，配上 Claude Code 插件。因为在那种场景下，我经常想往文档里敲点什么，然后再引用某段内容，也就是说把它选中、再用 AI 去改。」Peter 觉得反常好笑——「它本来是为写代码设计的，对吧？结果你拿它来处理文档」；Moritz 大方承认「我其实已经有一阵子没拿它写代码了，基本就当 Obsidian 用」。（一个有趣的反讽：他不用 Obsidian 当笔记，却把代码编辑器当 Obsidian 用。）→ 详细

• 这是整套系统的骨架。Moritz 交代来历：搭这套时「我基本是参考了 OpenClaw 的做法，直接照搬了过来」。最重要的指令文件是 cloud.md——「它相当于 OpenClaw 那边的 agents.md，是第一个被读取的文件，可以说是主指令，就像 system prompt 一样」（system prompt＝给 AI 设定身份与规则的开机指令）。机制是：开头一批文件「会被导入到每一次会话里」，而 cloud.md 负责「把其他文件也一并拉进来」。文件开头写明「这里就是你的 Claudia，这是你的工作区」。
• cloud.md 里有一段他称为「记忆循环（memory loop）」的设计，「是用来确保记忆机制真正生效的」：它要求 AI「每次跟它交互完，它都该往每日记忆里写一行，然后偶尔也存进长期记忆」。Peter 确认细节——「每发一条聊天消息，它都得存点东西？」Moritz 答「对」，并坦言坏处「可能是会让每次对话稍微变长一点」，但取舍很明确：「我不想让它丢掉任何信息。」
• 被 cloud.md 引用的其他文件逐项是：identity 和 soul（性格设定——Peter 问「identity and soul 这个文件就纯粹是它的性格设定，对吧？」Moritz 答「没错」）、user.md（「关于我个人的信息」）、各种放业务背景的文件夹、以及 tools.md（他强调「这其实是最关键的部分」，详见下节）。Peter 做了句结构性总结：「基本上你跟 Claudia 的每一次对话，它都会跑 Claude.md，而 Claude.md 又会指向它能引用的其他这些文件」，Moritz 接「对，这样它就能不断积累记忆，随着时间记住各种事情」。→ 详细

• Moritz 反复强调 tools.md 是「最关键的部分」。它的维护方式简单到近乎傻瓜：「我每次加一个新工具，或者一个新的 MCP、新接口之类的，就直接跟它说『把这个加到你的 tools.md 里』。这样它就知道自己手上有哪些工具可以用了。」——核心思想是：让 AI 自己维护一份「我有哪些武器」的清单，它才不会有工具却不会用。
• 这里他又提到一个内置的「夜间整理」小机制：让它在夜里做「流式整理（streaming）」——「它会去翻每日记忆文件，然后生成一个压缩版，存进长期记忆文件里」。Peter 问「这是用 cron 定时任务跑的吗？」Moritz 答「对，是个 routine（定时例程）」。这条把零碎的每日记忆「蒸馏」成长期记忆，避免记忆越堆越乱。
• 防止 memory.md 无限膨胀的做法：Peter 担心「你怎么防止这玩意儿变得超级长？还是说它本来就该那么长？」Moritz 的办法很土但有效——「我的 prompt 基本就是让它『一行就好』，最多一两行。目前还没长到离谱」，但也留了余地「我估计早晚会撞上点问题，到时候就得想个更好的记忆方案了」。→ 详细

• 密钥（API key 等敏感凭据）放在 .env 文件里——「显然还有 .env，用来存所有的密钥。每次我拿到 API key 之类的东西，就往这里放。」（.env 是约定俗成专门存密钥的隐藏文件。）
• Peter 问了个很实际的安全问题：「你怎么把密钥告诉 Claude……你是直接粘到 .env 里，还是说……因为你肯定不想把密钥贴到对话里，对吧？」Moritz 的做法是绕开对话框：「我一般就直接打开 .env 文件填进去，而不是绕道 Claude」——避免密钥出现在聊天记录里。
• 他清单上还想升级的方案是迁到 1Password（密码管理器）：「我已经在 1Password 里专门给 agent 建了一个独立的保险库（vault），可以把密码共享进那个库里。我只要确保我的 Claude OS 也能访问那个保险库就行了。」——好处是密钥集中、可控地共享给 agent，而不是散落在 .env 里。→ 详细

• Moritz 认为「工具」这块「其实是最重要的」，并按类型拆讲。第一类是 CLI（命令行小程序）——「这些基本就是跑在你电脑上的小程序」。他点出 Claude Code 能用 CLI 是它相对 Cowork 的一大优势：「因为 Cowork 算是被沙箱隔离的（sandboxed＝被关在隔离环境里、不能随便碰系统），每次用它都没法真正调用 CLI，而 Claude Code 可以。这也是我宁愿用 Claude Code 而不用 Cowork 的原因之一。」（Peter 顺嘴吐槽 Cowork：「按钮太多了。我还是更喜欢直接来个聊天框」，既然 Claude Code 有了好用的桌面 UI，「那用 Cowork 还有什么意义呢？」Moritz 答「我看不出有什么意义」。）
• 第二类是 MCP。Moritz 吐槽现在接 MCP 的方式太多、有点乱：「你可以通过桌面端连，也可以直接从 CLI 里、在你的 Claude Code 里连。我就觉得有点乱」，但「说到底，你总归能把 MCP 接上，然后你的 Claude Code 就能用它们了」。Peter 担心：「你是把它们都接上、一直开着吗？因为那样会把你的上下文撑爆吧？」Moritz 回应已改善：「我确实是一直开着的，不过我觉得现在好多了。他们做了改进，不会那么容易把上下文撑爆，所以我没太感觉到明显差别。」（context 被撑爆＝塞太多工具说明，挤占了 AI 能处理的有效信息空间。）
• 第三类是 API，并由此引出 Moritz 的一条选型铁律：「现在我找新软件工具的时候，第一件事永远是看：它有没有 CLI？再看有没有 MCP？要是都没有，那至少有没有 API？如果连 API 都没有，我就会去找另一个起码具备其中一种的工具。」——优先级清晰：CLI > MCP > API > 换工具。Peter 替软件厂商敲警钟：「这三样东西你必须得有。不然别人根本不会用你的 app。」
• 第四类是 skill 层（把固化下来的工作流存成可复用的「技能」）。攒法同样简单：「只要某个流程我重复做了好几遍，我就直接说一句『把这个变成一个 skill』，它就被存下来，以后可以反复用。」这与 tools.md 的维护哲学一脉相承——重复的事就让 AI 自己沉淀成可调用的能力。→ 详细

• 「买菜」是一个用浏览器的 skill，来历是：「我最早是在我的 OpenClaw 上把它建成 skill 的，基本上是训练它去用 OpenClaw 的浏览器，然后登录我那个买菜的购物 app。」（用的是 OpenClaw 自带的浏览器能力去模拟人操作网页。）
• 流程是清楚的三步：① 复购固定项——「它第一步是把我上周点的东西原封不动再放回购物车，因为这些都是我每周固定要买的」；② 搜索新增项——「然后它会拿一份清单——就是我通过对话临时加的、这周需要的新东西——去搜对应的商品，加到购物车里」；③ 人工确认——「最后让我确认一下」。Moritz 总结：「它基本上就是帮我把买菜这件事自动化了。」这是一个很好的「重复部分交给 AI、决策部分留给人」的范例。→ 详细

• 「视频上传工作流」是他内容系统里的一环，他形容「超级有用」。先讲清它替代了多麻烦的手工活：「以前每次要给我的剪辑师上传视频，我都得进 Google 建一堆文件夹，把素材拖进去，然后拿到链接发给剪辑师。」
• 现在「这个工作流基本上把所有事都包了。我只要说一句『跑视频上传工作流』，它就把这些文件夹全建好」——而且命名不是瞎起的：它会「从实际的脚本里去读，这样它就知道这期是讲什么的」，据此决定文件夹命名。剩下他只需要「在手机上点开那个文件夹，把所有东西上传进去」就齐活。
• 顺带澄清了 project 级 vs. user 级 skill 的区别。Peter 问「project 是只在当前 Claude Code 项目里生效，user 是在你所有项目里都通用，对吧？」Moritz 确认：「对，没错。这个是只在当前项目里用的（如买菜，属于 Claudia 这个项目），这个则是全局的（在所有 Claude Code 项目里通用）。」→ 详细

• routines 是 Claude Code 用来做自动化的新功能，现分两种。本地（local）：「你必须一直开着桌面 app，也就是你的电脑得开着。然后这些本地 routine 一旦被触发，它就会真的在你电脑上本地运行。」好处是权限全：「它能用你电脑上的那些 CLI，基本上你平时在电脑这边跟它对话时能做的事，它都能做。」代价是电脑必须开机。
• 远程（remote）：适合「你想让某个自动化一直跑着，哪怕你电脑没开也照跑」。设置更复杂——「你得先建一个仓库，把它运行这个自动化所需要的所有东西都放进那个仓库里」，然后「基本上托管在 GitHub 上，这样它就能在云端运行了」。权衡：本地＝能力强但要开机，远程＝随时在线但要先搭仓库。
• 他目前只有一个远程 routine——YouTube monitor：「它其实是在盯着我指定的那些频道，然后把这些频道最新的所有视频都爬下来，放进一个表格里」，表格带上「播放量、点赞、评论这些」，「每周跑一次」。目的 Peter 替他点明：「看看那些同类频道在做什么样的视频，找点灵感」，Moritz 答「正是」。
• 由此牵出一个相关 skill：把「点子（idea）」文件夹里的所有内容（「包括我手动记下来的所有点子」）拿出来「整理成一份周计划」，Moritz 说这个 skill「我记得它现在还跑在我的 OpenClaw 上」（部分能力尚未迁完）。Peter 插了句 AI 题材的特有痛点：「AI 这块的麻烦在于，每周都有新东西冒出来，所以你抓下来的有些内容可能已经过时了。」还顺带感慨 YouTube 标题现实——「光看一个标题你就会觉得，当个 YouTuber 也太容易了吧，就整点离谱的就行……我尽量不去搞那一套，但真的很难，因为你一旦那么写，点击率直接翻倍（2x）」，并引出「你有没有另一个 skill 专门分析这些东西、给你点建议」的提问。→ 详细

• 这是整期重头戏，Peter 称它是「整套东西的压轴重头戏（capstone）」。Moritz 点出前提：「基本上一旦你把工具都接好、把这套底层基础搭起来，你就能开始构建像这样的系统了。这个系统本质上就是一堆 skill、一堆小自动化拼到一起、合力撑起来的东西。」它专做短视频内容，「最早是在我的 OpenClaw 里搭的，现在正在把其中一部分迁移到我的 Claude OS 里」，平时主要通过 Telegram 操作——「我这里有个 Telegram 频道，下面分了一堆子话题」（比如「点子」对应第一步）。
• 第一步「点子采集」有三种捕捉方式：① 直接在 Telegram 打一句——「比如我突然冒出个想法，就直接打一句『把 OpenClaw 和 Claude Code 做个对比』，它就会把这条当成一个点子，记进我某个点子文档里」；② YouTube 自动抓取（即上文那个远程 routine）；③ 转发 Twitter 帖子——「我刷 Twitter 的时候，要是看到某条帖子挺适合拿来当灵感来源，我就直接把它转发给我那个 OpenClaw 机器人的 Twitter 账号，然后有个自动化一直在跑，它会去翻私信，把我发过去的这些东西全都记下来」。Peter 连说两遍「这太聪明了」，并感慨：收藏夹缺一个出口——「我收藏了一大堆东西，结果它们全都躺进了收藏夹的坟场（bookmarks graveyard）」，可惜「好像并没有一个收藏夹的 API」。
• 第二步「每周规划」：「点子采集完之后，我会进入一个每周规划的环节，它本质上就是把所有点子拿过来，帮我生成一份周计划。它会挑出一些主题，然后排进日程里——周一、周二、周三这样，再补充一点细节。」Moritz 说「这一步相对简单」。第三步「写脚本」：「一旦我批准了这份计划，它就能开始帮我写脚本，而且还会参考我过去的脚本来写」——他「已经攒了一个我过往脚本的库」，放在内容文件夹的「短视频脚本」里，系统「会给每一天都生成一个脚本」，他再「进去审一遍，想的话再补点细节」。→ 详细

• 拍摄步骤：「我就把那份脚本拿出来放到手机上，基本上就是对着手机把脚本念出来。」他坦白离不开脚本：「我知道有些人能直接对着镜头讲，根本不需要脚本，或者只要几个要点就行。但我通常至少得有点东西可讲，我得能看到点东西，没法就这么打开手机直接开讲。」Peter 问他为啥不用电脑录屏，Moritz 解释这是风格选择：「我也喜欢这种自然的风格，就是那种手机拍的 UGC 内容（UGC＝用户生成内容，泛指素人随手拍的真实感内容）。我试过各种不同类型的内容，通常最自然的那种风格反而表现最好。所以慢慢地我就索性走这条路了。」
• 剪辑师在环：他的视频风格「通常就是我在讲，偶尔会录一下屏幕来演示点什么」。他「先拍我自己，再录屏幕上的画面，然后把所有这些素材都收齐，发给我的剪辑师」。这一步半自动——「我只要说一句『跑视频上传工作流』，它就会建好对应的文件夹」（命名从脚本读取，见第 17 节）。成片好后，「我的剪辑师会把成片所在的云盘链接发回给我。然后我只要把那个链接粘给我的 agent」，进入发布环节。
• 发布步骤：agent「用一个 CLI 工具把它发布到各个平台上」。Peter 一边自嘲「我现在还在手动发到 Typefully 然后排期」，一边追问用哪个工具。Moritz 给出答案——Postel's（音 Posted's）：「我感觉他们最近真的火起来了，主要是沾了 OpenClaw 和他们那个 CLI 的光。所以，对，他们这个 CLI 相当不错。」用途上：「我是拿它来发视频的，发到 YouTube、Instagram 和 TikTok」，「他们可能也有 X 的集成」；它还能加字幕，「这块我其实也做了一部分自动化，让它根据我的脚本来生成字幕」。→ 详细

• 平台差异：Moritz 提醒「尤其是 TikTok，你通过 API 发布的时候得稍微小心点」。具体而言：「我觉得在 Instagram 和 YouTube 上一般没问题，不会影响表现，但在 TikTok 上可能会稍微影响一点表现。」（言下之意：有些平台对「非人工、走接口」发布的内容会暗暗降权。）
• 新号要养：「如果你是新开的账号，最好先稍微养一养号（warm up）。」Peter 追问「就是先用真人手动发？」Moritz 确认「对，先真人手动发，没错」——新号先靠真人发一阵建立信任，再交给自动化。
• Instagram 的 Edits app 玄学：这也是他一度还坚持手动发 IG 的原因之一。「他们有个叫 Edits 的 app，有段时间在创作者圈子里大家都说，如果你先把视频传进 Edits app，再从那里发到 Instagram，表现会更好。我试了，我觉得是有效果的。」但他给了个诚实的限定：「这种事很难说准，因为你没法做 AB 测试，但我感觉确实有用。」（AB 测试＝同时跑两个版本对比效果，这里没法做，所以只能凭感觉。）→ 详细

• Instagram 上有个常见涨粉/留资玩法：「你知道在 Instagram 上经常会发那种视频，可以送出一些东西，比如某个资源……就是那种『评论一下就送你这个资源』的玩法。」Moritz 把这一整套也自动化了。
• 自动化链路是：「它会根据脚本创建一个 Notion 资源页，把我所有的链接都放进去。然后它会自动把这个 Notion 资源的链接塞进我的 ManyChat 自动化流程里」（ManyChat 是做私信自动回复/营销漏斗的工具——用户评论后由它自动私信发资源链接）。Moritz 总结「这一块也是全自动的，能省下很多时间」。→ 详细

• Peter 注意到标题里写的是「无 AI 痕迹的流程（no AI slop flow）」（AI slop 指那种一眼假、味儿很冲的 AI 流水线内容），问他是不是「直接拿脚本来录的」。Moritz 明确否认，并交代他个人需要手动把关的恰恰就是写脚本这一环：「我想确保脚本是好的。如果完全让 AI 来写脚本，有时候行，但很多时候我还是想确保它够好，会过来做一些手动修改。」Peter 表示「挺好的」。
• 他最喜欢的工作流是一套「笔记 ↔ 脚本」的来回打磨：① 「我会让它根据前面的规划生成一些笔记。所以它其实不是脚本，更像是笔记」；② 「然后我看一眼这些笔记，用我的 whisper flow 往里面补充更多要点」（whisper flow 是一款把语音实时转成文字的工具，他用它口述补点）；③ 「接着我有个 skill，基本上能把笔记转换成我平常想要的那种脚本风格」。他形容这个节奏是：「我基本上就是加点笔记、转换一下，再加点笔记、再转换，给我要发的那七条视频都这么搞。」（一周约七条。）
• 各环节耗时他算得很清楚：脚本一旦准备好，拍摄「基本上就只要 10 分钟」——「你就拿起手机，差不多就是把脚本念出来，或者说演出来」；剪辑师剪「一条视频大概也就花半小时吧。短视频，所以也花不了多少时间」。真正最占时间、最需手动的就是 Peter 总结的那句——「做视频、还有真正剪辑视频」。Peter 确认通过这套流程他能做到大致「一天发一条视频/短片」，Moritz 答「对，差不多」。→ 详细

• Peter 的观察解释了为什么是创作者最早大规模用上这些自动化：「作为创作者，我们要做太多重复性的工作了，所以我感觉创作者算是站在 AI 应用最前沿的一群人」，原因是「我们通常没有一个很大的团队，但要做的事又特别多」——人手少、活又杂，自动化的回报因此特别高。Moritz 认为这套系统的天花板还很高：「我觉得这套东西还能玩出更多花样，对吧？现在只是短视频内容，你完全可以把它接到长视频那块，还有改编（repurpose）成 Twitter、你的 newsletter 等等。所以可做的事还很多。」（repurpose＝一鱼多吃，把同一份内容改写成多个平台的多种形态。）→ 详细

本期没有独立的「lightning round」环节，但结尾 Peter 让 Moritz 给「想在 Claude Code 上搭个人 OS 的人」一个收尾建议：

• Peter 先抛出自己的猜测：「我觉得这个建议可能就是一步一步来，对吧？想想什么最占你的时间，然后一步一步去搭。」→ 详细
• Moritz 顺着确认，并把建议拆成四条递进的原话：① 「先开始就行了（just get started）」；② 「我觉得最重要的就是先把最初的结构搭起来，那个文件夹结构」；③ 「一旦有了它，就开始一个一个地接入你的工具」；④ 「你不用一次性把所有东西都接上，先从一个开始，然后再慢慢往下做」。核心就一句：结构先行，工具渐进，别贪多求全。→ 详细
• Peter 的收尾评价：这套东西「特别有帮助，挺进阶的，不过我相信很多人会去试试」。→ 详细

• Moritz Kremb（嘉宾，自动化玩家）：Twitter 账号为 mugleskremp（转写音译，原话「on Twitter my handle is mugleskremp」）。→ 详细
• Peter Yang（主持人）：本期由 Linear 赞助（linear.app/agents），他自述用 Linear 打理自己的创作者生意。→ 详细