随着模型变得越来越智能，它们所需的指导、约束和示例也越来越少。我们有 /loop，有 /goal，还有 workflows。这些都是为了让 agent 能够长时间运行而设计的。这只需要一次尝试，就像一条 prompt 一样。它已经生成了 caption，生成了那个小 overlay，现在它要渐隐至黑屏了。我今年目标是提高效率，但减少工作时长。大家好。今天我非常高兴地欢迎来自 Claude Code 团队的 Tharic。这一刻我们已经等了很久。我要请 Tharic 展示如何设计 loops 和 workflows，让 Claude 工作更长时间，以及他个人如何使用 Claude Code 和新的 Claude tag。欢迎。嘿 Peter。是的。谢谢你邀请我。我一直很期待参加这次访谈，已经有一段时间了。好的，好的。那么在演示之前，也许你可以先高屋建瓴地谈谈，你和 Claude 团队是如何思考的：如何从由人亲自给 agent 下 prompt，过渡到设计 loops 和一些其他机制，让 agent 能自己独立工作。你们是怎么看这个问题的？完全同意。我认为 loops 是一个相当通用的术语，指的是让 agent 获得反馈，或者以某种编排好的方式长时间工作的不同方法。所以我们有 /loop，有 /goal，还有 workflows。这些都如你所说，是为了让 agent 能够长时间运行而设计的。/goal 的作用之一是帮助 agent 记住自己的退出条件是什么，对吧？而且只有在达成条件时才允许退出。所以当你有一个复杂任务，确实需要确保最终完成时，goal 非常有用。你真心希望防止它中途停止。你也想给 agent 一个反馈、一个信号，basically 告诉它：嘿，坚持下去，对吧？所以我觉得，如果你站在 Claude 的角度想一想，有时候别人让你做一项任务，你遇到了某种复杂情况，或者某些地方不太符合规范、不太匹配用户的说法，你就可能提前停下来，问：嘿，我还要继续吗？对吧？所以 /goal 是一种方式，让用户表明：嘿，我已经做了足够的规格说明和探索，我理解了问题空间，去执行吧。如果遇到什么，把它补上就行。这就是我们看待 goal 的方式。然后 workflows 在我看来可能是这其中最强大的形式，你可以启动 sub-agents 来执行工作、并行处理工作，以及验证工作。所以我觉得，特别是对于非技术性工作，这可以是一种很好的方式，把一个非确定性的任务大致拆解成确定性的任务。所以是的，我想这就是我们如何看待这些功能的。然后，我知道我要做个快速演示，但在此之前，想问问 Claude 团队内部，你们自己是怎么用这些功能的？比如你会不会说“去把这个做到和设计稿一致”，或者“去把这个数字提上去”？你们具体怎么用？是的。我的意思是，每个人做法都不一样，对吧？取决于他们具体想做什么。我觉得，你知道，Jared 谈了很多关于用 Rust 重写 bond 的事，以及那里面怎么用 workflows，而且他接下来还会再深入聊这个。我觉得，只要你有某种确定性的信号，比如 latency，对吧？/goal 就非常适合用来让 agent 以一种自动研究的方式去探索各种方案，对吧？然后，比如你聊到设计，对吧？我觉得你得先考虑一个问题：agent 到底能在多大程度上理解你的设计稿，对吧？所以你可能想把它转成一个可以验证的 spec。比如如果是 Figma 文件，你就用 Figma MCP，然后下指令 /goal，确保渲染出来的设计和 Figma MCP 里的一致。这比截图比对要容易多了，对吧？所以如果是截图，也许你就需要用一个 workflow，因为这种情况更模糊，你知道的，得有一个你用来评估的 rubric，还得有一个 verification agent 之类的东西。明白了。是的，非常取决于具体任务。所以 basically 规划很重要，对吧？因为我之前试过让它去做，就说“给我做个超棒的游戏”，然后它就跑偏了，因为你知道，就一句话。是的，我是说，我觉得……你知道，你想要什么，这里面有很多细节要厘清，有很多工作要做。明白了。好，那我们把这个说具体点。你之前在 Twitter 上分享过一些很棒的用 Claude 做视频的内容，我想你有一个 video workflow 想跟我们分享，对吧？是的，没错。有几个人问过我这件事，我觉得这可以作为一次不错的演示，既关于视频剪辑，也关于如何做非技术性工作的思考方式。所以在上这次通话前 10 分钟，我录了一段短视频，就是我……在做视频。基本上我在说的是：嘿，是我，你知道的，我在 Peter Yang 的播客上。我会指出来我希望 overlay 出现的位置，然后基本上在说：“嘿，渐隐至黑屏，”你知道吧？所以这就是我快速拼凑出来的一个视频，对吧？然后，现在我给它的 prompt 是这样的，对吧？呃，这是一个 Peter Yang 播客的 repo。里面有个样本视频叫 Peter Yang recording。用 Whisper 转录它。然后用 reotion 创建一个 UI，把逐字高亮的转录文本和不同的 overlay 都显示出来。然后，/goal，在视频完全渲染完之前不要停。对吧。所以，这只是一次尝试，就像一条 prompt 一样，对吧？它给我的成果是这样的。它已经完成了转录。它显然不知道我叫 Tharic，对吧？然后它把文字 overlay 上去了，或者抱歉，是它生成了 caption，生成了那个小 overlay，现在它要渐隐至黑屏了。对吧。所以哦，太棒了。所以所以你基本上是把指令大声说出来了，对吧？对吧？我就是大声说出来的。是的，没错。当然，有很多方法可以做到这一点，但现在这个目录里，你知道，已经把所有东西都转录好了。是的。用 Whisper，它生成了 reotion 相关的内容。是的。这就是我 video editing workflow 的最基础起点，也是一个很好的信号，说明如何在 Claude Code 里做非技术性工作。所以你一开始是用 prompt 手动做的，但之后你应该把它保存成 skill 之类的了，对吧？所以现在我还没有 skill。我觉得我要做的第一件事，是在把它转成 skill 之前，先真正搞清楚我想要什么，你知道的，所以这里的 edge cases 有哪些？嗯，我注意到有一件事我得专门 prompt 它去做，就是更好地判断我的手……我的手在哪里，对吧？或者说，我指向了哪里。即便现在，我对这个 overlay 出现的位置也不太满意，你知道的？所以，嗯，你可以想象，我可以把这个往一个方向发展，比如，我想追踪手指或者脸部，然后给 agent 更多元数据，对吧？这样它就能做出有趣的叠加效果。本期节目由 Whisper Flow 赞助。Whisper Flow 每周至少帮我节省 3 个小时，也是迄今为止我最喜欢的 AI 应用之一。用语音向 AI 口述比打字快得多。你只需自然说话，它就能输出干净、可直接发送的文字。Whisper Flow 甚至会自动去掉填充词并帮你格式化句子。我什么事都用 Whisper Flow，包括起草通讯文章、写产品规格、在 Slack 上回复消息等等。它支持 Mac、Windows、iPhone 和 Android，兼容你常用的所有应用。在 whisperflow.com 免费试用，并使用我的优惠码 peterwisperflow 即可获得 6 个月免费会员。是 Peter Whisperflow。现在，回到我们的节目。我记得你还有一个标签页，里面好像有个计划之类的东西。那是给视频技能用的吗？是的。所以，我想聊聊，我很想谈谈我是怎么做到这一步的。你懂我的意思吧？就是说，我觉得哪怕只是写出这个 prompt，也花了我不少时间去规划和摸索，对吧？然后我觉得，当我们谈到"计划"时，我们通常指的是那种一步到位的东西——你做个计划，然后去执行，完事了。但我觉得规划更像是一个迭代的过程，去探索、去研究、去发现你不知道什么、你想要什么，对吧？然后这些东西合在一起，最终自然会变得清晰。所以这儿有个例子。不过在我们聊这个的同时，我想做件事。比如，okay，我要告诉它：我想更新这些叠加层的 UI，对吧？而且我想用 Peter Yang 的风格。这是他的博客。创建一个 HTML artifact 来探索叠加层和字幕的不同设计方案、设计变体。Okay，对我来说这也是个例子。这也算是规划，对吧？因为我在做的事其实是想搞清楚我到底想要什么。所以这更像是一种探索。你可以看到，我做的一件重要的事就是给它一个参考，对吧？所以当我把，你知道，你的网站发给它，它就能获取 HTML 然后开始做。所以这算是我在讲其他规划方法时，同步运行的一个计划。比如说，其中一项是，转录是怎么工作的？这其实我觉得挺重要的，因为它关系到很多 edge case。这个转录用的是 Whisper，然后 cloud code 做了这份说明文档，说实话挺厉害的。对我来说重要的是那些可能出错的方式，对吧？这是我在计划里 prompt 它的：给我解释 Whisper，让我理解 edge case 有哪些。然后它提到的一点说，静音可能会被识别成"thanks for watching"，对吧？或者一个词可能被切成两段。它没有说话人识别，对吧？所以这里有一堆不同的 edge case，我觉得这些都很好，这也让我对使用 Whisper 更有信心了。是的。但能提前了解这些 edge case 和局限，真的帮我避免了那种情况：我搭了一个基于 Whisper 的复杂工作流，然后才发现有些地方不对劲，而我之前完全没有意识到这些"未知的未知"，对吧？所以这种情况看似我在做规划，但实际上是我在发现自己的未知。而且我觉得这可以有很多不同的形式。它可以是学习，可以是技术规格，对吧？可以是 mock-up 和探索。是的，我开始觉得"计划"这个词现在可能太宽泛了。所以它更像是探索和理解你真正想做什么。是的。我喜欢说，消除你的未知，你知道，我觉得每当你有一个任务时，几乎总是有很多你不知道的东西，要么你不知道事情怎么运作，要么你不知道你想要什么，而且这个过程非常迭代，你知道，所以不是说一次性全写下来然后去实现。我觉得有很多步骤和多轮迭代。所以而且，兄弟，这计划做得真漂亮。兄弟，你这是不是用了 claw 模板之类的？它还有图片。这是用了前端设计插件。我觉得，你知道，嗯，是的，这不是，嗯，也有更丑的计划。比如我拿到过这种 reotion 计划。嗯我觉得，你知道，设计本身没那么重要，你真正要确保的是你会去读它，你知道，大概了解一下，不是全部，但其中有重要的部分。而且我看到一种失败模式是人们还是会匆匆掠过这些计划和说明文档。所以，嗯，是的。是的，因为 AI 能写出所有这些，你知道，很复杂的 markdown 文件，而且通常很长，然后到了某个点我就犯懒了。我就会说，好吧，你知道，别管了，做就行了。就做吧。是的。是的。是的。完全没错。我觉得这就是那种，你知道，我们都会遇到的情况，对吧？prompt 框完全可以变成一个偷懒按钮，对吧？你就是直接说，嘿，把这个做了。嗯，但通常，你知道，你最终会为此付出代价，对吧？因为如果你想做一件正经事，你知道，每一步都在偷懒，最终反而要花更长时间，成本也可能更高。所以，嗯，所以这就是一种迭代。所以你先问 Whisper 相关的东西，然后学到一点，再让它做另一个计划，然后到了某个阶段你就有了一个可以分享的计划，对吧？是的。完全没错。是的。是的。所以关于这个视频识别的东西，我做了很多研究，去研究不同的视频算法是怎么工作的，对吧？比如我做了一个关于 video segmentation 的。我想把文字放在主体后面，所以这是我探索并深入了解过的东西。然后我发现这里没有一个足够可靠的方案让我使用。但是，嗯，是的，我觉得就是有很多这种迭代过程，去发现我想要什么，你知道，以及什么是可行的，然后才能动手去做。所以，嗯，看起来这个叠加层可能差不多完成了。我们很快就能看到它了。是的。那在团队里呢？你们会让团队其他人也 review HTML 吗？那是 markdown 还是是的。是的，当然。我的意思是，我觉得每个人都不一样，对吧？所以我想，但是 HTML artifacts，我是说我们推出了 artifacts，对吧？嗯，目前只在 teams 和 enterprise 版本上有，但 hopefully 会来到 Maxin Pro。嗯，然后，是的，这就是我们现在在公司里分享东西的方式。就是我们让 Claude 做一个 artifact，这可以是，你知道，一个我们已经完成的 PR 的计划。也可以是，你知道，像状态报告、incident report 之类的。所以，嗯，是的，这，嗯，绝对是我们的做法。是的。好，我们来看看它这里生成了什么。行，我们来看看。假设打开 overlay 风格的 HTML。好的，你看，这是它给出的一些选项。我觉得它可能更多参考了 Stack Overflow 或者 Substack 的品牌风格，而不是你的品牌风格。你懂我意思吧？对，因为我没什么品牌风格。不不，我觉得你有啊。你有自己的风格，比如红白配色。我们可以在那个基础上迭代。不过这也是我想说的，这些设计方案之间差异还挺大的。这是我做规划时喜欢用的方式之一，就是先探索一波，尤其因为我不是设计师，所以我真的只有看到实物才知道自己想要什么。明白明白。关于规划这块，最后总结一下：我做了大概 10 年产品需求文档，通常里面会写我们要解决什么问题、方案是什么、目标是什么之类的。但我感觉现在这些东西有一部分是给 agent 看的了。所以我觉得需求文档的不同章节可能需要调整，或者说产品需求文档和技术需求文档可能得合二为一。你们团队是怎么做的？会分成人读的部分和 agent 读的部分吗？还是你怎么看待这件事？好问题。我觉得这两者是紧密结合的，对吧？我认为需求文档甚至可以逐渐演化，变成一种规划。你看我这里展示的，让我看看……实施阶段。有时候你会发现，当你运行某个东西时，模型可能会发现一些它在实施前没预料到、或者你也没预料到的问题，对吧？所以我觉得……
我不太认为写需求文档只发生在项目开头。流程应该是：你先提出人工需求，然后 agent 做一些技术探索，它返回结果，你可能做一些 mockup、写一些说明文档来搞清楚你的未知点，再细化需求。然后你再交给 agent，它可能开始实施。我会让它在实施过程中记录实施笔记，这样它就能发现那些我们没预料到的实现细节。有了这些之后，如果需要，我们就可以重新写需求文档，看具体情况而定。所以这并不是需求文档一扔给实施就完事了，而是一个来回迭代的过程。对，因为现在构建成本很低。你可以先让它搭一个最简单版本，可能有很多 bug 和问题，然后不断迭代，对吧？没错。或者说先做一个原型版本。我就是这么看待这些 overlay 的，它们算是设计的原型，对吧？嗯。如果我们……
喜欢的话，再去做成本更高的版本，也就是不用 HTML，而是用 React。这意味着你得重新渲染视频，还要做一大堆代码改动。所以，你能采取的最小步骤是什么，用来验证你想要的那个概念，或者说进一步验证你的需求文档。而且我很喜欢它会记录实现过程。这样下次你开新板块的时候，它就可以直接引用之前的 HTML，对吧？就像一份活的文档。没错，就是这样。明白了。你现在有多少工作是通过 Slack 上的 Claude 完成的，又有多少是在终端或者 Claude 应用里做的？我觉得对我来说，趋势是这样的：很多并行任务是在 Claude 里跑的，所以任何多开 Claude 的操作通常都在 Claude 里进行，除非有必须在本地做的理由。我们团队花了很多时间确保环境可以远程运行，所以我都是在 Claude 里多开会话。初期的探索、PR 需求文档、试图理解某个东西，这些都在 Claude 里做。然后一旦我进入专注状态，通常只聚焦一件事，那时候就用 Claude Code，更多是来回迭代。对，我大概是这样用的，但公司里每个人用的方式和组合都不太一样。有意思。那你说多开 Claude 是什么意思？哦，就是如果我同时有多个任务在进行，尤其是需要涉及别人的时候。比如我有个 PR 想合并，我会让它盯着这个 PR、修测试，然后 tag 一个 reviewer，reviewer 会在同一个 Slack 频道被 tag 到，我们可以在那里交流。总的来说，多开 Claude 就是指任何后台工作。以前我可能在 Claude Code 里开五个不同的 Claude 会话，现在主要是一个活跃的 Claude Code 会话，再加上一堆 Claude 会话。有意思。那你在 Slack 上和 Claude 对话，是通过私信，还是也用在团队公共频道里？嗯……
主要是……对。对，在 Slack 上。我既有私人频道，比如我有一个 thoric Claude Slack 频道，大部分工作都在那儿做。然后我们也团队频道，比如 feedback 之类的，或者项目专属的工程频道，这种模式很常见。这说得通，因为我确实觉得现在的这些编程应用主要还是单人体验，你就是通过不同线程跟 agent 对话。而且你仔细想想，Claude 应用本身看起来其实有点像 Slack，都是一堆线程。就像 Slack 有一堆频道一样。所以我想，Slack 现在就是多人在线的 Claude 体验，对吧？因为所有人本来就在那儿。对，我觉得这还只是开始。我们最终希望 Claude 能成为一个主动式的 agent，在你所在的地方与你对接，而 Slack 就是 Anthropic 的阵地。这是个非常自然的探索方式，而且它的编程能力强得惊人。有些人几乎完全在 Claude 里写代码。不过，这可能是个蠢问题：在 Claude Code 里你可以轻松触发 scales 之类的东西，那如果我在 Claude 里，是不是只要 @Claude 然后输入 /scale 就行？还是怎么弄？嗯，你直接告诉它用 scale 就行。好吧好吧。对对对。不过这些交互体验我们还在迭代优化中。好的。我想问，你同意吗？我觉得这个东西的未来——因为你之前给我做过一个关于人与 agent 互动的演讲——我觉得未来 agent 就像另一名员工一样。你得给员工做入职培训，你可以通过 Slack 和它交流，还可以给它打电话。你知道，我们得想想。这是个好问题。我觉得这些比喻有时候有帮助，但某些方面也有局限性。谈到身份时，有一点是，在 Claude 里，每个 agent、每个频道都有自己的记忆。所以我认为这是一种选择。你也可以想象有多个 Claude，每个都有不同的 Slack 身份，你去 @ 它们之类的。我觉得把 agent 想象成具有持久性和记忆的存在，这有一定帮助，但它们在某些方面也不同于同事。它们具有主动性，有记忆，有身份。不过这有点像 Claude Code 的演进，我们更想看看模型会把我们带到哪里，而不是把它框死。是啊，有道理。它的记忆力肯定比任何人类都好得多。（笑）
有时候更好，有时候更差。你懂我意思吧？它是波动很大的，对吧？所以是的。嗯，有道理。好吧，哥们。要不我展示点有趣的？我想给你看看我的 Claude 配置。我们当面聊过这个，我对此挺自豪的。我建了一个播客制作 skill。它的功能是，我输入一段采访逐字稿。我采访了你们的同事 Jess，然后它帮我生成一堆东西。比如生成缩略图、要剪辑的素材什么的。基本上我就 @ 它一下，贴上逐字稿，它就开始生成那种标题党的 YouTube 缩略图之类的东西。（笑）
对，它会生成内容，我基本上会给它一些我的案例，尽量让它保持风格一致。嗯。但我觉得这个 skill 好像试图做太多事了。所以我想问问你有没有什么反馈。挺酷的。我能看看它产出的东西吗？比如那些片段之类的？哦，产出物吗？可以。有些产出就是纯文本，比如生成一篇新闻稿、一些要点总结。复制到 YouTube 里。对。对。然后我还有一个叫 video post skill 的东西。可能跟你那个有点像，但肯定没你的高级，它 basically 会提取这个节目的 YouTube 视频。酷。然后它做提取分析，再给我一些可以做片段的创意。嗯。它也会直接生成片段吗？是的，确实会。我说做两个，然后它用了什么工具我其实不清楚，用了各种零碎工具来——
可能是 ffmpeg 之类的，对吧？对。对，可能是 ffm（peg），然后它生成视频，还加上字幕。嗯，太厉害了。所以，对，虽然还不完美，但还行。嗯。这很棒。你觉得它多大程度上符合你的需求？或者说，更好的话应该是什么样？我希望它能加一些 B-roll，还有你给我看过的那种 overlay 之类的东西。之类的。我还希望它能聪明到知道怎么拉取素材，比如视频片段里如果需要 Claude logo 之类的东西，它能直接到网上去找。嗯。那我是不是应该直接让 Claude Code 做这些？我觉得可以。对了，你是在一个持续的 repo 里工作吗？我有时候会想，有时候你想要一个 skill，有时候你想要一个包含很多脚本的 repo，更像是一个工作空间，对吧？我觉得 skill——
对，我觉得有时候 skill 可以是关于如何创建那个工作空间的指令。所以——
这也许是值得考虑的一点，因为你积累的脚本和工具越多，agent 能做的就越多，需要从零开始做的就越少。不过，嗯……
我每次都是新建一个文件夹。不，我所有的 skill 都是在用户级别的。然后有个类似 personal OS 的文件夹，存放所有输出之类的东西。明白了。好的，酷。但你的意思是——
对，我觉得你可以在这里搭建一个视频编辑的框架。我好奇的是缩略图。你有没有用过图像生成 API，比如 Gemini 或者 OpenAI 之类的？用过，我发现它在改我表情方面很差。比如我有一张笑着的照片，要改成震惊脸，它就会把我弄得很丑。哥们，（笑）
太搞笑了。不过我觉得它在其他方面还不错，比如我不动我的脸，让它改背景或文字，就做得挺好的。是的。对，我觉得 Claude 很擅长使用其他工具。你可以给它 Gemini 或 OpenAI 的图像生成 API，然后让它审视它生成的你的脸，再进行调整。它可以交互式地、渐进式地做这件事，这很有帮助。哦，有意思。对。所以基本上我就是把一堆 skill 串在一起用，比如——
酷。准备素材，然后生成缩略图，等等等等。我觉得我现在知道怎么用 skill 了，但你在网上说的其他东西，比如 dynamic workflows 之类的，我完全不懂。对，完全没概念。嗯。那做这种事怎么用上 workflow 呢？我觉得可以想象这样一个场景，当你在用——
我觉得你刚才说的 shorts 例子就很好。比如你想生成 10 个或 5 个不同的 shorts。workflow 就很适合干这个。你可以让主 agent 决定，在视频的哪些部分做 short。然后 workflow 为每个部分分拆出一个 sub-agent。你还可以给它一个 rubric，比如什么样的片段才算好。然后每个 sub-agent 都按这个标准去验证。最后你得到的结果是，每个片段都投入了最大计算量来确保符合要求。相比之下，如果你同时做两三个，Claude 可能在单个片段上投入的验证或工作量就会变少。所以——
明白了。那要创建一个 workflow，我是不是直接告诉它做一个 workflow 就行？对。或者你就说："嘿，在这里生成 10 个片段，用一个 workflow。"
这是我用来验证什么样的片段才算好的评分标准，对吧？这也可以是一个 skill。所以你可以把一个 skill 打包进 workflow 里。这个 workflow 其实就是一个 JS 文件，你可以把它保存到 skill 里，这样你就有了一个可以重复使用的 skill。这可能是个蠢问题，但做这种 workflow 相比直接用一个 skill 的主要优势在于，它可以启动 sub agents 并保持上下文干净，是吗？对，我觉得，一方面是上下文。另一方面有点像惰性和验证，对吧？比如说，short 就是一个例子，这种情况下你无法确定性地判断“这是不是一条好的 short”，对吧？所以如果你有一个 rubric，还有一个 verification agent 来阅读这个标准，然后它会想：“嘿，让我 review 一下这个 short，确保它是好的，并给出反馈。”这也是 workflow 能够实现的事情。而且我们发现——我们称之为 self-referential bias——就是当模型偏好自己的输出时，它在验证时往往会更宽松。所以基本上，你就是想让一个单独的 Claude 负责干活，另一个负责验证，对吧？对。而且在这种情况下，让一个单独的 Claude 来协调工作，你的主 agent 负责协调，每个 agent 分别执行和验证。明白。这样的话，三个独立的 Claude 拥有不同的上下文和模型，不仅仅是减少偏差。对，没错。而且它们都会消耗更多 compute，我想它们会更不容易提前停止。会思考更多。好的，明白了。太棒了，兄弟。那我问你一些宏观的问题，兄弟。你主要是在终端里用 Claude，还是会用桌面端应用？我两个都用，终端和桌面端。对，显然取决于我们自己内部试用的情况，就是我们说的 ant fooding。所以就是，看我觉得最需要测试什么。明白了。你有什么建议吗？我觉得有时候很累，兄弟。就像同时在跑五个线程，五件不同的事，然后它们还在不断地 ping 我。从某种角度来说，这比连续开会还难受。（笑）有什么保持自己 context window 干净的建议吗？嗯，这是个好问题。我觉得这是我今年的目标——更高效，但工作更少。我觉得这是我们所有人都应该努力做到的。我觉得我们尝试做的一件事就是，我会尽量只专注一个项目。所以即使还有其他事情需要我去推动，比如我需要把这个构建合并了，或者去探索一些东西，但一个真正专注的项目是非常有帮助的。因为我发现最耗时间的情况是，我有点懒，同时多任务处理一堆事。我随便写个 prompt，然后心想“唉，这下浪费时间了”。所以我觉得，存在一个最佳的多任务程度，这取决于你是谁、在做什么。但至少对我来说，我倾向于有一个真正最专注的任务。明白。所以也许让 AI agents 去处理其他的事，为什么不呢？对，甚至给自己做的事排个优先级，你懂我意思吧？我觉得这可以是一个很好的角度。有道理。那你有没有顾虑？我是说，我担心因为 agents 工作起来很卖力，不停运转。也许这是我的问题，就像我说的，我其实不会仔细读它生成的所有内容。（笑）所以我就担心，如果我不仔细把关，整个 repo 总有一天会变成一堆 slop。你有没有什么例行程序或任务来定期清理这些东西？有，显然我们有一些工具，比如 Boris 推出的 Simplify，它可以简化 repo。我觉得这也取决于你用它来做什么。比如说，当你用它来生成输出，像是视频输出的时候，代码质量可能就没那么重要，而且 agents 非常执着，它们最终会搞定。但我发现，整理代码往往更多是为了让我自己对工作空间感觉舒服一点，而不一定是为了 agent。如果我只要最终输出的话，其实随时都可以让它去简化或整理。明白。那你会尽量保持 context window 干净吗？比如尽量不用一堆 MCP，或者 Claude MD 特别长，你会去优化这些吗？会，我觉得……对，我觉得我们注意到的一件事是，尤其是随着模型变得越来越聪明——我们之后会更详细聊这个——我们把 Claude Code 的 system prompt 削减了 80%。原因是模型越来越聪明，它们需要更少的指导、更少的约束，也更少的示例。所以我们以前的 system prompt 很多都是：好的，这是 batch tool，这里有五个使用它的例子，在这些情况下绝对不要用。而现在模型的对齐程度已经足够高，它们知道我们不需要……这些示例反而几乎成了一种约束，因为现在模型会觉得“哦，你就想要类似这个例子的东西”。所以如果你去掉示例，它其实可以更自由发挥。约束也是一样，因为很多时候你说“绝不”，其实并不是真的“绝不”，你只是想说“大多数情况下别这么做”。如果你给它的是“你不想这么做的原因”，而不是“别这么做”的约束，效果反而会更好。总而言之，你需要精简上下文。我觉得 Claude MD 现在可能太长了，你可能需要不断缩短它。很多 skills 可能也太长了。MCP 的话，要看具体是哪个。显然有些 MCP 会占用大量上下文，但 MCP 团队在 tool search 等方面做了很多优化。不过确实，Claude 也好，任何指令也好，模型往往只是需要更多自由发挥的空间。那你是不是不会直接说“比如写一条 Twitter 帖子，要确保 280 个字符以内，别做这个别做那个”，而是给它更多要遵循的原则？你会怎么 prompt 它？更像……
对，我觉得 Twitter 帖子就是个很好的例子，这种情况下你可以给它更多关于你自己的背景信息。所以你会说，嘿，我在 Anthropic 做 Claude Code，这算是我们遵循的一些原则。显然，280 个字符仍然是一个很好的约束条件，因为这确实是硬性要求，对吧？但你甚至可以直接说“这是一条推文”，它大概就能明白，嗯，或者这是一个很好的例子，你可以说“嘿，把它控制在 280 个字符以内”。但假设也许有一个版本，做成两条推文的推文串会更好。你明白我的意思吧？所以如果你让它知道，比如“我想写一个推文串，但我更希望它是一条推文”，你知道的？这会给我们更多的自由和灵活性。对。去找到一个好的方案。好的。明白了。好。那我问一下这个。嗯，Boris 一直在说，编程基本上已经是个已解决的问题了，对吧？而且我觉得现在变得更技术化有点像……我想我的问题是，对于像我这样的人，想要真正学会如何更好地与 agent 合作，真正了解它们在做什么。那要怎么才能真正变得更技术化呢？这无关语法之类的东西，对吧？是不是只要多用就行，还是怎么……
对，我是说，我认为第一步是激励自己去学习东西，你明白我的意思吧？我觉得这说实话真的很难，而且我发现自己也会这样，就是如果你不需要学某个东西也能完成工作，那你可能就不会去学，对吧？但我觉得这真的很重要。我认为学习变得更技术化的目标是去了解那些我不知道自己不知道的东西，对吧？所以有些东西，比如很技术化地去了解 TypeScript 的语法，其实并没有太大帮助，你知道吧？但我觉得，技术化地去了解比如不同后端服务的权衡是什么，不同的视频加密库有哪些、它们是怎么工作的，本地和远程视频加密或转录库之间的区别是什么，对吧，我觉得这些都挺有帮助的。所以我觉得很多时候我都在尝试了解系统的约束条件，对吧，比如什么是可能的，它现在是怎么做的，它能做到多好，如果我们换个方式会怎样。而且 Claude 通常可以帮你头脑风暴并教你这些，如果你去推动它的话，对吧？但你真的得去推动它。我觉得这大概就是教育最难的地方，大家都说的那种感觉尝试学习某样东西感觉很好，但真正学到东西是更费力的，你知道吧，而且这应该就是费力的。我觉得 Kaparthi 经常这么说，对吧？教育应该更像工作而不是乐趣。所以是的。对，这确实说得很好。因为嗯，因为实际上更简单的方式是，比如拿视频那件事来说，对吧？实际上更简单的是一直让 Claude 去做，然后看看输出结果，然后其实什么都没学到，兄弟。就像让它去处理，然后它自己搞定了。但你实际上会生成这些非常详细的 HTML 报告并阅读它们，我觉得这可能是例外，兄弟。我觉得大多数人不会这么做。对，我是说，我觉得这是我在努力推动的事。对。但我觉得这就是你可以学习如何制作……我觉得对你的问题是，好吧，你怎么从制作好的短视频，变成制作真正最棒的、制作质量最高的短视频。你明白我的意思吧？而且我觉得如果那是目标，对吧？那我觉得你可能需要更多地了解视频制作和剪辑，以及技术概念，对吧？然后朝那个方向鞭策自己。而且我觉得我们所有人都想鞭策自己变得更好且更快，而不只是更快。对。所以，好吧。那也许我应该给我的 Claude 加一些自定义指令。比如，“嘿，确保你为所有东西都生成 HTML 报告，这样我就能阅读了。”
对。对。对。嗯，我是说，你知道，我觉得这也是你想鞭策自己去做的事，就是弄清楚什么时候你想理解某个东西是怎么运作的。明白了。太棒了，兄弟。感谢你为我们所有人带来了 Claude Code 这份礼物，嗯，真的很期待接下来的发展，兄弟。我不知道你可能没法透露什么，但你知道的，真的很期待接下来的发展。接下来的很多东西都是关于 Claude 的，你知道的，它会不断变得更好，但我觉得有一点很难夸大，就是它很大程度上改变了 Anthropic 这里的工作方式，所以很期待其他人也能加入或尝试它。对，如果你有一个非常能干的员工，你不会去微观管理他们，对吧？你就说，嘿，在 Slack 上 @ 他们，说我搞不定这个。然后希望它就完成了。或者你想和其他人反复沟通、协作。对，你应该把它打造到我可以走到 Claus 的工位旁边，问几个问题，它就能回答的程度。对，像个机器人。对，我是说，那对你来说可以是个 hack 项目。你知道，我觉得我现在已经能做到了。对。酷。好了，嗯，聊得很开心，而且嗯，我觉得人们知道在网上哪里能找到你，所以我觉得我们不用提这个了。对，没问题。没问题。对。太好了。谢谢，Peter。