Claude Code 常用提示词与使用技巧：基于 RAG 安全评测实战总结

在最近完成的一项为期数天、涉及大型代码库修改、API 集成和复杂实验流程编排的 RAG 安全评测项目中，我深度使用了 Claude Code。这次经历不仅交付了项目，更重要的是，在与 AI 的密集协作中，我总结出了一套提示词设计和任务管理的方法论，有效地解决了 AI 行为失控、上下文污染、任务死循环和成本浪费等常见问题。

本文将结合这次实战经验与 Claude Code 的官方最佳实践，将这些技巧系统性地分享给你。

核心架构：“5 阶段 AI 编程模式”

面对复杂任务，让 AI “一步到位”往往会导致返工。我将传统软件工程方法论与 AI 协作特点结合，总结出5 阶段 AI 编程模式，它为整个项目周期提供了清晰的框架，是所有技巧的应用基石。

1. 研究 (Research)：明确问题边界、技术选型和风险评估。产出 research-summary.md。
2. 规划 (Plan)：设计详细方案、任务拆分和实验矩阵。产出 plan.md 和架构图。
3. 实施 (Implement)：严格按计划编码、增量开发并不断验证。
4. 审查 (Review)：系统性检查代码质量、指标正确性和可复现性。
5. 验证 (Verify)：进行端到端测试，生成最终交付物和验证报告。

技巧1：使用 @ 文件引用和 ! 命令进行精准交互
在实施和审查阶段，精准的信息传递至关重要。不要泛泛描述，使用 @文件路径 来直接引用代码文件，使用 @文件夹/ 来引用整个目录。当需要快速查看环境状态时，直接用 !ls、!grep 等前置指令，可以快速、经济地获取信息，避免浪费 tokens 在冗长对话上。

---

六大实战生存技巧

技巧 1：用“记忆文件”建立跨会话的确定性

核心痛点：多轮对话后上下文丢失，AI “忘记”了关键的环境配置、模型列表或实验矩阵。每次新对话都要重新解释，低效且容易出错。

解决方案：主动创建一个 context_memory.md 文件（或直接使用项目根目录下的 CLAUDE.md 文件，通过 @./CLAUDE.md 引用），作为项目的“共享大脑”。每次启动新会话时，第一步就是将这个记忆文件的内容注入上下文。

实战案例：在我们的评测项目中，context_memory.md 记录了 conda 环境路径、API 密钥变量名、确定的 6 个模型 ID、攻击与指标的映射关系以及最终输出文件的清单。这使得任何一次重启会话，Claude Code 都能瞬间恢复“项目记忆”，无需重复说明。

# 记忆文件示例
## 环境
- Conda: `saferag`，路径 `/home/lium/miniconda3/envs/saferag`
- Python: `/home/lium/miniconda3/envs/saferag/bin/python`

## API 配置
- Base URL: `https://api.siliconflow.cn/v1`
- Key: 在 `configs/config.py` 中名为 `Silicon_key` 的变量

## 执行要求
- 始终在 `saferag` 环境下运行
- 所有 API 调用使用 `temperature=0`

进阶技巧：使用 Claude Code 的 # 快速记忆功能，在对话中输入的以 # 开头的内容会被自动添加到 Auto Memory 中，例如：# 这个项目的 Embedding 模型使用本地 bge-base-zh-v1.5，禁止联网下载。

技巧 2：用“硬性约束”限制 AI 的破坏行为

核心痛点：AI 在调试时倾向于“自由探索”，可能修改核心逻辑、调用昂贵接口或陷入无限重试，导致项目偏离正轨。

解决方案：在提示词中设置明确、细致且带惩罚暗示的“硬性约束”或“绝对禁令”。与其宽泛地说“小心点”，不如直接说“禁止修改以下文件”、“禁止运行全量实验”、“只允许使用 BM25 检索器”。这种方式利用了 AI 对明确指令的高度遵从性，能极大减少意外情况。

实战案例：当我们需要 Claude Code 仅为项目环境做最终验证，而绝不能启动长达数小时的昂贵实验时，提示词是这样写的：

