AI Notes

Appearance

Claude Code 创建者的实战方法：从代码库问答到自验证闭环 ​

出处

来源：原网页 1 · 原网页 2

一句话结论 ​

Claude Code 的高质量结果并不主要来自“万能提示词”，而来自一套可重复的工程方法：先让 Agent 理解代码库，再通过计划控制方向，通过工具补足上下文，通过测试和截图形成反馈闭环，最后把有效经验沉淀为团队共享的项目配置。

一张图看懂 ​

Claude Code 创建者的实战方法：从代码库问答到自验证闭环

核心观点 ​

1. 第一步不是让 Agent 写代码，而是让它回答代码库问题 ​

Boris Cherny 最推荐的新手入口是 codebase Q&A，也就是先把 Claude Code 当成代码库研究助手。

适合先问的问题包括：

  • 这个模块承担什么职责，主要调用链是什么
  • 某个类或函数在项目里是如何实例化和使用的
  • 某个设计为什么会变成现在这样
  • 某些奇怪参数是在哪次提交中引入的
  • GitHub issue、提交记录和当前实现之间是什么关系

这种方式比直接要求 Agent 实现功能更稳，因为使用者可以先建立对 Agent 能力边界的认识：

  • 哪些问题可以一次回答好
  • 哪些问题需要继续追问
  • 哪些任务必须交互式推进
  • 哪些判断仍然需要工程师亲自确认

视频中提到，Anthropic 会在技术入职第一天让新人这样使用 Claude Code。他们的技术入职时间据称因此从约 2～3 周缩短到 2～3 天。这个数字未必能直接复制到其他团队，但“先用 Agent 加速理解，再让它参与修改”的顺序值得采用。

2. 大任务先讨论方案，把昂贵的错误暴露在写代码之前 ​

让 Agent 直接实现一个几千行规模的需求，有时能够成功，但也可能生成一个完整却方向错误的方案。

Boris 给出的办法很简单：明确要求它在写代码之前先探索、思考和规划。

text
暂时不要写代码。
先阅读相关实现并理解现有约束，提出可行方案和主要权衡。
给出实施计划，等我确认后再开始修改。

这里真正有价值的并不是某一句固定提示词，而是把任务拆成两个成本不同的阶段：

  1. 在低成本的方案阶段校准目标、范围和设计
  2. 确认方向后，再进入高成本的代码修改阶段

这相当于把人放在最需要判断力的节点，而不是让人逐行监督 Agent 的操作。

3. Agent 能否检查自己的工作，决定了结果上限 ​

视频中信息密度最高的一点，是要给 Claude Code 提供观察结果的工具。

如果 Agent 只能生成代码，它交付的通常只是第一版草稿；如果它能够运行测试、查看报错、启动应用、截取界面并比较结果，它就可以自己迭代两三轮，让结果逐步收敛。

不同任务可以使用不同的反馈信号：

  • 后端：单元测试、集成测试、类型检查、静态分析
  • 前端：启动本地服务、浏览器操作、截图和设计稿比较
  • 移动端：模拟器运行结果和截图
  • 数据任务：统计量、抽样检查、异常值和约束校验
  • 运维任务：日志、监控指标和健康检查

可以把验证要求直接写进任务：

text
完成修改后不要直接宣布结束。
运行相关测试并检查结果；如果失败，分析原因、修复并重新验证。
如果是界面任务，启动应用并截图检查，与参考图比较后继续迭代。

这说明 Agent 工作流的核心不是一次生成，而是一个闭环：

执行 → 观察 → 判断差异 → 修正 → 再验证

4. CLAUDE.md 的作用是把隐性经验变成共享上下文 ​

CLAUDE.md 会在 Claude Code 会话开始时自动进入上下文。它适合记录每次工作都可能用到、但模型无法仅靠阅读代码稳定推断出的信息：

  • 常用构建、测试和检查命令
  • 项目的架构决策与依赖边界
  • 重要入口文件和目录职责
  • 代码风格与团队约定
  • 内部 CLI、MCP 工具的使用方法
  • 特殊限制和高频踩坑点

