Claude Code 生产力指南：新手也能每天稳定交付的10个技巧

真正的效率来自固定workflow，而不是一句神奇prompt

刚开始使用 Claude Code 时，很多人会被它的能力吓一跳：它能读代码、改 bug、写测试、整理文档，甚至帮你生成 PR 说明。但过几天后，新的问题会出现：每次都要重新解释项目背景，改动范围比预期更大，最后说完成了却没有跑 build，或者下一次会话又忘了上次的判断。

所以，Claude Code 的 productivity 不是靠一句万能提示词，而是靠稳定的工作流。你需要让它知道项目目标、允许修改的范围、不能碰的地方，以及什么结果才算完成。

本文把日常使用 Claude Code 的方法整理成新手也能复制的10个技巧。官方文档里也介绍了常见工作流、记忆和设置，建议同步查看 Common workflows、Memory、Settings。这里会把这些概念翻译成更接近真实项目的操作方式。

目标	做法	效果
减少重复说明	写好 CLAUDE.md	第一次回答更准确
避免危险修改	明确范围和权限	不容易误删或乱改
交付可验证	先写验证命令	不再只靠感觉说完成

Tip 1: 先写一个短小有力的CLAUDE.md

CLAUDE.md 可以理解为 Claude Code 的项目说明书。它不应该变成一本历史记录，也不需要包含所有需求。它应该告诉 Claude：这个项目的目标是什么，技术栈是什么，质量标准是什么，哪些操作不能做。

# Project Rules

## Goal
- Grow ClaudeCodeLab as a monetized traffic source.
- Prefer useful evergreen content over thin daily posts.

## Stack
- Astro content collections
- MDX articles under site/src/content/blog*
- Cloudflare Pages deployment

## Quality
- Include real examples, pitfalls, and runnable commands.
- Preserve frontmatter, lang, and heroImage.
- Check code fences and mobile layout before publishing.

## Safety
- Do not revert user changes.
- Do not run destructive git commands.

这样写的好处是，每次新会话都能继承基本判断。比如文章项目里，Claude 会知道不要随便破坏 frontmatter，也会记得代码块在手机端曾经出过问题。

Pitfall 是把 CLAUDE.md 写得太长。太长的规则会让重点消失，也容易混入过期信息。建议只保留会影响未来决策的内容。更详细的模板可以看 CLAUDE.md 最佳实践。

Tip 2: 用「目的、对象、限制、完成条件」写需求

不要只写「帮我优化一下」。这句话对人类同事都不够清楚，对 Claude Code 也一样。更稳定的写法是四段式。

目的:
  提高这篇文章的停留时间，让初学者看完后能实际操作。

对象:
  site/src/content/blog-zh/claude-code-productivity-tips.mdx

限制:
  不要改其他文件。
  保持 frontmatter 格式。
  至少加入一个官方文档链接。

完成条件:
  有3个以上真实 use case。
  有可复制的命令或配置。
  有 pitfalls 和验证记录。

这个格式可以用于文章、UI、后端 API、测试补充、部署脚本修复。关键是让 Claude Code 知道「哪里可以动」「哪里不能动」「怎样才算完成」。

常见失败案例是把合格标准留在自己脑子里。你觉得「当然要跑测试」，但没有写出来，Claude 就可能只完成代码修改。把完成条件写成清单，会明显减少返工。

Tip 3: 大任务拆成探索、编辑、验证

如果你说「把整个网站的文章质量全部提高」，Claude Code 会面对一个很大的上下文。更好的方式是拆成三个阶段。

Step 1: Explore
读取相关文件，只提出修改方案，暂时不要编辑。

Step 2: Edit
根据方案做最小范围修改。

Step 3: Verify
运行 lint、test、build 或页面检查。失败就继续修复。

这个 workflow 很适合新仓库。第一步只理解结构，第二步再动手，第三步用命令验证。官方 common workflows 也把理解代码、修 bug、重构、测试、PR 和脚本化工作拆成可重复的模式。

Masa 的验证笔记：一次性要求「全站文章都变好」时，输出会变得不稳定。后来改成按 slug 集群处理，每次只修一组文章，再跑质量检查和移动端检查，整体可控很多。

Tip 4: 把真实错误、命令和复现步骤贴出来

不要把错误过早总结成「TypeScript 坏了」。Claude Code 需要看到原始信息。

npm run build

Type error: Property 'name' does not exist on type 'User | undefined'.
File: src/components/Profile.tsx:15:22

复现步骤:
1. npm install
2. npm run build
3. build 在上面的类型错误处停止

请求:
先解释原因，再用最小差异修复，最后重新运行 npm run build。

这个 use case 适用于构建失败、测试失败、部署失败、浏览器控制台错误。截图有帮助，但日志文本更重要，因为它可以搜索、复制和精确引用。

