我如何用 Claude Code 在 40 分钟里规划、构建、运行循环——Thariq Shihipar

• 「loop」在 Thariq 嘴里是个宽泛的词，泛指各种「让 agent 拿到反馈、以某种编排方式长时间干活」的做法。Claude Code 现在有三样东西奔着这个目标去：/loop、/goal、workflows（工作流，用一段代码把多个 agent 的分工和验收编排起来）。片中他只点了 /loop 的名字没展开，重点讲的是后两个——他的判断是 workflow「在我看来可能是这几种里最强的形态」。→ 详细
• 三者的分工一句话说清：/goal 管「什么时候才允许停」，workflow 管「活怎么拆、分给谁干、谁来验」。Thariq 特别强调 workflow 对非技术类的活尤其有用——它是把一个「不确定性很强的任务」大致拆成「确定性任务」的办法。→ 详细

• /goal 的作用是「让 agent 不断提醒自己退出条件是什么，只有真正达成了才允许它停」。它适合那种复杂、你非常需要确保最后真的做完的任务——你就是要防着它中途撂挑子。→ 详细
• Thariq 让你设身处地站在 Claude 的角度想一想：有人给你派了个活，干着干着碰上点麻烦，或者某处不太合规格、跟用户说的对不上，你很可能就提前停下来问一句「这个我还要不要继续？」。而 /goal 就是用户提前表态：「我前期的 spec 和探索已经做够了，问题空间我心里有数，你只管去执行，路上遇到没定的东西你自己补上。」——等于给 agent 一个「硬着头皮往前推」的反馈信号。→ 详细
• 但 /goal 不是万能挡箭牌。Peter 承认他试过直接甩一句「给我做一个超棒的游戏」当 goal，「结果它整个跑偏了，毕竟就那么一句话」。Thariq 的回应很克制：「你到底想要什么，这里面细节非常多，是要花不少功夫去理清的。」——前期规划做不做得够，决定了 goal 是加速器还是放大器。→ 详细

• 判断用哪个，Thariq 给的分水岭是：你手上有没有一个确定性的信号。比如延迟（latency）这种能量出来的指标，/goal 就特别好用——让 agent 自己反复试、自己看数字，「有点像自动做研究」。→ 详细
• 换到设计这类活，他说你首先该想的是：agent 到底能多准确地理解你所谓的「设计」本身。所以要把它变成一份它能自己验证的 spec：源头是 Figma 文件，就接 Figma MCP（Model Context Protocol，让 Claude 直接读取外部工具数据的标准接口），然后 /goal 说「确保渲染出来的界面和 Figma MCP 里的一致」——「这比丢给它一张截图容易多了」。→ 详细
• 如果你手上只有一张截图，那就没有确定性信号可用，只能走 workflow 那条更贵的路：「标准更软、更模糊，你得有一份评分 rubric（评分标准表，把「什么样才算好」逐条写下来给模型自查），再配一个专门做验收的 agent。」→ 详细
• 他顺带提到，同事 Jared 讲过他们用 Rust 重写某个项目时是怎么用 workflows 的，后续会有更详细的分享（字幕对该项目名的识别不可靠，此处不臆测具体名字）。→ 详细

▲ 一句 prompt 生成的视频编辑器：左边是素材与配置文件，右边直接预览渲染结果。