项目根目录中的共享规则应该提交到版本控制，让团队只维护一次、所有人共同受益。个人偏好则放在本地配置中，不必污染团队规则。

子目录还可以放置局部 CLAUDE.md，只在 Agent 进入对应模块时加载。这是一种按需提供上下文的方式，避免把所有知识一次性塞满上下文窗口。

Boris 也特别提醒：CLAUDE.md 应尽量短。它不是项目百科全书，而是高密度的行动指南。

5. 应该沉淀可复用工作流，而不只是保存聊天记录 ​

对于反复发生的任务，可以把提示和步骤沉淀成 Slash Commands、CLI 脚本或 CI 流程，例如：

  • 根据 Git 历史生成个人周报
  • 对 GitHub issue 自动分类和打标签
  • 检查 PR 的测试覆盖和潜在回归
  • 从日志或监控数据中提取异常
  • 按仓库惯例执行 commit、push 和创建 PR

视频把 Claude Code 的非交互模式描述成一种“智能 Unix 工具”：它可以接收管道输入，使用限定工具，并输出 JSON 或流式 JSON，从而嵌入 CI、事故响应和团队内部流水线。

这带来的变化是：Agent 不再只服务于一次对话，而可以成为既有工程系统中的一个可组合部件。

6. 工具接入的价值，在于复用团队已经拥有的能力 ​

Claude Code 不需要为每个内部系统重新设计专用交互界面。只要团队已有 CLI 或 MCP 服务，就可以告诉 Agent：

  • 工具叫什么
  • 在什么场景使用
  • 必要时通过 --help 学习参数
  • 哪些命令允许执行，哪些需要审批

当这些工具说明写入共享项目配置后，任何进入仓库的工程师都能直接获得相同能力。

视频举出的例子是 Anthropic 在应用仓库中共享 Puppeteer MCP 配置。工程师不必分别安装和摸索，就能让 Claude Code 执行端到端测试、截图并根据结果继续迭代。

7. 并行会话只有和工作区隔离结合才有意义 ​

高阶用户会同时运行多个 Claude Code 会话，提高任务吞吐量。例如：

  • 会话 A 实现功能
  • 会话 B 补测试
  • 会话 C 调查另一个 bug

但多个 Agent 不应该同时在同一个工作目录里随意修改文件。视频提到的常见做法是多个 checkout 或 Git worktree，让每个任务拥有独立工作区。

并行提高的是吞吐量，隔离解决的是变更冲突、状态污染和任务互相覆盖的问题。没有隔离的并行，很容易把节省的执行时间重新花在合并和排错上。

8. 权限应按风险分层，而不是全部允许或逐条打断 ​

在问答环节，Boris 提到 Claude Code 最难实现的部分之一是 Bash 安全。

如果每一条命令都要求人工批准，工程师会持续被打断；如果默认允许所有命令，Agent 又可能意外改变系统状态。

更合理的设计是分层控制：

  • 明确的只读命令可以自动执行
  • 常用测试和检查命令可以进入允许列表
  • 文件修改可在受控范围内自动接受
  • 网络访问、删除、部署、凭据和不可逆操作继续保留审批
  • 团队可以通过企业策略统一允许或禁止特定行为

权限配置的目标不是单纯减少弹窗，而是在安全边界内降低无意义的人机同步成本。

9. 多模态能力使“设计稿 → 实现 → 对比”成为完整工作流 ​

Claude Code 虽然运行在终端中，但可以读取图片。视频问答中提到，可以通过拖放、复制粘贴或文件路径把设计稿交给它。

真正有效的用法不是只让它“照图写页面”，而是同时提供浏览器或模拟器，让它看到自己的实现结果：

  1. 输入设计稿或参考图
  2. 实现界面
  3. 启动应用
  4. 截取当前结果
  5. 与参考图比较
  6. 修正差异并重新验证

这再次印证了全文的核心：模型能力很重要，但可观察、可迭代的执行环境更重要。

核心脉络 ​

