Inside Stainless: The Developer Tools Startup Anthropic Just Bought for $300 Million

互联网的运行依赖于计算机彼此通信，但它的整个架构都是为一个 pre AI 时代构建的。现在我们正试图通过 MCP，也就是 Model Context Protocol，把 AI 接入互联网；它可以把任何网站或 web service（网络服务）转变成一组 AI 能原生使用来完成工作的工具。而那些学会把 MCP 做好的软件公司，将在未来十年胜出。这就是为什么我请来了 Stainless 的 founder and CEO Alex Rattray 做客节目。Stainless 的工作，就是帮助计算机彼此通信。

他们为你熟知的那些大公司制作 API 和 SDKs，比如 OpenAI 和 Anthropic，而且他们现在也开始构建 MCP servers 了。所以我和 Alex 深入聊了聊 MCP 的未来会是什么样、怎样设计好的 MCP、为什么 MCP 实际上非常难以 scale（扩展），而且可能并不安全。我们还一起试着弄清楚，什么样的模型才能更好地让 AI 使用互联网。这期节目非常精彩。Alex 是我的好朋友。

我们开始吧。Alex，欢迎来到节目。

谢谢，Dan。能来这里我真的很兴奋。

很高兴你能来。给不了解的人介绍一下，你是 Stainless 的 founder and CEO，这是一家 API 公司。你们为 OpenAI 和 Anthropic 这样的公司制作 API；随便说一家你可能会用到其 API 的大公司，背后很可能都有 Stainless。在那之前，你在 Stripe 负责他们的 API。

没错。再往前说，更重要的是，我们大学时就是很好的朋友，后来也一直保持着这份友谊。我们俩在大学时都在创业，而且我是 stainless 的一个很小的投资人。不过，这些年看着你的历程一路走来、也一直有很多机会一起相处，真的非常非常有意思。而且，我也很高兴请你来聊聊 AI，以及你们在 stainless 正在做的事情。

谢谢，Dan。是啊，这些年真的很有意思。我是说，你知道的，我们上大学那会儿，我在做一家 start up，你也在做一家 start up。

你当时把一家 venture capitalist（风险投资人）办公室里的会议室当作自己的办公室，你还让我和我的 co-founder 以及团队一起借用那个地方。我们就在会议桌另一边一直埋头写代码到晚上。我对那段日子有非常美好的回忆。现在虽然不是每天晚上都这样了，但周末之类的时候，本质上还是同样的事还在发生。这可不是每天都能见到的。

这真的是一种很美好的感觉。而且一路走来，看到每件事不断发生、不断推进，也真的很棒。

谢谢。就像我常说的，我们是从底层一路走到今天的。是的。我的意思是，每次我遇到别人，他们问起你时，为了让你尴尬一点，我都会说，你是我所知道的唯一一个会一直光着脚跑过 Philadelphia 街头的人。因为我们刚认识的时候，你不太喜欢穿鞋，但你很喜欢跑步。

你想聊聊这件事吗？

对。倒也不是我不喜欢“鞋”这个概念，而是我一直找不到一双合适的鞋。到某个时候，你知道的，我穿 Nikes 跑步，但每隔几个月鞋就会裂开。我想真正的问题其实是我的脚特别宽。

而我当时买的鞋大概又偏窄，所以鞋总是很快就坏掉。再加上大学时期预算有限，就会觉得，这样下去不行，这太糟了。最后我就决定，好吧，鞋子穿得越久，只会越磨损；但脚用得越久，反而会越结实。

所以

脚用得越久。

你可以试试看。试试这个，也许有帮助。能出什么问题呢？不过其实我现在一只脚上正扎着一根特别烦人的刺，所以还是别真的在家里试这个了。不过——你现在还光脚跑步吗？

不是，不是。这就是家里附近弄的。

我懂。挺危险的。

对，对。但你看，关键就在这儿。如果我之前一直不穿袜子在柏油路上走来走去，那我的脚底就会更耐磨，也就不会扎进木刺了。

所以你不赤脚跑的时候，就是穿着 Stainless 跑。也就是说你是在跑 Stainless。那你们现在有多少人了？大概 50 人左右了，对吧？

