Claude Code 创建者亲授：从代码问答到并行工作流的 28 分钟实战

导读： Claude Code 创建者 Boris Cherny 用 28 分钟讲了一套很实在的进阶路线：先读懂代码，再规划改动；给它测试和截图，让它自己纠错；最后把经验写进 CLAUDE.md，再扩展到脚本与并行任务。我把演讲里的做法按 2026 年 7 月官方文档重新核了一遍；旧安装方式和快捷键变化会单独标出。

这 28 分钟，讲的是一条完整升级路线。

Boris 对 Claude Code 的定义很直接：它不是逐行补全代码的工具，而是可以读取文件、搜索项目、运行命令，再完成一个功能或修复一个 Bug 的 Agent。

视频从入门一路讲到并行工作，大致可以压成这条路线：

阶段	先练什么	判断是否学会
1	代码库问答	能让 Claude 找到入口、调用链和 Git 历史
2	规划后改代码	动手前能给出方案、风险和测试计划
3	自我验证	能运行测试、截图或模拟器并继续修正
4	项目记忆	团队共用的规则进入 CLAUDE.md
5	自动化与并行	用 -p、worktree 和多会话拆任务

最容易被忽略的是：Prompt 不是越长越好，反馈回路才决定结果上限。 Claude 能看到测试失败、页面截图或真实运行结果，通常比再补一大段形容词有效。

先把安装和基础设置配好

视频现场使用的是 npm 安装，而且要求先装 Node.js。这个细节已经过时。Anthropic 当前推荐原生安装器，macOS、Linux 和 WSL 可以直接运行：

curl -fsSL https://claude.ai/install.sh | bash

macOS 也可以用 Homebrew：

brew install --cask claude-code

安装完成后，进入你的项目目录并启动：

cd /path/to/your-project
claude

官方安装说明： https://code.claude.com/docs/en/setup

第一次启动后，先做这几件事：

• 运行 /init，让 Claude 为当前项目生成一份初始 CLAUDE.md。
• 运行 /permissions，查看哪些读写和命令需要确认。
• 运行 /terminal-setup，检查多行输入和终端快捷键。
• 需要连接 GitHub 或外部工具时，再配置 /install-github-app 和 /mcp。

不要一上来就把权限全放开。先用默认模式跑几个小任务，确认它读的是正确仓库、执行的是正确测试命令，再按需要增加权限。

第一步：先问代码，别急着让它改

Boris 给新用户的第一条建议有点反直觉：先做代码库问答，不要从写代码开始。

原因很简单。问答阶段没有文件修改风险，却能同时训练两件事：你怎么描述问题，以及 Claude 对这个项目究竟理解到了哪一层。

先试这组问题：

💡 PROMPT
先不要修改任何文件。阅读这个项目的目录结构和关键入口，回答：  

1. 应用从哪里启动？  
2. 用户登录请求经过哪些模块？  
3. 相关测试在哪里？  
4. 哪些结论来自代码，哪些只是你的推测？
   请引用具体文件路径和关键函数。

接着让它查 Git 历史。比如某个函数为什么有 15 个参数，不要只问“这段代码做什么”，而是问：

💡 PROMPT
查看这个函数及其 Git 历史。解释这些参数分别在什么提交中加入、当时解决了什么问题、是否仍然全部必要。给出相关 commit 和文件位置，但先不要重构。

视频里 Boris 还展示了一个很日常的用法：每周让 Claude 根据 Git log 总结“我这周交付了什么”。这类任务很适合入门，因为结果容易人工核对。

第二步：先规划，再让它动手

当任务从“解释代码”变成“修改代码”，先加一道计划关。视频里的核心句子其实很短：写代码前先制定计划，并等我确认。

一个更稳的中文模板可以这样写：

💡 PROMPT
先探索相关代码、测试和 Git 历史，不要修改文件。
给出 2-3 个可行方案，分别说明：  

• 要改哪些文件  
• 主要风险和边界情况  
• 需要新增或更新哪些测试  
• 哪个方案最小、最容易回滚  

推荐一个方案并说明理由。等我确认后再开始写代码。

这一步不是为了增加仪式感。大型需求如果方向错了，Agent 写得越快，返工越大。先看计划，通常一分钟就能发现它是否找错入口、漏掉兼容性，或者准备改动过多文件。

确认计划后，再给明确的完成标准：

💡 PROMPT
按方案 2 实施。保留现有 API，不引入新依赖。完成后运行相关单元测试和类型检查，汇报修改文件、测试结果和仍未覆盖的风险。不要自动提交或推送。