• 上节目前 10 分钟，Thariq 随手录了段视频当素材：对着镜头说「嘿，是我，我现在在 Peter Yang 的播客上」，用手指了一下想让浮层出现的位置，然后说「好，淡出到黑场」。→ 详细
• 他给 Claude Code 的 prompt 原话大意是：「这是 Peter Yang 播客的 repo，这里有个样片叫 Peter Yang recording，用 Whisper 把它转写出来；然后用 Remotion 做一个 UI，把转写文本显示出来、每个词逐词高亮，再加上各种浮层。」最后追加一句 goal：不把整支视频渲染完就别停。（Whisper 是 OpenAI 的开源语音转文字模型；Remotion 是「用 React 代码写视频」的框架——写代码即出片。）→ 详细
• 结果「完全是一次成型的，就一句 prompt」：转写做完、逐词字幕做出来了、小浮层也加上了，接着淡出黑场。唯一的破绽是它不知道他名字叫 Thariq。他说这是他那套视频剪辑工作流「最最基础的起点」，也是「在 Claude Code 里怎么干非技术类的活」的一个好样本。→ 详细
• 他到现在都还没把这套存成 skill，理由值得抄：「我一般会先把『我到底想要什么』搞清楚，再去把它变成 skill。」目前没搞定的边界情况是——判断他的手在哪儿、指向哪里，这块模型做得不好，「就算是现在这一版，那个浮层出现的位置我也不太满意」。下一步的方向是做手指追踪或人脸追踪，把更多元数据喂给 agent，让它能做出更有意思的浮层。→ 详细

• Thariq 说，就算只是为了写出上面那一句 prompt，前面也做了不少规划和摸索。而大家平时说 plan，往往指的是那种一次性的东西——「你规划一下，然后照着做，完事」。他的看法正相反：规划是个反复迭代的过程——探索、调研、搞清楚自己不知道什么、自己到底想要什么，最后这些东西会自己收敛成一个简洁的结果。→ 详细
• 他更愿意把「规划」换个说法叫「消灭你的未知」：每次接到一个任务，「几乎总是有一大堆你不知道的东西：要么不知道某个东西怎么运作，要么不知道自己到底想要什么……它不是『一次性全写下来然后照着实现』，中间会有很多步、很多轮。」他甚至觉得 plan 这个词现在「可能太笼统了」。→ 详细
• 这件事可以有很多种形态——「可以是学习，可以是技术方案，也可以是原型稿和探索」，都算规划。表面上是在做 plan，实际上是在把自己的未知项挖出来。→ 详细
• 一个具体的收获例子：他为了把文字放到画面主体的后面，专门研究了 video segmentation（视频分割，把画面里的人和背景分离出来的算法），结论是「这块并没有哪个方案可靠到能让我直接拿来用」——这也是规划的成果，它省下的是「照着做了才发现做不成」的时间。→ 详细

• 他在 plan 里专门下了一条指令：「给我讲清楚 Whisper 是怎么回事，以及有哪些边界情况。」Claude Code 生成的那份讲解他评价是「说实话挺惊艳的」，而对他最重要的部分是「哪些地方会出错」。→ 详细
• 列出来的坑很具体：一段静音会被识别成「thanks for watching」（模型见多了 YouTube 结尾）；一个词会被切成两段；它没有说话人识别能力，分不清谁在说话。→ 详细
• 为什么这一步值钱：「提前知道这些边界情况、知道它的能力边界在哪儿，帮我避开了一种很糟的情况——我吭哧吭哧围着 Whisper 搭了一套复杂的 workflow，跑起来才发现这儿那儿都不对，而这些未知的未知（unknown unknowns，你连『自己不知道这件事』都不知道）我事先完全没意识到。」这一步同时也让他「对用 Whisper 这件事建立起了信心」。→ 详细

▲ 把设计变体一次铺开来看：同一条「Hey Peter Yang」浮层，右侧列出多套字幕/浮层样式供挑选。

• 录制途中他顺手演示了一条指令：「我想改这些浮层的 UI，我想用 Peter Yang 的风格，这是他的博客，做一个 HTML artifact，用来探索浮层和字幕的几种不同设计变体。」关键动作是给参考物——把 Peter 的网站丢给它，它就能抓那份 HTML 当风格依据，而不是靠你干巴巴描述；他强调这也是规划，因为本质上是在搞清楚自己到底想要什么。→ 详细
• 结果出来后他点评「它可能更多是照着 Substack 那套品牌调性来的，而不是你自己的品牌」；Peter 说「我压根没什么品牌」，他反驳「你有的——你不是有红白配色嘛」。为什么要铺开看：「这几版设计之间的差别其实挺大的……尤其我又不是设计师，只能是「看到了才知道自己要什么」。」→ 详细
• 那份让 Peter 惊叹「太漂亮了、还带图」的 plan，用的是 front-end design 这个 plugin；但他补了一句：也有难看的，比如之前生成的那份 Remotion 的 plan。→ 详细