差不多，没错。

这真的挺不可思议的。你是在前 AI 时代创办 Stainless 的，而现在我们已经进入了 AI 时代。我想你对 AI 的未来会是什么样子，以及 API 会怎么融入其中，也许还有 MCP 会怎么融入其中，应该都有一些想法。你愿意给我们大致描绘一下我们将走向哪里吗？

好啊，很乐意。所以先从最基础的开始：什么是 API？不是每个人都熟悉这个。它的全称是 Application Programming Interface（应用程序编程接口）。

不会有小测验的，对吧，Dan？没有小测验吧？

不，不做小测验。

很好。基本上，它就是一个计算机程序如何与另一个计算机程序对话。也就是计算机与计算机对话、app 与 app 对话的方式。所以，API 是互联网的 dendrites（树突）。Dendrites 就是你的 neurons（神经元）彼此连接并真正交换信息的地方。

所以，如果你大脑里有两个 neurons，但它们彼此不交流，那你实际上就没有在思考，对吧？没有神经元之间的连接，大脑里就不会产生思维。如果你再想想互联网，假如 cloud 里的这些服务器彼此不通信，那就不会有互联网，对吧？就像什么都不会发生一样。互联网软件里的程序如果没有 API、没有与其他程序的连接，就什么也做不了。

所以，它其实是几乎所有现代软件这张网络中非常基础的一部分。如今我们想到技术时所想到的一切，API 某种程度上都处在核心和中心位置，就像 dendrites 处在大脑网络的中心、决定我们如何思考一样。而 Seamless 从第一天起的使命，大致就是让计算机与计算机之间的对话变得更容易。技术的长期趋势一直都是更多的 automation（自动化），对吧？当我们说“要把技术应用到某件事上”时，通常指的就是 automation。

一般来说，我们是在让事情变得更高效。而 API 正是大多数 business-to-business 交互以这样或那样的形式真正落地、真正实现 automation 的方式。随着 AI 的兴起，我们看到的是，一个新的计算机加入了聊天。对吧？出现了一种新的系统，它可以和其他系统对话，或者至少我们希望它能够做到这一点。

以前，基本上只有两种情况：要么是人类通过 user interface（用户界面），也就是 UI，与计算机交互；要么是计算机通过 API 与另一台计算机交互。而现在，我们有了 LLM 与计算机交互。对吧？那这是通过什么来实现的？我相信，凡是熟悉 every 以及他的常规听众的人，应该都熟悉 MCP model context protocol，它大致来说是一种把 LLM 连接到计算机系统的机制。

这是我们在 Stainless 正在投入的一个领域。我认为，它确实也是我们核心使命的一部分——就像我说的，让计算机更容易与计算机对话。我们已经投入了很多时间。在 Stainless，我们最早推向市场的核心产品是 software development kits，也就是 SDKs。所以，它们是在说：好，Stripe 有一个很棒的 REST API，你可以通过 HTTP 发送 JSON，再通过 HTTP 收回 JSON。

如果你想让这件事变得非常方便，你就会使用 Stripe Python library，也就是 Stripe Python SDK。所以，如果你是一个 Python 开发者，你会先执行 pip install Stripe，然后在你的应用代码里写 stripe.customers.create，突然之间，你就在某种意义上的 Stripe 数据库里得到了一个很不错的新 customer object，然后就可以快速推进了。或者在以前，用 stripe.charges.create 来给信用卡收费。SDKs 给开发者提供了这种轻松对接 API 的方式。那什么东西能给 LLM 提供一种轻松对接 API 的方式呢？

你也许会说是 MCP，从某种意义上讲，你说得没错。但到目前为止，随着 MCP 在现实世界中逐步推出，人们开始拿它做实验、试用它，我们看到的是，它的效果并没有那么理想。比如说，很难真正实现我所理解的 MCP 最核心、也最令人兴奋的愿景：就是有一个 dashboard（仪表盘）和 user interface（用户界面），你可以在里面到处点一点、看到一堆内容、填写表单、点击按钮、完成各种操作。基本上，凡是你平时在和软件交互时会通过 user interface 去做的事情，都应该能这么做。但当 LLM（大语言模型）通过 MCP 进行交互时，通常会受到更多限制。

