大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



看到一篇非常的内容，想给大家分享一下在这支视频中，我将分享使用ClaudeCode的经验，探讨它如何显著提升团队开发效率，以及与Cursor相比的优势。目前关于ClaudeCode的中文内容较少，很高兴能结合自身使用体验为大家提供参考。此外，我将演示PromptX的增强系统，它能有效解决包括ClaudeCode在内的部分AI工具在实际开发中的痛点问题。

首先简要介绍ClaudeCode的安装环境。安装过程非常简单，但目前仅支持Linux和MacOS系统。Windows用户需借助WSL或虚拟机运行。安装只需在终端运行命令即可。部分用户可能遇到网络连接问题，这源于某些不可抗力因素。除了使用全局代理如Term Mode外，我会通过修改ClaudeCode的配置文件来强制代理流量，这样会更加稳定。接下来将演示这一方法：在配置文件中添加代理地址（如10808）后即可正常使用。

最后谈谈定价结构，我们仅关注个人使用场景。个人用户有两个可选计划。

Pro计划每月17美元，Max计划起价100美元。我目前使用的是Max计划。

Pro计划适合非全职开发者或非每日使用的用户。理论上，Pro和Max计划均支持无限使用，但官方会根据使用频率和资源负载设置软性限制，通常每5小时重置一次额度，月使用上限为50次。

具体限制可能有所浮动，但根据我的个人经验，正常使用Max计划几乎不会触及额度限制，除非频繁调用Alpas模型。

Claude Code目前支持Claude4 Sonnet和Claude4 Alpas两种模型。虽然不像Cursor等AI IDE提供多种模型选择，但在开发场景下，这些模型已足够强大。

那么，究竟是什么原因促使我从Cursor转向Cloud Code呢？在过去的几天里，我们团队的大部分成员都已从Cursor迁移至Cloud Code。主要原因在于，Cloud Code在各方面表现都显著优于Cursor。即便使用相同的模型，Cloud Code的响应速度更快，网络连接更稳定，错误率更低，且上下文窗口更大。此外，它不会像Cursor那样频繁出现压缩上下文的情况。可以说，Cloud Code提供了一个更简洁、高效且可靠的开发环境。

尽管Cloud Code对不熟悉终端操作的开发者不够友好，且订阅价格较高，但其带来的生产力提升足以覆盖这部分成本。因此，我们团队愿意为其付费，这确实是一种开发效率的飞跃。

接下来，我将完整演示如何使用Cloud Code辅助开发，包括如何上手新项目、发现潜在问题、提出修改建议，以及让Cloud Code协助修复或重构代码。希望这个演示能对大家有所帮助。

我的系统是Ubuntu。首先打开终端，进入工作目录：Distop/Developer/Java/LexilasLibrary。随后直接启动Cloud Code。由于已安装并配置好代理，这里我们选择英国节点启动——在实际测试中，其他地区的节点可能出现问题，而英国节点最为稳定。

成功启动Cloud Code后，打开IDE并通过Cloud Code绑定。当IDE成功连接后，我们可以复制代码片段进行交互。例如复制某个文件内容粘贴进去，右下角会显示”Wireline Selected”表示选中行。发送这段代码时，会连同所在类一起传递。根据JetBrains IDEA的反馈，它能够识别所选类并提供相应帮助。

接下来我们需要分析这个项目。由于刚接触该项目，可能对某些部分不太熟悉。老板要求我们优化Player模块，并对其进行评估。现在切换到Claude Code，这里使用PromptX作为辅助框架。PromptX能显著提升Claude Code的上下文理解能力，使其能够记住重要信息，如项目结构和**实践，避免每次都要重新分析。此外，它还提供多种角色选择功能来增强Claude Code的专业能力。

我们可以询问预设角色。系统显示Claude Code的官方3LM已加载，PromptX也已成功加载。PromptX提供以下角色：Java后端开发者、产品经理智能助手、测试角色等。我们选择Java后端开发者角色（输入3即可激活）。

