用久了自然就有心得

前面几章讲了这么多功能,现在我想分享一些实际使用中的心得体会。这些东西不是文档里能学到的,都是我自己用 Claude Code 一段时间后摸索出来的。

说实话,刚开始用的时候我也踩过不少坑。完全依赖它生成的代码,结果出了问题排查半天。提示词写得太模糊,得到的答案完全不是我想要的。还有最要命的一次,差点把 .env 文件传上去了,吓得我一身冷汗。

所以这一章,我想把这些经验教训都分享给你,希望能帮你少走弯路。

提示词怎么写效果好

一定要具体

我见过太多人写这种提示词:

1

claude "写个函数"

这种能写出好东西才怪。你得说清楚要什么:

1

claude "用 Python 写一个函数,接收一个整数列表,返回去重后的列表,保持原始顺序,使用集合操作优化性能"

语言、功能、输入输出、特殊要求,这些都得说清楚。你越具体,它给的答案就越接近你想要的。

上下文很重要

别让它猜你想要什么,直接给上下文:

1

claude "这是一个 Flask 应用的认证模块 [代码],请添加刷新 token 的功能,保持与现有代码风格一致"

我试过给上下文和不给上下文,效果差距挺大的。给上下文之后,它能生成更贴合你项目的代码。

格式也要指定

如果你对输出格式有要求,直接说:

1

claude "用表格格式对比这三种数据库:MySQL、PostgreSQL、MongoDB,包括:数据结构、查询语言、适用场景"

渐进式细化

复杂任务别指望一次就完美。我一般是这样:

1
2
3
4
5
6
7
8

# 第一轮:创建基础版本
claude "创建一个用户认证系统"

# 第二轮:添加功能
claude "在上面的基础上添加 JWT token"

# 第三轮:完善细节
claude "添加 token 刷新机制"

这样每一步都能验证,出了问题也好调整。我一开始总想一次搞定,结果往往要返工好几次。

我的工作流

我一般的工作流是这样的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

1. 快速原型
   └─> claude "创建项目骨架"

2. 功能实现
   └─> claude "实现具体功能"

3. 代码审查
   └─> git diff | claude "审查代码"

4. 测试生成
   └─> claude --agent test "生成测试"

5. 文档编写
   └─> claude "生成 API 文档"

这个流程用下来感觉挺顺畅的。每个步骤都有 AI 辅助,但决策权还在我手里。

关于时间节省,我大概算过:样板代码能省 80% 的时间,代码理解能省 60%,简单重构能省 50%,复杂设计能省 30%。当然,这些都是我的经验,你的情况可能不一样。

几个常见的坑

过度依赖

我见过有人完全依赖 Claude Code 写代码,生成的代码看都不看就直接用。这真的太危险了。

我自己的做法是:理解生成的每一行代码、审查和测试所有输出、把 Claude Code 当辅助工具而不是替代品。它的建议我听得,但最终决定权在我手里。

需求太模糊

“优化代码”这种提示词真的没用。你得说清楚:

1

claude "优化这个循环的性能,目标:将时间复杂度从 O(n²) 降到 O(n)"

具体目标、具体指标,这样才能得到有用的答案。

忽略上下文

如果你让它”修复这个 bug”,但不给错误日志,它怎么知道哪里错了?

1

cat error.log | claude "根据错误日志分析并修复 bug"

给足上下文,效果会好很多。

安全问题

这个真的很重要。别在提示词里包含密钥,别上传敏感数据,生成不安全的代码就更不行了。

我吃过亏,所以现在养成习惯:先用 .claudeignore 排除敏感文件,然后审查生成的代码安全性,遵循安全最佳实践。

效率提升的几个招

命令别名

1
2
3
4
5

# 在 ~/.bashrc 或 ~/.zshrc 中添加
alias cc='claude'
alias ccreview='git diff | claude "审查代码"'
alias cccommit='git diff | claude "生成提交消息"'
alias cctest='claude --agent test "生成测试"'

这个真的省时间。我天天用这些别名,比每次都敲完整命令快多了。