你通常只能做少数几件小事。一般来说，你不会向模型开放特别多的 tools（工具）。

我先打断你一下。所以，我觉得我听到你的意思是：MCP 所做的事情，就有点像 website（网站）是为人类使用而构建的一样，MCP 可以算是某种对应物；从某些角度看，它是在向模型暴露一组 tools，让模型能够用它们来执行某些功能。就像你可能会在一个网站上点击某个按钮一样，MCP 会给模型一堆它可以“点击”或使用的东西，来把事情做完。比如说，一个 Gmail MCP 可能会有 send mail tool、compose mail tool，或者 read inbox tool，类似这种。区别在于，不是人类去 Gmail 网站上操作，而是 LLM 本身像是在“登录”并亲自使用它；它是一个面向 language models（语言模型）的原生 interface（接口）。

但你的意思是，这种方式目前效果不太好。你能具体多讲讲吗？

对。所以，我们先从我眼中 MCP 的宏大愿景说起，某种意义上，这其实也是 agentic AI（代理式 AI）最初的宏大愿景。我先举一个你能想到的最普通不过的例子。结合我们前面的语境，这个例子可能还有点好笑：比如说，Dan 走进我的店里，买了一双条纹袜子，可能还顺手买了其他几样东西。然后第二天，我收到 Dan 的反馈，说很遗憾，东西出了点问题。

这种事总会发生嘛。于是我转头对团队里的某个人说，嘿，能不能把 Dan 昨天买的那双条纹袜子退款了？再给他发一个下次进店可用的 discount code（折扣码），顺便附上一张简短的感谢便条，因为我们一向很重视客户体验。这种小任务，在软件里其实是最常见不过的事情。而我的团队成员会怎么做呢？他们会打开内部 admin（管理后台），到处找相关信息。可能会进 Stripe dashboard，翻 payment（付款）列表，或者 transaction（交易）/order（订单）列表，试着找出一个名字叫 Dan 的人——可到底是哪个 Dan，我也不知道，毕竟可能有好几个 Dan。然后再去看这个订单里的 product（商品）列表，确认里面是不是有那双条纹袜子。

这中间可能还得点好几下，具体要看情况。找到正确的那一单之后，再进入可以创建 refund（退款）的页面，发起退款，并确认金额是对的。

然后再去创建那个 discount（折扣）。接着把那个 discount code 拿出来，发送到另一个 SaaS app 里——你得登录那个系统，才能自动发邮件。当然，如果你把这个场景从面向消费者的版本切换到 business-to-business 的语境里，那你可能还要进 Salesforce，再给某个 account administrator（账户管理员）或 account manager（客户经理）发一条 Slack 消息，诸如此类。总之，在日常工作中，一项任务要来回穿梭五个不同的 app，每次点上 15 下，滚几次页面，看几个 loading spinner（加载转圈），最后只是为了完成一件很简单的小事，这实在太正常了。而 agentic AI 的承诺，就是把我刚才那段话同样作为 prompt（提示词）输入到 ChatGPT、Claude 之类的系统里，然后说一句：嘿，chatty，buddy，能帮我把我朋友 Dan 的退款处理一下吗？

让 AI 直接去把这件事做完。基本上就是在这五个不同的 app、15 个不同的界面，以及各种不同的按钮点击之间一路操作，完成任务，然后回来告诉你：很好，已经完成了。要做到这一点，作为 AI model（模型），为了执行这样一条精确、线性的事件链，实际需要发起的 tool call（工具调用）数量是有限的。这在某种程度上还是 tractable（可处理）的。但如果从一般情况来想，你会希望 LLM 能够做到——你会希望你的 agentic AI（代理式 AI）能够做到——那个真人操作员本来能做的任何事情。

