聊《Claude Code到底能不能干活？别只看 Demo 和跑分》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

之前试用 Claude Code 的时候，个人写点小脚本、改个 Bug，体验确实丝滑。但最近看了几家大厂的 AI 编程岗位 JD，要求里反复出现"团队协作"、"工作流集成"、"工程化落地"这几个词，才意识到一个问题：个人 Demo 能跑通，不代表工具真的能进团队。

我拿一个中等规模的 Python 服务项目做了轮测，把过程记录下来，有些判断可能和主流说法不太一样。

目录

• Claude Code 适合做什么，不适合做什么
• 真实案例：拿一个真实项目跑一遍
• 排查过程：测试用例遗漏的根因
• 代码解释：生成的测试文件分析
• 失败原因：三个常见错误类型
• 适用边界：什么时候不该用 Claude Code
• 总结：从个人试用到团队协作的关键转变

Claude Code 适合做什么，不适合做什么

先说结论，再展开。

Claude Code 在以下几类场景里确实能提效：

• 理解一段陌生的代码库，快速定位调用链
• 把模糊需求拆成可执行的小任务
• 写单测、补测试覆盖
• 重构时做安全的代码替换

但它做不好的事情也很明确：

• 直接生成一个从零到上线的完整系统
• 处理需要深度业务理解的设计决策
• 在没有明确输入的情况下自主推进复杂任务

我之前的判断是"AI 编程工具能替代初级开发"，这个结论现在修正为"AI 编程工具能替代重复性编码工作，但决策和架构判断仍然需要人"。

真实案例：拿一个真实项目跑一遍

项目背景：一个基于 FastAPI 的内部服务，约 8000 行 Python 代码，有数据库操作、外部 API 调用、异步任务处理。没有完整的测试覆盖，文档也比较零散。

任务：让 Claude Code 帮我写一个核心模块的单测，覆盖主要边界情况。

输入给 Claude Code 的 prompt：

项目路径：~/projects/internal-service

请为 src/services/order_service.py 中的 OrderService 类编写单元测试。
要求：
1. 覆盖 create_order、cancel_order、get_order_status 三个方法
2. 使用 pytest + unittest.mock
3. 包含正常路径和异常路径
4. 生成后可直接运行

执行过程：

1. Claude Code 先读取了整个项目的目录结构
2. 找到 order_service.py 及其依赖
3. 分析了数据库模型和外部 API 的接口定义
4. 生成了测试文件 tests/testorderservice.py
5. 运行测试，发现三个测试用例失败
6. 根据错误信息自动修复了 mock 配置
7. 最终全部通过

输出结果：

• 生成了约 150 行测试代码
• 覆盖了 7 个正常路径用例和 5 个异常路径用例
• 测试执行时间 2.3 秒
• 有一个边界情况（并发取消订单）没有被覆盖，需要人工补充

这个案例说明：Claude Code 能完成一个有明确输入和输出标准的任务，但在边界条件的判断上，它依赖 prompt 的质量。

排查过程：测试用例遗漏的根因

第一次跑完测试，我发现有一个并发场景没覆盖到。排查过程如下：

现象：测试通过，但代码 review 时发现缺少并发场景的测试。

验证动作：
1. 检查生成的测试文件，确认没有并发相关用例
2. 查看 order_service.py 中是否有并发保护逻辑
3. 发现代码中有 asyncio.Lock 实现，说明并发场景是设计意图
4. 回溯 prompt，确认没有提到并发要求

排除结果：

• 不是模型能力问题：Claude Code 能理解并发代码
• 不是工具配置问题：环境正常，依赖完整
• 是 prompt 设计问题：没有明确要求测试并发场景

结论：测试遗漏的根本原因是输入不完整，不是 Claude Code 的能力缺陷。这说明在使用 AI 编程工具时，输入的完整性和明确性比工具本身更重要。

代码解释：生成的测试文件分析

生成文件的关键部分：