Pitfall 是只说「我这里报错了，你修一下」。没有命令、没有文件、没有复现步骤，Claude 只能猜，猜出来的修复很可能只是表面正确。

Tip 5: 允许安全检查命令，阻止危险命令

每次运行 npm test 都等待确认会浪费时间。但什么都允许又很危险。比较好的做法是允许常见安全检查，拒绝会删除历史或覆盖用户工作的命令。

{
  "permissions": {
    "allow": [
      "Read",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(npx tsc --noEmit)",
      "Bash(git diff --check)"
    ],
    "deny": [
      "Bash(git reset --hard)",
      "Bash(git checkout --)",
      "Bash(rm -rf *)"
    ]
  }
}

具体格式要以当前 Settings 为准，但原则很稳定：读取和验证可以放行，删除、重置、覆盖要谨慎。

如果你关心权限设计，可以继续读 Claude Code 权限设置指南。

Tip 6: 把重复检查做成脚本

自然语言适合沟通，脚本适合重复。发布前总要做的事情，不要每次都靠记忆。

#!/usr/bin/env bash
set -euo pipefail

npm run lint
npm run build
node scripts/check-code-fences.mjs
node scripts/check-updated-article-quality.mjs
git diff --check

如果在 Windows 上工作，也可以写 PowerShell。

$ErrorActionPreference = "Stop"
npm run build
node scripts/check-code-fences.mjs
node scripts/check-updated-article-quality.mjs
git diff --check

这样 Claude Code 和人类都知道「完成」不是主观判断，而是命令通过。注意不要把所有小修改都绑定到很慢的完整流程。日常检查可以轻，发布前检查可以重。

Tip 7: 记忆只保存事实和判断标准

Claude Code 的 memory 很有用，但不要把聊天记录都塞进去。应该保存下一次会话必须知道的事实。

## Project memory

- Monetization matters more than raw page count.
- After AdSense approval, avoid thin mass-produced articles.
- Code blocks must be checked on mobile before deploy.
- Preserve frontmatter, lang, and heroImage for localized articles.
- End with changed files, verification, and remaining risks.

这样的记忆能帮助下一次工作保持方向。它不会替代测试，也不会替代仓库里的文档，但能减少每次重新解释的时间。更多上下文设计可以看 Claude Code 上下文管理。

Tip 8: 三个真实use case

Use case 1: 30分钟理解新仓库

请阅读这个仓库，并说明：
1. 主要目录的作用
2. 启动、测试、构建命令
3. 新成员最应该先看的5个文件
4. 不应该随便修改的风险区域

暂时不要编辑文件。

这适合接手新项目，也适合外包或副业项目的第一天。

Use case 2: 从复现到测试修 bug

Bug:
登录后 /dashboard 显示空白页。

复现:
1. npm run dev
2. 使用 test@example.com 登录
3. 打开 /dashboard

期望:
显示收入卡片。

实际:
空白页，console 出现 Cannot read properties of undefined。

请求:
列出3个可能原因，选择最小修复，加入回归测试，并运行相关检查。

先列原因再修改，可以降低「只修表面现象」的风险。

Use case 3: 安全添加小功能

给咨询表单添加 consultation type 字段。

需求:
- 选项为 training, consulting, other
- 必填校验
- 继续使用现有提交 API
- 增加或更新一个测试

限制:
- 不重新设计整个表单
- 如果需要数据库迁移，先说明理由

完成:
- npm test 通过
- npm run build 通过

小而清楚的任务最适合 Claude Code。不要把 UI 重做、数据库迁移、营销文案和测试全部混在一个请求里。

Tip 9: 先写不想要的输出

告诉 Claude Code 什么是坏结果，通常比只说「高质量」更有效。

请避免:
- 只有抽象建议，没有实现
- 能写真实代码却只写伪代码
- 修改无关文件
- 没有验证就说完成
- 回滚用户已有修改

我需要:
- 小范围差异
- 可复制命令
- 验证结果
- 剩余风险

这个方法对内容生产也有效。如果不想要低质量 SEO 文章，就明确写「不要只做信息整理，要有真实 workflow、失败案例和验证笔记」。

Tip 10: 每次结束只要三个结果

让 Claude Code 最后报告三件事。

最后只报告:
1. 修改了哪些文件
2. 执行了哪些验证命令和结果
3. 还有哪些注意点

这样交接会非常轻。下一位开发者或另一个 agent 不需要读完整对话，也能继续工作。

Masa 的实际验证结果是：最有效的不是复杂 prompt，而是把 CLAUDE.md、四段式请求、验证脚本和权限边界先准备好。这样 Claude Code 的输出更稳定，人工 review 也更省力。

如果团队想把这套方法变成标准开发流程，可以查看 ClaudeCodeLab training and consulting。如果你是个人开发者，先把本文模板复制到一个真实项目里，用一周再决定要不要继续自动化。