Anthropic 在和客户合作的过程中总结的的企业落地 AI 最佳实践以及常见错误

在 AI 迅速发展的今天，企业如何将 AI 技术落地应用，推动业务创新，成为了摆在许多从业者面前的难题。Anthropic 这两天在“AI Engineer Summit 2025”分享了他们在与众多客户合作的过程中，总结出来的一套行之有效的企业落地 AI 的最佳实践，并识别出了一些常见的错误。我在这里把视频上一些有价值的实践经验和教训整理出来了，希望能帮助你在 AI 应用的道路上少走弯路。

常见场景与挑战：你是否也有这些困惑？

Anthropic 通过和企业客户的协作过程中，发现主要的问题集中在这几个方面：

• 问题一：从何入手？你知道 AI 很强大，但具体到你的业务场景，应该从哪里开始？是做一个聊天机器人，还是做数据分析工具？抑或是更高级的 AI Agent？
• 问题二：如何评估效果？你花了大量时间和资源搭建了一个 AI 系统，但如何判断它是否真的有效？是看用户反馈，还是看技术指标？评估的标准是什么？
• 问题三：技术选择困惑。你听说过微调（fine-tuning），觉得这听起来很高大上，是不是应该一上来就用微调来提升模型性能？

这些问题，你是否也曾遇到过？别担心，你并不孤单。许多企业在落地 AI 时都会面临类似的困惑。那么 Anthropic 是如何应对这些挑战的呢？

最佳实践一：评估先行，切勿本末倒置

在 AI 应用中，最常见的错误之一就是“先构建复杂流程，最后才想到做评估”。很多企业热情高涨，一上来就投入大量资源搭建复杂的 AI 系统，却忽略了评估的重要性。结果往往是，系统上线后才发现效果不尽如人意，浪费了大量时间和精力。

视频中不止一次强调，评估是指引你走向理想结果的工具。在 AI 应用中，评估不仅仅是事后的检验，更是整个开发过程中的“北极星”。为什么这么说呢？

• 评估帮助你明确目标。在开始任何 AI 项目之前，你需要清楚地知道什么是成功。评估标准能够帮助你设定明确的目标，比如准确率、响应时间、用户满意度等。
• 评估指导优化方向。通过定期评估，你可以及时发现系统的问题，调整优化策略，避免在错误的道路上越走越远。
• 评估是你的“知识产权”。一位专家曾说：“评估就是你们的‘知识产权’。”在 AI 应用的潜在空间中，谁能更快地通过评估找到最优解，谁就能在竞争中脱颖而出。

案例分享：Intercom 的 AI Agent Fin

Intercom 是一家 AI 客服平台，他们的 AI Agent Fin 在业内颇有名气。然而，即使是这样的领先企业，在优化 AI 性能时也曾面临挑战。他们采取了评估先行的策略。

在合作初期，Intercom 与 Anthropic 的技术团队合作，将 Fin 的提示词（prompt）迁移到新模型上，并进行了为期两周的评估测试。结果显示，新模型在多个关键指标上优于 Intercom 当时使用的大语言模型。

随后，双方进行了为期两个月的冲刺，优化了所有与 Fin 相关的提示，确保在新模型上获得最佳性能。最终，Fin 2.0 版本上线后，数据显示，Fin 能够处理高达 86% 的客服需求，其中 51% 无需人工介入。这一成果的取得，离不开前期充分的评估和优化。

这个案例告诉我们，评估不仅是检验成果的手段，更是指导整个开发过程的关键环节。

最佳实践二：权衡“智能度、成本、延迟”，找到最优平衡

在 AI 应用中，企业往往需要在“智能度、成本、延迟”这三个维度之间进行权衡。而 Anthropic 的建议是：很少有企业能够同时在这三个方面都做到极致，因此，明确你的核心需求，找到最适合的平衡点至关重要。

• 智能度：AI 模型的准确性和智能水平。
• 成本：开发和运维 AI 系统的经济成本。
• 延迟：AI 系统响应的速度。

不同的应用场景对这三个维度的要求不同。例如：

• 客服场景：延迟是关键指标。用户希望在 10 秒内得到回复，否则可能会流失。因此，在客服应用中，快速响应比极高的智能度更重要。
• 金融研究员助手：智能度是核心。金融决策需要高度准确的信息，响应时间可以适当放宽。

如何找到平衡？

1. 明确核心指标。根据业务需求，确定哪个维度是最关键的。
2. 设计评估标准。针对核心指标，设定明确的评估标准。
3. 灵活调整。在开发过程中，根据评估结果，灵活调整技术方案，找到最优平衡。