而且你会希望它们能做到这一点时，不需要等待网站上一大堆 JavaScript 加载之类的过程。这意味着，你需要的不只是 Stripe create refund tool、Stripe list transactions tool、Stripe list products、look up customer，还有 create discount tool 这些工具。你需要的不仅是这些工具，而是 Stripe dashboard 里你能做的所有事情；而那基本上也就等于 Stripe API 里你能做的所有事情。实际上这可不少。比如说，Stripe API 里你能访问的 endpoint（端点）就有几百个。

Stripe dashboard 实际上非常庞大。它是一个巨大的应用。如果你今天把那份工具列表拿出来，交给一个 LLM，然后说，嘿，这是我们为这一整套东西定义的 MCP。这里有一个 create refund tool。这里有一个 create transactions tool，诸如此类。

然后你把这些工具的全部信息都告诉它。这里是描述。这里是你可以发送的各种 request property（请求属性）。这里是你可能收到的 response property（响应属性）。这里是这些东西各自对应的全部文档。

在听这段内容的每个人应该都知道，到这里你已经把整个 context budget（上下文预算）烧光了。光是这些可能就已经是几十万 token，而且基本上等于把 Stripe Open API spec 直接翻译成 MCP tools。而今天的模型不仅根本处理不了这么大的上下文量，这样用上下文本身也是很低效的，因为你还有很多别的事情也在同时发生。而且这对模型来说也会造成困惑。一次性塞进脑子里的东西实在太多了。

而这还只是 Stripe 这一部分，对吧？因为你真正想做的，是让你的操作员能够做任何他们平时会做的事。而且再说一次，这会跨越很多很多不同的 SaaS 工具，对吧？在一次交互过程中，可能会涉及五个；下一次交互里，又可能是另外五个。

所以，如果你去想想你的业务每天为了完成工作而使用的每一个 SaaS 工具，理想情况下，你会希望每一个这样的工具都暴露给你的操作员，让他们能在 AI chat 里使用，里面每一个工具都可用，每一个边边角角和 corner case（边界情况）也都可用，这样你就能通过 AI 做任何事。这就是那个愿景。当然这里面有很多问题。我提到的最大问题，是这种 context window（上下文窗口）限制。但你还会遇到各种 security（安全）和 permissions（权限）问题，因为你并不希望 AI 越界，突然说，好。

除了给 Dan Sox 退款之外，我还给所有客户历史上的所有交易都退了款。你知道吧？然后我还把一大笔钱转到了我自己的 AI bank account。 所以这个挑战还有更多层面，但这就是我所看到的愿景。

但我觉得，你知道，我们刚才讨论的起点是你说“它行不通”。可我不认为这就是它今天行不通的原因。对吧？还是说，那其实就是它今天行不通的原因？

所以，人们现在使用 MCP 时，有时会尝试把他们 API 的所有部分都暴露出来。人们构建 MCP tools 的方式，一般来说，是先有一个底层 API，通常是 REST API。然后他们把其中不同的部分、不同的 endpoints（端点）、不同的 operations（操作）封装成 MCP tools。你既可以基本按一对一映射来做，也可以专门为 MCP 手工定制。而今天，人们发现，要想做好这件事，你确实得为 MCP、为 LMs 手工定制。

你必须明确地说，好，我要做一个专门的 tool，用来根据描述查询某个 customer（客户），并给他们的 transaction（交易）退款。

所以这里面有很多你必须做的决策；为了确保模型在大多数情况下都能做对事，你需要把模型的 ergonomics（易用性特征）以及模型的思考方式都考虑进去。

对，很难。

很难。

对，对。所以我有时会用这个 SDK 的类比。人类花了很长时间，才发展到这样一个阶段：我们能够为 Python developer 做出一个非常好的 Python SDK，并把 API 很好地封装进去。我觉得这件事我们已经攻克了。Steamless 提供了非常优秀的 Python libraries（库），但我们其实是站在巨人的肩膀上构建这些东西的。

很多人长期以来一直在做这件事。我们还没有搞清楚，怎样才能像面向 Python developer 那样，以符合 ergonomics（易用性）的方式把 API 暴露给 LLM。某种意义上，这有点像一个新的研究问题。而且它更难，因为如果我愿意，我可以去学习如何成为一个 Python developer；但我没法真正学会像一个 LLM 那样去思考或感知。