@pytest.mark.asyncio
async def test_create_order_success():
    # 输入：有效的订单数据
    order_data = {
        "user_id": "user_123",
        "product_id": "prod_456",
        "quantity": 2
    }

    # 核心逻辑：调用 OrderService.create_order
    result = await order_service.create_order(order_data)

    # 输出验证：返回订单 ID 和状态
    assert result["order_id"] is not None
    assert result["status"] == "created"

    # 异常处理：验证数据库调用被正确 mock
    mock_db.create_order.assert_called_once_with(order_data)

逐段解释：

第一段是输入构造。这里用字典模拟订单数据，结构清晰。关键点是 quantity 设置为 2，这触发了后续的价格计算逻辑。

第二段是核心调用。await 关键字说明 create_order 是异步方法，测试框架需要配合 @pytest.mark.asyncio 装饰器。

第三段是输出验证。断言了两个关键字段，但没有验证价格计算是否正确，这是一个遗漏点。

第四段是 mock 验证。确认数据库调用被触发，参数正确。这是单元测试的核心价值——隔离外部依赖。

异常处理部分没有显式写，但通过 pytest.raises 在异常路径测试中实现。

失败原因：三个常见错误类型

根据我的实践，Claude Code 使用失败的常见原因可以归为三类：

业务错误：prompt 描述的业务逻辑不准确。比如"帮我优化订单查询性能"，但没有说明具体的查询场景和性能指标。模型会按照字面理解，可能生成一个不相关的优化方案。

配置错误：环境依赖不完整。比如项目用了特定的数据库版本，但 prompt 中没有说明，模型生成的代码可能不兼容。或者缺少必要的 API key，导致外部调用失败。

环境错误：代码库结构复杂，模型无法正确解析依赖关系。比如跨模块的导入、动态加载的类、或者生成代码时没有考虑项目的编码规范。

区分这三种错误的方法：

• 业务错误：检查 prompt 是否包含了足够的上下文信息
• 配置错误：检查项目依赖和版本信息是否在 prompt 中说明
• 环境错误：检查模型生成的代码是否符合项目规范，是否需要人工调整

适用边界：什么时候不该用 Claude Code

我的判断标准：

适合用：

• 任务目标明确，输入输出清晰
• 代码库结构相对简单，依赖关系明确
• 有完善的测试基础设施，可以快速验证结果
• 开发人员具备代码 review 能力，能判断模型输出的正确性

不适合用：

• 需要深度业务理解的设计决策
• 代码库极其复杂，依赖关系难以梳理
• 没有测试基础设施，无法快速验证
• 开发人员不具备代码 review 能力

团队协作时的取舍：

个人使用时，可以接受一定的试错成本。但团队推广时，需要建立代码 review 流程，确保模型生成的代码符合团队规范。否则，效率提升可能被后续的技术债抵消。

总结：从个人试用到团队协作的关键转变

跑完这个项目后，我对 Claude Code 的定位更清晰了：它是一个高效的代码辅助工具，但不是替代开发者的智能体。

团队推广时的关键建议：

1. 建立 prompt 模板库：把常用的任务类型（写测试、重构、查 Bug）的 prompt 固化下来，提高输入质量
2. 强制代码 review：模型生成的代码必须经过人工 review，不能直接合入主分支
3. 从小范围试点开始：先让对工具熟悉的开发者试用，总结经验后再推广
4. 关注边界情况：模型在边界条件的处理上仍有局限，需要人工补充

招聘 JD 里反复强调的"工程化落地"能力，本质上就是这些实践经验的积累。工具本身不难上手，难的是知道什么时候该用、怎么用、用到什么程度。

如果你正在评估 Claude Code 是否适合团队，我的建议是：先在一个小项目上跑完一个完整的开发周期，记录每个环节的效率变化和问题点，再决定是否推广。Demo 能跑通和真的能干活，中间还隔着一个完整的项目实践。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。