例如，在客服场景中，你可以通过设计“思考中”的动画或引导用户阅读其他内容来缓解延迟问题，同时优化模型以提高响应速度。

常见错误：过早考虑微调，忽视基础优化

在 AI 应用中，微调（fine-tuning）是一个常被提及的技术。许多企业一听到微调，就觉得这是提升模型性能的“灵丹妙药”，急于尝试。然而，Anthropic 警告，微调并不是万能的，而且往往不是最佳选择。

微调的误区

1. 微调不是“银弹”。微调相当于对模型进行“脑外科手术”，会影响模型在其他领域的推理能力。盲目微调可能导致模型在某些任务上表现更好，但在其他任务上表现下降。
2. 微调成本高昂。微调需要大量的数据和计算资源，而且成功率参差不齐。很多时候，企业投入了大量资源，却未能获得预期的效果。
3. 忽视基础优化。在没有充分评估和优化基础模型的情况下，过早考虑微调，往往是本末倒置。

何时考虑微调？

建议，只有在基础优化无法满足需求时，才考虑微调。具体来说：

• 先尝试提示工程（prompt engineering）。通过优化提示词，提升模型在特定任务上的表现。
• 利用其他技术。例如，提示缓存（prompt caching）可以降低成本和延迟，检索增强（retrieval augmentation）可以提高模型的知识覆盖面。
• 评估后再决定。在充分评估后，如果发现基础模型无法满足需求，再考虑微调。

其他实用建议

除了上述最佳实践，Anthropic 还分享了一些其他实用建议，帮助企业更好地落地 AI 应用。

• 构建代表性的评估集。确保你的评估集覆盖了各种可能的情况，包括边缘案例。例如，在客服场景中，不仅要评估常见问题，还要评估无关或恶意的问题。
• 监控和回放。建立完善的监控系统，记录 AI 系统的表现，并定期回放评估结果，持续优化。
• 探索创新架构。例如，AI Agent、上下文检索等，可以提升 AI 应用的智能度和用户体验。

结语

AI 技术的快速发展为企业带来了前所未有的机遇，但同时也伴随着诸多挑战。Anthropic 总结出了一套宝贵的最佳实践和常见错误，帮助企业在 AI 应用的道路上少走弯路。

记住，评估是你的“北极星”，指引你找到最优解；权衡“智能度、成本、延迟”，找到最适合的平衡点；避免过早考虑微调，先从基础优化做起。这些经验，不仅适用于 AI 企业落地，也适用于任何技术创新的实践。

希望本文能为你提供有价值的参考。

视频文稿：构建安全且可解释的大语言模型：Anthropic 的企业实践与最佳实践分享

请与我一起欢迎登台的两位嘉宾：Anthropic 技术团队成员 Alexander Briken，以及 Anthropic 企业 GTM 负责人 Joe Bailey。

Alexander Bricken 00:15

我们来了。比我想象中要亮啊。嗯，很高兴今天见到你们。我是 Alexander Briken，我在 Anthropic 的应用 AI 团队工作。我与客户紧密合作，负责技术实施，同时也会把相关建议反馈给产品研究和模型研究部门。嗯，我现在把话筒交给 Joe。

Joe Bayley 00:34

大家好，很高兴来到这里。我叫 Joe Bailey，负责 Anthropic 的市场拓展（go-to-market）工作。我大约在一年多前加入 Anthropic，所以我看到了我们模型从 2.1 到如今能力的演进。我觉得在日常工作中最令人兴奋的事情之一，就是与那些正在解决真实商业问题的 AI 领导者们合作，而这些问题在一年前看起来还近乎不可能解决。所以我对这一切发展如此迅速感到非常振奋。

Joe Bayley 00:58

好的，今天我们会做一个简短的概述，介绍我们是谁、我们的使命，然后重点谈一下如何实施 AI、一些最佳实践以及常见错误。其实我和 Alex 并不只是依赖我们自己的经验，我们还和很多同事讨论过。所以我们讲的内容都是基于数百次与客户的真实互动。我们希望其中有一些可操作的见解可以带给各位。

Joe Bayley 01:27

太棒了。那么什么是 Anthropic？我们是一家专注 AI 安全和研究的公司，致力于构建世界上最出色、最安全的大语言模型。公司由一些 AI 领域的顶级专家在几年前创立。自成立以来，我们不仅发布了多次前沿模型的迭代，也在安全技术、研究和政策的前沿不断探索。

Alexander Bricken 01:52

我把话筒交给 Alex，让他来谈谈我们目前的主力模型。

