> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Claude Code实战惊人但不完美
- URL: https://www.hubwiz.com/blog/claude-code-impressive-in-practice-but-not-perfect/
- Published: 2025-03-28T01:58:16.000Z
- Updated: 2025-03-28T01:59:15.000Z
- Description: 在CodeConcise中添加对新编程语言的支持是一项重要但耗时的任务；我们想看看是否可以利用Claude Code来帮助完成。然而，尽管初始结果令人印象深刻，但它并不总是成功的，正如你将看到的……
- Author: admin
- Tags: TOOL, CLAUDE CODE, ANTHROPIC, #Import 2026-10-14 14:41

我们一直在尝试使用Anthropic最近发布的编码助手Claude Code，它被集成到我们为Thoughtworks开发的工具CodeConcise中，用于理解遗留代码库。

在CodeConcise中添加对新编程语言的支持是一项重要但耗时的任务；我们想看看是否可以利用Claude Code来帮助完成。通常，这需要一对开发人员花费两到四周的时间，但Claude Code和一位主题专家（SME）只用了半天时间。然而，尽管初始结果令人印象深刻，但它并不总是成功的，正如你将看到的……

## 1、Claude Code是什么？

Claude Code是由Anthropic开发并发布于2025年2月24日的AI编码助手。它是一个所谓的“监督式编码代理”的例子。这些工具可以在软件开发工作流中执行相对复杂的任务，有时甚至可以自主完成。

目前大多数最知名的监督式编码代理都是通过IDE集成到工作流中的：它们包括Cursor、Cline、Windsurf。（GitHub Copilot的自主工作流目前处于预览阶段，但这种功能很快可能会广泛可用。）Claude Code与这些工具的不同之处在于它是基于终端的界面（开源的代理工具Aider和Goose也通过终端而不是IDE运行）。通过终端工作使其更容易将代理集成到更广泛的生态系统中，而不仅仅局限于IDE。

## 2、Claude Code vs.其他编码代理

鉴于这一领域的快速发展，必须警告的是，任何工具之间的比较都应谨慎对待，因为它们都在快速变化。现在的一次性比较可能在几个月——甚至几周后就会过时。不过，有一些值得注意的地方：

- Claude Code类似于Cline和Aider，需要插入LLM的API密钥。你很可能会访问Claude-Sonnet系列模型之一，因为这些模型目前在编码方面最为有效。相比之下，Cursor、Windsurf和GitHub Copilot是订阅产品。
- Claude Code与Cline和Goose一样，可以与Model Context Protocol（MCP）集成，这是一种连接LLM与数据源的开放标准。

Claude Code当前的表现和实用性实际上取决于它在协调代码上下文、提示模型以及与其它上下文提供者集成方面的表现如何。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-569.png)

## 3、我们为什么对Claude Code感兴趣？

我们对AI辅助编码和自主AI很感兴趣；自然地，Claude Code的发布引起了我们的注意。

虽然潜在的应用场景非常广泛，但我们特别想看看Claude Code是否能帮助我们解决在开发生成式AI代码发现和智能工具CodeConcise时遇到的一个具体挑战：添加对新语言的支持。

到目前为止，支持仅在需要时添加。然而，我们假设预先扩展对大多数编程语言的支持可以极大地提高CodeConcise的有效性。这不仅是一个技术效率的问题：如果我们花更少的时间在CodeConcise中为一种语言构建支持，那么我们可以把更多的时间投入到其他增值工作中。

然而，构建支持并不是一件简单的事——我们认为Claude Code或许可以帮助我们。由于实验与Claude Code的发布同时进行，我们迅速进行了尝试……

## 4、CodeConcise的一些技术背景

为了理解我们是如何用Claude Code进行实验的，了解CodeConcise的工作原理是有帮助的。CodeConcise利用抽象语法树（AST）不仅分解代码库并提取其结构，还当LLM用于总结和解释代码时导航这些代码库。

更具体地说，CodeConcise要求特定于语言的具体实现一个名为IngestionTool的抽象类。该实现旨在返回从代码中提取的节点和边列表，然后填充知识图谱。到目前为止，我们自己的实现利用AST来实现这一点。随后，我们有针对这种图结构的语言无关遍历，这些遍历使用LLM从代码中提取的信息丰富了图谱。这个知识图谱然后可供应用程序使用代理和GraphRAG向用户提供代码的见解。

虽然LLMs是分析代码库的强大工具，但其中一个缺点是，每当我们要支持一种新的编程语言——并从其AST中提取相关部分时，我们需要编写新代码以生成和解释这棵树。这需要时间；通常需要一对开发人员花费两到四周的时间。我们需要找到相关的代码库示例，构建一套自动化测试，并对代码库进行更改以支持新语言。这就是为什么我们只在必要时才这样做。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-571.png)

## 5、Claude Code迄今为止表现良好的地方

### 5.1 成功：请求Claude Code识别必要的更改

首先，我们请Claude Code为我们识别添加Python支持所需的更改。这对已经在代码库上工作了几周的开发人员来说可能相当简单，但对于完全新手来说却非常有价值。