▲ Claude 产出的 HTML artifact《The Anatomy of a Transcript》——排版精致到像一篇正式刊物，也正因为漂亮，更容易「生成了却没人读」。

• Anthropic 内部现在共享东西的方式，就是让 Claude 生成一个 artifact（可交互的 HTML 页面）：一份 plan、一个已经做完的 PR、状态报告、事故复盘，都走这个格式。artifacts 目前只有 Teams 和 Enterprise 版能用，「希望之后能开放给 Max 和 Pro」。→ 详细
• 但他对「好不好看」态度很淡：「它长得好不好看没那么重要，关键是你真的得去读它——不用全读，但里面有些重要的部分你得看。我看到的一个常见失败模式就是，大家还是会把 plan 和这些讲解一眼扫过去、根本没看进去。」→ 详细
• Peter 老实承认自己就是这样：AI 刷刷刷写出一堆疯狂的 markdown、通常还特别长，看到某个点就懒了，心想「行吧行吧，你直接干就完了」。Thariq 的回应是全片最扎心的一句之一：「那个输入框完全可以当成一个『偷懒按钮』——你就打一句『诶，把这事儿办了』。但通常你是要为此买单的。因为如果你做的是件正经事，而每一步你都选了偷懒的那条路，最后反而会拖更久，可能也更烧钱。」→ 详细

▲ 最小验证步的实况：Claude 改掉一行浮层 HTML（红绿 diff），紧接着自己跑起 shell 命令验证效果。

• Peter 的提问很产品经理：他写产品 spec 写了十年，套路都是「要解决什么问题 / 方案是什么 / 目标是什么」，但现在这些东西有一部分是写给 agent 读的——章节该不该改？产品 spec 和技术 spec 要不要合成一份？要不要分「给人看的」和「给 agent 看的」两部分？→ 详细
• Thariq 的答案是两者紧紧绑在一起，spec 本身甚至会一路演化成 plan。他描述的实际流程是：人提出需求 → agent 去做一轮技术探索 → 回来后你再做几个 mockup、写几份说明把未知搞清楚 → 打磨一遍再交回去 → 它开始动手实现。「所以我不认为写 spec 只发生在一开始……这远不是『spec 写完一次性交接给实现』，而更像是来回拉扯的过程。」→ 详细
• 中间有个可以直接抄的动作：让 agent 一边实现一边记 implementation notes（实现笔记），把「这次实现里有哪些是我们原本没料到的」沉淀下来；有了这些，需要的话就回头重写 spec。Peter 的总结是「就像一份活的文档」——下次开新章节时它可以直接去参考前面那份产物。→ 详细
• 配套心法是「最小验证步」：那些 HTML 浮层其实只是设计的原型；觉得这版行了，再上更贵的版本——从 HTML 换成 React，「那就意味着你得把视频重新渲染一遍、代码也得全改」。所以每次都问自己一句：「要验证你想要的那个概念、把 spec 再往前推一步，你能迈出的最小一步是什么？」→ 详细