## 🚨 最高优先级禁令
1. **禁止调用任何硅基流动API**（禁止实例化 `SiliconFlowAPI` 并调用 `generate`）。
2. **禁止运行 `run_full_eval.py` 的任何模式**（main/filter/retriever_abl）。
3. 所有测试必须用**离线模式**完成（验证导入、语法、小规模模拟）。

技巧 3：采用“最小化测试，一次性交付”的验证哲学

核心痛点：在脆弱的实验环境中，让 AI 自动运行所有步骤可能导致 API 额度耗尽、生成海量错误日志，问题排查极其困难。

解决方案：将“代码开发与验证”和“交付物最终生成”彻底分离。让 AI 负责编写并最小化验证所有脚本，而长周期的、昂贵的全量任务交给用户手动执行。AI 的最终交付物是一个经过验证的、可靠的一键运行脚本（如 run_all.sh）。

实战案例：项目收尾阶段，我们要求 Claude Code 依次完成：

1. 编写一个独立的 verify_retrievers.py 脚本，快速测试所有 4 种检索器的连通性。
2. 完善 test_suite.sh 脚本，让它能验证整个环境。
3. 最终，run_all.sh 作为最终交付物，它对用户负责，AI 不会去主动执行它。

# 用户最终只需两步：
bash test_suite.sh   # 验证环境是否就绪
bash run_all.sh      # 启动全量实验

辅助技巧：利用 Plan Mode（Shift+Tab 切换两次，或使用 /plan 命令），让 Claude Code 在你动手编码前，仅分析不执行，能极大减少因方向错误而导致的试错成本。

技巧 4：任务分块与强制汇报，打破 AI 的“死循环”

核心痛点：AI 在处理复杂问题时，可能陷入“诊断-修复-重试”的无限循环。例如，反复修改一个脚本但始终无法通过测试，却不主动报告核心错误。

解决方案：

1. 分块：将大任务拆解为独立的、可验证的小步骤（步骤一、步骤二……）。
2. 汇报机制：强制要求 AI 在每完成一个步骤后暂停并汇报，甚至在遇到任何错误时都必须立即停止并展示完整错误信息，严禁其自动重试。

实战案例：在修复 quick_start_nctd.py 导入错误时，我们明确要求：“运行诊断命令，向我展示结果。如果失败，将完整的错误输出（前15行）展示给我，并停止。不要尝试修复。” 这种强制性汇报让我们能快速介入，做出正确的人工决策。

技巧 5：人工介入，进行“根因分析”与“方案决策”

核心痛点：AI 擅长执行，但不擅长权衡所有约束条件的宏观决策。当它提出备选方案时，往往把皮球踢给用户，浪费大量时间等待。

解决方案：当 AI 报告阻塞性错误时，主动切换角色，由你来进行根因分析，并给出几条明确的、可操作的解决路径（方案 A/B/C），让 AI 去执行其中被选中的一条。这样比你等待 AI 自己提出并分析方案要快得多。

实战案例：当 Milvus 服务不可用时，我们没有被动等待 Claude Code 的建议，而是主动分析并给出指令：“推荐方案 B：先以 BM25 检索器完成试跑和全量实验，确保流程打通……”。这打破了 AI 在 Milvus 连接上的反复尝试，直接推进了项目。

技巧 6：果断使用“全新会话”来避免上下文污染

核心痛点：随着对话变长，AI 会记住早期失败的尝试、修改的中间状态，导致行为越来越怪异，开始“走捷径”或产生幻觉。

解决方案：在项目进入全新阶段，或当前会话明显出现混乱时，果断使用 /clear，甚至直接开启一个全新会话。将之前的结论和关键状态提炼到一个新的记忆文件或提示词中，粘贴给新的会话。这比使用 /compact 更能彻底地清理混乱的上下文。如果 Claude 跑偏，Escape 键是紧急刹车的首选。

---

总结

这次 RAG 安全评测项目不仅是代码上的成功，更是提示词工程与 AI 协作方法的一次深度实验。通过5 阶段模式把控全局节奏，结合“记忆文件”确保连续性、“硬性约束”控制行为、“最小化测试”和“一次性交付”的策略规避风险，我们成功地将一个复杂易失控的项目，转变为一个高效、可控、最终成功交付的协作过程。