Claude Code 实战经验分享（上篇）：从启动到并发协同

冬奇Lab
0 阅读9分钟

前言

如果你已经上手了 Claude Code（以下简称 CC），但还停留在"有需要就问一句"的用法，那这篇文章可能会让你重新认识它的潜力。

本文是实战经验分享的上篇，内容来自日常开发中踩坑和总结出的一些习惯做法。覆盖范围从启动方式的灵活运用，到 CLAUDE.md 的工程化配置，再到三种对话模式的场景选择，以及多任务并发操作时的注意事项。

不追求大而全，只谈实用。如果其中有一个点能改变你的使用方式，那就值了。

启动进阶：两种被忽视的启动模式

拉尔夫循环：让 CC 自主迭代完成任务

cc-practical-tips-01.PNG

《辛普森一家》里的拉尔夫·维格姆：看起来愚笨，但乐观且不屈不挠。

拉尔夫循环的核心思想很简单：让 CC 在一个循环中不断执行、检测、推进，直到任务完成。

适用场景：任务可以被分解为多个步骤，每步都有明确的完成标志，不需要人工介入每一步决策。

#!/bin/bash

# 最大迭代次数，防止无限运行
MAX_ITERATIONS=10
PROMPT_FILE="prompt.md"       # 每次迭代喂给 AI 的 prompt 文件
COMPLETE_SIGNAL="COMPLETE"    # 完成信号标记

for i in $(seq 1 $MAX_ITERATIONS); do
  echo "=== 第 $i 轮迭代 ==="

  # 调用 Claude Code，将 prompt 文件内容传入
  OUTPUT=$(claude --print --dangerously-skip-permissions < "$PROMPT_FILE")

  echo "$OUTPUT"

  # 检测完成信号，提前退出循环
  if echo "$OUTPUT" | grep -q "<promise>$COMPLETE_SIGNAL</promise>"; then
    echo "✅ 任务完成，退出循环（第 $i 轮）"
    exit 0
  fi

  echo "--- 未完成，继续下一轮 ---"
done

echo "⚠️ 达到最大迭代次数 ($MAX_ITERATIONS)，停止"

配合这个脚本，你需要一个驱动 CC 行为的 prompt.md：

你是一个自主软件工程师，正在处理这个代码库。

## 你的任务
参考 `PRD.md` 中的需求文档，找到**一个**尚未完成的任务，实现它，然后将其标记为完成。

## 工作规则
1. 先读取 `PRD.md`，找到第一个未完成（标记为 `[ ]`）的任务
2. 完整实现该功能，包括必要的测试
3. 运行测试，确保通过
4. 将 `PRD.md` 中该任务标记为 `[x]`
5. 用 git commit 提交本次变更
6. 检查 `PRD.md`，如果**所有任务都已完成**，输出：
   <promise>COMPLETE</promise>
   然后停止。
7. 如果还有未完成任务，直接结束本次会话，等待下一轮迭代

## 重要约束
- 每轮只做**一个**任务，不要贪多
- 遇到编译错误或测试失败，要修复后再提交
- 始终通过 git 历史来了解上一轮做了什么

对应的 PRD.md 示例：

# 项目需求

## 功能列表

- [ ] 实现用户注册 API（POST /api/register）
- [ ] 实现用户登录 API（POST /api/login），返回 JWT
- [ ] 实现权限中间件，校验 JWT
- [ ] 为以上三个接口编写集成测试
- [ ] 添加 README，说明如何本地运行

运行后，CC 会自动一条一条地推进任务，完成后打 [x]，直到全部完成输出 COMPLETE 信号，循环脚本捕获信号后退出。

你唯一需要做的事：写好 PRD，然后去泡杯咖啡。

claude -p：把 CC 当作 API 来调用

有时候你并不需要一次对话，而是需要"丢一个 prompt 进去，拿一个结果出来"。claude --print（简写 -p）就是为这个场景设计的。

echo "分析这段代码的时间复杂度：..." | claude -p

这让 CC 变成了一个命令行黑盒：prompt 进去，结果出来，一次完成，无需交互。

实际应用场景：Jira 上的 Bug 分析工具直接调用 CC 的 skill 来分析日志，无需人工打开终端启动会话。

如果你需要在上一次对话的基础上继续追问，可以加上 -c 参数：

# 第一次调用
echo "帮我分析这个日志文件" | claude -p

# 继续上一次会话追问（-c = continue，-p = print 模式）
echo "刚才分析的问题，有哪些修复建议？" | claude -c -p

-c 会恢复上一次对话的上下文，让多轮调用之间保持连贯性。

CLAUDE.md：工程的说明书

拿到一个新工程，第一条指令应该是 /init。

CC 会读取工程中的文档、代码结构，生成一份对整个工程的理解报告，并写入 CLAUDE.md。这个文件是 CC 理解你工程的"入场白"——每次对话开始时都会被读取。

一个好的 CLAUDE.md 应该包含：

# 项目说明

## 技术栈
- 语言：Kotlin + Java
- 构建工具：Gradle
- 框架：Android AAOS (Android Automotive OS)

## 目录结构
- `app/` - 主应用模块
- `libs/` - 公共库
- `scripts/` - 构建脚本

## 常用命令
- 构建：`./gradlew assembleDebug`
- 测试：`./gradlew test`
- 代码检查：`./gradlew lint`

## 注意事项
- 不要直接修改 `auto-generated/` 目录下的文件
- 提交前必须通过 lint 检查
把 CLAUDE.md 想象成给新同事的工程交接文档——越清晰，CC 的理解就越准确，后续每次对话的质量就越高。

