Claude Code 最佳实践：社区秘诀带来 10 倍生产力提升
Claude Code 已悄然成为 AI 原生开发者和知识工作者的首选工具。但在官方文档和 YouTube 教程之间，存在着一个鸿沟：真正的实践方法，这是区分高效用户和那些"向 Anthropic 捐款"的人的关键。
本指南汇集了 Claude Code 创建者 Boris Cherny、产品发现专家 Teresa Torres 和社区教育者（如 Greg Isenberg 和 Ross Mike）的见解，将官方功能与经过实战检验的工作流相结合。
核心洞见：输入质量决定输出质量
让我们从最重要的一课开始，由 Ross Mike 在 Greg Isenberg 节目中阐述：
"你的输入质量会决定输出质量。我们正处于一个模型好得不可思议的时代，如果你产生的是所谓的垃圾，那是因为你给了它垃圾。"
这不是激励性的废话——这是本指南中每一项最佳实践的基础原则。Claude 的能力已经跨越了一个门槛，质量问题可以追溯到人类指令，而不是模型限制。
第一部分：ask_user_question 的秘密
大多数 Claude Code 用户不知道这个工具的存在。那些知道的人认为它是非平凡项目中最重要的功能。
它的作用
在规划功能时，Claude 可以通过多选题对你进行采访，询问你永远不会想到指定的细节。Claude 不会接受通用的规划问题，ask_user_question 工具会强制进行精细的思考：
- 数据库选择和数据模型
- UI/UX 布局和交互
- 成本处理和边界情况
- 错误状态和恢复流程
- 测试策略
如何调用它
只需要求 Claude 对你的项目进行采访：
> Interview me about this feature: user authentication system
或更具体一些：
> Before implementing the payment flow, use ask_user_question to understand my requirements for:
> - Payment providers
> - Currency handling
> - Refund policies
> - Error recovery
Claude 会提出多选题，让你在编写任何代码之前思考决策。
为什么这很重要
Greg Isenberg 的关键见解："很多时候人们会描述一个产品，而不是描述功能，然后会对 AI 感到沮丧。" ask_user_question 方法强制你用具体功能和清晰的接受标准来思考。
前期提问的投资可以防止后期昂贵的迭代循环。正如 Ross Mike 所说："如果你有一个糟糕的计划，如果你有一个糟糕的 PRD，这一切都无关紧要。你只是在向 Anthropic 捐款。"
第二部分：上下文架构（Teresa Torres 方法）
Teresa Torres 是《Continuous Discovery Habits》的作者——她不编写代码。然而，她通过开创被称为"上下文架构"的方法，成为了最复杂的 Claude Code 用户之一。
原则
"要做好上下文，不仅仅是我们必须记录一切。我们必须用微小的文件来记录一切，这样当我们要求 Claude 执行一项任务时，我们只能给 Claude 它需要的上下文。"
这与典型的方法相反（一个庞大的 CLAUDE.md 文件）。相反，Torres 创建了精细的上下文库：
.claude/
├── CLAUDE.md # 高级项目概览
├── context/
│ ├── business-profile.md # 公司背景、目标
│ ├── writing-style.md # 语调、词汇偏好
│ ├── product-docs/
│ │ ├── auth-system.md # 身份验证详情
│ │ ├── payment-flow.md # 支付实现
│ │ └── api-design.md # API 约定
│ └── personal/
│ ├── preferences.md # 你的工作偏好
│ └── schedule.md # 可用性、截止日期
└── commands/
├── today.md # 每日任务生成
├── blog-review.md # 写作反馈
└── research.md # 研究自动化
通过上下文进行"懒惰提示"
有了广泛的上下文库，Torres 可以"懒惰地提示"：
> Claude, blog post review
Claude 会加载她的写作风格指南，并提供根据她的实际目标校准的反馈——无需冗长的解释。
为一切配对编程
Torres 最强大的见解超越了代码：
"我现在和我所做的一切都配对编程，即使它不是编程。我配对任务管理、配对写作和配对一切。"
她的自定义 /today 命令通过检查多个来源来生成每日待办事项清单：
- Markdown 任务文件
- Trello 看板
- 日历集成
- 前一天未完成的项目
第三部分：50% 上下文规则
Ross Mike 强调了大多数用户忽略的一个关键阈值：
"永远不要超过 50% 的上下文。一旦你在一个会话中达到约 100K tokens，模型质量就会下降。"
如何监控上下文
使用 /context 命令来可视化你的 token 使用情况：
> /context
这会显示一个彩色网格，显示什么在消耗你的上下文窗口。
何时启动新会话
在以下情况下启动新会话：
- 上下文超过 50%：非常大的上下文会导致质量下降
- 切换项目：不同的代码库需要不同的上下文
- 任务发生巨大变化：例如从前端到 DevOps
- 对话变得陈旧：旧信息可能会让 Claude 困惑
紧凑对话
/compact 命令可以总结你的对话历史，释放 tokens 同时保留关键信息：
> /compact focus on the authentication changes we made
这会创建一个摘要并用该摘要作为上下文重置对话。
第四部分：RALPH 循环（谨慎使用）
RALPH（以《辛普森一家》中的 Ralph Wiggum 命名）是一种自主开发技术，其中 Claude 在没有人工干预的情况下迭代地处理任务列表。
它的工作方式
- 你提供一个 PRD（产品需求文档）以及任务列表
- 一个钩子阻止 Claude 在完成每项任务后退出
- Claude 处理任务 1，记录进度，移动到任务 2
- 循环继续，直到所有任务完成
警告
Ross Mike 对 RALPH 循环持坚定立场：
"如果你没有构建任何东西，没有部署任何东西，没有一个 URL 让我或 Greg 可以点击进去看你构建的东西，你就没有资格使用 RALPH。"
RALPH 循环放大你的规划质量：
- 好的 PRD + RALPH = 能够构建完整应用程序的多天循环
- 糟糕的 PRD + RALPH = 昂贵的混乱
RALPH 的最佳实践
如果你确实使用 RALPH 循环：
- 详尽的 PRD：使用 ask_user_question 填补每一个空白
- 清晰的接受标准：每个功能都需要可测试的标准
- 测试优先验证：在继续之前，在每个功能后运行测试
- 保持在 50% 上下文以下：在整个过程中监控 token 使用情况
第五部分：Boris Cherny 原则
作为 Claude Code 的创建者，Boris Cherny 对如何思考 AI 增强型开发提供了独特的见解。
70% 生产力提升
在建立 Claude Code 的 Anthropic：
"Anthropic 员工人数增加了三倍，但由于 Claude Code，每名工程师的生产力增长了 70%。这不是自动化取代工作——这是增强创造杠杆。"
这不是自动化——这是增强。Claude 处理繁琐的部分，而人类提供判断和方向。
为未来模型而构建
"不要为今天的模型而构建。为六个月后的模型而构建。"
Cherny 的估计：一个耗时 20-30 名工程师两年的项目（Facebook Groups 迁移）现在可以由 5 名工程师在 6 个月内完成。再过 6 个月？也许只需要一个。
这意味着：
- 投资于良好的架构而不是聪明的提示
- 构建可以随模型改进而扩展的工作流
- 不要过度优化当前的限制
通才优势
"在 Anthropic，产品经理编写代码。数据科学家编写代码。用户研究者编写代码。这不是关于工作头衔模糊化——这是关于降低构建的协调成本。"
Claude Code 使这种通才方法成为可能。当每个人都可以对整个堆栈做出贡献时，速度会指数增长。
第六部分：自动化与增强
Teresa Torres 对每项任务的框架：
"我强制自己每次执行任务时都问：AI 如何帮助这个？它能自动化吗？它能增强吗？我喜欢做这个吗？我想让 AI 为我做吗？"
什么应该自动化
- 研究摘要（arXiv、Google Scholar 论文）
- 数据处理和格式化
- 样板代码生成
- 测试编写
- 文档更新
什么应该增强（保持人工参与）
- 写作（如果你喜欢的话）
- 设计决策
- 用户研究综合
- 战略规划
- 代码架构
Torres 的见解："我喜欢写作。我不想自动化写作。" 随着 AI 能力的扩展，要有意地选择哪些工作定义了你。
第七部分：必要的工作流
每日任务管理
创建一个检查多个来源的 /today 命令：
<!-- .claude/commands/today.md -->
检查我的任务来源并生成今天的优先事项：
1. 查看 @tasks/current.md 了解活跃项目
2. 检查是否有任何逾期截止日期
3. 考虑我今天的日历
4. 按影响力和紧急性排序
格式为带有时间估计的编号列表。
研究自动化
设置隔夜研究处理：
<!-- .claude/commands/research.md -->
处理我下载到 @research/inbox/ 的论文：
1. 总结关键发现（每项 3-5 个要点）
2. 确定与我的当前项目 @context/project-goals.md 的相关性
3. 提取值得保存的引用
4. 将处理的文件移动到 @research/processed/
代码审查
创建一个全面的审查命令：
<!-- .claude/commands/review.md -->
查看我当前分支中的代码更改：
1. 检查安全漏洞
2. 根据我们的标准 @context/code-standards.md 进行评估
3. 识别潜在的性能问题
4. 建议改进（要具体）
5. 注意任何缺失的测试
智能搜索
Torres 在笔记中查找内容的方法：
> I have a thing called new blog post tomorrow
Claude 搜索上下文并找到"article Wednesday"——即使你记错了也能理解意图。
第八部分：CLAUDE.md 最佳实践
你的 CLAUDE.md 文件是 Claude 的持久记忆。以下是如何有效地结构化它：
层级
企业政策（组织范围）
└── 项目记忆（团队共享，在 git 中）
└── 项目规则（模块化主题）
└── 用户记忆（你的偏好）
└── 本地项目（不在 git 中）
好的 CLAUDE.md 结构
# 项目名称
## 架构
- 框架：[你的堆栈]
- 数据库：[你的数据库]
- 关键模式：[重要约定]
## 代码标准
- [具体、可行的规则]
- [不是泛泛之谈]
## 命令
- `bun run dev`：启动开发
- `bun test`：运行测试
## 重要上下文
- [项目特定的陷阱]
- [Claude 应该始终记住的东西]
## 禁止事项
- [要避免的特定反模式]
条件规则
使用 frontmatter 进行路径特定的规则：
---
paths:
- "src/api/**/*.ts"
---
# API 开发规则
- 所有端点必须包括输入验证
- 使用标准错误响应格式
- 包括 OpenAPI 文档
第九部分：非技术用户
Claude Code 不仅仅是为开发者准备的。Teresa Torres 每天使用它，没有编码经验。
入门
- 安装 Claude Code：按照设置指南进行
- 从简单开始：要求 Claude 解释你的项目结构
- 逐步构建上下文：随着学习创建上下文文件
你可以提出的问题
> What does this code do?
> Explain this error in simple terms
> I need a feature where users can [describe what you want]
> Fix the bug when I click [describe the problem]
提示
- 具体一些："修复我点击提交时的 bug" 比"修复 bug"更好
- 分享错误：复制完整的错误文本——它帮助 Claude 诊断
- 要求解释："用简单的术语解释你刚刚做了什么"
- 命名会话：使用
/rename my-task这样你可以稍后返回
第十部分：TeamDay 集成
TeamDay 在 Linux 服务器上运行 Claude Code，使其可以通过网络浏览器访问。这意味着你可以：
- 从任何没有本地安装的设备访问 Claude Code
- 与团队成员共享会话
- 与 TeamDay 的代理生态系统集成
- 在不保持笔记本电脑打开的情况下运行长时间运行的任务
开始使用 TeamDay + Claude Code
- 创建一个 TeamDay 工作区
- 连接你的存储库
- 从网络界面启动 Claude Code 会话
- 你的 CLAUDE.md 和上下文文件会自动加载
关键要点
- 输入质量是一切：宗教般地使用 ask_user_question
- 上下文架构：精细文件优于单一文档
- 监控上下文使用情况：保持在 50% 以下，需要时使用 /compact
- RALPH 循环需要专业知识：先手动构建代表
- 选择性自动化：保留你喜欢的，自动化你不喜欢的
- 为未来构建：模型改进的速度比你的工作流快
接下来是什么
专家们同意：我们处于 AI 增强型工作的早期阶段。Boris Cherny 的预测，即一个 20-30 名工程师的项目很快就能由一个人完成，这不是夸张——这是我们正在走的轨迹。
赢家不会是那些拥有最好工具的人，而是那些投资于制作精确输入的人。从 ask_user_question 开始，构建你的上下文库，然后迭代。
来源