在查看MCP时，可以看到已连接JetBrains的MCP。这意味着系统能够通过MCP访问所有项目文件和相关警告信息。接下来让系统熟悉Player模块：我们直接复制粘贴Player模块的路径，要求其阅读源码并进行评估。

需要注意的是，Claude是一个混合模型。对于复杂任务，必须明确指示其进行深度思考，否则可能不会主动分析。现在系统已开始思考（显示Thinking状态）。放大终端窗口后，系统识别出这是一个标准的Java项目，从目录结构判断属于玩家数据管理模块，并进行了详细的内容分析。

可以看到，他表示需要先探索项目结构，阅读源码并理解模块功能，从架构设计、代码质量和设计模式等专业角度进行评估。在实际使用Claude Code时，相比Cursor有一个显著优势：它会主动进行思考，并创建有用的待办事项清单来规划目标，从而更快地满足我们的需求。仅通过阅读部分源码，它就能提供这些分析。

接下来，我们需要指示它继续逐行阅读代码，并评估整个项目。从已读取的内容来看，它查看了配置文件（误认为是Mainware文件）、测试类、工厂类、RedditStream接收器，以及主要服务类、数据类和主类。基于这些文件，它已完成了初步评估，涵盖架构设计、代码质量、性能优化、容错机制、测试覆盖、生产就绪度和可维护性等方面。

在检查过程中，发现存在代码重复问题。例如ParaLauncher模块中的RomDebugTest方法，与其他模块的测试代码高度重复。我们可以将这段代码复制到Claude Code中，它会自动标注代码来源。然后，我们要求它不要立即修改代码，而是先在GitHub上提交Issue。具体操作是使用已配置好的GitHub CLI工具，参照最近的Issue格式来提交问题报告。

因此，他使用了一些命令来查看最近的Issue。现在，他提出要创建一个Issue来解决RomDebugTest方法的重复问题。我们打开浏览器，查看他是否提交了这个Issue。

他酝酿许久，终于提交了一个Issue。他甚至花了五分钟才完成这个Issue的提交。

让我们评估这个Issue的质量。可以看出他的描述相当详细，我们可以通过翻译来进一步了解。这是一个适合新手处理且需要加强的Issue，优先级为中等。主要内容是将通用测试逻辑提取到基础模块中。目前每个模块启动器都实现了几乎相同的RomDebugTest方法，存在代码重复问题。他以PlayerLauncher为例，指出了代码重复和维护挑战，并提供了解决方案建议，包括模块解耦方案。

技术实现部分详细说明了分阶段实施计划： - 第一阶段的任务 - 第二阶段的任务 - 功能增强方案 - 需要修改的文件列表

此外，还阐述了改进后的预期收益，整体方案较为完善。

接下来，他创建了一个Ticket来分析模块中现有的测试基础设施。完成Ticket创建后，他计划开发一个工具类和必要的接口。我们直接授权他执行这些修改，无需再征询确认。此时系统已开启自动接收模式，可以自动采纳所有更改。

界面右下角显示当前上下文压缩率仅为30%。这是因为刚才让他分析了整个项目并提交了Issue，消耗了大量上下文资源。接下来，我们将使用PromptX来演示如何优雅地解决上下文占用问题。

可以看到，他已经完成了大部分工作，并在Foundation模块中添加了基础测试基础设施。随后，他使用Gradle进行构建。在日常使用Claude Code时，我们建议指导Claude Code自行完成构建，这有助于发现项目中的所有错误并逐一修复。

在构建过程中，他发现了若干错误并逐步修复。目前，他已成功修复Foundation模块中的错误，并测试Player模块能否正常构建。编译成功后，他开始对比重构前后的代码行数差异，并创建测试用例来验证新编写的工具类。

接下来，他准备更新Gradle Hub Issue，但我们建议暂缓此操作以便自行检查。可以看到他的代码编写非常详细且工整。这里包含一个接口定义、工具类实现以及测试代码。虽然测试代码因缺少依赖而报错，但这并非重点。编译已通过，总代码量为283行。