Alexander Bricken 01:55

好的。你们中的一些人也许已经知道，我们在去年十月底发布了最新的模型 Sonet 3.5 new。开发者可能对它有所熟悉，因为如果你是程序员，Sonet 其实是代码领域表现领先的模型之一。比如在像 Swe Bench 这种针对于代码的测试评估中，Sonet 仍位居排行榜的前列。我就不展开谈具体的评估细节了，让我们继续往下看。

Alexander Bricken 02:24

嗯，所以呢，除了 Joe 刚才提到的研究方向，我们还在很多不同领域进行着研究，包括模型能力、产品研究和 AI 安全，这些研究之间相互交织。我们最大的差异点之一，可能就是模型可解释性（interpretability）。说白了，就是对模型进行“逆向工程”，试图弄清它们究竟是如何“思考”，以及为什么这样“思考”。同时，我们也在探索如何根据不同的用例，将模型引导到正确的方向。

让我们具体谈谈这个。关于可解释性研究，目前还处于早期阶段。正如你所见，这是一条很长的时间线，我们可能只走了前半段，甚至只有前 25% 的进度。但我们的确在分阶段进行，这些阶段相互递进，比如：

• 理解（即把握 AI 的决策过程）
• 检测（识别特定行为并打上标签）
• 引导（对 AI 的输入进行某种方式的影响）
• 最后是可解释性本身

而这正是为企业带来价值的关键。当我们展望未来，可解释性会在提高 AI 安全性、可靠性和可用性方面带来极大的提升。具体来说，我们的可解释性团队会研究模型层面的特征激活，并已经发布了相关研究论文，例如《towards monoticity》和《scaling monoticity》，强烈推荐大家去看看。

随着技术发展到检测层面，比如说，我们可以更好地识别模型的具体思维模式和行为，甚至发现可能深藏在模型内部的“潜伏代理”（sleeper agents），以保证安全性。举个例子，想象你问模型：“今天 NBA 比赛的比分是多少？”然后它回答：“哦，斯蒂芬·库里得了 30 分。”这就会激活特征编号 304——“著名 NBA 球员”。其实这是在模型回答所有涉及著名篮球运动员的问题时，一群神经元会以可识别的模式激活，而不仅限于斯蒂芬·库里。

也许你们听说过“Golden Gate Claude”这个实验。那就是我们在模型上进行引导的例子，通过提高“golden gate”方向上的特征激活，于是每当你问它“我应该把卧室刷成什么颜色？”时，Claude 就会回答：“你应该刷成金门大桥一样的红色，或许还可以加些桥柱之类的元素。”

Joe Bayley 05:04

我把话筒交给 Joe，让他谈谈我们所合作的一些客户。

Joe Bayley 05:07

好的，我们会从两个方面来介绍：一方面是早期沟通的情况，另一方面是一些做得很棒的客户案例。首先，大家都知道目前市场上有大量的噪音和热议，这非常好。但我们经常建议客户，回归核心：AI 能如何帮助你们解决产品的核心问题？我们也与许多“AI 原生”或 AI 初创公司合作，他们也是从这样的思路来设计产品。

而且我们希望大家能超越“聊天机器人”和“摘要”这类常规功能。这些功能当然可能有用，但也许你应该思考更大的应用场景，比如在什么地方需要更大的投入。举个例子（请再点击一下，这个幻灯片有个动画）：

假设你是一个针对员工入职和技能提升的平台。你所解决的客户需求是：帮助用户更快上手（ramp up），并且帮助他们在职场中晋升，比如需要练习演讲技能或想成为一名管理者。 因此，如果仅仅做个总结功能或提供一个简单的聊天机器人回答他们的问题，可能还行，但未必能从根本上解决问题。换一种思路：

• 你能否为每个员工提供高度个性化的课程内容？
• 如果有人学得很快，能否根据他们的学习进度动态调整课程难度？
• 如果某人是视觉型学习者，是否能让 AI（或者说大语言模型）自动为他们生成更加可视化的内容？

想想这样做是否比简单的摘要或者问答机器人更能解决核心问题。这些都值得思考。

然后我们再看一些真正做得很出色、在行业里取得领先成果的客户案例，他们充分发挥了自身领域专长并结合我们的模型。这里的例子涉及各行各业，比如税务、法律、项目管理，他们在用 AI 大幅提升客户体验，让产品更易用、更可信。从而极大改善了用户体验，而不只是一种“锦上添花”的功能。他们也获得了高质量的输出。比如在税务场景中就不能搞“幻觉”（hallucination），那可能会带来各种麻烦。所以我们非常高兴看到这些在业务关键工作流程中使用 AI 的成功案例，让客户和企业都受益。