是啊，如果我真能做到，那肯定会很强大。但这也让问题变得棘手。我觉得在 Seamless，我们确实在酝酿一些东西来解决其中一部分问题，也包括你刚才提到的那些。比如，LM（语言模型）在处理一连串重复且需要持续执行的 action（操作）时会非常吃力。你知道的，就算只是拿到一个 API 响应，说“嘿，把所有交易都列出来”，里面的数据量也会非常大。

然后你可能还得一页一页再一页地翻下去，把所有交易都过一遍，才能找到那笔和 Dan 的条纹袜子有关的交易。这说到底，还是在一大堆上下文里，只找一两根很小的针。LM 在这方面其实已经挺不错了，但并不完美。而且当“草堆”大到离谱的时候，你知道的，我们大家最后都会有点束手无策，LM 也是一样。所以，是的。

所以今天确实存在很多挑战。

所以，当你去看——我的意思是，你在帮别人构建 MCP server——但当你自己去构建它们时，以及更广泛地说，当你看到现在有人把这件事做得不错时，你会遵循哪些原则？或者你会怎么思考，去做一个 MCP SCP server：第一，得有人真的会用它，这其实就是个很大的问题；第二，当它被使用时，它确实能把事情做对？

我真正见过把这件事做好了的情况，其实相对不多。不过我确实见过做得好的。我们现在也在推进一些让我非常兴奋的东西。但以今天的技术水平来说，你真的必须把 product management（产品管理）做好。我的意思是，你得走向市场，和客户交流，了解他们真实的需求，还要站在他们身后看他们是怎么使用、怎么操作你的软件的；然后去思考，通过 AI，我们到底能解锁什么，让人们能做到一些他们今天用我们的软件其实做不到、或者因为现在变得容易太多而终于愿意去做的事情。

然后通常你还得做大量 engineering（工程）工作，把这些东西包装成一个对 models（模型）真正有效的整体。你还必须建立一套非常好的 evals（评测）系统。如果你在做 MCP，你还得考虑人们可能在用的不同 client（客户端）。他们是在用 cursor 吗？是在用 Claude code 吗？

还是在用别的东西？以及这些东西底层对应的不同模型。所以最后你会得到一个相当疯狂的组合矩阵：有很多维度你可能都想优化，也有很多方式你可能都想拿来评估，以确保你提供的东西确实运行良好。而且，要把这些反馈再传回你的 server，也有点像个 black box（黑箱）过程，这样你才能弄清楚：嘿，我们这里返回了一次 tool call（工具调用）响应。我们给出了某种答案。

那它到底好不好？用户喜欢吗？LM 能把它用起来吗？我觉得这是一个我目前还没看到很多人真正解决好的问题。所以，要把这件事当成 first class thing（一级重要事项）来考虑，也许你可以做一个类似 send feedback 的工具。

这是我们一直在考虑要做的事。这样一来，如果用户在 chat 里直接说出“哦天，这就是一堆毫无用处的垃圾”，那至少 MCP server 会知道这件事。

但是，除了那种显而易见的原则——你得和客户沟通、思考你的 use case——之外，你有没有学到什么更具体的东西，比如到底怎样才能把这件事做好？也就是，更落地、更可操作地说，怎样设计一个好的 MCP server。

你会想把 tools 的数量控制得相对少、相对低。你还会希望 tool 的名称和 description 都非常精确、非常具体。

这两点不是互相矛盾吗？

是的。好的写作很难。对，我的意思是，比如说，你完全可以做出一个很棒的 tool：按姓名和产品描述查找某个人，然后给他退款。你可以做出这样一个很棒的 tool。

你还会希望 input schema 里的 properties 数量尽可能少。你会希望 parameters 的数量少，而且它们的描述要简洁，但又得描述充分。这同样很难。你还会希望返回的 response data 只有非常少的数据量，只包含 model 真正需要的那些内容。这也非常难，因为你可能事先并不知道 model 真正在找的是哪些东西。