![](https://www.hubwiz.com/blog/content/images/2025/03/image-572.png)

![](https://www.hubwiz.com/blog/content/images/2025/03/image-573.png)

有了代码及其旁边文档的访问权限，Claude Code产生了惊人的结果。它准确地识别出所有需要支持Python的更改。此外，建议的代码表明，代理不仅检查了我们在过去开发的其他摄入工具，还考虑了我们在询问的新代码中使用的模式。

### 5.2 局限的成功：请求Claude Code自行实施必要的更改

我们给Claude Code的第二个提示是要自行实施建议的更改：

> ***我需要构建一个新的工具，将Python代码加载到CodeConcise中。请完成这项任务并进行测试。***

它花了三分钟多一点的时间自主完成了工作。所有更改都在本地实施，包括测试。Claude Code建议的所有测试都通过了，但当我们使用CodeConcise将其源代码加载到知识图谱上并运行我们自己的端到端测试时，我们发现了几个问题：

1. 文件系统结构本身没有包含在图谱中。
2. 连接节点的边不符合CodeConcise的模型。例如，调用依赖关系缺失（后续的部分如理解管道将无法像预期那样遍历）。

### 5.3 AI辅助编码中反馈循环的重要性

这个实验很好地提醒了我们，在使用AI帮助编写代码时，拥有多个反馈循环是多么重要。如果没有测试来验证集成是否真正有效，我们不会在更晚的时候才发现这个问题。这可能会既具有破坏性又代价高昂；开发人员和代理都会失去对正在进行工作的上下文。

### 5.4 这教会了我们什么？

尽管现有解决方案架构良好，但平均需要一对开发人员和一位主题专家花费两到四周的时间来为新语言构建支持。有一位主题专家和Claude Code一起工作，只需几分钟就能为这个特定用例生成代码，并且只需几个小时就能验证它。

## 6、哪些不成功？

### 6.1 完全失败：请求Claude Code帮助我们添加JavaScript支持

我们对实验结果相当满意，因此我们尝试了相同的方法来处理JavaScript：

> ***我希望你添加一个用于JavaScript的摄入工具。我已经在其中放入了lexerbase和parserbase供你使用。请像在其他地方一样使用stageobserver，并像tsql加载器那样使用lexer和parser的访问者模式。***

第一次尝试时，它试图使用JavaScript的ANTLR语法来实现。我们无法让语法工作（这超出了Claude Code和CodeConcise的范围），所以我们无法验证代码是否真的有效。

第二次，我们提示Claude Code并要求它使用treesitter。我们觉得运气不太好，它开始使用不存在的库。同样，我们无法验证生成的代码。

第三次也是最后一次尝试，我们要求它尝试另一种方法。它决定使用正则表达式模式匹配来解析代码。

那么，它成功了吗？*没有：代码引用了根本不存在的内部包。*

![](https://www.hubwiz.com/blog/content/images/2025/03/image-574.png)

显然，代理缺乏对生成代码的更强验证机制。就好像它错过了简单的单元测试这样的反馈一样。

这并不是什么新鲜事；事实上，我们已经多次观察到其他编码助手也有类似的情况。

我们想知道第一次使用Python时是否只是运气好，所以我们要求它用C语言做同样的事情。结果与Python的情况大致相同，尽管它采用的方法是使用正则表达式匹配，而不是更可靠、基于AST的方法。

## 7、结束语

上述实验解决了一个非常特定的用例问题，因此重要的是不要得出不恰当的结论。然而，仍然有一些重要的收获值得分享：

1. 输出可能非常不一致。当要求Claude Code实现Python和C语言的解析工具时，它产生了令人惊叹的结果，但当要求它为JavaScript做同样的事情时，结果却非常差。
2. 编码助手的输出取决于多个因素：
3. **代码质量。** 我们一直认为对人类来说高质量的代码很重要，对于代理也是如此。这意味着当代理处理编写良好、模块化且干净的代码时，这些代码设计时考虑到了关注点分离并且有文档记录，那么我们就最大化了它产生高质量输出的机会。
4. **库生态系统。** 构建Python解析器到CodeConcise中是否更容易，因为Python（CodeConcise构建所依赖的语言）已经提供了将Python代码转换为抽象语法树(AST)的标准模块？我们的假设是，虽然代理需要一套良好的工具来执行它们所做的决策，但其输出的质量也取决于它们能否使用设计良好、广泛使用的库来解决问题。
5. **训练数据。** 已知大型语言模型（LLMs）以及由此扩展的AI代理，在其原始训练数据集中包含大量编程语言相关数据的情况下，会产生更好的代码。
6. **大型语言模型。** 由于代理建立在大型语言模型之上，其性能直接受到底层模型性能的影响。
7. **代理本身。** 这包括提示工程、工作流程设计以及其可用的工具。
8. **人机协作。** 很多时候，当我们看到人和代理一起工作时，我们会得到两者最好的结合。此外，有经验的开发者通常知道一些技巧，可以引导他们完成工作并最终产生更好的结果。

Claude Code展现了许多潜力，看到另一个可以在终端使用的监督式编码代理是非常令人兴奋的。Claude Code肯定会不断发展——就像整个领域一样——我们期待着探索如何继续将其整合到我们的工作中。

---

原文链接：[Claude Code saved us 97% of the work — then failed utterly](https://thoughtworks.medium.com/https-www-thoughtworks-com-insights-blog-generative-ai-claude-code-codeconcise-experiment-b3b1f31d718c?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处