• 先解释两个名词：Claude Tag 就是「Slack 里的 Claude」——你在 Slack 频道里 @ 它派活，它在那个 thread 里干活、回话；multi-Claude（multi-Clauding）指同时开着好几个 Claude 会话干不同的事。→ 详细
• Thariq 现在的配比非常明确：「以前我是在 Claude Code 里同时开五个 Claude，现在基本上是一个活跃的 Claude Code 会话，外加一堆 Claude Tag 会话。」分工标准是：只要不是非得在本地跑的并行活儿都丢给 Claude Tag，初步探索、写 PR 的 spec、想搞明白某个东西也都在 Claude Tag；等聚焦到某一件具体的事上，才回到 Claude Code 做那种来回迭代的活。为此他们花了很多力气确保开发环境能在远端跑起来。→ 详细
• 一个很具体的用法：有个 PR 要合进去，他会「让它去盯着这个 PR、把测试修好，然后 tag 一位 reviewer」——reviewer 在同一个 Slack 频道被 @ 到，人和 agent 直接在那儿聊。这就是 Slack 相比终端的独特价值：把 agent 拽进多人协作的场子里。他自己有个 thariq-claude 私人频道干大部分活，团队则用 feedback 这类频道和按项目分的工程频道。→ 详细
• Peter 的观察很到位：现在这些写代码的应用基本还是单人体验，你在一个个 thread 里跟 agent 对话；而 Claude app 长得跟 Slack 挺像（一堆 thread 对一堆频道），所以 Slack 天然成了「多人协作版的 Claude」，因为大家本来就都待在那儿。Thariq 认可这只是起点，最终设想是 Claude 变成一个主动型 agent，「你人在哪儿它就出现在哪儿」；而且「它写代码好得出乎意料——真有人几乎所有代码都是在 Claude Tag 里写完的」。→ 详细
• 一个操作细节：在 Claude Tag 里怎么触发 skill？不用打斜杠命令，直接跟它说用哪个 skill 就行——这块交互他们还在迭代。→ 详细

• Peter 抛出流行判断：「未来 agent 就跟公司里多了个员工似的——你得给它做入职、在 Slack 上跟它说话、甚至给它打个电话。」Thariq 的回答很有分寸：「这类比喻有时候挺有用，但某种程度上也会框住你的想象。」拿身份（identity）举例：Claude Tag 里每个 agent、每个频道都有自己独立的记忆，但这只是一种设计选择——你也可以想象好几个 Claude 各有不同的 Slack 身份、你按需 @ 不同的那个。它主动、有记忆、有身份，但「说到底它就是 Claude Code 的一次演进」，比起套框他们更想看模型会把人带到哪儿。→ 详细
• Peter 说它记性肯定比人强，Thariq 纠正得很准：「有时候更强，有时候更差……它的能力是尖刺状的（spiky）——有的地方特别强，有的地方特别弱。」→ 详细

▲ Peter 那个 skill 一口气揽了四件事：缩略图与标题组合、开场混剪、最该剪的 5 个片段、节目笔记——这正是 Thariq 说它「想干太多事」的地方。

角色提醒：这一段是 Peter 在演示自己的东西、Thariq 在提问和给建议。

• Peter 展示了两个自建 skill。① podcast production skill（播客制作）：把某期访谈的文字稿丢进去（他举的例子是采访 Anthropic 的 Jess），它就生成封面缩略图、该剪哪些片段、newsletter 贴文、要点清单——「@ 它一下，把文字稿一贴，它就开始生成那种标题党式的 YouTube 缩略图」，他会喂自己的样例进去防跑偏。② video post skill：把整期 YouTube 视频拿过来、抽出内容、给出可剪成短片段的点子，并且真的把片段剪出来——他说「做两条」，它就用 ffmpeg（命令行视频处理工具，剪切/转码/加字幕都靠它）做出成片，还自动加字幕。他所有 skill 都放在 user level（用户级，任何目录都能调），产出统一堆在一个叫 personal OS 的文件夹里，用法是把一堆 skill 串起来：先准备素材、再做缩略图，一路串下去。→ 详细
• Peter 自己给出的不满：希望它能自己往里加 B-roll（穿插的辅助画面）和 Thariq 演示的那种浮层特效；还希望它「聪明到知道该往视频片段里配什么素材——比如需要 Claude 的 logo，那种网上随手就能扒到的东西」。他也主动承认「这个 skill 想干的事有点太多了」。→ 详细
• Thariq 反馈一：skill 和 workspace 是两回事。「有时候你要的是一个 skill，有时候你要的其实是一个塞满脚本和各种小工具的 repo——那更像是一个你日常干活的 workspace（工作区）」，而且「skill 本身就可以是『怎么把那个 workspace 搭起来』的说明书」。理由：「你攒下来的脚本和现成的东西越多，agent 能直接拿来用的就越多，需要从零开始现造的活儿就越少。」他建议 Peter 干脆在这基础上搭一套做视频剪辑的 harness（外壳／编排层）。→ 详细
• Thariq 反馈二：把外部工具交给 Claude 自己去调、自己去看效果。Peter 抱怨图像生成 API 特别不擅长改他的脸（笑脸改成震惊脸「能把我弄得奇丑无比」），但保留原脸、只改背景和文字就相当不错。Thariq 的建议是：「Claude 特别擅长的一件事就是去调用别的工具」——把 Gemini 或 OpenAI 的图像生成 API 交给它，再让它自己去看生成出来的人脸效果怎么样、在那基础上做微调，这样它能交互式地、一轮一轮往前推进。→ 详细
• Thariq 反馈三（也是最重的一条）：这活该上 workflow。触发点是 Peter 说「skill 我现在是会用了，但你在网上讲的 dynamic workflow（动态工作流）我完全没概念，一点头绪都没有」——展开见下两节。→ 详细