我们现在在自己的 MCP servers 里用了一种技术：给 model 一个 JQ filter，也就是一种筛选 JSON 的方式。这个方法效果往往还不错。不过这算是一种比较特殊的技巧。

这是不是意味着，MCP 其实还需要再多一层东西，比如一个用于搜索 tools 的 search tool function？也就是：根据我的任务，找出一组相关的 tools？

tool 浏览问题绝对是一个非常严重的问题。这当然是一种处理方式。所以我们现在在 Stainless 其实就是这么做的：你可以为自己的 API 获取一个 MCP server，它就像我前面说的那样，采用非常简单的方式——把每个 endpoint 都暴露为一个 tool。如果你的 API 规模较小，这种方法效果非常好。你也可以把它筛选一下，只暴露一个只包含少量 endpoint 子集的 MCP server。

这效果很好。你也可以使用一种我们称为 dynamic mode 的方式，不管你的 API 有多大，都只有三个 tool。一个是列出 endpoint，另一个是获取某个 endpoint 并了解它，最后一个是执行 endpoint。

这样就能让这种 context（上下文）机制很好地扩展。但这也意味着，模型为了完成一件事，得先进行三轮交互。所以它会更慢。从另一种意义上说，成本也更高。而且还会有一些信息损耗。

通常表现相当不错，但还没有那么好，因为这些 tool 的加载方式并不完全相同。

你自己也在使用 MCP server 吗？

对。我确实会用 MCP——有意思的是，不太是在 coding 这一侧，而更多是在业务侧。我会使用 Notion、HubSpot、Gong 的 MCP server，还会用一个连接我们数据库的 MCP server——它对应的是我们数据库的只读副本——然后说，嘿，帮我看看上周注册 Stainless 的有意思的客户有哪些？它就会去对我们的 Postgres 数据库发起一个很不错的查询。然后它还能在 HubSpot 里交叉比对这些信息，再去 Notion 查我们的笔记，甚至还可能看看 Gong 里的 transcript（转录文本），然后把相关情况都告诉我。

这真的太惊人了。

我们很多人都在把 AI 部署到 production（生产环境）中，这对提升生产力当然很好，但也会带来焦虑。你微调一个 prompt（提示词），替换模型，调整 router（路由器），测试里看起来一切正常，于是你就合并了。结果三天后，甚至更早，support ticket（支持工单）就开始不断涌来。AI 开始给你的客户一些出乎意料的回答，而你完全不知道这是从什么时候开始的，也不知道为什么会这样。BrainTrust 就是用来解决这个问题的 AI observability platform（可观测性平台）。

它把 evals（评估）和 observability（可观测性）连接到同一个工作流中。这样一来，你既能看到 production（生产环境）里实际发生了什么，也能衡量改动到底是让结果变好了还是变差了。traces（追踪）会展示完整的执行路径。evals 定义“什么才算好”，而 experiments（实验）让你在发布前并排比较 prompts（提示词）和 models（模型）。production traces 会直接进入你的 eval datasets（评估数据集）。

每一次失败都会变成一个测试用例。你能在 CI（持续集成）里，在问题到达用户之前就抓住 regressions（回归问题）。而 Notion、Stripe、Zapier、Vercel 和 Ramp 的团队也在用它，以规模化方式交付高质量 AI。BrainTrust 是为那些在构建 production AI systems（生产级 AI 系统）的团队设计的，在这类场景里，silent regressions（无声回归）的代价很高。它适用于任何技术栈。

他们提供 Python、TypeScript、Go、Ruby、C 的 SDKs（软件开发工具包）。没有 framework lock-in（框架锁定）或 vendor dependencies（供应商依赖）。它通过了 SOC 2 Type 2 认证，并且符合 GDPR 和 HIPAA。可前往 braintrust.dev 开始使用。再说一遍，braintrust.dev。

现在回到这期节目。所以这就是你的一个主要 use case（使用场景）之一。比如，你会每周都这么做吗，还是说频率怎样？我现在感兴趣的甚至不只是从 MCP 的角度，而是对任何经营有一定复杂度业务的人来说：如果你想知道业务里到底发生了什么，那你实际上在做什么？最后产出的 report（报告）是什么？你多久做一次？以及诸如此类的事情。这样你告诉我之后，我也可以偷学一下。

