首页 › LLM大语言模型 › Claude专栏 › Claude Code 完全指南:使用方式、技巧与最佳实践 › 六、最佳实践

六、最佳实践

6.1 项目组织最佳实践​

目录结构规范​

​

飞书文档 - 图片

​

CLAUDE.md 层级配置​

​

飞书文档 - 图片

​

6.2 工作流最佳实践​

探索-规划-编码-提交工作流​

这是一个完整的开发工作流程,需要配合特定的Skills和MCP使用。​

前置准备 - 安装必要工具:​

​

飞书文档 - 图片

​

详细工作流程:​

第1步:探索阶段 - 理解项目​

​

飞书文档 - 图片

​

第2步:规划阶段 - 使用Plan模式​

​

飞书文档 - 图片

​

第3步:编码阶段 - 实施计划​

​

代码块​

Bash

# 让Claude按照计划实施​

按照上面的计划开始实施​

​

# 如果遇到问题,可以要求暂停​

暂停,让我先检查一下这一步​

​

# 继续实施​

继续下一步​

​

# 运行测试​

!npm test# 修复失败的测试​

测试失败了,请帮我修复​

​

第4步:提交阶段 - 使用commit skill​

​

​

测试驱动开发(TDD)工作流​

前置准备 - 安装测试相关工具:​

​

代码块​

Bash

# 1. 安装测试编写skill(可选)​

npx skills-installer install @anthropics/claude-code/test-writer --client claude-code​

​

# 2. 或者配置test-writer子代理(后面详细说明)​

​

TDD工作流程:​

​

代码块​

Bash

# 第1步:先写测试# 使用test-writer skill或agent​

使用test-writer skill为用户登录功能编写测试,包括:​

​

代码审查工作流​

前置准备 - 创建和配置代码审查子代理:​

方式1:使用 /agents 命令创建​

​

代码块​

Bash

# 在Claude Code中​

claude​

/agents​

​

# 选择 "Create new agent"# 按提示配置:​

- Name: code-reviewer​

- Description: 专门负责代码审查的子代理​

- Instructions: 你是一个代码审查专家,专注于检查代码质量、安全漏洞和性能问题​

- Tools: read, search, git​

- Permissions: 禁止写入(allowWrite: false)​

​

方式2:手动配置文件​

​

代码块​

Bash

# 创建agents配置文件mkdir -p ~/.claude​

​

使用代码审查工作流:​

​

代码块​

Bash

# 第1步:使用子代理并行审查# 代码质量审查​

使用code-reviewer agent审查以下文件的代码质量:​

- 是否符合Clean Code原则​

- 是否有代码异味​

- 是否易于维护​

​

@src/auth.ts @src/user.ts @src/database.ts​

​

# 安全审查(并行)​

使用security-reviewer agent审查这些文件的安全问题:​

- SQL注入风险​

- XSS漏洞​

- 敏感信息泄露​

​

@src/auth.ts @src/user.ts @src/database.ts​

​

# 性能审查(并行)​

使用performance-reviewer agent审查这些文件的性能问题:​

- 算法复杂度​

​

6.3 团队协作最佳实践​

共享 CLAUDE.md​

场景:团队项目​

实施步骤:​

在项目根目录创建 CLAUDE.md​

团队共同维护​

定期更新​

版本控制​

示例:​

​

代码块​

Markdown

# 团队项目规范## 团队约定- 代码审查至少 1 人 approve​

- 所有 PR 必须通过 CI​

- 文档与代码同步更新​

​

​

GitHub 集成​

安装 GitHub App:​

​

代码块​

Bash

/install-github-app​

​

使用 PR 评论:​

​

代码块​

Bash

​

6.4 性能优化最佳实践​

极致的并行处理(Parallelism)​

来自 Claude Code 创始人 Boris Cherny 的核心理念:不要让 AI 等你,也不要让你等 AI​

终端里的"多线程"操作​

​

代码块​

Bash

# 同时运行 5 个 Claude 实例# 将终端标签页标记为 1-5# 配置系统通知(System Notifications)# 当某个 Claude 完成任务需要输入时,直接弹窗提醒# 在 ~/.claude/settings.json 中配置​