这段视频真正想传达的工作方式 ​

  1. 先通过代码库问答建立理解和信任边界
  2. 对复杂任务先探索和规划，再进入实现
  3. 把团队 CLI、MCP 和既有工具交给 Agent
  4. 用测试、截图和运行结果提供客观反馈
  5. 将反复有效的上下文写入 CLAUDE.md
  6. 将高频流程封装为命令、脚本或自动化流水线
  7. 用独立 worktree 承载并行会话
  8. 用分层权限平衡效率和安全

可以把它压缩成一个公式：

高质量 Agent 结果 = 足够的上下文 + 合适的工具 + 可验证的反馈循环 + 关键节点上的人工判断

对实际工作的启发 ​

1. 新项目的默认起手式应该从“调查”开始 ​

text
先不要修改文件。
阅读相关代码、文档和 git 历史，解释当前实现、关键调用链和设计原因。
列出你仍不确定的地方，以及修改这里最可能造成的回归。

这种起手式既能帮助人理解项目，也是在检验 Agent 是否真的找对了上下文。

2. 复杂任务使用固定的六阶段流程 ​

text
1. 调研：阅读代码、文档、issue 和 git 历史，不修改文件。
2. 复述：说明对需求、现状和约束的理解。
3. 计划：提出方案、风险和验证方法，等待确认。
4. 实现：按确认后的计划完成修改。
5. 验证：运行测试或启动应用检查，失败则继续修复。
6. 交付：总结变更、验证结果、剩余风险和人工检查项。

这套流程比追求某个“神级提示词”更稳定，也更容易在团队中复制。

3. 判断一个任务是否适合交给 Agent，要先看验证成本 ​

最适合 Agent 的任务通常具有明确的成功信号：测试能否通过、页面是否与参考图一致、输出是否满足 schema、错误是否消失。

如果一个任务无法定义“完成后如何证明是对的”，那么先补验证机制，往往比继续优化提示词更有价值。

4. 团队推广应该从共享项目上下文开始 ​

与其要求每个成员各自摸索提示词，不如先共同维护一个短小的 CLAUDE.md，记录：

  • 正确的构建和测试方式
  • 最容易犯错的项目约束
  • 内部工具的入口
  • 重要模块的职责
  • 安全边界

这是投入很小、网络效应很强的起点。

5. 不要把帖子附带的功能清单当成方法论本身 ​

附带文章列出了 Projects、Memory、Artifacts、Scheduled Tasks、Skills、浏览器控制、CLAUDE.md 和 Prompt Caching 等功能。它适合用来发现能力入口，但文风明显偏营销，具体产品名称、入口、价格和能力边界也可能随时间变化。

比功能清单更值得长期保留的是两个原则：

  • 把稳定背景放入持久上下文，减少重复解释
  • 不要只让 AI 顺着自己说，要主动要求它寻找反例、薄弱假设和失败路径

例如在重大决定前使用：

text
不要支持我的结论。
请构造反对它的最强论证，指出关键假设、三个最现实的失败方式，
以及出现什么新信息时我应该改变决定。

我认为最值得记住的三句话 ​

  1. 先用 Agent 理解代码库，再让它修改代码库。
  2. 第一次生成只是草稿，能观察结果并持续验证，才会让质量真正收敛。
  3. 不要把精力只花在提示词上，要建设上下文、工具、权限和反馈闭环。

原文标记 ​

  • 视频主讲人：Boris Cherny，Claude Code 创建者、Anthropic 技术人员
  • 分享形式：Claude Code 实战技巧演讲与现场问答，视频时长约 27 分钟
  • 转发与整理者：Anatoli Kopadze
  • 原帖标题要点：CLAUDE.md、memory shortcuts、parallel sessions、prompting patterns
  • 原帖与视频：https://x.com/AnatoliKopadze/status/2078827490575843583
  • 附带文章：Claude Can Do All of This. Most People Have No Idea.
  • 附带文章链接：https://x.com/i/article/2057813254617858078
  • 说明：本文以视频内容为主要依据，附带文章仅用于补充功能背景；中文内容为学习提炼与重写，并非逐字翻译。视频中的产品界面、命令名称和功能状态应以使用时的官方文档为准。

Copyright © 2026 openalon. All rights reserved.