最后一句很重要。视频里展示了 commit, push, pr 这种极短指令，但对自己的仓库和权限还不熟时，最好把提交、推送和建 PR 分开确认。

第三步：把验证工具交给它

这段演讲里，我最推荐照抄的不是某个快捷键，而是这条工作流：

探索 → 规划 → 确认 → 实现 → 验证 → 继续修正

Claude 看到真实结果，才有机会改对。不同任务需要的“眼睛”不同：

• 后端功能：单元测试、集成测试、真实请求结果。
• Web 界面：浏览器、Puppeteer 或 Playwright 截图。
• iOS/Android：模拟器截图和运行日志。
• 数据任务：固定样例、断言、统计检查。

做网页时可以这样下任务：

💡 PROMPT
根据 mock.png 实现这个页面。先确认现有组件和设计变量，再开始修改。
完成后启动本地服务，用浏览器打开目标页面并截图；把截图与 mock.png 对比，列出差异并继续调整。最多迭代 3 轮，最后运行测试并汇报仍不一致的地方。

这里的重点不是“最多 3 轮”这个数字，而是让任务有停止条件。没有停止条件，Agent 可能在一个很小的视觉差异上反复消耗时间。

第四步：用 CLAUDE.md 把经验留下来

CLAUDE.md 是 Claude Code 每次会话都会读取的项目说明。适合写构建命令、目录约定、架构边界和团队规则；不适合塞进整本开发手册。

一个够用的项目模板可以从这里开始：

Project:
- 这是一个 Next.js 15 + TypeScript 项目。
- API 路由位于 src/app/api。
Commands:
- 安装依赖：pnpm install
- 单元测试：pnpm test
- 类型检查：pnpm typecheck
- 本地启动：pnpm dev
Conventions:
- 使用 pnpm，不要生成 package-lock.json。
- 新功能必须补测试。
- API 错误统一返回现有 ErrorResponse 结构。
- 不要修改 migrations 目录中的历史文件。
Definition of done:
- 相关测试通过。
- 类型检查通过。
- 汇报改动文件和未解决风险。

项目根目录的 CLAUDE.md 可以提交到 Git，让团队共用。个人偏好放在 CLAUDE.local.md；只对某个子目录有效的规则，可以放进该目录下的 CLAUDE.md，或者使用 .claude/rules/ 做路径范围控制。

运行 /memory 可以检查当前加载了哪些规则。新版 Claude Code 还有 auto memory，会把构建命令、调试发现和偏好写到项目记忆目录。两者不要混为一谈：CLAUDE.md 是你明确写下的规则，auto memory 是 Claude 自己积累的笔记。

官方记忆说明： https://code.claude.com/docs/en/memory

第五步：快捷操作、脚本和并行任务

视频里的快捷键表很有用，但它对应的是当时的版本。现在 Shift+Tab 会在默认、接受编辑和计划模式之间循环；上下文检查更适合用 /context；快捷键不一致时，运行 /help 或 /keybindings 查看当前配置。

几个仍然值得记住的操作：

• Esc：停止当前执行，再补充方向。
• Esc 两次：回到更早的会话节点。
• !命令：直接执行本地命令，并把命令和结果放进上下文。
• claude --continue：继续当前目录最近的会话。
• claude --resume：从会话列表中选择并恢复。
• /context：查看上下文被哪些内容占用。
• /memory：查看项目规则与自动记忆。

再往前一步，可以用 -p 把 Claude Code 当作 Unix 工具：

claude -p "总结这个项目的入口、测试命令和主要风险" \
  --output-format json

需要它运行工具时，明确限制允许范围：

claude -p "运行测试并修复失败项" \
  --allowedTools "Bash,Read,Edit" \
  --output-format json

非交互模式文档： https://code.claude.com/docs/en/headless

最后是并行。视频当时建议开多个 checkout、tmux 或手工 Git worktree。现在可以直接让 Claude Code 创建隔离 worktree：

claude --worktree feature-auth

再开一个终端处理另一个任务：

claude --worktree bugfix-123

worktree 文档： https://code.claude.com/docs/en/worktrees

并行之前先拆清任务边界。一个会话改认证、另一个会话也改认证，隔离目录只能避免文件互相覆盖，不能替你解决设计冲突。更稳的拆法是：一个会话实现功能，一个会话补测试或做只读审查，最后由主会话合并。

第一次照着实践，不必把所有功能一起打开。先完成一个小闭环：问清代码 → 看计划 → 批准修改 → 运行验证 → 把一次真实纠错写进 CLAUDE.md。 这五步跑顺了，再考虑权限放宽、脚本化和并行会话。更多实战讨论与工具分享，欢迎到云栈社区一起交流。