▲ workflow 跑完的产出：候选片段被逐条排序、附上理由与时间码，供人最后拍板。

• Thariq 拿 Peter 的 shorts（短视频切片）需求当例子：「假如你想一次生成 10 条不一样的 shorts，或者 5 条——这种场景用 workflow 就非常对路。」→ 详细
• 机制拆开就是三步：① 主 agent 先决定这段素材里挑哪五个片段来做（只统筹、不下场）；② workflow 给每一个片段各自起一个 subagent（子智能体，即主 agent 派出去干一件事的分身，各自有独立的上下文）；③ 你给一份 rubric——写明什么样的片段才算好片段——每个 subagent 都拿这同一份标准去自查。→ 详细
• 为什么非要拆开跑，理由很实在：「最后你拿回来的结果，是每一条片段都被投入了最大限度的算力去打磨、去确保它符合你要的效果。这跟你同时跑两三条的情况不一样——同时跑的时候，Claude 对单条片段的验证和打磨往往就没那么到位了。」换句话说，并发是有代价的：一个上下文里塞太多条，每条分到的注意力就稀了。→ 详细
• 怎么创建一个 workflow？不用学新语法，直接跟它说——「嘿，帮我出 10 条片段，用 workflow 来做，这是我的 rubric，拿它来判断什么样的片段算好片段。」→ 详细
• 本片最实用的一句：「workflow 其实就是一个 JS 文件。」——「你让它把这个 JS 文件存进 skill，你就有了一个能反复复用的 skill。」也就是说 workflow 不是什么黑箱功能，它是一段可读、可改、可版本管理的代码；而「skill + 里面的 workflow 文件」就是一个能分发给别人的组件。→ 详细

• Peter 问了个「可能有点蠢」的问题：用 workflow 相比直接用 skill，好处是不是就在于它能拆出 subagent、把 context（上下文）保持干净？Thariq 说 context 只是一部分，另一部分是「偷懒」和验证。→ 详细
• 核心论据就是这一句：「我们发现——我们把它叫做 self-referential bias（自我偏好偏差）——当一个模型偏爱自己的输出时，它验证起来就会格外宽松。」所以像 shorts 这种「你没有一个确定性的标准去判断它到底好不好」的产出，正确做法是配一份 rubric，再派一个专门做验证的 agent 去读这份 rubric、审这条片子、给出反馈，而不是让做的那个自己拍胸脯说「挺好的」。→ 详细
• Peter 的复述就是这条原则最好的记法：「所以基本上，你是想让干活的那个 Claude 和验活的那个 Claude 分开，对吧？」Thariq 点头并补了第三个角色：还有一个单独的 Claude 负责协调——主 agent 只做统筹调度，subagent 各自干活，再有一个来做验证。→ 详细
• 拆成三个独立的 Claude，好处不止是「偏见更少」：它们各有各的 context；而且「它们都会投入更多算力，也更不容易提前收工」——想得更多。→ 详细

