Transcription
我们不使用很多 Google Docs 来处理 Cloud Code。我们许多最好的功能都源于工程师原型化一个想法，将其发布给内部用户试用，然后我们听取反馈。比如，人们是否立刻理解了它？人们是否感到困惑？它是否有 bug？或者人们是否就是喜欢它？
>> 你们是怎么看待自己的？
>> 如果你看到 Sweet Bench 分数的变化，并不总是清楚是什么原因造成的，你实际上需要阅读这些相当棘手的转录文本。而且很多时候，我可以说，我们大约每 10 分钟就能收到一条新的反馈。我们喜欢负面反馈。我们不想要空洞的赞美。我们想听听什么不起作用。
>> 你有像愿景文档之类的东西来规划 Cloud Code，或者你认为一两年后这个产品会是什么样子吗？
>> 一两年是很长的时间。我可以谈谈接下来的几个月。
>> 好的。欢迎大家。我今天的嘉宾是 Cat，她是 Cloud Code 的产品负责人。嗯，Cloud Code 是我最喜欢的 AI 代理。所以，我非常兴奋能和 Cat 聊聊团队是如何快速发布的，她个人是如何使用 Cloud Code 来进行产品工作的，以及她对产品的愿景是什么。那么，欢迎你，Cat。
>> 非常感谢你，Peter。很高兴能与你的观众分享更多关于 Cloud Code 的信息。
>> 好的。那么，嗯，我们为什么不从 Cloud Code 的愿景故事开始，以及你是如何参与进来的呢？
>> 是的。嗯，Cloud Code 最初是 Boris 在进行一项项目，以更好地理解我们的 API，并看看他能在多大程度上增强软件工程。当时我正在投入 20% 的时间来添加 RL 环境，我发现 Cloud Code 能让我在这方面效率更高，而且它能很好地与我们内部的所有工具集成。所以，我给了他很多产品反馈，嗯，我希望在工具中做出的改变。当我们决定将其公开发布时，我非常非常兴奋能全职投入其中。从那时起，它在外部也得到了广泛的应用。所以，我们非常兴奋能继续投资于它，使其功能更丰富，使其能在异构的开发环境中工作，并使其更加易于访问。
>> 太棒了。所以，它并不是某种宏大战略的一部分。他只是构建了一个他自己捣鼓的小工具，然后他就参与进来了。那么，发生了什么？
>> 是的。是的。没错。他构建了这个工具，他团队里的其他人开始使用它，然后整个组织都开始使用它，然后它就跨越到了研究领域，然后它实际上开始跨越到像数据科学和产品管理以及产品设计这样的技术相关领域。所以在我们推出它之前，它在内部就有了非常高的病毒式传播效应。好的。所以，你知道，当我第一次开始玩 Cloud Code 时，我把它安装在终端里，然后我就想，就是这样吗？这就是产品。但是当我越用越多的时候，我发现了越来越多的功能，感觉就像在掌握一款电子游戏。它似乎不会立刻向你解释一切，但是越深入，我就感觉越强大，就像一个高级用户。所以，我想问，这是有意的吗？你和你的团队在构建这个工具时有什么产品原则吗？
>> 终端的美妙之处在于，通过终端，Cloud Code 可以访问开发者几乎可以访问的一切，这就是为什么上手这个工具如此顺畅。如果你习惯于调用像 GitHub CLI 或 Datadog CLI 或任何 CLI 工具，你立刻就知道 Cloud Code 也能做到。所以这使得上手非常快。终端也是一种极简的形态。所以不像 Web 应用，你只能使用屏幕上可用的字符数量。你没有添加任何按钮的选项。因此，我们在决定展示哪些功能以及不展示哪些功能时，一直非常务实，甚至可以说是残酷，因为屏幕空间非常有限。
>> 嗯。因此，应用程序的形态非常轻量，这意味着你刚开始时不会感到不知所措，但这也意味着，因为我们将其构建为高度可扩展的，所以当你开始使用时，会有一个任意的深度。我们的设计理念是确保 CLI 非常非常容易上手。我们有一个理念，对于新功能，应该没有用户引导的 UX。它应该只是直观的。
>> 通过功能名称，通过类似一句话的描述它做什么。
>> 然后你应该能够立即开始使用。而且我们也认为 CLI 需要非常可扩展，因为开发环境差异很大，我们希望公开工具，以便每个工程师、每个开发者生产力团队都能为自己的设置进行定制。
>> 明白了。所以这就是为什么我们有钩子、自定义斜杠命令和子代理之类的东西。
>> 好的。所以，就像，先做简单的事情。没有，没有，没有，你知道疯狂的用户引导流程，并且使其可组合和可扩展。
>> 是的，绝对要让它非常容易上手，但能够随着时间的推移处理复杂性。
>> 明白了。你们一直在不断发布，新功能层出不穷，我只是想知道 Cloud Code 团队是如何工作的，你知道，在一周内，工程师们是否基本上自己端到端地发布功能？如果是这样，那么你作为 PM 的角色是什么？你知道，你们是如何合作的？
>> 我们的团队非常强大，有很多非常优秀的产品工程师，他们喜欢对功能拥有端到端的拥有权。
>> 通常的工作方式是，有一些我们想要遵循的更高级别的设计原则。比如我们总是希望工具是可定制的，但在这一点上，你可以构建很多东西。我们许多最好的功能都源于工程师原型化一个想法，将其发布给内部用户试用，到目前为止可能有几百甚至一千名内部员工可以尝试。然后我们听取反馈：人们是否立刻理解了它？人们是否感到困惑？它是否有 bug？或者人们是否就是喜欢它？对于人们喜欢的功能，这是一个非常强烈的信号，表明我们应该快速将其推广给公众。所以，你们看到的许多功能，很多时候在我们公开发布之前，我们已经在内部经历了两次或三次迭代。而且我们还玩过很多内部功能，然后决定不发布。我认为作为 PM，为开发者产品担任 PM 是很棘手的，因为归根结底，开发者是最终用户。所以，我认为 PM 的角色是设定更广泛的方向，比如我们暴露多少可定制性，我们产品的最低标准是什么，或者我们希望产品功能落在哪个范围内，并引导它完成整个过程。在 AI 工具时代，PM 的很大一部分工作也与定价和打包有关。所以，只是确保开发者能够专注于创造最佳的编码体验，然后 PM 的角色是确保它对全世界都是可访问的。
>> 好的。所以，甚至还有产品审查流程吗？还是你们只是原型化一些东西，然后它在内部获得关注，然后就说，好了，我们来做吧。是这样吗？
>> 是的。是的。对于我们较大的项目，有一个产品审查流程。所以，如果你回顾一下 Cloud 4，我们已经发布了与 VS Code 和 IntelliJ 的集成。所以，对于这些，我们有一个明确的决定，我们希望 Cloud Code 在人们工作的地方与他们见面，并对他们的工具拥有更多的上下文信息。所以我们做出了决定，花了几个月时间进行开发，然后发布了。但是对于像待办事项列表或计划模式这样的小功能，这些是我们内部讨论过的想法。它们不需要 PRD，因为困难的事情实际上是找出正确的形态。它不是一个集成挑战。它是一个设计工具，以正确的方式，用正确的提示来挑战。
>> 明白了。
>> 好的。这里有一条来自我们的赞助商 Laura Keat 的快速通知。我最讨厌的事情之一就是坐在那里等待客户支持，或者不停地按按钮才能联系到真人。这就是为什么企业正在转向 Laura Keat，一个 24/7 全天候工作的 AI 客户支持礼宾服务，它支持聊天、电子邮件和语音。它不仅仅是指向帮助文章。它实际上可以解决问题。Loret 了解你公司的系统、政策和工作流程，以 99% 的准确率端到端地解决问题。当需要真人时，它会确切地知道何时移交。一些金融科技、医疗保健和能源领域的大公司已经在使 Luret，并且他们的客户满意度提高了 30 个百分点。在 10 月 31 日之前切换，Lori 甚至会买断你现有的支持合同。所以，现在就去 litcx.ai/pater 看看他们。现在，回到节目。我认为 Boris 在 Twitter 上发了一些关于，嗯，不是三个，他在 Threads 上发了关于他如何设计待办事项列表，这只是他原型化 Cloud Code 并尝试不同形态，对吧？然后你们都试过了。是这样吗？
>> 是的。待办事项列表有很长的历史。
>> Sid 实际上是我们团队第一个开始尝试待办事项列表的人。他试图解决的问题是，我们注意到很多人使用 Cloud Code 来重构或重命名变量，或者进行其他一些较大的任务。而这些任务通常涉及进行 20 或 30 次更改。而 Cloud Code 有时会完成前五次，然后就忘记完成剩下的。所以我们一直在努力弄清楚如何迫使模型完成这些任务。所以 Sid 想出了一个绝妙的主意，就是强迫模型写下它的任务，就像人类在日常生活中所做的那样。我们完全惊呆了，因为实际上，仅仅通过强迫模型写下它的任务并提醒它，嘿，你不能停止，直到任务完成，这实际上迫使模型完成了所有 20 或 30 个项目，而没有任何提前停止。
>> 所以这是 Sid 的自下而上的方式。然后待办事项列表现在已经得到了很大的增强。过去，Cloud Code 只会在转录文本中写下待办事项列表，所以你会看到它在屏幕上飞过，但它不是持久的。然后很多人，我们注意到很多人实际上只是用待办事项列表来跟踪模型的进度。而这实际上意味着你实际上想要它更持久，你不想让它飞出屏幕，否则
>> 用户碰巧看终端的人不知道代理在做什么，他们不得不向上滚动很多。所以 Boris 正在尝试的新形态实际上是让待办事项列表更持久，这样你就可以在任何时候调用斜杠待办事项。
>> 是的。是的。我我我我用过。是的。我认为有一个快捷键可以随时查看它的进度，对吧？
>> 是的，完全正确。我们一路尝试了很多形态，但最终没有保留。比如我们有一些可爱的小思考词，一度我们将待办事项列表放在里面，然后人们并不非常满意，所以这肯定是一个迭代的过程。
>> 当你迭代时，你显然有，你知道，Anthropic 的员工会给你反馈，但你也有客户社区吗？或者你只是看看 Twitter？你是如何获取反馈的？
>> 是的。我们很幸运，Anthropic 的员工对 Cloud Code 的反馈非常积极。所以，我们有一个内部聊天，大约有 1000 名，甚至更多 Anthropic 员工选择加入。所以，人们不是默认加入的。他们只是决定加入。而且我可以说，我们大约每 10 分钟就能收到一条新的反馈。而且它总是高质量的。所以我们非常非常幸运，在产品推出之前就能获得如此大量的反馈。一旦产品发布，我们就会查看早期企业客户的反馈，以及偶尔来自 Twitter 的反馈。我认为我们的企业客户目前可能是信号最强的。我们与大约 10 家公司密切合作，我们告诉他们，嘿，尽量大声说出来。如果遇到任何问题，请在聊天中提出。我们可能无法立即解决，但我们想听听。我们很感激。请，请，请分享负面反馈。我们非常坚持我们喜欢负面反馈。我们不想要空洞的赞美。我们想听听什么不起作用。而且，谢天谢地，这些用户既非常投入 Cloud Code，又非常乐意分享他们遇到的问题，而且我们对解决许多这些问题设定了相当快的 SLA。所以，对于我们决定优先处理并决定解决的问题，我们会在一到两周内解决。
>> 你知道，在一个更传统的公司里，PM 需要维护一堆文件，对吧？比如规格、路线图，也许是愿景文档之类的东西，还有，嗯，还有，嗯，还要跟踪所有反馈。所以，你有这些东西吗？或者你使用 Cloud Code 来总结所有反馈，或者你是如何做的？
>> 是的。嗯，这是一个有趣的问题。我们实际上收到的反馈如此之多，以至于我们应该优先处理什么变得相当清楚，因为你会听到 10 次。我知道这不是一个非常令人满意的答案。我希望我能说，“嘿，我们对每一个东西进行排名，跟踪每一个东西，然后对它们进行排名。”
>> 是的。但我想在实践中发生的是，有人发布了一个 GitHub 问题，他们说有些东西坏了，然后那个 GitHub 问题上有一百个赞，然后我们的销售团队会给我们发私信说，嘿，对于这三位客户来说，这个东西坏了。所以，通常当一个问题优先级很高时，它会非常非常明显。
>> 我确实通过几种方式使用 Cloud Code 来帮助我解决这个问题。一种是我们已经将 Cloud Code 与 Slack 连接起来。所以，综合反馈非常容易。例如，如果一个客户要求我们能够通过子代理自定义模型。我只会问 Cloud Code，嘿，还有哪些客户要求过这个？这样，当它建成时，我们就知道我们告诉了正确的人我们已经完成了。然后我也可以问 Cloud Code，嘿，也看看我们的 GitHub 问题，看看是否有关于这个的 GitHub 问题。这样，当它建成时，我们就关闭了所有的 GitHub 问题。我们还使用 Cloud Code 来自动化尽可能多的处理。例如，Cloud Code 会帮助我们更新文档。它会进行初步的文档编写，然后我们再清理剩下的 10%，以确保它非常准确，所以人类仍然会审查它。然后我们还使用 Cloud Code 来对 GitHub 上的问题进行去重。对于很多问题，我们看到五次或更多次重复提交。所以这有助于我们维护待办事项列表，并确保我们的社区保持最新状态。
>> 你们可能所有的文档都在 MD 文件里，对吧？你们没有 Google Docs。我只有一个。是的。
>> 我们不怎么用 Google Docs 来处理 Cloud Code。不。明白了。
>> 也很棒，因为我们的代码库实际上很小。所以，即使我认为人们通常使用 Google Docs 来记录功能或我们构建某个功能的原因。我认为对于 Cloud Code 的许多功能来说，我们构建它的原因有时就在 PR 中。所以，如果你问它，嘿，待办事项列表的最初灵感是什么？搜索 GitHub，它就能找到原始 PR 并告诉你。而且因为代码库很小，如果你想确切地知道某件事是如何实现的，实际上比阅读可能过时的文档更快、更准确地询问 Cloud Code，同时它又初始化在该仓库中。
>> 是的，这是一个非常好的观点，因为真相的来源是代码库，对吧？而且你知道，这个模型非常擅长总结代码库中的内容。所以，
>> 完全正确。是的。而且代码库很小。你自己会提交代码吗？比如做一些小的修改，或者你提交功能？
>> 是的，我会。嗯，当我刚加入 PM 的时候，我经常这样做，而且总有一些小功能，对我来说比让团队里的其他人来做要快。所以，比如两个月前，我们与 Rick Rubin 合作进行了关于 Vibe Coding 的项目，我们品牌团队的一个想法是，我们应该有一个 Vibe 命令，引用 Rick Rubin 关于这个话题的一些写作。所以，对我来说，添加它比让团队里的某个人添加它要容易得多。所以，只是把它承担下来。我们也在我们团队的其他成员身上看到了这一点，比如 Megan，她是我们的优秀设计师。她以前从不提交代码，这对于产品设计师来说是很正常的。当她开始更多地使用 Cloud Code 时，她开始向 Console 提交 PR，Console 是我们管理 API 密钥和其他 API 使用的产品。她也向 Cloud Code 本身提交了 PR。所以，它肯定降低了每个人提交 PR 的门槛，特别是对于简单的更改。
>> 是的，这太棒了。我的意思是，这简直是梦想，对吧？让设计师和 PM 能够直接提交代码，对最终用户体验产生影响，而不仅仅是写一堆 Google Docs，这简直是梦想。
>> 是的，完全正确。而且它也使得审计流程更容易，因为我们有很多分支逻辑。所以，例如，如果你使用的是 Max 计划，有很多条件我们会向你显示速率限制警告，或者显示升级消息，这取决于你可能使用的每个计划，无论你是使用一个 PI 还是 3P API，还是 Cloud for Enterprise 或 Proumer。所以，Cloud Code 也使得审计这些流程非常容易，因为你可以直接问它，好的，跟踪每个流程的代码，然后告诉我具体发生了什么。然后你就可以
>> 明白了。
>> 你可以对它的准确性感到相当满意，如果它返回的结果是准确的。
>> 明白了。好的。嗯，所以可能整个团队一天中最常谈论的就是 Cloud Code。是的。嗯，让我问你，最近 Twitter 上有很多关于评估的激烈讨论。有些人说，在你发布任何东西之前，你必须进行非常稳健的评估。有些人则说，呃，随便吧。你们是如何看待评估和在发布之前运行东西的？
>> 是的，评估非常困难。嗯，我们关心两种评估，它们都不完美，我们都在努力改进这两种评估。第一个是端到端评估。你可以把它想象成在新的 Cloud Code 框架上运行 SWE Bench，以确保我们没有降低性能。所以，这是我们定期进行的一项工作，无论是进行大的框架更改还是测试新模型。这并不那么精细。所以，如果你看到 SWE Bench 分数的变化，并不总是清楚是什么原因造成的，你实际上需要阅读这些相当棘手的转录文本，而且很多时候才能找出主题和出了什么问题。我们想让这变得更好，但目前我们还没有万能的解决方案。
>> 另一个我们认为非常重要的评估是触发评估。所以，这意味着有很多情况 Cloud Code 可以决定是否使用工具。理想情况下，Cloud Code 可以独立于人类做出这些决定。这样事情对人类来说就会感觉更神奇。例如，Cloud Code 支持网络搜索，我们希望确保网络搜索不会过于积极。比如，如果你问它一个问题，你不想让它 100% 的时间都进行网络搜索。
>> 是的。
>> 但如果你说，“嘿，最新的 React 版本是什么？那里有什么新功能？”时，你希望它进行搜索。所以，实际上调整这种触发机制是相当困难的。所以，在这种情况下，既很容易进行评估，因为你知道你可以清楚地说明何时应该发生网络搜索，何时不应该发生，而且也很容易评估网络搜索是否发生。
>> 明白了。
>> 更难的评估是能力评估。
>> 比如什么样的能力评估？举个例子。
>> 是的。所以，如果你想评估，嘿，这个框架在数据科学工作方面是否比上一个更好？这实际上要困难得多，因为你实际上需要一些更接近 SWE 的设置，模型可以访问一个非常大的底层数据集，能够针对数据集编写查询，迭代这些查询，并且你需要有一个黄金标准答案，并且你需要确保答案没有歧义。
>> 是的，明白了。好的。嗯，网络搜索那个，你只是看看，也许看看过去，当触发网络搜索时，看看它是否有意义，或者有没有分数之类的。是这样吗？
>> 是的。所以，对于网络搜索，有一个范围，何时网络搜索永远不应该触发，何时应该总是触发。所以，作为开始，我建议在评估中将黑白区域编码化。总有一个灰色区域，我可能会在之后处理它们。
>> 是的。而且，而且，而且，我的意思是，事实是，你有一个如此活跃的社区，你的用户一直在让你保持诚实，对吧？所以你可以看一些分数，但你的用户一直在让你保持诚实，关于什么在起作用，什么不起作用。
>> 是的，那是真的。是的。就像待办事项列表一样，我们花了很多时间来确保它触发得很好，因为有时 Cloud Code 会想为一项任务创建一个待办事项列表，然后将其标记为完成。
>> 这是一个明确的例子，不应该使用待办事项列表，因为你真的不需要这种形态来跟踪一项任务的完成。直接做任务就行了。
>> 明白了。
>> 这是一个 EVA 会非常有帮助的情况。比如你可以确保你能够采取代理创建待办事项列表的轨迹，将其放入你的评估套件中，然后确保代理不创建待办事项列表项，或者如果它创建了待办事项列表项，那么它就是三个或五个项目。
>> K，你能给我讲一些有趣的故事吗？我的意思是，你一直在 Cloud Code 团队的这个旅程中，对吧？有没有什么团队会因为而笑的有趣故事？你知道，你知道，我好像听过一个关于你们在会议期间发布一个功能的故事。讲讲一些 Cloud Code 团队的有趣故事。
>> 是的。
>> 是的。当我想到这个团队时，我想到的就是人们绝对热爱开发者。我们一些最美好的回忆是当我们刚发布时。我们想感谢我们最早的用户。所以，如果有人在使用 Cloud Code 时不小心提到了“Swag”或“Stickers”这个词，我们会给他们发送 Sid 构建的这个。我们会给他们发送到一个贴纸门户，他们可以在那里输入他们的地址，然后我们就会寄给他们一套贴纸。有人实际上逆向工程了代码，或者查看了我们的源映射之类的，找到了这个。
>> 结果我们收到了大约 500 个询问，人们提交了他们的地址，这只是一个可爱的小东西，一个可爱的彩蛋，我们想嵌入其中，没有任何其他原因，只是为了感谢我们最早、最投入的用户。
>> 是的。
>> 我们认为，我们 12 个人发送 500 张贴纸只需要一个小时，但实际上可能花了我们八个小时。
>> 哇，好的。
>> 然后我们就，我们原本打算包饺子，结果我们只是点了外卖，然后一直忙着寄贴纸。
>> 哇，好的。你们可能不得不移除这个功能，因为你们不想整天寄贴纸。
>> 是的，我们很庆幸我们把它限制在了大约 500 张左右。
>> 好吧，这次之后给我寄一张贴纸，我想要一张贴纸。是的。
>> 哦，我们有很多。我们一直在改进它们。现在我们有更硬核的贴纸和超级硬核的贴纸，还有。
>> 有很多梗，对吧？比如，Cloud Code 会说，它们会创建一个待办事项列表，然后说，“哦，这需要一个工程师，这需要我两周才能完成，而我只用了 10 分钟就完成了。”
>> 是的。
>> 我以前见过这种情况。是的。
>> 是的。我们需要教它更好的时间观念。我认为它引用的是人类的时间，然后它就不行了，因为我认为它只在网上看到过人类的时间。
>> 所以，嗯，我的意思是，听起来团队里有一些相当不错的氛围。而且我知道你们正在为 Cloud 团队招聘 PM。你知道，你们在寻找什么样的人？面试过程是怎样的？我们正在寻找一个热爱开发者的人，就像热爱一样，最好是以前做过开发者，或者做过开发者工具一段时间。理想情况下，我们希望找到一个想要确保 Cloud Code SDK 是构建代理的最佳方式的人。我们希望创造更多代理，我们认为 Cloud Code SDK 是原型化代理并将其投入生产的最快方式。我们也在寻找一个想要发展生态系统的人。所以，我们注意到很多开发者都在定制他们的设置。他们正在构建自定义斜杠命令、自定义钩子和状态行。我们希望有一个中心，人们可以在那里分享所有这些，人们可以互相审查他们的定制，有人可以一键安装到他们自己的 Cloud Code 实例中。所以，我想说我们正在寻找一个既能作为构建代理的最佳方式来管理 SDK，又能发展社区，使这些定制易于共享的人。
>> 所以，可能是一个已经相当喜欢 Cloud Code 的人。是的，我们绝对是超级用户。
>> 是的。是的。你们呢？也许是 Cloud Code，或者只是 Anthropic 整体？嗯，在面试过程中，有没有像“嘿，你能在这里构建一些东西吗？”或者“你知道，你能用 Cloud Code 添加一个功能吗？”或者有没有什么现场演示？
>> 噢，也许我们应该这样做。我们确实让人们花一些时间使用产品，并对他们希望看到改进的地方进行评论。好的。
>> 我认为通常我们可以从那里对一个人对工具的投入程度有一个相当好的了解。但那样会很有趣。
>> 是的。或者我们正在寻找那些在 YouTube 上制作教程的人。开玩笑的。
>> 是的，完全正确。
>> 是的。好的。那么，我们来做一个闪电战。我想听听一些关于如何充分利用 Cloud Code 的技巧，对吧？也许还有你个人是如何使用它的。
>> 是的。我分享的三个技巧是：一，演示而非文档。Cloud Code 使创建原型变得如此容易，如果你正在考虑“我们应该构建这个功能吗？”，我实际上会问，“嘿，有没有办法让 Cloud Code 为你原型化这个功能，这样你就可以在写一个多页文档之前感受一下它的有用性？”第二件事是，我将 Cloud Code 视为一个积极主动的新晋工程师。所以，我会把它看作是一个对反馈非常敏感的工具。我有时会看到人们给 Cloud Code 一个非常雄心勃勃的提示，然后当 Cloud Code 做出错误假设时，他们就放弃了。但相反，我会说，如果你注意到 Cloud Code 做错了什么，就告诉它做错了，就像你会给人类提供反馈一样。它非常 receptive，并且通常会改变方向并采纳这些反馈。然后第三件事是，投资你的 Cloud MD 文件有巨大的价值。Cloud MD 是 Cloud Code 的记忆。每次启动 Cloud Code 实例时，Cloud MD 都会包含在其中。所以，你可以把它看作是边缘用户引导。它是你想告诉任何新接触你代码库并希望立即高效工作的人的一切。所以，它是提及你的应用程序架构、任何陷阱、你喜欢如何测试和验证工作，任何你会告诉新员工的事情的好地方。
>> 对 Cloud MD 有两种方法，对吧？你可以输入斜杠 init，它会扫描代码库并添加一些东西。
>> 但我我我我喜欢 Megan 的用法。她有，她说，“我是一名产品设计师。你得向我解释一切。”就像一种更个人化的风格的 Cloud MD。
>> 是的。是的。完全正确。所以整个系统都非常可配置，所以你可以有一个针对整个仓库的 Cloud MD，然后你也可以有你完全个人的 Cloud MD。在 Megan 的案例中，对于描述你是谁以及你在公司的角色的 Cloud MD，它适用于所有项目。你也可以有一个全局的个人 Cloud MD，这样 Cloud Code 无论在哪个仓库工作，都有这个上下文。
>> 明白了。明白了。好的。在关于你分享的第二个技巧，将它视为一个积极主动的工程师方面，我发现你花在计划上的时间越多，结果就越好。所以，就像实际上让它写一个相当详细的规范，说明你想构建什么，然后你审阅它，然后还要求它创建一个待办事项列表，然后审阅它。
>> 完全正确。
>> 这对我来说一直非常有帮助。是的。
>> 完全正确。我们的用户喜欢计划模式。所以，实际上，
>> 是的。
>> 也许一个有趣的故事是，我们最初知道人们想要计划模式，因为人们一直在说，“嘿，只是告诉我你要做什么，但不要写代码。”我们一直抵制添加计划模式，因为我们想教用户用自然语言表达他们的想法。当你用自然语言表达时，Cloud Code 会为你制定一个计划，即使在计划模式之外。在过去一两个月里，足够多的用户表示他们只是想非常明确，他们想要一个快捷方式，所以我们屈服了，说，“好吧，好吧，我们会添加一个明确的计划模式。”但我们真的希望我们能够教会用户直接要求模型进行计划。也许将来，当模型更好地遵循这些用户指示时，我们可能会移除它。
>> 嗯，是的，我的意思是，现在的模型太急于写代码了。就像，即使在计划模式下，当我像，“嘿，你能为我制定一个计划吗？”然后它会制定一个计划。它们会说，“哦，顺便说一句，我现在就可以开始编码了。你想开始编码吗？”就像，“不，停止编码，我得先审阅你的计划。”是的。所以，我认为它太急于求成了。是的。是的。完全正确。
>> 你有 Cloud Code 的愿景文档之类的东西吗？或者你认为一两年后这个产品会是什么样子？
>> 一两年是很长的时间。我可以谈谈接下来的几个月。所以，我们希望确保 CLI 继续成为最强大的编码代理，我们也希望它具有极高的可定制性，以便它能在任何开发环境中工作。它可以与你所有现有的工具集成，并且你可以，并且我们围绕这些定制创建了一个生态系统。第二点是，我们非常关心发展 SDK。所以，总的来说，我们希望世界上有更多的代理。不仅仅是编码代理，还有法律助手、EA 助手，比如个人助理 AI，
>> 嗯，健康助理 AI，财务助理，诸如此类。我们希望 Cloud Code SDK 实际上能让所有构建通用代理的公司更容易上手。我们已经看到了初步迹象。我们正在与许多公司密切合作，他们正在构建非编码代理，使用 SDK。我们希望确保这些公司取得巨大的成功，并在他们的产品上市时讲述他们的故事。
>> 是的。
>> 第三类，也是最模糊的一类，是将 Cloud Code 引入终端之外，使其对更多受众更易于访问。所以，目前我们主要针对专业开发者。我们将继续专注于专业开发者，因为那是 Cloud Code 的核心市场。但我们越来越多地发现，它为技术相关人员带来了很多价值。比如数据科学、产品管理、产品设计，我们理想情况下希望有一种形态，让这些人也能从中受益，并逐渐扩大到营销人员、销售人员，我们认为他们也将受益。
>> 是的。是的，因为 Anthropic 的人们，设计师、营销人员都在使用这些东西，对吧？我的意思是，
>> 有一些，我们想吸引更多人。目前，向那些以前从未使用过终端的人解释终端界面仍然非常困难，但我认为核心的原始概念非常通用。所以，我对未来感到非常兴奋。
>> 而且它不需要，你知道，你知道，我刚刚录制了 Alex 的节目，他对他的生活进行了记录，他使用 Cloud Code 来处理很多任务。而且你不需要有什么疯狂的提示。你只需要和 Cloud Code 交流来弄清楚事情。
>> 是的。
>> 你只是告诉它。而且如果你感到困惑，就像我最近让一位营销团队的成员上手 Cloud Code，她说，“我从来没有写过代码，我甚至不知道我应该问什么。”我说，“好吧，就让它帮你构建一个应用程序。”然后 Cloud Code 就带着某种目的去构建应用程序。她说，“好吧，我不知道如何运行这个应用程序。”所以我告诉她，“嘿，你可以直接问 Cloud Code。”她就问了。我告诉她如何运行它。她说，“哇，你的意思是任何问题我都可以问吗？”我说，“是的。”而且这真的很酷，因为它就是能用。
>> 是的。是的。是的。而且我我我喜欢你们如何发布了说明性风格，来帮助人们在使用这些东西时变得更具技术性。我我我有一个功能请求，就是能够从手机上使用 Cloud Code，因为这些东西非常具有代理性，对吧？它会工作 10 分钟，然后我就可以去和我的孩子们玩了。所以，如果以后在手机上有什么东西会很酷。
>> 完全正确。我同意。这也是我们构建钩子的最初灵感，有点与此相关。很多人想要在 Cloud Code 等待他们的回应时收到 Slack 通知。
>> 是的。
>> 所以，是的。所以钩子使其可定制。所以，例如，如果你想在 Cloud Code 等待你时收到短信，你可以为此配置一个钩子。但我也能理解你关于远程运行的更广泛要求。
>> 是的。我还没有玩过钩子。我仍然有一长串功能要深入研究。但是，是的，嗯，你知道，我喜欢你说的，你知道，两三年太长了。你知道，你知道，讽刺的是，只是为了结束，我觉得像你们这样最具创新性的团队只是在不断迭代，而一些更传统的团队则说，“哦，我们得有一个三年的愿景，我们得去那里。”感觉非常，你知道，那就是我的感觉，就像把自己推出去，你知道，和你的用户一起迭代，那就是你创造创新的东西的方式。
>> 我同意。我们非常务实。所以
>> 是的。
>> 我们试图构建我们今天希望拥有的产品。而且因为模型变化如此之快，我们认为很难预测超过 6 个月以后的事情。我们认为为下一代模型构建产品非常重要。
>> 是的。
>> 但一代能力直到几个月前才变得明显。所以，我不知道人们如何计划更长远。是的。是的。是的。好的。那么，有什么结束语或建议给那些想要成为 AI PM 的 PM 们，或者，你知道，有什么建议吗？
>> 作为 AI PM 最难学的是要对模型的能力有很好的掌握。很难构建评估。归根结底，很多都取决于直觉。就像，如果你想构建一个功能，你可能应该对模型是否能够支持该功能有很好的直觉。如果不能，模型还有多远？模型已经完成了 80%，你可以通过提示来完成剩下的 20%？或者模型只完成了 10%？在这种情况下，你可能应该在三个月或六个月后回来查看。
>> 只有三个月。是的。是的。
>> 这是最难的技能，也是最稀有的技能。而且我认为你必须有好奇心去推动模型，对吧？去尝试做一些你知道它不能做的事情，或者不是，只是尝试让它奏效。
>> 是的。是的。没错。就像你必须知道模型是否失败，是因为上下文错误？是因为你可能使用了错误的模型来完成任务，还是模型本身就不具备能力？
>> 明白了。好的。这真是个好建议。是的。嗯，好的。那么，人们在哪里可以在网上找到你？或者你想让人们，是的，人们在哪里可以给你关于 Cloud Hub 的反馈？
>> 是的。所以，有两个地方，要么是 Twitter 上的 @catw，要么如果你有技术反馈，请随时打开一个 GitHub issue，我们会进行查看。
>> 好的。好的，Cat，这太棒了。我从和你交谈中学到了很多，我肯定会越来越多地使用 Cloud。感谢你的支持，如果你有更多的功能请求，请告诉我。