走进 Claude Code：一个 AI 原生团队究竟如何闪电发版 | Cat Wu

我们团队很强，有很多非常优秀的产品工程师，他们喜欢对功能有端到端的所有权。

通常的运作方式是，我们先有一些高层级的设计原则要遵循，比如我们始终希望这个工具是可定制的，但在这个框架下可以构建很多东西。很多最棒的功能都是工程师先快速原型化一个想法，然后推到内部试用，到现在已经有几百甚至大概一千名内部员工可以试用。我们就听反馈：大家是不是立刻就懂了？会不会困惑？有没有 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。