• 起因是 Peter 的真实痛点：「我有时候真的会被搞到精疲力尽，五个线程同时在跑五件不同的事，然后它们不停地来找我。某种意义上，这比连轴开会还累。」他问的是：有什么办法能让你自己的 context window（上下文窗口）保持干净？→ 详细
• Thariq 的答案是全片最值得贴墙上的一句：「我今年给自己定的目标就是：更高产，但工作更少。我觉得这是我们所有人都该往这个方向逼自己一把的事。」→ 详细
• 他的具体做法：尽量在同一时间只专注一个项目。「哪怕还有别的事得往前推——比如某个东西得先 build 完、合进去，或者需要去探索别的方向——但始终有一个我真正专注的项目，这一点非常有帮助。」→ 详细
• 理由是本片最反直觉的一条经验：「我发现，最浪费时间的情况恰恰是：我有点偷懒，同时开着一堆任务来回切换，随手写了个敷衍的 prompt，然后回头一看——完了，这段时间白花了。」他明确说「同时开几个 Claude」是存在一个最优值的，因人而异、也因你在做什么而异——但对他来说，永远留一个投入最多注意力的任务。→ 详细
• 一个顺带的用法：Peter 说「剩下的事交给 agent 去顶」，Thariq 补了一句——「甚至可以让它帮你做优先级排序，我觉得这也是个不错的切入角度。」→ 详细
• 他自己是终端和桌面 App 混着用，取决于内部所谓的 ant fooding（Anthropic 版的「吃自家狗粮」）——哪块他觉得最需要测，就用哪块。→ 详细

• Peter 的担心很真实：他不会逐行细读 Claude 的产出，「要是我一直不读，整个 repo 到某个时候是不是就变成一堆 slop（低质量垃圾产出）了」——有没有定期跑的例行任务来清理？→ 详细
• Thariq 给了工具也给了判断：工具是 simplify——Boris 放出来的那个，能帮你把 repo 精简一遍，随时可以让它跑。判断是得看你拿它来干什么：拿它出成品（比如做视频输出）时代码质量就没那么要紧，「agent 是很『轴』的，它自己会想办法搞定」。最诚实的一句是：「我发现，『整理』这件事往往更多是做给我自己看的，不是做给 agent 看的……如果我只在乎最终产出，那其实无所谓。」→ 详细

• Peter 问他会不会有意识地保持 context window 干净——别开一堆 MCP、别让 CLAUDE.md（放在项目里的常驻指令文件，每次对话都会被读进上下文）变得超长。Thariq 直接抛出了本片最硬的一个数字：「我们注意到的一件事是，尤其随着模型越来越聪明——我们把 Claude Code 的 system prompt 砍掉了 80%。」→ 详细
• 原因就是开篇那句金句的展开：「模型变聪明之后，它需要的指导更少了，需要的约束更少了，需要的示例也更少了。」他举了他们自己以前的写法：「好，这是 batch tool（批量工具，把多个操作打包成一次调用），这里有五个用 batch tool 的例子，在这几种情况下永远不要用它」——现在的模型「已经足够对齐，它自己就知道该怎么办」。→ 详细
• 示例为什么反而有害：「那些例子其实反而在限制它——因为它会想『哦，你要的是这个例子那样的东西』。你把例子删掉，它反而能更自由地发挥。」→ 详细
• 硬约束为什么反而有害：「你说 never（永远不要）的时候，你其实很少真的是『永远』，你只是想说『大多数时候别这么干』。这时候与其写一条『不要这样做』的硬约束，不如告诉它你为什么不希望这样做——那往往更有效。」→ 详细
• 结论他说得毫不含糊：「我感觉现在大家的 CLAUDE.md 基本都太长了，你应该越删越短。很多 skill 大概也写得太长。」MCP 要看是哪一个，有些确实很吃 context，但 MCP 团队用 tool search（工具搜索，让模型按需检索工具定义，而不是把全部工具塞进上下文）这类办法改善了不少。一句话收口：「模型需要的其实是更大的发挥空间。」→ 详细
• 那具体该怎么改写 prompt？Peter 拿写推文举例：与其写「控制在 280 字符以内、不要做这个不要做那个」，Thariq 建议先给它关于你自己的背景——「我是做 Claude Code 的，我在 Anthropic，这是我们遵循的一些原则」。280 字符这种硬性要求当然可以留，但「你甚至只要说『这是一条推文』，它就知道了」。更妙的是把偏好而非命令说出来：「我想写一个推文 thread，但我更希望能压成一条」——这样给了它自由和弹性去找出一个更好的答案（比如做成两条的 thread 反而更好）。→ 详细

