我们不太用 Google Docs 来规划 Claude Code。很多最棒的功能都是工程师先快速原型化一个想法，把它推到内部试用（dogfooding），然后我们就听反馈。比如，大家是不是立刻就懂了？会不会感到困惑？有没有 bug？还是大家就是很喜欢？你们是怎么看的？如果你看到 SWE-bench 分数变了，并不总能明显看出是什么导致了变化，而且你还得去读这些非常棘手的对话记录。我们大概每 10 分钟左右就会收到一条新反馈。我们喜欢负面反馈。我们不想要客套话。我们想听哪里不好用。你们有没有给 Claude Code 写愿景文档之类的东西？或者你觉得这款产品一两年后会是什么样子？一两年太长了。我可以聊聊接下来几个月。好。欢迎大家。今天我请到的是 Cat，她是 Claude Code 的产品负责人。Claude Code 是我最喜欢的 AI agent，所以我很高兴能和 Cat 聊聊她的团队怎么做到快速交付、她个人如何用 Claude Code 做产品工作，以及她对这款产品的愿景。欢迎 Cat。非常感谢 Peter。很高兴向你的观众分享更多关于 Claude Code 的信息。好的。那我们不如从 Claude Code 的愿景故事开始，讲讲你是怎么加入的。好。Claude Code 最初是 Boris 做的一个 side project，他想更好地了解我们的 API，看看能在多大程度上增强软件工程能力。那时候我花 20% 的时间在搭建 RL 环境，我发现 Claude Code 能让我效率提升很多，而且它能很好地集成我们内部的各种工具。所以我给他发了一堆产品反馈，说我想在工具里改哪些地方。后来我们决定对外发布时，我特别兴奋能全职投入这个项目。从那以后，它在外部也被广泛采用。所以我们很期待继续投入，让它功能更丰富，能在更多异构的开发环境中运行，并且让更多人能用上。太棒了。所以这并不是什么宏大战略的一部分。只是他做了一个小工具自己捣鼓，然后你参与了进来。后来呢？对，完全是这样。他先做了这个工具，然后团队里其他人开始用，接着整个组织都在用，后来又渗透到研究团队，再后来连技术相关岗位的人也开始用了，比如数据科学、产品管理和产品设计。所以在对外发布之前，它在内部就已经有很强的自传播性。好。你知道，我第一次用 Claude Code 的时候，我先在终端里安装了它，然后心想：就这？这就是产品？但后来用多了，我发现功能越来越多，感觉就像是在精通一款电子游戏。它不会一上来就把所有东西解释清楚，但我越深入使用，就越觉得自己变得更强大了，有点像变成了高级用户。所以我想问，这是有意为之的吗？你和团队在设计这个工具时有没有什么产品原则？终端的好处在于，通过终端，Claude Code 几乎可以访问开发者能访问的一切，这让工具的上手过程非常顺畅。如果你平时会用 GitHub CLI、Datadog CLI 或者任何 CLI 工具，你立刻就能明白 Claude Code 也能做到这些，所以上手特别快。终端也是一种非常极简的形态。不像 Web 应用，你只能用 ASCII，屏幕上能显示的字符就那么多，没法加任何按钮。因此，在决定展示哪些功能、不展示哪些功能时，我们非常务实，甚至可以说非常苛刻，因为屏幕空间实在太有限了。嗯。因此，这个产品的形态非常轻量，所以你一开始用的时候不会觉得信息过载，但也正因为它的可扩展性很强，随着你深入使用，它又有某种无限的深度。我们的设计理念是确保 CLI 的上手过程极其简单。我们有一个原则：新功能不应该有 onboarding UX，它应该凭直觉就能上手——
通过功能名称，通过一两句话的描述说明它是做什么的——
然后你就能直接开始用。另外我们也认为 CLI 必须具有很强的可扩展性，因为每个人的开发环境差异很大，我们希望能暴露出一些工具，让每个工程师、每个开发者效能团队都能根据自己的环境去定制。明白了。所以才会有 hooks、自定义斜杠命令、sub-agents 这类东西。好。所以有点像先保持简单，不要搞那些复杂的 onboarding 流程，同时又要让它可组合、可扩展。对，绝对要让上手非常简单，但同时能随着时间推移承载越来越高的复杂度。明白了。你们一直交付得很快，新功能层出不穷。我想知道 Claude Code 团队实际是怎么运作的？比如某一周里，工程师是不是基本上从头到尾自己 ship 功能？如果是这样，你作为 PM 的角色是什么？你们是怎么协作的？我们团队很强，有很多非常优秀的产品工程师，他们喜欢对功能有端到端的所有权。通常的运作方式是，我们先有一些高层级的设计原则要遵循，比如我们始终希望这个工具是可定制的，但在这个框架下可以构建很多东西。很多最棒的功能都是工程师先快速原型化一个想法，然后推到内部试用，到现在已经有几百甚至大概一千名内部员工可以试用。我们就听反馈：大家是不是立刻就懂了？会不会困惑？有没有 bug？还是大家就是很喜欢？如果某个功能大家很喜欢，这就是一个很强的信号，说明我们应该把它 fast track 到对外发布。所以很多你们看到我们发布的功能，很多时候在公开之前已经在内部迭代了两三轮。也有很多功能我们在内部试过，最后决定不上线。我觉得做开发者产品的 PM 挺难的，因为说到底开发者就是最终用户。所以我认为 PM 的角色，一方面是设定更大的方向，比如我们要暴露多少可定制性，产品功能的最低标准是什么、理想标准又是什么，然后推动它落地。另外，在 AI 工具时代，PM 的很多工作也围绕 pricing 和 packaging。所以要确保开发者能专注于打造最好的编码体验，而 PM 的角色则是确保全世界的人都能用上它。好。那你们有没有产品评审流程？还是说工程师先做个原型，然后在内部有了反响，就拍板上？是这样运作的吗？对，是的。对于我们较大的项目，有一个产品评审流程。所以如果你回顾 Claude 4，我们发布了与 VS Code 和 IntelliJ 的 IDE 集成。对于这些功能，当时的决策非常明确：我们希望 Claude Code 能在用户工作的地方与他们相遇，对其工具有更多上下文，于是我们做了决策，花了几个月开发，然后发布了。但对于更小的功能，比如待办清单或计划模式，这些是我们内部讨论过的想法，不需要 PRD，因为难点其实在于找到合适的 form factor。这不是集成层面的挑战，而是如何用正确的 prompt 把工具设计好的挑战。明白了。好的，这里有一则来自我们赞助商 Laura Keat 的简短通知。我最反感的事情之一就是拿着电话等客服接通，或者狂按按钮只为找到一个真人。这就是为什么企业纷纷转向 Laura Keat——一款 AI 客户支持礼宾服务，7x24 小时运行在聊天、邮件和语音渠道上。它不只是指向帮助文档，而是真正解决问题。Loret 了解你公司的系统、政策和工作流，能够以 99% 的准确率端到端地解决问题。而当需要真人介入时，它也清楚知道何时该转交。金融科技、医疗和能源领域的一些最大型企业已经在使用 Luret，它们的客户满意度提升了 30 分。如果在 10 月 31 日前切换，Lori 甚至会买断你现有的支持合同。现在就访问 litcx.ai/pater 了解详情。现在，回到节目。我记得 Boris 发过相关内容，呃，不是在 Twitter 上，是在 Threads 上，说他怎么设计待办清单的，就像他在用 Claude 快速做原型并尝试不同的 form factor 一样，对吧？然后你们大家都试用了。是这么回事吗？是的。待办清单有一段很长的渊源。
Sid 其实是我们团队中第一个开始试验待办清单的人。他试图解决的问题是，我们注意到很多人用 Claude Code 来做重构、重命名变量或者其他类似的大型任务。这些任务通常涉及 20 到 30 处改动，而 Claude Code 有时会做完前五个，然后就忘了剩下的。于是我们就在想，怎么才能让模型真正完成这些任务。然后 Sid 想出了这个很棒的主意：强制模型写下它的任务，就像人类在一天中安排事项时那样。我们完全被震撼了，因为仅仅通过强制模型写下任务并提醒它“嘿，在任务完成之前你不能停”，这就促使模型逐一完成了全部 20 或 30 项，没有提前停止。所以这是 Sid 自下而上推动的。然后待办清单现在已经被大幅增强。过去，Claude Code 只是把待办清单写在对话记录里，你会看到它从屏幕上飞快掠过，但它并不是持久化的。然后我们注意到，很多人其实只是在用待办清单来追踪模型的进度，而这其实意味着你希望它更常驻、更显眼——你不想让它从屏幕上飞走，因为否则那些碰巧看向终端的用户就不知道 agent 在做什么，他们得使劲往上翻。所以 Boris 正在试验的新形式其实是让待办清单更持久化，这样你随时都可以通过 slashtodo 调用它。对，对，我用那个。是的，好像有个快捷键可以随时查看进展，对吧？对，完全正确。我们一路上尝试了很多 form factor，其中一些最终没有保留。比如我们有那种可爱的“思考中”小词汇气泡，有一段时间我们把待办清单放在那里面，但用户不太满意，所以这确实是一个反复迭代的过程。那你们在迭代的时候，显然会从 Anthropic 员工那里获得反馈，但你们也有客户社区吗？还是只看 Twitter？你们怎么收集反馈？是的，我们很幸运，Anthropic 员工对 Claude Code 的反馈非常直言不讳。我们有一个内部聊天群，大概有一千甚至更多主动加入的 Anthropic 员工。不是默认所有人都在里面，是他们自己决定加入的。我们大概每 10 分钟就会收到一条新反馈，而且质量一直很高。所以我们非常幸运，能在产品发布前就获得如此大量的反馈。产品上线后，我们会参考早期企业采用者的意见，以及偶尔看看 Twitter。我觉得目前企业用户对我来说信号最强。大约有 10 家我们合作非常紧密的公司，我们跟他们说：嘿，请尽量大声反馈。如果遇到任何问题，请发到群里。我们可能无法立即修复，但我们想听到。我们很感激。而且请、请、请分享负面反馈。我们坚持强调我们喜欢负面反馈。我们不想要客套话，我们想听什么不好用。谢天谢地，这些用户既非常深度地使用 Claude Code，也非常乐意分享哪里不对，而我们对自己修复这些问题也设定了相当快的 SLA。所以对于我们决定优先处理并修复的问题，我们会在一两周内搞定。你知道，在更传统的公司里，PM 得维护一堆文档，对吧？比如 spec、路线图，可能还有愿景文档之类的，而且还得跟踪所有反馈。那你们有这些吗？还是你们会用 Claude 来汇总所有反馈？你怎么做的？是的。嗯，这个问题挺有意思。我们收到的反馈实在太多了，该优先做什么其实相当明显，因为你会听到 10 次。我知道这个回答不太让人满意。我多希望能说：“嘿，我们会排序，我们跟踪每一条并给它们排名。”
是啊。但我觉得实际发生的情况是，有人提了一个 GitHub issue，说某个东西坏了，然后这个 issue 下面有一百个赞，接着销售团队私信我们说：嘿，这三个客户也遇到这个问题了。所以通常当某件事优先级真的很高时，它是非常非常明显的。不过，我确实有一些用 Claude Code 来帮忙处理这些事的方法。一是我们把 Claude Code 接入了 Slack，所以整合反馈很容易。比如，如果某个客户要求我们支持按 sub-agent 自定义模型，我就会问 Claude Code：嘿，还有哪些客户提过这个需求？这样我就知道功能上线后该通知哪些人。然后我也可以问 Claude Code：嘿，再看看我们的 GitHub issues，有没有相关的 issue？这样功能上线后，我们就能关掉所有相关 issue。我们也尽量用 Claude Code 把这类处理工作自动化。比如，Claude Code 会帮我们更新文档。它先写一版文档初稿，然后我们清理剩下的 10%，确保非常准确——人类还是会审阅的。另外我们还用 Claude Code 在 GitHub 上去重。很多问题会被反复提交五次甚至更多。这帮我们维护 backlog，并确保社区状态保持最新。你们的文档应该都是 MD 文件吧？没有用什么 Google Docs。如果我在那儿只有一个的话。对，我们在 Cursor 上不怎么用 Google Docs。没有。明白了。好的。这也挺好的，因为我们的代码库其实很小。我觉得通常大家会用 Google Docs 来记录功能，或者记录为什么做某个东西，但很多 Cursor 功能背后的原因有时就在 PR 里。所以如果你问它，嘿，to-do list 最初的灵感是什么？呃，去搜 GitHub，它就能直接找到最初的 PR 并告诉你。而且因为代码库很小，如果你真想搞清楚某个东西具体是怎么实现的，直接问 Cursor——在那个 repo 里初始化之后去问——实际上比读一份可能已经过时的文档要快得多、也准得多。对，这点很有道理，因为源代码才是唯一可信来源，对吧？而且你知道，这个模型很擅长总结代码库里的内容。所以……
完全同意。对。而且代码库很小。你自己会提交代码吗？比如改改文案，或者提交功能？会的。会的。嗯，我刚加入做 PM 的时候做得更多。总有一些小功能，我自己做比让团队其他人接手要快。比如两个月前，我们和 Rick Rubin 合作搞 vibe coding，品牌团队有个想法是做一个 vibe 命令，引用 Rick Rubin 关于这个话题的一些文字。所以我自己加进去比让团队其他人做要简单得多，我就直接揽过来了。我们团队其他人也是这样，比如 Megan，我们很棒的设计师。她以前从不提交代码，这对产品设计师来说很正常。但她开始更多用 Cursor 之后，就开始给 Console 提 PR——Console 是我们的管理后台，嗯，是我们用来管理 API key 和其他 API 使用的产品——而且她也给 Cursor 本身提 PR。所以 Cursor 确实降低了大家提 PR 的门槛，尤其是对一些简单的改动。对，这太厉害了。我是说，这简直就是理想状态，对吧？设计师和 PM 能直接提交代码，对最终用户体验产生实际影响，而不是只写一堆 Google Docs，这就是梦想中的场景。对，完全同意。而且这也让我们更容易审计流程，因为我们有很多分支逻辑。比如，如果你是 Max 套餐用户，会有很多条件下我们会给你展示速率限制警告，或者升级提示，而且这会根据你所在的每一个套餐而有所不同，无论你是 1P 还是 3P API，还是 Cursor for Enterprise 或者 Pro。所以 Cursor 也让审计这些流程变得很容易，因为你直接问它就行，比如，把每一种情况的代码都 trace 一遍，告诉我具体会发生什么。然后你就可以……
明白了。如果它返回的结果是准确的，你就可以很放心地相信它的准确性。明白了。好的。嗯，所以可能全团队白天聊得最多的就是 Cursor 了。对。嗯，我问你，最近 Twitter 上关于 eval 有很多激烈观点，有人说你必须在发布任何东西之前建立超级健全的 eval，也有人说啊无所谓。你们是怎么看待 eval 的，以及在发布前怎么跑测试？对，eval 真的很难做。嗯，我们关心两种 eval，它们都不完美，我们也都在努力改进。第一种是端到端 eval。你可以理解为，在新的 Cursor harness 上跑 SWE-bench，确保性能没有退化。这是我们常规会做的，无论是对 harness 做大改动，还是测试新模型的时候。但这种 eval 粒度不够细。比如，如果你看到 SWE-bench 分数变了，并不总能明显看出是什么原因造成的，你得去读那些非常复杂的运行记录，而且得读很多份，才能找出主题和哪里出错了。我们想改进这点，但目前还没有银弹。嗯，另一种我们认为很重要的 eval 是触发 eval。也就是说，在很多场景下，Cursor 需要决定是否使用某个工具。理想情况下，Cursor 可以在不需要人类干预的情况下自己做决定。这样对用户来说体验就更魔幻了。比如，Cursor 支持 web search，我们想确保它不会过度激进。如果你问它一个问题，你肯定不希望它 100% 的情况都去搜网页。对。但如果你是问，嘿，最新的 React 版本是什么，有什么新功能？那你就希望它去搜。所以实际上调教这种触发机制挺难的。而这种场景就非常适合做 eval，因为你可以很清楚地表述什么时候该触发 web search、什么时候不该，而且判断它到底有没有触发也很容易。明白了。更难的是能力类的 eval。比如什么样的能力？给我举个例子。好。对。比如你想评估，这个 harness 是不是比上一个更擅长数据科学工作，这其实难测得多，因为你需要一个更接近 SWE-bench 那样的 setup：模型能访问一个非常大的底层数据集，能写查询去查数据，能迭代这些查询，而且你需要有一个 gold standard answer，还要确保正确答案没有任何歧义。对，明白了。好的。那 web search 这个 eval，你们大概就是看，比如回顾一下 web search 是在什么情况下触发的，判断一下是否合理，然后可能打个分什么的。是这样做的吗？对。对。对于 web search 来说，存在一条光谱：有些情况绝对不该触发，有些情况绝对应该触发。所以一开始，我建议把非黑即白的部分在 eval 里明确规定下来。总会有灰色地带，那些我可能之后再处理。对。而且说实话，你们的社区参与度那么高，用户其实一直在帮你们保持诚实，对吧？就是说你可以看一些分数，但用户会直接告诉你什么管用、什么不管用。对，确实。比如 to-do list，我们就花了相当多时间确保它触发得合理，因为有时候 Cursor 会想要给单个任务写一个 to-do list，然后把它勾掉。而这明显是不该用 to-do list 的场景，因为你不需要这种形式去跟踪一个任务的完成。直接做就行了。明白了。这种场景下 eval 会非常有帮助。你可以把 agent 给一个任务创建 to-do list 这条轨迹拿出来，放进你的 eval suite，然后确保要么 agent 不创建 to-do list，要么如果创建了，那里面至少有三到五项。对了，你能讲些有意思的故事吗？我是说，你加入 CLCO 团队也有一段时间了，对吧？有没有什么团队里大家都会笑的趣事？我听说你们有次在会议中上线了一个功能。给我讲讲 Claude 团队里一些有趣的故事吧。是啊。说到这个团队，我想到的就是一群发自内心热爱开发者的人。我们最珍贵的回忆之一是刚发布产品的时候。我们想感谢最早期的用户，所以如果有人在使用 Claude Code 时不小心提到“swag”或“stickers”这样的词，我们就会——这是 Sid 做的——把他们引导到一个贴纸门户网站，让他们填写地址，然后我们会真的寄给他们一套贴纸。后来有人通过逆向工程或者查看我们的 source map 之类的方式发现了这个功能。结果我们收到了大概 500 多份申请，人们纷纷提交地址。这只是我们埋的一个小彩蛋，没别的目的，就是为了感谢最早、最活跃的那批用户。对。我们原本以为 12 个人花一个小时就能寄出 500 份贴纸，结果实际上大概花了八个小时。哇，好吧。然后其实我们本来打算包饺子的，最后变成了点外卖，一整天都在寄贴纸。哇，好吧。那之后你们可能不得不把这个功能下线了，毕竟不能整天都在寄贴纸。对，幸好我们设了上限，大概 500 份左右。那这次之后也给我寄一张贴纸吧，我想要一张。哦，我们有很多，而且一直在迭代。现在有 “Think Harder” 贴纸、“Ultra Think” 贴纸，还有……
还有很多梗，对吧？比如说，Claude Code 会列一个待办清单，然后它会说：“哦，这得让一个工程师来做，大概需要两周”，结果我十分钟就搞定了。对，我以前也见过这种情况。我们得教它更好地感知时间。我觉得它是在引用人类工时，然后它就搞不清了，因为它只在互联网上见过人类工时。所以，听起来团队氛围很不错。我知道你们在招一个 Claude 团队的产品经理。你们在找什么样的人？面试流程是怎样的？我们在找一个热爱开发者的人，要发自内心地热爱，最好以前做过开发，或者长期从事开发者工具相关工作。理想情况下，我们希望这个人能确保 SDK，也就是 Claude Code SDK，成为构建 agent 的最佳方式。我们想在世界上创造更多 agent，而 Claude Code SDK 是将 agent 从原型落地到生产环境的最快途径。同时，我们也希望这个人能壮大生态。我们注意到很多开发者在自定义他们的配置，比如构建自定义斜杠命令、自定义 hook 和状态栏。我们想建立一个中心，让大家可以分享这些东西，互相评审自定义配置，还能一键安装到自己的 Claude Code 实例中。所以我想说，我们要找的人既要能推动 SDK 成为构建 agent 的最佳选择，也要能发展社区，让这些自定义配置更容易分享。所以可能得是已经深度使用 Claude Code 的人吧。对，我们肯定想要超级重度用户。对了，你们面试的时候——不管是 Claude Code 团队还是 Anthropic 整体——会不会有那种环节，比如“你能用这现场做点什么吗”？或者“你能用 Claude Code 加个功能吗”？会有现场演示吗？哦，也许我们应该这么做。我们确实会让候选人在产品里花点时间，然后给出他们希望改进之处的 critique。通常基于这一点，我们就能很好地判断一个人对这个工具有多投入。不过那样做也挺有意思的。对，或者我们在找那种会在 YouTube 上做教程的人。开玩笑的。是啊，完全没错。好，那我们来个快问快答吧。我想听听如何才能最大程度地用好 Claude Code，以及你个人是怎么用的。好，我有三条建议。第一，用 demo 代替文档。Claude Code 让做原型变得非常容易，所以如果你在考虑“我们要不要做这个功能”，不如先问问能不能让 Claude Code 帮你做个原型，感受一下它到底有多大用，而不是先写一份好几页的文档。第二，把 Claude Code 当成一个积极主动的应届软件工程师。它是一个非常乐于接受反馈的工具。我有时看到人们给 Claude Code 一个雄心勃勃的 prompt，一旦它做出了错误假设，他们就放弃了。但我想说，如果你发现 Claude Code 做错了，就直接告诉它做错了，就像你给人类同事提反馈一样。它很愿意接受，通常会调整方向并吸收这些反馈。第三，好好打磨你的 Claude.md 文件非常有价值。Claude.md 相当于 Claude Code 的记忆。每次启动 Claude Code 实例时，Claude.md 都会被加载进去。你可以把它理解为一种 edge onboarding——那些你会告诉 codebase 新人、想让他一上来就能高效产出的所有信息。所以在这里说明应用架构、各种坑、你喜欢怎么测试和验证工作，或者任何你会告诉新员工的注意事项，都非常合适。
Claude.md 有两种用法，对吧？你可以直接输入 /init，它会帮你扫描代码库并填充一堆内容。但我挺喜欢 Megan 的用法。她写的好像是“我是产品设计师，你得把所有事情都给我讲透”。就是一种更个性化、更有风格的 Claude.md。对，完全没错。整个系统非常可配置。你可以为整个仓库设置一个 Claude.md，也可以有一个完全属于你自己的个人 Claude.md。Megan 的做法是用 Claude.md 来描述你是谁、你在公司的角色是什么，这适用于所有项目。你还可以设置一个全局的个人 Claude.md，这样无论 Claude Code 在哪个仓库里工作，都能拥有这些上下文。明白了。关于你分享的第二条建议，也就是把它当作一名工程师来对待，我发现做计划的时间越多，效果其实越好。比如让它写一份相当详细的 spec，说明你想做什么，然后你审阅一遍；再让它列个 to-do list，你再审阅一遍。完全同意。这对我特别有帮助。我们的用户很喜欢 plan mode。其实有个有意思的故事：我们早就知道大家想要 plan mode，因为不断有人说“嘿，你先告诉我你要做什么，但先别写代码”。但我们一直不太愿意加 plan mode，因为我们想教会用户用自然语言表达需求。而当你真的用自然语言表达时，Claude Code 即使在 plan mode 之外也会为你制定计划。在一两个月的时间里，足够多的用户表示他们就是想要更明确的操作，想要一个快捷方式，于是我们妥协了，说：“好吧好吧，我们会加一个显式的 plan mode。”但我们原本真的很希望能教会用户直接让模型去做规划。也许未来，等模型更擅长遵循这类用户指令时，我们可能会把它移除。嗯，是的，我是说现在的模型太急着写代码了。哪怕在 plan mode 里，我跟它说：“嘿，你能帮我做个计划吗？”它做完计划后就会说：“哦对了，我现在就可以开始写代码，你要我现在开始吗？”我说：“不，别写，我得先审一下你的计划。”对，所以我觉得它就是太心急了。对，完全同意。你们有给 Claude Code 写什么愿景文档之类的东西吗？或者你觉得一两年之后这个产品会是什么样子？一两年是很长的时间。我可以聊聊接下来几个月的方向。首先，我们想确保 CLI 继续是最强大的编程 agent，同时也希望它有极高的可定制性，能在任何开发者环境里运行，能集成你所有的现有工具，并且围绕这些定制化建立一个生态。第二个支柱是我们非常希望壮大 SDK。总的来说，我们希望世界上能有更多的 agent，不只是编程 agent，还有法律助手、EA 助手，比如个人助理 AI，呃，健康助手 AI、金融助手之类的东西。我们希望 Claude Code 的 SDK 能让所有做通用 agent 的公司更容易上手。我们已经看到了初步迹象，有很多跟我们紧密合作的公司正在基于这个 SDK 构建非编程类的 agent。我们想确保这些公司非常成功，等他们的产品上市后，我们会分享他们的故事。嗯。第三个方向也是最模糊的，就是让 Claude Code 走出终端，触达更多受众。目前我们主要面向专业开发者，并且会继续聚焦这个群体，因为这是 Claude Code 的核心市场。但我们越来越发现，它对技术周边角色也很有价值，比如数据科学、产品经理、产品设计。我们理想中希望能有一种产品形态，让这些人也能受益，再往外扩展一圈到营销、销售等我们认为同样能获益的人群。对，对啊，因为 Anthropic 里的设计师、营销人员都在用这东西，对吧？我是说，有一些了，但我们还想让更多人用上。现在，要跟没用过终端界面的人解释清楚还是很难，但我认为核心的原语是非常通用的。所以，我对未来很期待。而且也不需要……你知道，我刚录了一期 Alex 的节目，他基本上就是用 Claude Code 来运行一堆任务，像管理自己的生活一样。你不需要写什么复杂的 prompt，只要跟 Claude 对话，让它帮你搞定就行。对。你直接告诉它就行。如果你不知道怎么弄，就像我最近让团队里一位做营销的同事上手 Claude Code，她说：“我从没写过代码，甚至不知道该问什么。”我说：“好吧，你就让它给你做个 app。”然后 Claude Code 就很有目标性地去做这个 app 了。她说：“我完全不知道怎么运行这个 app。”我就告诉她：“嘿，你可以直接问 Claude Code。”她照做了，我告诉了她怎么运行。然后她说：“哇，你的意思是我有任何问题都可以直接问？”我说：“对啊。”这真的很酷，因为它就是能用。对对对。而且我很喜欢你们推出的解释风格，能帮助人们在使用的过程中也变得更好。其实我有一个功能请求，就是希望能从手机上用 Claude Code，因为这种东西非常 agentic，对吧？它可以自己运行个十分钟，我就可以去陪孩子玩了。所以之后如果能在手机上用就太棒了。完全同意。这也是我们打造 hooks 的原因，做 hooks 的初衷很大程度上就来自这个需求。很多人希望在 Claude Code 等待他们回复时能收到 Slack 通知。对。所以，Hooks 让它变得可定制。比如，如果你想每次 Claude Code 等你回复时都收到一条短信，你可以为此配置一个 hook。不过我也理解你想远程运行它的这个更宏观的需求。对，我还没玩过 hooks 呢，我有一堆功能要深入研究。不过，嗯，我喜欢你刚才说的，两三年太长了。说来讽刺，快结束时我想说，我觉得最创新的团队，像你们这样的，就是在不断迭代；而一些更传统的团队则说，我们得有个三年愿景，得朝着那儿走。感觉就是……反正我就是这种感觉，就是大胆投身出去，和用户一起迭代，这样才能做出创新的东西。我同意。我们非常务实。所以对，我们试着做那种我们自己今天就想用的产品。而且因为模型变化太快了，我们觉得要预测未来六个月以上真的很难。我们认为为下一代模型做产品非常重要。对。但下一代能力往往要到面世前几个月才会显现出轮廓。所以我真不知道人们怎么规划更长远的事。对对对。好了，你对那些产品经理，那些想转型做 AIPM 的人，有什么临别赠言或建议吗？或者任何建议？做 AIPM 最难学的一点，是要对模型的能力边界有非常精准的把握。做 eval 很难。说到底，很多时候靠直觉。比如说你想做一个功能，你得有很好的直觉，判断模型到底能不能支撑这个功能。如果不能，差距还有多远？模型已经做到 80% 了，剩下 20% 靠 prompt 就能补上？还是只做了 10%？如果是后者，那你其实应该等三个月或六个月后再回来看。就三个月。对，对。这是最难、也是最稀缺的能力。而且我觉得你得有那种好奇心去 push 模型，对吧？就是试着去实现一些东西，哪怕你觉得它现在做不到，或者不确定，就先去试试，看能不能搞定。对对，完全正确。你得知道，如果模型失败了，是因为上下文给错了？是因为你用了错误的模型来做这个任务？还是说模型从根本上就做不到？明白了。好，这建议太棒了。嗯，好了，那大家在网上哪里能找到你？或者你希望大家……对，大家可以在哪里给你反馈？关于 Claude Code 的。两个地方，一个是 Twitter 上的 underscore catw，另外如果你有技术反馈，欢迎直接开 GitHub issue，我们会去看的。好的。太棒了，Cat。这次和您交流我确实学到了很多，我相信我会越来越多地使用 Cloud。