Claude Code实战教程(2):交互式会话的36种开场白——让AI一次性做对
《从零开始的 Claude Code 实战系列教程》第 2 篇 · 公众号「麒麟剑的AI自动化Lab」连载
▲ 好的提问方式,是让AI帮你高效工作的关键
一、为什么很多人用 Claude Code 效果不好?
你有没有过这样的经历:
“我跟 Claude 说’帮我优化一下性能’,它改了一堆代码,但性能根本没提升,反而引入了新 bug…”
或者:
“我问它’这个项目怎么工作’,它回答得泛泛而谈,完全没抓住重点…”
问题通常不出在工具本身,而是出在提问方式上。
人类和 AI 沟通,有点像和实习生合作:
- 你越清晰,它越能干好
- 你越模糊,它越容易跑偏
- 给它上下文,它才能做出正确的判断
本章将带你掌握 36 种开场白,覆盖从探索项目到完成复杂任务的全流程。
二、黄金法则:好提示词的三层结构
无论做什么任务,一个高效的提示词应该包含三层信息:
┌─────────────────────────────────────────────────────┐
│ 第一层:上下文 → Claude 需要知道什么背景? │
│ 第二层:目标 → 最终要达成什么结果? │
│ 第三层:约束 → 有什么限制条件或风格要求? │
└─────────────────────────────────────────────────────┘为什么这三层结构重要?
想象一下,你带一个新同事入职:
- 上下文:告诉他公司的业务是什么、他负责哪个模块、团队用什么技术栈
- 目标:明确告诉他今天要完成什么任务
- 约束:说明有哪些限制(时间、资源、规范)
如果只说”把这个 bug 修一下”,新同事可能会:
- 不知道 bug 在哪里
- 不理解这个功能的重要性
- 用错误的方式修复(可能引入新问题)
❌ 差的提示词
修复这个 bug问题:Claude 不知道你指的是哪个 bug,在哪一行,期望的行为是什么。
✅ 好的提示词
上下文:用户登录时,如果密码错误,页面应该显示红色错误提示,但当前什么也不显示。
目标:找到导致错误提示不显示的 bug 并修复。
约束:不修改其他功能,保持现有的 CSS 类名不变。对比一下,哪个提示词更容易让 Claude 一次性做对?
▲ 清晰的沟通能让团队协作更高效,与 AI 协作也是如此
三、探索阶段的 12 个开场白
当你刚接手一个新项目,或者 Claude Code 打开了一个陌生仓库时,第一步应该是理解项目。
了解项目全局
| # | 开场白 | 目的 |
|---|---|---|
| 1 | 这个项目是做什么的?用一句话概括 | 快速建立全局认知 |
| 2 | 给我讲一下整体目录结构 | 理解项目架构 |
| 3 | 这个项目用了哪些技术栈? | 识别框架、库、语言版本 |
| 4 | 主入口文件在哪里?请求是如何路由的? | 找到代码入口 |
| 5 | 数据库 schema 是怎样的? | 理解数据模型 |
| 6 | 核心业务逻辑在哪些文件里? | 定位关键代码 |
实战示例:
你:这个项目是做什么的?用一句话概括
Claude:这是一个基于 Next.js 的电商后台管理系统,
主要功能是商品管理、订单处理和数据分析。
你:给我讲一下整体目录结构
Claude:
src/
├── app/ # Next.js 页面路由
│ ├── (admin)/ # 管理后台页面
│ └── api/ # API 路由
├── components/ # UI 组件
├── lib/ # 工具函数
├── prisma/ # 数据库 schema
└── types/ # TypeScript 类型定义理解代码细节
| # | 开场白 | 目的 |
|---|---|---|
| 7 | 解释一下这个函数的作用:@src/auth.ts | 聚焦理解特定函数 |
| 8 | 这个模块和那个模块之间是怎么交互的? | 理解模块间关系 |
| 9 | 帮我画一下数据流向图 | 可视化理解流程 |
| 10 | 这段代码有什么潜在问题? | 主动发现隐患 |
| 11 | 这个函数的时间复杂度是多少? | 性能分析 |
| 12 | 有没有不必要的重复代码? | 识别代码重复 |
提示:用 @文件名 或 @目录名 来引用具体文件,Claude 会自动读取并理解。
▲ 理解系统架构是高效开发的前提
四、编码阶段的 12 个开场白
当你理解了项目,接下来就是让 Claude 帮你写代码了。
新功能开发
| # | 开场白 | 目的 |
|---|---|---|
| 13 | 在 src/user/ 下创建一个注册 API 端点,接收 email 和 password,验证后存入数据库 | 完整的功能描述 |
| 14 | 按照现有的代码风格,在 src/components/ 中添加一个 UserCard 组件 | 保持风格一致 |
| 15 | 实现一个防抖函数 debounce,参数是 fn 和 delay,返回节流后的函数 | 精确的工具函数 |
| 16 | 添加一个 /api/products 端点,支持 ?page=1&limit=20 分页查询 | 带参数的 API |
| 17 | 在 tests/ 下为新加的 API 写单元测试,使用 pytest | TDD 驱动 |
| 18 | 把这个功能做成可配置的,通过环境变量 DB_HOST 来指定数据库地址 | 可配置化 |
改造与重构
| # | 开场白 | 目的 |
|---|---|---|
| 19 | 把 src/utils.py 中的 300 行代码拆分成 3 个独立模块 | 模块化重构 |
| 20 | 把这个 React 类组件改写成函数组件 + hooks | 现代写法升级 |
| 21 | 用 TypeScript 类型替换这里的所有 any | 类型安全升级 |
| 22 | 把这个同步函数改成异步,使用 await/async | 异步化改造 |
| 23 | 提取公共逻辑到 Hook 中,消除重复代码 | DRY 原则 |
| 24 | 优化这个查询,现在有 N+1 问题 | 性能优化 |
Bug 修复
| # | 开场白 | 目的 |
|---|---|---|
| 25 | 用户反馈:提交表单后页面崩溃,报错 "Cannot read properties of undefined" | 带错误信息的 bug 报告 |
| 26 | 这个 API 在并发 100 请求时响应变慢,帮我分析原因 | 性能相关的 bug |
| 27 | find the bug where users can see other users' data | 权限漏洞 |
| 28 | 测试失败了,错误是 Assertion Error: expected 200 but got 500 | 带测试结果的 bug |
| 29 | 这个函数在输入为空时崩溃,加上防御性处理 | 边界条件修复 |
| 30 | 生产环境偶发这个错误,日志显示...(粘贴日志) | 日志驱动的排查 |
五、高级协作的 6 个开场白
当你和 Claude 已经配合默契,可以进行更复杂的协作:
多步任务
| # | 开场白 | 目的 |
|---|---|---|
| 31 | 分三步完成:①分析现有 API ②设计新接口 ③编写代码并写测试 | 分步执行复杂任务 |
| 32 | 先做一个 Plan,列出所有需要修改的文件和大致方案,我确认后再执行 | Plan Mode 前置 |
| 33 | 并行地:同时调研 3 个不同的实现方案,然后推荐最优的一个 | 多方案并行调研 |
| 34 | 先写测试(RED),再写代码让它通过(GREEN),最后重构(REFACTOR) | 真正的 TDD |
代码审查与质量
| # | 开场白 | 目的 |
|---|---|---|
| 35 | /code-review(内置命令) | 对当前 diff 进行代码审查 |
| 36 | 这个 PR 有什么安全风险?重点关注 SQL 注入、XSS 和越权访问 | 安全审查 |
六、使用内置命令加速工作流
最常用命令
| 命令 | 功能 | 使用场景 |
|---|---|---|
/help | 显示所有可用命令 | 忘了命令时随时查看 |
/clear | 清空对话历史 | 切换话题时 |
/compact | 压缩上下文,保留关键决策 | 对话过长时主动执行 |
/model | 切换模型 | 简单任务用 Haiku,复杂任务用 Opus |
/diff | 查看当前未提交的变更 | 确认 Claude 改了哪些内容 |
/continue | 继续上次的会话 | 想接着聊 |
/resume | 选择并恢复历史会话 | 回到之前的对话 |
/init | 初始化 CLAUDE.md | 新建项目时运行一次 |
/doctor | 检查环境和配置 | 遇到问题时诊断 |
/btw | 插话问旁问题 | 不污染主对话的补充提问 |
Plan Mode(计划模式)
按两次 Shift+Tab 进入 Plan Mode。这是 Claude Code 最强大的功能之一:
- Claude 先分析任务,输出详细计划
- 你审阅并确认计划后再执行
- 避免 Claude 一口气做了太多不必要的修改
适用场景:复杂重构、多文件修改、触及核心逻辑的代码
关闭场景:简单的小改动、临时查询七、描述需求的最佳实践
原则一:具体优于笼统
❌ "优化一下性能"
✅ "首页加载时间从 3.2s 降到 1s 以内,重点关注 API 请求数量和首屏渲染"原则二:提供错误信息而非模糊描述
❌ "有 bug"
✅ "用户在点击'提交'按钮后,控制台报 TypeError: Cannot read properties of undefined"原则三:指定期望的输入输出
✅ "输入: { userId: string }
输出: { name: string, email: string, role: 'admin' | 'user' }
如果 userId 不存在,返回 null"原则四:说明上下文和约束
✅ "基于现有的 REST API 风格(参考 src/api/users.js),添加一个类似的订单 API。
不要修改现有的用户 API,保持相同的项目结构。"八、多轮对话技巧
渐进式细化
不要把所有细节一次说完,而是循序渐进:
第一轮:帮我创建一个用户注册功能
→ Claude 实现基础版本
第二轮:加上邮箱验证和密码强度检查
→ Claude 在原有基础上添加
第三轮:写单元测试覆盖所有边界情况
→ Claude 补充测试纠正与引导
如果 Claude 做错了,直接告诉它:
❌ 沉默忍受,等它自己改
✅ "你漏掉了密码加密这一步,应该使用 bcrypt,哈希成本设为 12"
✅ "思路是对的,但不要用 class component,用 function component + hooks"使用 /btw 不打断主线程
当你在等 Claude 执行复杂任务时,想插一个问题:
/btw 这个函数用的什么算法?时间复杂度多少?Claude 会在后台回答你,不干扰当前正在执行的主任务。
九、实战演练:构建一个完整的 REST API
场景:从零开始,用 Claude Code 构建一个待办事项 API
Step 1:初始化项目
mkdir todo-api && cd todo-api
claudeStep 2:让 Claude 创建项目骨架
请帮我创建一个 Node.js + Express 的 REST API 项目,包含:
1. package.json(使用 TypeScript)
2. src/ 目录下有 index.ts 作为入口
3. src/routes/ 下有 todos.ts 路由
4. tsconfig.json 配置
5. .env.example 环境变量模板
使用 Express + TypeScript,遵循已有的最佳实践。Step 3:实现 CRUD 接口
实现 TODO 的增删改查:
- GET /api/todos 获取所有待办
- POST /api/todos 创建新待办
- GET /api/todos/:id 获取单个待办
- PUT /api/todos/:id 更新待办
- DELETE /api/todos/:id 删除待办
数据暂时存在内存中(数组),稍后会换成数据库。Step 4:添加测试
为所有路由编写 jest 单元测试,使用 supertest 模拟 HTTP 请求。
覆盖正常情况和边界情况(如 ID 不存在)。Step 5:运行并修复
运行 npm test,如果失败帮我修复直到全部通过。十、常见错误与规避方法
| 错误做法 | 正确做法 |
|---|---|
| 一次给一个超大任务 | 拆分成小步骤,逐步完成 |
| 只用一句模糊描述 | 提供具体的上下文和约束 |
| 不检查 Claude 的输出 | 每次修改后都用 /diff 查看变更 |
| 让上下文膨胀到瓶颈 | 定期用 /compact 压缩,或 /clear 新开会话 |
| 在 Manual 模式下反复打断 | 熟悉后切到 Auto 模式,更高效 |
| 忽略 Claude 的警告 | Claude 标记的风险点要认真对待 |
十一、本章小结
| 核心要点 | 说明 |
|---|---|
| 三层提示结构 | 上下文 + 目标 + 约束 |
| 善用 @ 引用 | 用 @文件 精准引导 Claude 关注特定代码 |
| Plan Mode 很重要 | 复杂任务先用 Plan Mode 出方案,确认后再执行 |
| 内置命令是利器 | /diff、/compact、/debug、/code-review 经常用到 |
| 多轮渐进式 | 先做骨架,再填充,最后打磨 |
| 及时纠偏 | Claude 做错时直接指出,不要等它自己发现 |
下期预告(第 3 篇):CLAUDE.md——给AI装上一颗项目大脑,让它成为真正懂你项目的专属助手
关注本系列,从入门到专家,系统掌握 Claude Code 的全部技能。