三种对话模式：选对模式比什么都重要

CC 有三种模式，对应不同的信任级别和使用场景。用快捷键 Shift + Tab 在模式间切换。

Plan Mode：军师模式，只谋划不动手

运筹帷幄之中，决胜千里之外。

Plan Mode 下，CC 绝对不会修改你工程中的任何文件。它只思考、只规划，等你确认后才会执行。

适用场景：需求不清晰、逻辑复杂、可能影响多个模块的改动。

实际操作：

  1. 切换到 Plan Mode（Shift + Tab）
  2. 把需求丢给 CC，让它制定实现计划
  3. CC 生成计划文件（可用 Ctrl + G 直接在 IDE 中打开）
  4. 仔细审查计划，必要时手动修改
  5. 确认后切换回执行模式，让 CC 按计划实施
简单的 UI 调整、文案翻译等小改动没必要走 Plan Mode，会拖慢节奏。只有那些"一旦改错了就很麻烦"的任务才值得认真规划。

一个实际的工作流建议（来自 CC 之父 Boris 的做法）：

先让 Claude 在 Plan Mode 下理解代码、生成计划，然后用第二个 Claude 会话审计这个计划的合理性，确认后才开始编码。

两个 CC 会话相互审查，可以有效减少方向性错误。

Auto-accept Edits Mode：信任模式，全速推进

在 Plan Mode 确认计划之后，可以切换到 Auto-accept Edits Mode。CC 的创作内容会直接写入文件，不需要你逐一审核每处改动。

适用场景：已经有清晰计划，修改风险可控，希望让 CC 快速推进。

Default Mode：谨慎模式，逐步审核

每次文件改动都需要你手动确认授权。

适用场景：核心逻辑、复杂逻辑的修改，建议查看变更内容后再授权写入，避免 CC 在不清楚边界的地方乱改。

三种模式对比

模式代码修改适用场景
Plan Mode❌ 只规划需求分析、复杂功能规划
Auto-accept Edits✅ 自动写入计划明确、低风险改动
Default Mode⚠️ 逐步确认核心逻辑、高风险改动

典型工作流

理解了三种模式之后，推荐以下工作流结构：

接到需求
    │
    ▼
Plan Mode：理解代码 → 生成计划
    │
    ▼
审查计划（必要时人工修改）
    │
    ▼
Auto-accept Edits Mode：执行实现
    │
    ▼
Default Mode：审核核心改动
    │
    ▼
测试验证 → 提交

关键点：Plan 阶段不要省。很多人一上来就让 CC 写代码，然后发现方向不对、大段逻辑重写，反而浪费更多时间。

并发操作：多窗口多任务

CC 没有人脑的单线程限制，可以多个终端同时运行不同任务。

比如：终端 A 在开发需求 A，终端 B 在开发需求 B，两个任务并行推进互不干扰。

实际操作中会碰到两个常见问题：

问题一：窗口名称混乱

CC 会根据对话内容自动生成窗口名称，有时不是你想要的，而且随着对话推进名称还会变。

解决方案：用 /rename 命令手动指定窗口名称：

/rename 需求A-座舱氛围灯开发

这样多窗口同时开着也不会搞混。

问题二：CC 完成任务时如何通知你

多任务并发时，你不可能盯着每个窗口等结果。需要给 CC 配置通知能力，任务完成时主动提醒你。

macOS 通知配置（加入 ~/.claude/settings.json）：

{
  "hooks": {
    "Notification": [
      {
        "matcher": "permission_prompt",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"需要你的确认\" with title \"Claude Code\" sound name \"Ping\"'"
          }
        ]
      },
      {
        "matcher": "idle_prompt",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"等待你的输入\" with title \"Claude Code\" sound name \"Glass\"'"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"任务已完成\" with title \"Claude Code\" sound name \"Hero\"'"
          }
        ]
      }
    ]
  }
}

Ubuntu 系统需要额外的 Python 脚本，将以下配置加入 settings.json：

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/anaconda3/bin/python3 ~/.claude/hooks/hook_stop_notification.py"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/anaconda3/bin/python3 ~/.claude/hooks/hook_notification_notification.py"
          }
        ]
      }
    ]
  }
}

配好之后，CC 完成任务、需要确认、等待输入时都会弹出通知，你可以安心去做其他事，等通知来找你。

彩蛋：CC 之父 Boris 在用的终端工具

Ghostty

  • 支持窗口任意分隔（上下左右任意分屏）
  • 支持 Theme 定制
  • 支持快捷键定制

并发操作多窗口时，Ghostty 的分屏功能非常好用，所有 CC 终端尽收眼底。

总结

上篇覆盖了 CC 使用中的几个基础但容易被低估的能力：

  1. 拉尔夫循环：写好 PRD，让 CC 自主迭代完成，适合任务分解明确的场景
  2. claude -p 模式：把 CC 当 API 用，适合外部程序集成调用
  3. CLAUDE.md：工程的说明书，/init 之后长期维护，是 CC 理解你工程的基础
  4. 三种对话模式：Plan → Auto-accept → Default，根据任务风险灵活切换
  5. 并发操作：多窗口多任务，配好通知，CC 完成时来找你

这些内容偏向"工程使用方式"的层面。下篇将深入记忆机制、规则约束、权限管理和快捷操作——那些让 CC 真正符合你和团队工作习惯的配置能力。

avatar
文章
阅读
粉丝