Claude Code 实战：从真实需求重新拆一遍

学习实战派

153人浏览 · 2026-07-09 09:05:28

学习实战派 · 2026-07-09 09:05:28 发布

聊《Claude Code 实战：一次新的项目切入》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

最近团队里开始讨论把 AI 辅助编程从“个人提效神器”推向“团队协作规范”。以前我总觉得 Codex 或者 Claude Code 这种工具就是让我少敲几行样板代码，但这次接入一个遗留的 Java 微服务项目时，我发现事情没那么简单。如果你也正准备在正式项目里引入 Claude Code，别急着把它当 Chatbot 用，我们先聊聊我是怎么被它的“过度自信”打脸，又是怎么把它驯服成靠谱结对伙伴的。

Claude Code 适合做什么：从“猜”到“读”的转变

文章插图 1

很多人用 Claude Code（或类似 CLI 工具）最大的误区是：直接扔给它一个模糊的需求，让它“搞定它”。在个人 Demo 里这行得通，但在企业级项目里，这是灾难的开始。

Claude Code 的核心优势在于它的上下文窗口和对大型代码库的理解能力。它不是简单的补全助手，而是一个能读取整个仓库结构的 Agent。

我的建议是：
1. 适合：理解现有架构、生成复杂的测试用例、重构特定模块、将自然语言需求转化为具体的 PRD 技术细节。
2. 不适合：从零构建复杂的全栈应用、处理极度依赖业务逻辑且缺乏文档的黑盒系统、需要即时反馈的高频迭代。

我第一次尝试让它重构一个订单服务时，直接让它“优化这段代码的性能”。结果它改了一堆我不认识的函数，甚至引入了不必要的依赖。后来我换了个思路，先让它“阅读并解释当前模块的职责”，再基于解释去改，准确率提升了不止一个量级。

代码库阅读：建立全局视角

文章插图 2

在处理遗留项目时，最难的不是写新代码，而是搞懂旧代码。Claude Code 在这里的价值极大，因为它可以一次性 claude code --read 整个项目结构。

比如，我想搞清楚为什么某个接口响应慢。我不需要手动去翻 Controller -> Service -> DAO，我只需要问它：“找出 /api/orders/{id} 接口的完整调用链，并标出可能的瓶颈。”

它会返回类似这样的分析：

$ claude "请分析 /api/v1/users 接口的调用路径"

> Analyzing codebase...
> Found entry point: UserController.listUsers()
> Call chain:
>   1. UserController.listUsers -> UserService.findAll()
>   2. UserService.findAll -> UserRepository.findByStatus()
>   3. UserRepository -> JPA Query Execution
> Potential Bottleneck: UserRepository lacks pagination, loading all records into memory.

你看，它不仅是读，还在思考。但这种思考依赖于它对你项目规范的熟悉程度。所以，先喂它规则。在项目根目录创建一个 .claude/settings.json 或者直接在对话初期设定：

{
  "rules": [
    "所有数据库查询必须包含分页，默认每页 20 条。",
    "禁止在 Service 层直接捕获 Exception，需向上抛出或记录日志后抛出。",
    "代码风格遵循 Google Java Style Guide。"
  ]
}

有了这些约束，它的“阅读”才具备工程意义。

CSDN资料领取方式

需求拆解：把模糊想法变成可执行任务

这是我最喜欢的功能之一。以前接需求，产品经理说“加个用户导出功能”，我得自己拆：
1. 定义 DTO
2. 写 Repository 查询
3. 实现 Service 逻辑
4. 处理 Excel 生成
5. 写单元测试

现在，我会让 Claude Code 帮我做第一步。

操作示例：

User: 我需要实现用户列表的 CSV 导出功能。
请根据现有项目结构，拆解为具体的开发任务，并列出需要的文件修改点。

Claude Code 通常会给出一个非常结构化的回复：

1. 新增文件: src/main/java/com/example/export/UserCsvExportService.java
2. 修改文件: src/main/java/com/example/controller/UserController.java (添加 POST /export 接口)
3. 依赖检查: 确认是否已引入 Apache POI 或 OpenCSV。

这时候，我不会直接让它写代码，而是让它生成任务清单（Checklist）。然后，我逐个任务交给它执行。这种“分而治之”的策略，能有效避免它在长上下文中丢失细节。

重构与测试：AI 的强项

重构旧代码时，AI 是最耐心的搭档。特别是对于缺乏测试覆盖的老模块，Claude Code 能自动生成单元测试骨架。

场景： 我有一个 OrderValidator 类，里面全是 if-else，没有测试。

我的做法：
1. 选中方法，让 Claude Code 解释其业务逻辑。
2. 要求它基于这些逻辑，编写 JUnit 5 + Mockito 的测试用例，覆盖正常路径和异常路径。
3. 运行测试，修复失败项。

这里有一个关键技巧：不要让它直接修改生产代码来通过测试，除非你非常信任它。 先让它生成测试，你自己审查测试的正确性。如果测试是对的，再让它在测试基础上重构代码。

// Claude Code 生成的测试片段示例
@Test
void shouldRejectOrderWhenAmountExceedsLimit() {
    // Given
    Order order = new Order(1L, BigDecimal.valueOf(100000), "USD");

    // When
    assertThrows(OrderValidationException.class, () -> {
        orderValidator.validate(order);
    });

    // Then
    verify(mockAuditLogger).log(anyString());
}

使用边界：什么时候该停下来？

虽然 Claude Code 很强，但它不是万能的。作为开发者，你必须守住底线：

1. 安全性：它可能会引入硬编码密钥或 SQL 注入漏洞。每次它生成的涉及安全相关的代码，必须人工审计。
2. 业务逻辑的微妙差异：AI 不懂你们公司的“潜规则”。比如，“状态为 2 表示审核中，但也可能表示草稿”，这种歧义它无法理解，除非你明确告诉它。
3. 过度工程：有时候一个简单的 if 就够了，它可能会给你造一个策略模式+工厂模式+责任链。你要学会拒绝，说“太复杂了，简化一下”。

我的判断标准：
如果 AI 生成的代码我能一眼看懂并验证正确性，就合并；如果我需要花 10 分钟才能搞懂它在干什么，我就重写，不妥协。