{​

"notifications": {​

"enabled": true,​

"sound": true,​

​

就好比你雇了 5 个初级程序员同时干活,你只需要负责 Review 和分配任务,效率直接翻倍。​

本地与云端的"混合双打"​

​

代码块​

Bash

# 在本地终端运行 5 个实例# 同时在 claude.ai/code 网页端运行 5-10 个会话# 利用 & 命令将本地会话"甩"给网页端后台运行​

& 将这个任务转到网页端继续​

​

# 在网页版开始新任务# 然后在终端用 claude --teleport session_id 拉回本地​

​

跨设备同步工作流​

​

代码块​

Bash

# 早上在办公室:终端 + 网页版# 中午休息:手机版 Claude App 查看进度# 晚上回家:claude --teleport 继续开发# 工作流永不中断​

​

效果对比:​

​

​

上下文管理​

策略:​

​

代码块​

Bash

# 长对话定期 compact​

/compact "保留以下要点: ..."# 新任务先 clear​

​

Token 优化​

​

​

模型选择策略​

Claude Code 创始人的独家见解: 只用最强的模型:Opus 4.5 + Thinking​

很多人为了省钱或追求速度会用 Haiku 或 Sonnet,但 Boris Cherny 只用 Opus 4.5,并全程开启 Thinking(思考)模式。​

理由:​

•

虽然 Opus 4.5 更贵、更慢,但它不需要你频繁纠正(Steer less)​

•

工具使用能力更强,一次就能做对​

•

从"任务完成总耗时"来看,聪明的大模型反而比"快但笨"的小模型更快​

•

一次做对,永远比反复修改更省时间​

土豪专属了属于是。​

国外模型选择策略:​

国外模型使用建议:​

•

快速查询/格式化: Haiku 4.5 - 最快最便宜​

•

日常开发/代码编写: Sonnet 4.5 - 性价比平衡​

•

架构设计/复杂重构: Opus 4.5 + Thinking - 最高质量(创始人首选)​

国内模型选择策略:​

国内模型使用建议:​

​

​

模型切换策略:​

​

代码块​

Bash

​

成本优化建议:​

混合使用策略:​

​

代码块​

Bash

# 日常开发用国产模型(便宜)export ANTHROPIC_MODEL=GLM-4.7​

​

# 遇到复杂任务时临时切换到高质量模型​

/model​

# 选择 Opus 4.5# 完成后切换回国产模型​

/model​

# 选择 GLM-4.7​

​

6.5 安全最佳实践​

Sandbox 配置​

​

代码块​

JSON

{"permissions": {"allow": {"bash": ["npm run *", "git *"],"write": ["src/**/*", "tests/**/*"],"read": ["**/*.ts", "**/*.js", "**/*.json"]},"deny": {"bash": ["rm -rf *", "format *", "shutdown"],"write": ["node_modules/**/*", ".git/**/*", "/etc/*", "/usr/*"]}}}​

​

Hooks 安全检查​

​

代码块​

Bash

#!/bin/bash# ~/.claude/hooks/security-check.sh# 检查敏感操作if [[ "$TOOL_NAME" == "Bash" ]]; then​

COMMAND=$(jq -r '.command' <<< "$CLAUDE_HOOK_INPUT")​

​

# 危险命令黑名单​

DANGEROUS_CMDS=("rm -rf" "format" "shutdown" "reboot" "chmod 000")​

​

for cmd in "${DANGEROUS_CMDS[@]}"; doif [[ "$COMMAND" == *"$cmd"* ]]; thenecho "🚫 拦截危险命令: $COMMAND"exit 1​

fidonefi​

​

敏感信息保护​

​

代码块​

Markdown

# CLAUDE.md 安全规范## 禁止事项- ❌ 在代码中硬编码密钥​

- ❌ 在 CLAUDE.md 中记录密码​

- ❌ 在 Git 提交中包含凭证​

​

6.6 验证闭环(Feedback Loop)​

来自 Claude Code 创始人的最重要的一条技巧:永远给 Claude 一种验证自己工作的方法​

核心原理​

如果 Claude 能看到自己代码的运行结果(报错信息、测试通过与否),它的代码质量会提升 2-3 倍。​

实践方法​

简单的任务:运行 Bash 命令验证​

​

代码块​

Bash

# 编写代码后立即验证​

请实现一个用户登录功能,然后:​

​

复杂的 UI:使用浏览器自动化​

​

代码块​

Bash

# 使用 Claude Chrome 扩展​

请修复这个 Bug 并验证:​

1. 用 Chrome 打开 http://localhost:3000/login​

2. 输入测试账号和密码​

3. 点击登录按钮​

4. 检查是否正确跳转到首页​

5. 查看控制台是否有报错​

6. 直到体验"感觉对劲"为止​

​

端到端验证流程​

​

代码块​

Bash

​

效果对比​

​

​

为什么验证循环如此重要?​

人类开发流程:​

写代码​

手动测试​

发现 bug​

修复 bug​

重复测试​

Claude + 验证循环流程:​

Claude 写代码​

Claude 自己测试​

Claude 看到错误​

Claude 立即修复​

Claude 再次验证​

循环直到完美​

关键差异:​

•

Claude 能立即看到错误信息​

•

Claude 不需要等待人工反馈​

•

Claude 可以在几秒内完成多个修复循环​

•

最终代码质量远超人工编写​

最佳实践建议​

✅ 推荐做法:​

​

代码块​

Bash

​

❌ 避免做法:​

​

代码块​

Bash

# 不要让 Claude"盲写"​

请实现功能 X​

# (没有验证步骤,Claude 不知道代码是否正确)​

​

​