学 Claude Code：先问代码，再让它动手

这篇根据小抄收录的 Boris 演讲整理帖提炼工作方法。原帖含约 28 分钟的视频与双语转录；这里给出适合第一次上手的练习路径，不复刻逐字稿。演讲提到的具体命令和产品菜单可能随版本变化，操作时以 Claude Code 当前界面和官方文档为准。

1. 从代码库问答开始

先在一个你熟悉的项目里问三个只读问题，暂时不要让它改文件：

这个项目的入口在哪里？列出关键文件和调用关系，并给出引用位置。先不要修改代码。

这个函数在哪里被调用？哪些测试覆盖了它？请区分实际读到的代码与推测。

这个行为为什么这样设计？先查相关提交历史和文档，再说明证据与不确定之处。

这能让你熟悉它如何搜索文件、追踪调用和阅读 Git 历史，也能看出它在哪些问题上需要补充上下文。对于新项目，先问答往往比上来就交付一个大功能更容易校准预期。

2. 先约定结果，再修改

问题清楚以后，让它先比较方案：

目标是修复这个登录错误。先给出两到三种实现方案、影响文件、回退方式和需要验证的行为；我确认方案后再修改。

确认后再让它改代码。一个任务最好包含触发条件、期望行为、约束和验收标准。例如“提交空表单时，在字段下显示错误且焦点移到第一个无效项；桌面和手机都可键盘操作”。这比“把表单做好”更可验证。

3. 给它能检查结果的工具

演讲反复强调反馈回路：有测试、页面截图、模拟器或日志，它才能发现偏差并继续修改。完成一次改动后，可要求：

运行与本次改动相关的测试，检查差异；如果是页面，分别在手机和桌面截图。列出通过的证据、仍未验证的行为，以及你实际改过的文件。

不要把“命令执行了”当作“功能通过了”。检查测试结果、页面状态、错误日志和最终差异。涉及部署、付款、发消息或其他外部操作时，先看清影响范围与实际授权。

4. 把稳定上下文留在项目里

演讲建议用项目级 CLAUDE.md 记录团队反复需要的事实，而不是把整套仓库文档复制进去。一份短文件通常足够：

# Project context
- Entry points: src/main.ts, server/app.ts
- Test command: npm test
- Build command: npm run build
- Before changing the API, check docs/api-contract.md
- Never commit credentials or generated private subscriptions

可复用的命令、架构约束和重要文件适合共享；个人偏好和敏感资料不要放进公开仓库。团队的 CLI 或 MCP 工具可按项目接入，但要核对权限、数据来源和工具输出，不要把“能调用”误当成“结果已证实”。

5. 再考虑自动化和并行

熟悉单任务后，再尝试把 Claude Code 接进 CI、脚本或多个隔离工作区。并行会增加冲突与验证成本；先保证每个任务有自己的工作目录、清楚的输入、验收标准和最终审查。原帖也提到用终端、SSH 与 tmux 继续会话，这属于工作方式选择，不是初学者必须完成的安装步骤。

演讲中提到“没有远程代码索引”，这不等于任何代码都不会进入模型请求。涉及私有仓库时，仍要以当前产品的数据处理说明、账户设置与组织政策为准。第一周最值得练习的不是快捷键，而是问清代码 → 制定可检查的改动 → 让工具验证 → 亲自复核结果。