Alexander Bricken 07:58

好的，这个我可以来讲。往下看。

Joe Bayley 08:01

那么，开始吧。我想快速介绍一下，我们有什么产品？主要有两个：我们的 API，以及面向工作场景的 Claude for Work。API 适用于想在自家产品或服务中集成 AI 的企业，而 Claude for Work 则赋能全公司在日常工作中使用 AI。

我们还与 AWS 和 GCP 建立了合作伙伴关系，你可以在 Bedrock 或 Vertex 上使用我们的前沿模型，也可以在你现有的环境中部署这些应用，无需管理额外的基础设施。所以，这几乎没有什么进入壁垒，还能充分享受这两全其美的方案。接下来我们会提到一些支持服务方面的内容。其实，无论你通过哪一个平台接入我们的模型，我们都会提供相应的支持，这点需要特别强调。

Alexander Bricken 08:59

好的。既然我们谈到了一些客户案例，接下来看看我们在 Anthropic 是如何帮助客户成功的。先简单介绍一下我所在团队的职能。正如之前提到的，我们处在产品研究、客户对接以及公司内部研究的交汇点。我们专注为客户在技术上提供支持，比如如何设计架构、如何做评估、如何微调 Claude 提示（prompt）以发挥模型的最好效果等等。然后我们也会把与客户合作中得到的见解反馈到产品和研究团队。

这其中有一些对外发布的成果，比如我的同事 Barry 发布的《Building Effective》研究论文（他会在明天做演讲），以及我们推出的 Model Context protocol，这是一种开源协议，让语言模型可以与数据源进行交互。我的同事 Mahesh 会在周六就此举办一个工作坊。总的来说，我们非常重视对客户的技术支持。

而我们团队尤其会深入那些在使用 Claude 的过程中遇到特殊技术挑战的客户，比如在某个高度细分领域需要将最新研究成果或提示工程技巧落地。一般来说，我们会与客户一起启动一个短期冲刺，帮助他们解决难题，比如 LLM ops 架构、评估标准设计或怎样在提示中加入特定策略等等。然后再把这些成果放到 AB 测试环境里验证，最后再进入生产环境。在这个过程中，评估（evals）非常重要，我稍后再多说一些。

现在，我先把话筒交给 Joe，让他介绍一下我们是怎么与 Intercom 合作的。

Joe Bayley 10:56

好，我觉得这正是对 Alex 所说内容的一个很好补充。对不熟悉 Intercom 的朋友来说，Intercom 是一家 AI 客服平台，拥有一个名为 Fin 的 AI Agent。就很多指标来看，Fin 都是业内最好的之一，而这个市场也相当竞争。当我们和他们交流时，他们分享了对未来客服和 AI Agent 的愿景。我们觉得基于我们模型的能力，应该能显著提升他们一些关键指标。

我们先做了一个为期两周的小测试，我们的应用 AI 团队负责人和他们的数据科学团队合作，把他们最难的 Fin 提示词放到我们的 Claude 模型上做了比较，并且帮助他们设计了针对 Claude 的提示。结果在头两周就很不错，这让我们继续推进了一个大约两个月的冲刺，优化所有与 Fin 相关的提示，以便在 Claude 上获得最佳性能。结果表明，Anthropic 模型的表现优于他们当时使用的大语言模型。

值得一提的是，Intercom 的定价模式是基于“问题是否解决（resolution）”，所以大家都希望模型真的能帮助客户解决问题，而不是敷衍了事；我们都体验过那种只会打太极的客服机器人吧。最后，在两个月后，他们决定采用 Anthropic，也就是 Fin 2。你可以在网上找到相关信息。他们给出的数据非常惊人：最多可处理多达 86% 的客服需求，其中 51% 无需人工介入。我们的支持团队也尝试了 Fin，并且也得到了类似的解决率。

同时，Fin 也变得更加“有人情味”，比如可以调整语气和回答长度，并且还能很好地识别与各种政策相关的问题（例如退款政策）。因此，这对他们来说是一次功能层面的拓展。我们很高兴能与他们继续合作，让他们在这个领域保持领先。

Alexander Bricken 13:00

是的，另外最近我还看见 Claude 在推特上的很多人那里扮演了某种“心理咨询师”的角色，我觉得这是它表现个性的一个有趣例子，哈哈。

好的，让我们进入下一部分：那么让我们来谈谈 go-to-market 团队在实际工作中看到的一些最佳实践和常见错误。首先是测试和评估（testing & evaluation）。相信大家今天和明天都会多次听到这两个词。