• 背景是 Peter 引用 Boris 的判断——「编程基本上已经是个被解决的问题了」——然后问：对于像他这样想真正学会跟 agent 协作、想搞懂它到底在干什么的人，到底怎么才能变得更技术？「我说的不是学语法之类的东西。」→ 详细
• Thariq 说第一步最难：说服自己去学。「说真的，这件事本身就很难，我自己也一样——如果不学某个东西照样能把活干完，那你可能就不会去学。」→ 详细
• 目标他定得很清楚：「学技术的目标，是搞清楚自己有哪些「未知的未知」。」所以懂 TypeScript 的语法帮助不大；真正有用的是这一类：不同后端服务各有什么取舍？有哪些视频编码库、它们分别怎么工作？本地跑和远程跑的转写库有什么区别？——「我很多时候是在学这个系统的边界在哪：什么是可能的、它现在是怎么做的、最好能做到什么程度、要是换个做法会怎样。」→ 详细
• 谁来教你？Claude 就能教——「但前提是你得推着它问，而且你真的必须去推。」他引 Karpathy 的话收尾：「『试着去学』感觉很爽，但真正学会是要费力的，而且它本来就该有『干活』的感觉……教育应该更像干活，而不是像玩。」→ 详细
• Peter 的自省很有代表性：最省事的做法就是一直催 Claude 去做、看一眼产出，结果什么都没学到；「而你居然会让它生成那些相当详细的 HTML 报告，而且真的去读——我觉得这大概是个例外，大多数人不会这么干」。Thariq 把问题还给他：「你怎么从『能做出不错的 shorts』，走到『能做出真正顶级、制作水准最高的 shorts』？」如果那是目标，就得去学视频制作和剪辑本身、也学那些技术概念，然后往那个方向逼自己一把——「我觉得我们都想让自己变得更好、更快，而不只是更快。」→ 详细
• Peter 当场想到的动作是往 CLAUDE.md 里加一条「所有事情都给我生成一份 HTML 报告，好让我能读」；Thariq 没有拦他，只是提醒这也需要自我推动——「去判断什么时候你是真的想搞懂某个东西是怎么运作的。」（注意这和上一节「CLAUDE.md 该越删越短」形成了一处有意思的张力。）→ 详细

▲ 主持人 Peter Yang——这期他既是提问者，也是把自己的剪辑 skill 拿出来被点评的那个人。

本期没有独立的闪电问答环节，以下是收尾对话里的观点与预告，逐条列出：

• 接下来最大的一块是 Claude Tag。Thariq：「接下来很大一块是 Claude Tag，它会一直变好。但我觉得有件事怎么说都不为过——就是它对 Anthropic 内部的工作方式改变有多大。所以也很期待更多人用起来、去试一试。」→ 详细
• 别微观管理你的 agent。Peter：「如果你手下有个特别能干的员工，你是不会去微观管理他的，对吧？你就在 Slack 上 @ 他一下，说『这个能帮我搞一下吗』，然后事情就办好了。」Thariq 补充：或者你想跟别人来回讨论、一起协作。→ 详细
• 「走到 Claude 工位旁边随口问两句」。Peter 半开玩笑地提要求，Thariq 的回答是：「对，像个机器人一样。哈，我觉得这可以当成你的一个 hack project 啊——我感觉这现在其实就已经能做出来了。」→ 详细
• artifacts 的开放范围：目前只有 Teams 和 Enterprise 版可用，Thariq 表示希望之后能开放给 Max 和 Pro。→ 详细
• Claude Tag 的 UX 还在迭代：连「怎么在 Slack 里触发 skill」这种基础交互，答案目前也只是「你直接跟它说用哪个 skill 就行」。→ 详细