测试结果显示所有用例均已通过，格式符合预期。测试报告包含通过数量、总测试数及耗时等信息。需要注意的是，这些测试不包含压力测试，且当前报错是由于分布式环境下的锁竞争性能测试所致。

在提交代码前，我们需要进行人工审核。发现部分代码风格与习惯不符，已手动调整。确认接口定义无误后，重新格式化代码。现在所有工作均已完成，可以提交更改并关闭相关任务。

Claude Code还有一个非常实用的功能。

当你让它自行提交更改时，它会自动添加自己的署名。这里可以看到它先检查了差异，然后将所有更改添加进去。虽然它署上了自己的名字，但这并无大碍。

它发现医学分支虽已关闭，但命令中存在一些错误，随后进行了提交。现在我们来检查医学分支是否确实已关闭，并分析刚才出现的错误原因。

代码可能存在一些问题，但目前已修复完成。我们可以进一步调整。

当前衣袖关闭功能的信息存在错误，请修复。系统自动添加了一条更正评论来解决该问题。随后，系统在下方补充了修正内容，我们将其删除。现在系统确认衣袖关闭信息已完整。

系统指出之前的评论存在格式问题，并提供了更正后的信息。实现代码已精简，新增了技术组件和技术模块的API方法。效果良好，系统已按指示提交了署名信息。

查看提交记录显示：重构通用测试执行逻辑并提取至基础模块，共计修改200行代码。虽然问题较为简单，但仍存在一些细微问题需要完善。

我们刚刚发现不仅是配合模块存在重复代码，该模块本身也有重复。因此需要明确指出复制粘贴的问题。不仅仅是配合模块，annotation模块也存在类似情况。

各位如果仔细观察，会发现我在编写Javadoc时习惯仅使用一个标签，而不会特意添加结束标签。AI在编写Javadoc时很好地模仿了我的风格，比如这里没有使用句号，也没有结束标签，完全符合我的写作习惯。

接着AI自动进行了update和deduce检查，确认了模块间的依赖关系。可以看到上下文即将超载，因此我们暂停操作，要求AI保存当前经验记忆，并说明已完成的工作、发现的新问题以及后续任务。AI还详细说明了技术要点和重构模式。

由于上下文即将超载，我们使用clear命令清除上下文。然后指示AI切换到Java后端开发者角色，回忆之前的工作。PromptX的配置文件将保存在项目目录下。由于当前PromptX存在一些小问题，需要手动指定记忆文件路径让其读取，以便继续未完成的任务并进行深度思考。

值得一提的是，此前我们只让AI深度思考过一次，即在读取整个项目时。即便如此，AI的表现依然非常出色，这一点与Cursor相比差异明显。

现在AI已成功切换到Java后端开发者角色，并读取了记忆文件。虽然记忆系统显示暂存内容存在一些小bug（开发者后续会修复，我已就此在GitHub提交了issue），但所有launch操作都已完成。AI正在更新构建状态并验证编译是否通过，它已自动调用了maven命令。

应使用 Gradle 的 shadowJar 进行编译。Ubuntu系统提示home目录磁盘空间不足，建议清空回收站。在编译过程中，可查看home目录的空间使用情况。当前home空间已占用97%，仅剩2.6%，主要占用来自桌面文件和当前录制的视频文件，共计11GB。

重构完成后，提交所有更改并关闭相关issue。目前已经同时运行了两个 ClaudeCode 实例，这表明可以并行运行多个AI代理，分别负责前端开发、后端开发、测试和运维工作。

系统已完成宝贵记忆的传承，并展示了深度思考的能力。

本次提交是否包含ClaudeCode？我确认存在。此外，当前仅提交了代码但尚未推送。

对吧。我们推送一下。

确实如此。在此过程中，我们成功完成了从熟悉项目、发现问题、提出issue，到最终解决问题并关闭issue的完整流程。

整个流程的所有任务均已完成。当前代码库更加简洁、一致且易于维护。