常见错误：

1. 先构建复杂流程，最后才想到做评估有些人会先构建一个非常复杂的流程，花很多时间搭建好架构，最后才想到做评估。这其实是反过来的。评估（evals）才是指引你走向理想结果的工具。为什么？因为你不知道你设计的工作流是否真的高效，只有通过评估才能验证。
2. 只靠“直觉”或缺乏代表性样本有的客户会因为数据问题，一时搞不清怎么做评估；或者有的客户干脆只靠“直觉”，测试了几次觉得“好像不错”，然后就盲目自信了。但这里要问：你测试的样本是否具有代表性？样本量足够吗？是否可以在统计上证明这个结果？如果进入生产环境后，有成百上千种情况下出现差错，你之前的几次测试可能完全捕捉不到这些边缘案例。

因此，我会让大家把用例（use case）想象成一个潜在空间（latent space）。就像有一片潜在空间，而你在里面不断尝试不同方法，比如提示工程（prompt engineering）、提示缓存（prompt caching）等等，这些都会改变模型的注意力机制，导致结果大不相同。唯一能确定是否真的有效的方式就是实证测试，也就是评估。

所以评估非常关键，但很多人意识不到。在某种程度上，我甚至会告诉客户，评估就是你们的“知识产权”，如果你想在某个领域中战胜竞争对手，那就要在这个潜在空间里通过评估更快地找到最优解。要做到这一点，就需要有完善的监控（telemetry）来回放测试结果；需要确保你收集了有代表性的测试用例，比如之前提到客服场景，可能会遇到一个小孩上来就问“我在《我的世界》里怎样打僵尸？”完全和产品无关，但这有可能发生，所以也要把这种问题纳入评估，看看模型会怎样处理。

Alexander Bricken 17:52

然后是如何确定度量指标（metrics）。很多情况下，我们需要在“智能度、成本、延迟”这三者之间权衡。大多数组织只能重点优化其中一到两个，很难同时把三者都做到极致。不同的用例，其侧重点也不同。

• 比如做客服，你肯定希望顾客 10 秒内能收到回复，超过 10 秒他就走了，然后可能还会到处吐槽你的服务。
• 但是如果你在做金融研究员的助手，可能等待 10 分钟也无所谓，毕竟后面要做的是重要的资本分配决策。

所以不同的决策时效性和重要性决定了你怎么在这三者之间取舍。有时用户体验（UX）也很重要，比如你做客服，可以在等待时显示一个“思考中”的动画，或者把顾客先引导到其他页面阅读一些内容，总之有各种方式来稍微掩盖或分担延迟问题，但你还是要清楚自己的关键指标是什么，并据此去做技术或设计层面的优化。

最后是微调（fine tuning）。很多客户一上来就说“我们要做微调！”我心想，又来了……微调并不是万能的，它是有成本的，而且很多人不知道这个成本在哪。微调相当于对模型做“脑外科手术”，会影响它在其他领域的推理能力。所以我们一般建议先尝试其他方法。

很多情况下，客户在评估集都没准备好的情况下就嚷着要微调，但你要先知道什么才是成功，如果只有微调才能让你在某个特定领域达到标准，那么再考虑也不迟。不要一开始就面面俱到。另外，微调的成功率也参差不齐，你需要有理由相信微调带来的收益能够覆盖它的成本和难度。所以我们建议，不要让微调成为阻碍你先行探索的绊脚石，可以先用基础模型和提示工程来做初步验证，等确实需要微调时，再把它接入。

还有很多其它方法可以尝试，比如我们在这里列出了一些可能的思路和特性。我不一一细讲了。简单来说，除了最基础的提示工程外，还有各种架构思路，例如提示缓存（prompt caching）可以在保证模型推理智能的前提下，大幅降低成本、缩短响应时间；也可以用更加高效的检索机制（contextual retrieval）来让模型更快速地提取所需信息；再比如一键生成引用（citations）之类的功能，这些都能改善你用模型的方式。或者在架构层面设计 AI agent 等方案。我的同事 Barry 明天会有更多相关内容的分享。

总的来说，这些方式都可以帮你在不同需求里找到合适的平衡点，而不一定非要上来就做微调。

Alexander Bricken 20:35

嗯，大概就到这里了，谢谢各位的时间。待会儿我们会在剧院层的休息区回答问题。Joe，你还有什么想补充的吗？

Joe Bayley 20:37

没有了，谢谢大家。

Alexander Bricken 20:37

好的，谢谢，干杯。