官方推荐的最佳实践：https://code.claude.com/docs/zh-CN/best-practices
技巧1：明确需求，从规划开始
原始需求
一开始的需求，是爬取一个排行榜链接的数据。继续了解后发现，这个链接里的内容其实是 iOS 应用排行榜。
一开始的问题
我最初直接让 AI 按“爬这个链接”去写脚本，于是它很自然地把重点放在登录、页面结构、请求细节、反爬限制这些问题上。
结果就是整个任务被做复杂了：
- token 消耗很高
- 代码效果不好
- 还容易被登录和页面变化限制
后来确认的真实需求
后面我才发现，需求并不是一定要爬某个排行榜网站，而是只要能获取 iOS 应用排行榜数据就行。
这两者区别很大：
- “爬某个链接”是在限定实现路径
- “获取排行榜数据”才是在描述真正目标
优化后的做法
确认真实需求后，我没有再让 AI 直接写脚本，而是先让它给方案建议，比较网页爬取、现成库、第三方接口等方式的成本、稳定性和限制。
最后选出来的方案，是直接使用 app-store-scraper 和 google-play-scraper第三方库完成需求。
结果
这样做之后，效果明显好了很多：
- token 消耗更少
- 不再受登录限制
- 实现更简单
- 稳定性更高
这个例子说明什么
提示词工程优化，很多时候优化的不是措辞，而是任务表达方式。
如果一开始就把问题写成某种具体实现，AI 很容易被锁死在那条路径里；但如果先把目标讲清楚，再让 AI 从规划开始，它更容易给出更轻、更稳、更合适的方案。
更好的提问方式
需求是稳定获取 IOS 应用和Android应用排行榜数据。不要写代码，先分析可行方案，并比较它们的实现成本、稳定性、维护成本和限制。最后给出推荐方案。
技巧2：先探索，再规划，最后编码
问题背景
让 AI 直接跳到编码环节，很容易产生错误或不合理的代码。更稳妥的方式是把整个过程拆成三个阶段：探索、规划、实现。
推荐的工作流
1. 探索阶段
在这个阶段，让 AI 先读取相关文件并回答问题，不做任何修改。
如果你使用的是 Claude 命令行工具，可以通过以下方式切换到 Plan Mode（规划模式）：
claude --mode plan
或者在对话中直接说：
切换到 Plan Mode
然后让 AI 先探索现有代码：
读取
/src/auth目录，理解我们是如何处理会话和登录的。同时看一下我们如何管理环境变量中的敏感信息。
2. 规划阶段
在探索完成后，要求 AI 创建详细的实现计划：
我想添加 Google OAuth 登录。需要修改哪些文件？会话流程是怎样的？请创建一个实现计划。
这时 AI 会基于刚才探索的内容，给出完整的方案和步骤，而不是直接开始写代码。
3. 实现阶段
切换回 Normal Mode（正常模式）并让 AI 开始编码，根据它自己的计划进行验证：
切换命令：
claude --mode normal
或者在对话中说：
切换回 Normal Mode
然后开始实现：
按照你的计划实现 OAuth 流程。为回调处理器编写测试，运行测试套件并修复所有失败的测试。
什么时候需要规划
Plan Mode 很有用，但也会增加一些开销。
不需要规划的情况：
- 范围明确且修改很小的任务
- 比如修复拼写错误、添加日志行、重命名变量
- 如果你能用一句话描述这次改动，可以跳过规划
需要规划的情况：
- 你对实现方法不确定
- 更改会涉及多个文件
- 你不熟悉被修改的代码
- 功能复杂度较高
这个例子说明什么
把探索、规划、实现三个阶段分开，可以让 AI 在更清晰的上下文中工作。
探索阶段让 AI 先理解现有代码结构，规划阶段让它输出完整方案而不是直接动手，实现阶段才真正开始编码。这样做的好处是：
- 减少返工
- 降低错误率
- 让整个过程更可控
- AI 的输出质量更高
这也是为什么很多 AI 编程工具都会提供"只读模式"或"规划模式"的原因。
技巧3：在提示中提供具体的上下文
问题背景
Claude 可以推断意图，但它不能读心术。很多时候，AI 给出的结果不够准确，不是因为它能力不够，而是因为提示中缺少足够的上下文信息。
具体策略对比
| 策略 | 之前 | 之后 |
|---|---|---|
| 限定任务范围 <br> 指定哪个文件、什么场景和测试偏好 | "为 foo.py 添加测试" | "为 foo.py 编写测试，涵盖用户已注销的边界情况。避免 mock。" |
| 指向来源 <br> 指导 Claude 到可以回答问题的来源 | "为什么 ExecutionFactory 有这样奇怪的 api？" | "查看 ExecutionFactory 的 git 历史并总结其 api 是如何形成的" |
| 参考现有模式 <br> 指向代码库中的模式 | "添加日历小部件" | "查看主页上现有小部件的实现方式以了解模式。HotDogWidget.php 是一个很好的例子。按照模式实现一个新的日历小部件，让用户选择月份并向前/向后分页以选择年份。从头开始构建，除了代码库中已使用的库外，不使用其他库。" |
| 描述症状 <br> 提供症状、可能的位置以及"修复"的样子 | "修复登录错误" | "用户报告会话超时后登录失败。检查 src/auth/ 中的身份验证流程，特别是 token 刷新。编写一个失败的测试来重现问题，然后修复它" |
这个例子说明什么
提供具体上下文，可以让 AI 更准确地理解你的意图和约束条件。
好的提示词应该包含：
- 明确的范围：哪个文件、哪个场景、什么边界条件
- 清晰的来源：去哪里找答案、参考什么历史记录
- 具体的模式：参考哪个现有实现、遵循什么规范
- 详细的症状：问题是什么、可能在哪里、期望的结果是什么
这些信息越具体，AI 的输出就越符合预期。
技巧4：写 /init 生成项目 CLAUDE.md
问题背景
每次新开对话，AI 都需要重新了解你的项目结构、技术栈、编码规范、约束条件。这会导致：
- 需要反复说明项目背景
- AI 可能违反项目约定
- 来回纠正浪费时间
- 很难快速进入实质性开发
解决方案
在项目根目录创建 CLAUDE.md 文件，把项目的隐性知识变成显性约束。
在 Claude 中输入 /init 命令，它会自动生成一个包含项目信息的 CLAUDE.md 文件，内容通常包括：
- 项目技术栈和架构
- 代码风格和规范
- 常用命令和工作流
- 重要约束和注意事项
- 目录结构说明
效果
有了 CLAUDE.md 后，每次对话 AI 都会先读取这个文件，从"了解项目的状态"开始，而不是从零起步。
这在 vibe coding（快速迭代开发）时特别有用：
- 减少来回纠正
- AI 的输出更符合项目规范
- 更快进入实质性的功能开发
- 不用每次都重复说明项目约束
示例内容
一个典型的 CLAUDE.md 可能包含：
# 项目说明
## 技术栈
- Next.js 14 (App Router)
- TypeScript
- Tailwind CSS
- Prisma + PostgreSQL
## 代码规范
- 使用函数式组件，避免类组件
- 优先使用 Server Components
- 文件名使用 kebab-case
- 组件名使用 PascalCase
## 重要约束
- 所有 API 调用必须包含错误处理
- 不使用 any 类型
- 数据库操作必须在 Server Actions 中进行
## 常用命令
- `npm run dev` - 启动开发服务器
- `npm run build` - 构建生产版本
- `npx prisma studio` - 打开数据库管理界面
这个技巧说明什么
把项目知识显性化，可以让 AI 每次对话都带着正确的上下文开始工作。
这不仅节省了重复说明的时间，更重要的是让 AI 的输出从一开始就符合项目规范，减少了后续调整和纠正的成本。
技巧5：通过 @ 引用文件比粘贴文件路径更好
问题背景
在和 AI 交互时，有两种方式让它访问文件：
- 直接粘贴文件路径，让 AI 自己读取
- 使用 @ 引用文件，直接附加文件内容
两种方式的对比
粘贴路径：
请修改 src/components/Header.tsx 文件
AI 需要先执行读取操作，然后才能看到文件内容。
@ 引用：
请修改 @src/components/Header.tsx 文件
文件内容会被直接附加到对话上下文中，AI 可以立即看到。
为什么 @ 引用更好
虽然复制路径确实更快（不需要等文件上传和解析），但代价是 AI 需要多一个读取步骤。
对于简单任务：
这个差别不大，两种方式都可以。
对于需要快速浏览内容的任务：
@ 引用可能让 AI 响应更快，因为：
- 文件内容已经在上下文中
- 不需要额外的读取步骤
- AI 可以立即开始分析和处理
- 减少了一次工具调用的开销
适用场景
推荐使用 @ 引用的情况：
- 需要同时参考多个文件
- 文件内容需要反复查看
- 任务涉及文件间的对比和分析
- 希望减少 AI 的响应延迟
可以使用路径的情况：
- 文件很大，不想占用太多上下文
- 只是简单提及，不需要详细分析
- 文件内容可能会变化，需要实时读取
这个技巧说明什么
选择合适的文件引用方式，可以优化 AI 的响应速度和工作效率。
@ 引用虽然需要稍微多一点操作，但它把文件内容直接放入上下文，让 AI 可以立即开始工作，在需要快速浏览和分析文件内容的场景下更有优势。