前言

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

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

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

从启动进阶来看，两种被忽视的启动模式

再看拉尔夫循环。让 CC 自主迭代完成任务

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

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

#!/bin/bash
# 最大迭代次数，防止无限运行
MAX_ITERATIONS=
PROMPT_FILE="prompt.md" # 每次迭代喂给 AI 的 prompt 文件
COMPLETE_SIGNAL="COMPLETE" # 完成信号标记
for i in $;do
echo "=== 第 $i 轮迭代 ==="
# 调用 Claude Code，将 prompt 文件内容传入
OUTPUT=$
echo "$OUTPUT"
# 检测完成信号。提前退出循环
if echo "$OUTPUT" | grep -q "$COMPLETE_SIGNAL";n
echo "✅ 任务完成，退出循环"
exit
fi
echo "--- 未完成，继续下一轮 ---"
done
echo "⚠️ 达到最大迭代次数，停止"

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

## 你的任务
参考 `PRD.md` 中的需求文档，找到**一个**尚未完成的任务，实现它，接下来将其标记为完成。## 工作规则
. 先读取 `PRD.md`，找到第一个未完成的任务
. 完整实现该功能，包括必要的测试
. 运行测试。确保通过
. 将 `PRD.md` 中该任务标记为 ``
. 用 git commit 提交本次变更
. 检查 `PRD.md`，如果**所有任务都已完成**，输出：
COMPLETE
接下来停止。. 如果还有未完成任务，直接结束本次会话，等待下一轮迭代
## 关键约束
- 每轮只做**一个**任务，不要贪多
- 遇到编译错误或测试失败，要修复后再提交
- 始终通过 git 历史来了解上一轮做了什么

对应的 PRD.md 示例：

## 功能列表
- 实现使用者注册 API
- 实现使用者登录 API。返回 JWT
- 实现权限中间件，校验 JWT
- 为以上三个接口编写集成测试
- 添加 README，说明如何本地运行

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

你唯一需要做的事：写好 PRD，接下来去泡杯咖啡。按理说，

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

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

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

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

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

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

# 第一次调用
echo "帮我分析这个日志文件" | claude -p
# 继续上一次会话追问
修复建议？" | claude -c -p

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

CLAUDE.md：工程的说明书

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

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

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

# 技术栈
- 语言：Kotlin + Java
- 建立工具：Gradle
- 框架：Android AAOS
# 目录结构
- `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
2. 把需求丢给 CC，让它制定实现计划
3. CC 生成计划文件
4. 仔细审查计划。必要时手动修改
5. 确认后切换回执行模式，让 CC 按计划实施

简单的 UI 调整、文案翻译等小改动没必要走 Plan Mode，会拖慢节奏。只有那些"一旦改错了就很麻烦"的任务才值得认真规划。一个实际的工作流建议：

两个 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通知配置:

{
"hooks": {
"Notification":
},{
& quot;matcher & quot;: & quot，idleprompt & quot;,& quot，hooks & quot;:
}
],& quot;Stop"，:
}
]
}
}

Ubuntu程序 需要额外的 Python 脚本，将以下配置加入settings.json:

{
"hooks": {
"Stop":
}
]。Notification:
]
}
}

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

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

Ghostty

• 支持窗口任意分隔
• 支持 Theme定制
• 支持快捷键定制

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

上篇覆盖了 CC 使用中的几个基础但容易被低估的能力 : 1. 拉尔夫循环: 写好 PRD,让CC自主迭代完 成,适合任分分解明确的场最 2.clau-p模式:把当API月,适合外部程序集成调用 3.CLAUDE md: 工程的说明书。/inti之后长期维护,是cc理解你工程的基础 4.三种对话模式:Plan→Accept→Defalut,根据任分风险灵活切換 5.并发探作:多窗口多任分,配好通知,cc完 成时来找你

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

---