提示词模板

常用的提示词我一般会存成模板:

1
2
3
4
5

# ~/.claude/templates/code-review.txt
审查以下代码,关注:代码质量、潜在 bug、性能问题、安全隐患、改进建议

# 使用
cat ~/.claude/templates/code-review.txt | claude - < code.py

这样不用每次都重复写一样的提示词。

批量操作

1
2
3
4
5

# 批量生成文档
find src -name "*.py" | while read file; do
  echo "为 $file 生成文档"
  cat $file | claude "生成 docstring" > $file.new
done

批量处理确实能省时间,但记住要先在几个文件上测试,确保没问题再全量操作。

代码质量不能马虎

生成后验证

我一般会这样:

1
2
3
4
5
6
7
8
9
10
11

# 1. 生成代码
claude "创建函数..."

# 2. 语法检查
python -m py_compile script.py

# 3. 运行测试
pytest

# 4. 代码审查
claude "审查生成的代码"

这一套流程下来,基本能保证代码质量。

测试覆盖

1
2
3
4
5

# 生成测试
claude --agent test "为这个函数生成全面测试"

# 检查覆盖率
pytest --cov=src --cov-report=html

我一般会要求它生成全面的测试,包括正常情况和边界情况。

文档同步

1
2

# 代码变更后更新文档
git diff | claude "根据代码变更更新文档"

这个功能挺实用的,尤其是改完代码忘记更新文档的时候。

安全和隐私

敏感信息保护

.claudeignore 这东西我前面说过多次了,真的太重要了:

1
2
3
4
5
6

# .claudeignore
.env
*.key
*.pem
secrets/
credentials/

千万别偷懒,我吃过亏,你别犯同样的错。

代码安全审查

1

claude "审查这段代码的安全问题:SQL 注入、XSS 漏洞、CSRF 保护、认证授权、数据加密"

我一般会让它帮我检查常见的安全问题,尤其是处理用户输入的代码。

API 密钥管理

1
2
3
4
5

# 用环境变量
export ANTHROPIC_API_KEY="sk-xxx"

# 别在命令行里
claude --api-key sk-xxx "..."  # 不要这样!

这个原则适用所有密钥,不只是 Claude Code 的。

团队协作

统一提示词风格

团队共享提示词模板挺重要的:

1
2

# .claude/team-templates/api-generation.txt
使用 {language} 创建 API 端点:路径:{path}、方法:{method}、功能:{description}、认证:JWT、验证:输入验证、错误处理:统一错误格式

这样大家生成的代码风格比较一致,review 起来也轻松。

代码规范集成

1

claude "遵循团队的编码规范生成代码:[粘贴规范文档]"

把团队的编码规范告诉它,它就能按照规范生成代码。

性能优化

减少上下文

1
2
3
4
5

# 只包含相关文件
claude --add-dir ./src/auth "修改认证模块"

# 别加载整个项目
claude "修改认证模块"  # 这样会很慢

我一般在处理大型项目的时候会手动限制上下文范围,这样响应更快。

选择合适的模型

1
2
3
4
5

# 简单任务用快速模型
claude --model haiku "简单问题"

# 复杂任务用强大模型
claude --model sonnet "复杂架构设计"

这样既省钱又能保证质量。

我的经验总结

配置好 .claudeignore 真的很重要,我吃过亏,你别犯同样的错。

批量操作之前先在小范围测试,这个习惯能帮你省不少麻烦。用版本控制也是必须的,出错了随时能回滚。

提示词写清楚点,别让它猜你想要什么。你越具体,效果就越好。

生成代码之后,一定要审查、测试、理解。别直接用,出了问题麻烦的是你。

Claude Code 是助手,不是替代品。把它当工具用,别当拐杖用。

下一步

最佳实践讲完了,接下来我们聊聊怎么解决常见问题。用工具总会遇到问题,知道怎么快速定位和解决很重要。

第十一章:故障排查

下一章我会分享常见问题的诊断方法、API 问题的处理技巧、性能优化方法。