对我来说，这通常还处在一种有点像边玩边试的模式。其中一个问题是，MCP servers 会断开连接，然后我就会有点烦。所以你知道的，你就得重新连上之类的。也不是什么大事。

但像这么新的技术，仍然会有很多细小但烦人的 paper cuts（小摩擦、小障碍），这是意料之中的，而且它们确实会在一定程度上抑制你的使用频率。我发现一个非常有帮助的做法，是在更 meta（元）层面上——我相信你其他嘉宾应该也提过——就是养成这样一种实践：为 AI 收集笔记，这些笔记由 AI 生成，再由你自己编辑和整理。所以，我有一个——我有点记不清我是不是就叫它 note，我想我有一个 notes folder、一个 research folder，或者类似的东西——放在一个专门的 Git repo 里，我只把它用于这类内部用途。我会说，嘿，当你发现有趣的客户引语时，就把它们放进这个文件夹里，并附上完整 citation（引文信息），这样我下次开始问一些有意思的问题时，它就不用再去 MCP servers 里重新搜索了。

这样它们就等于被缓存到磁盘上，以 markdown files（Markdown 文件）的形式保存下来了。

等等，这也太疯狂了。等等，所以你是怎么把内容写进那个 git repo 的？比如，你用的是 cloud code 吗？

你是在用 touch ebt 吗？比如，它是怎么放进去的？

对。现在这类事情我会用 Cloud Code。

所以你就是一直开着并运行着 Cloud Code，然后一有新的客户 testimonial（客户证言/推荐语）进来，你就会说，嘿，能不能把这个扔进我的、类似那个 git master company git knowledge repository（git 主公司知识库）里？基本上就是这样。然后以后你需要什么的时候，你就会说，Claude，去我的主知识库里搜一搜，看看这个场景下最好的客户引言是哪一条。

完全是。

这他妈也太酷了。我们能不能看看

它？不行。太乱了，而且里面可能有很多 confidential information（机密信息）。后者更重要一些。

你说它很乱的时候，是指你有让 Claude 帮你整理吗？还是说，它现在大概是怎么组织的？

这里面有很多我希望我们去做的事，只是我们还没来得及做。还有一些别的、更 low-hanging fruit（更容易先做的事情）是我现在正在处理的，也是我们业务团队现在正在推进的，就是一些基础层面的东西，比如你那种 CRM systems（客户关系管理系统）之类的。所以它现在还没有那么有条理，不过我觉得这也没关系。对，我暂时不打算把“把它整理得特别、特别完善”这件事放到很高优先级，至少要等到我们更多地用起来再说。

我更广泛地在用它，因为你知道，我自己有时会用这些东西。团队里有一位业务人员用得相当多。我觉得，我们有一两位 customer support engineer（客户支持工程师）也非常常用这些东西，但目前还没有更大范围地铺开。我希望之后能发展到那一步。等我们看清楚整体是怎么演进的，我想那时候我们就会开始引入更多结构化的做法。

但就目前来看，Cloud Code 很擅长处理非结构化的东西。所以在我看来，你没必要事先想得太复杂。之后再调整、再搬动内容也可以。

除了客户引言之外，你们那里还放了什么？

SQL query（SQL 查询）。所以，你知道，我是个 software developer（软件开发者）。我现在其实已经不怎么大量写代码了，但你知道，我以前在这上面花了很多时间。所以当我说，嘿，你能不能查一下，比如说，我们某个 xyz metric（指标）在过去三个月里的 month-on-month growth（环比增长）怎么样？你知道，我最近就做过这个。

我上次准备 board prep（董事会材料准备）时就这么做了。它立刻给出了一个相当不错的答案。我当时就觉得，哇，这太棒了。然后我又稍微往深里看了一点，就发现，哦，其实我想把这些用户排除在这次分析之外，还想按这种方式筛选、按那种方式筛选。于是我就把更多业务语境灌输进了那条 SQL query 里。