本文永久链接 – https://tonybai.com/2026/01/05/claude-code-author-reveals-private-ai-coding-config

大家好，我是Tony Bai。

自从 Claude Code 发布以来，我和大家一样，都在探索这个“终端里的 AI 智能体”到底能爆发出多大的能量。

就在昨天，Claude Code 的创造者、Anthropic 的核心工程师 Boris Cherny 在社交媒体上毫无保留地晒出了他自己的 Claude Code Setup（配置与工作流）。

看完他的分享，我最大的感受是：英雄所见略同！

Boris 的很多“私房技巧”，不仅验证了 AI 原生开发的高效性，更令人惊喜的是，其中 80% 的核心实践，竟然都与我的专栏《AI 原生开发工作流实战》中的教学内容完美印证。

今天，我就带大家深度拆解一下这位“Claude Code 之父”的开发心法，结合他晒出的真实配置代码，看看Claude Code作者们都是如何驾驭 AI 的。

心法一：多线程并发 —— 做 AI 的“指挥家”

Boris 分享的第一个技巧就非常硬核：

“I run 5 Claudes in parallel in my terminal… I also run 5-10 Claudes on claude.ai/code.”
（我在终端里并行运行 5 个 Claude… 同时在网页端也运行 5-10 个。）

这意味着什么？这意味着他把自己变成了一个“任务调度器”。

这正是我们在专栏 “概念篇” 中反复强调的开发者角色转型：从“代码的生产者”转变为“工作流的指挥家”。

在 Boris 的截图中，我们可以清晰地看到他正在运行多个独立的 Session，其中一个正在处理复杂的类型检查和构建任务：

Bash(bun run typecheck 2>&1 | head -100)
Bash(bun run build:agent-sdk-typings && tsc ...)
# ... AI 正在自主修复类型错误 ...

在 AI 原生时代，我们的生产力不再受限于打字速度，而是受限于并发管理能力。你可以同时开启多个 Session：1 号 Claude 负责修 Bug，2 号 Claude 负责写测试，3 号 Claude 负责重构。你不再是自己在写代码，你是在指挥一个“虚拟团队”。

心法二：上下文的艺术 —— 极简主义的 CLAUDE.md

Boris 也晒出了他的 CLAUDE.md 文件。出乎意料的是，它非常简洁，没有任何冗余的废话。

Boris 的 CLAUDE.md 真实代码：

# Development Workflow

**Always use bun, not npm.**

```sh
# 1. Make changes

# 2. Typecheck (fast)
bun run typecheck

# 3. Run tests
bun run test -- -t "test name"  # Single suite
bun run test:file -- "glob"     # Specific files

# 4. Lint before committing
bun run lint:file -- "file1.ts" # Specific files
bun run lint                    # All files

# 5. Before creating PR
bun run lint:claude && bun run test

这完美印证了我们在专栏 第 06 讲《上下文的艺术（上）：详解CLAUDE.md 与 AGENTS.md》 中的观点：CLAUDE.md 是 AI 的操作手册，必须精准、可执行。

注意看他的第一句：Always use bun, not npm. —— 这是一个典型的“负向约束”。他在教 AI “做什么”的同时，更明确了“不做什么”，这能极大地减少 AI 犯错的概率。

心法三：将经验“代码化” —— Slash Commands 与 Sub-agents

Boris 提到他极度依赖 Slash Commands（斜杠指令） 和 Sub-agents（子智能体）：

“I use slash commands for every ‘inner loop’ workflow… This saves me from repeated prompting.”
（我把所有高频工作流都封装成了 Slash Commands，这让我免于重复写 Prompt。）

他展示的 .claude/commands/ 目录结构简直就是我们专栏 第 08 讲 自定义指令：精通Slash Commands，打造你的私人命令集 的最佳教具：

.claude/
  commands/
    build-validator.md   # 专门负责构建验证的指令
    code-architect.md    # 专门负责架构设计的指令
  agents/
    code-simplifier.md   # 一个专门负责简化代码的 Sub-agent
    verify-app.md        # 一个专门负责全链路测试的 Sub-agent

他把“架构设计”、“代码简化”、“应用验证”这些复杂的脑力劳动，全部封装成了可一键调用的指令和专家分身。把你的经验变成代码，让 AI 替你执行经验，这才是高阶玩家的玩法。

心法四：自动化收尾 —— Hooks 的妙用

这也是我最喜欢的一部分。Boris 展示了一个非常漂亮的 PostToolUse Hook 配置，用来解决代码格式化问题：

Boris 的 settings.json 配置片段：

"PostToolUse": [
  {
    "matcher": "Write|Edit",
    "hooks": [
      {
        "type": "command",
        "command": "bun run format || true"
      }
    ]
  }
]

这段配置的含义是： 每当 AI 使用 Write 或 Edit 工具修改了文件后，立刻、自动执行 bun run format。

他的逻辑非常清晰：AI 负责写逻辑，Hook 负责格式化。 AI 生成的代码可能有格式问题，但通过 Hook 自动运行 prettier 或 gofmt，就能解决这“最后的 10%”。

这完全对应了我们专栏 第 11 讲《事件驱动：详解Hooks机制，让AI在关键节点自动触发》 的实战案例。我们当时也演示了如何用 Hook 实现 Go 代码的自动格式化，简直是异曲同工！

心法五：安全第一 —— 拒绝 YOLO

最后，Boris 特别展示了他的权限配置搜索界面，并强调：

“I don’t use –dangerously-skip-permissions. Instead, I use /permissions.”
（我从不使用危险的跳过权限模式，而是使用权限白名单。）

即使是工具的开发者本人，也对安全保持着绝对的敬畏。他展示的权限白名单列表（Allowlist）非常详细：

Bash(bq query:*)
Bash(bun run build:*)
Bash(bun run lint:*)
Bash(bun run test:*)
...
Bash(cc:*)
Bash(comm:*)

他宁愿多花点时间把常用的 bun run、bq query 命令一条条加入白名单，也不愿意让 AI 在“裸奔”状态下运行。

这也正是我们在 第 09 讲《安全基石（上）：用权限控制与沙箱为AI戴上“安全镣铐”》 中苦口婆心强调的：没有安全，就没有生产力。 盲目追求全自动（YOLO 模式），是在给未来埋雷。

小结：未来已来，你准备好了吗？

看完 Boris 的分享，我更加确信：我们正在经历一场软件工程范式的彻底重塑。

Boris Cherny 是这个工具的创造者，他定义了“上限”；而我们作为使用者，需要通过系统的学习，去触达这个上限。

如果你也想：

• 像 Boris 一样，构建一套属于自己的 AI 驾驶舱；
• 掌握 Slash Commands 和 Hooks，让 AI 乖乖听话；
• 学会 SDD（规约驱动开发），让代码生成一次做对；
• 搭建 Headless 自动化流水线，让 AI 在你睡觉时也能干活…

那么，欢迎加入我的极客时间新专栏 《AI 原生开发工作流实战》。

在这门课里，我不只会教你工具的用法，更会带你像 Boris 一样思考——如何用 AI 重塑你的开发习惯，成为新一代的“AI 架构师”。

扫描下方二维码，让我们一起，站在巨人的肩膀上，开启 AI 原生开发之旅！

(P.S. 专栏内容偏实战，以 Go 语言项目为例，但方法论通用于所有语言。Claude Code 也是一个刚刚诞生不到一年的新物种，我们都是探索者，期待在课程里与你交流碰撞！)

资料链接：https://x.com/bcherny/status/2007179832300581177

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/01/04/stop-lying-to-the-compiler

大家好，我是Tony Bai。

“半夜被值班的运维同事叫醒，发现生产环境崩了，原因是一个深藏在业务逻辑里的 nil 指针异常。”

这个场景，对于每个后端开发者来说都是挥之不去的噩梦。事后复盘时，我们往往会懊恼：“为什么这里没加 if != nil 判断？”然后，我们在代码里撒上一把防御性检查的“盐”，祈祷下次好运。

但这真的是解决之道吗？

最近，Daniel Beskin 的一篇深度好文《The Compiler Is Your Best Friend, Stop Lying to It》（编译器是你最好的朋友，别再对它撒谎了），为我们提供了一个全新的视角：这些运行时崩溃，本质上是因为我们在编译时对编译器撒了谎。

我们告诉编译器“这是一个字符串”，但实际上它可能是 nil；我们告诉编译器“这个函数返回一个整数”，但实际上它可能抛出一个 panic。当我们停止撒谎，开始用类型系统表达真实意图时，编译器将从一个“报错机器”，变成我们最强大的“安全副驾驶”。

我们对编译器撒过的“谎”

在 Go 语言的日常开发中，我们常常为了“方便”而向编译器撒谎，埋下了日后爆炸的地雷。

谎言一：隐形的 nil

当我们定义 func Process(u *User) 时，我们告诉编译器：“给我一个 User，我处理它。” 但在 Go 中，指针可以是 nil。
* 谎言：我承诺会处理一个 User。
* 真相：我可能会收到一个 nil，然后炸掉。
* 后果：为了弥补这个谎言，我们需要在函数内部写无数的 if u == nil 防御性代码。一旦遗漏，就是生产事故。

谎言二：盲目的类型断言与 any

当我们使用 interface{} (或 any) 时，我们实际上是在对编译器说：“别管这个，我知道我在做什么。”
* 谎言：这个 any 类型的变量，其实是一个 int。
* 真相：它可能是一个 string，或者 nil。
* 后果：运行时的 panic: interface conversion: interface {} is string, not int。

谎言三：隐藏的副作用与 Panic

当我们看到一个函数签名 func Parse(s string) int 时，编译器认为它是一个将字符串映射为整数的函数。
* 谎言：这是一个纯粹的转换函数。
* 真相：如果字符串格式不对，我会直接 panic，中断整个 goroutine。
* 后果：调用者无法通过函数签名预知风险，导致程序在边缘情况下意外崩溃。

停止撒谎，开启“对话”

如何重建与编译器的信任关系？答案是：将运行时的检查，提前到编译时的类型定义中。

策略一：让非法状态无法表示

这是消除 nil 和无效数据的终极心法。

• 场景：一个配置项 Port，如果是 0 表示随机端口，如果是正数表示指定端口。
• 糟糕的设计：Port int。你必须在代码各处检查 Port < 0 的情况，并且含义模糊。

• 诚实的设计：

  type Port int
  
  // 使用构造函数来保证 Port 的合法性
  func NewPort(p int) (Port, error) {
      if p < 0 || p > 65535 {
          return 0, fmt.Errorf("invalid port")
      }
      return Port(p), nil
  }
  

  一旦你通过 NewPort 拥有了一个 Port 类型的值，编译器就为你担保：它一定是一个合法的端口号。你后续不再需要防御性检查(未通过NewPort获得的除外)。

策略二：用类型区分概念

• 场景：用户 ID 和 订单 ID 都是 int64。
• 糟糕的设计：func GetOrder(userID, orderID int64)。调用者很容易把两个 ID 传反，而编译器毫无察觉。

• 诚实的设计：

  type UserID int64
  type OrderID int64
  
  func GetOrder(uid UserID, oid OrderID) { ... }
  

  现在，如果你试图把 UserID 传给 OrderID，编译器会直接报错。这不是繁琐，这是编译器在帮你 Review 代码。

策略三：显式的可空性

虽然 Go 没有 Rust 的 Option，但我们可以利用指针的语义来诚实地表达“可能不存在”。

• 场景：更新用户信息，只更新非空字段。
• 诚实的设计：
  go
type UpdateUserRequest struct {
Name *string // nil 表示不更新，非 nil 表示更新为新值
Age *int
}
  这里，指针不再是“可能导致崩溃的引用”，而是“可选值”的显式类型标记。这让代码的意图对编译器和人类都一目了然。

编译器是你的朋友，不是敌人

很多时候，我们觉得编译器很烦人：它阻止我们快速写出“能跑”的代码，强迫我们处理每一个 err，纠结于类型转换。

但 Daniel Beskin 提醒我们：编译器是你唯一一个会不厌其烦地帮你检查每一个细节、永远不会疲倦、永远不会因为“差不多就行”而放过 Bug 的队友。

当你觉得编译器在“阻碍”你时，停下来想一想：是不是我在试图对它撒谎？

• 如果类型不匹配，是不是我的数据模型设计得不够清晰？
• 如果错误处理太繁琐，是不是因为我试图把不确定的状态传递得太远？

小结：睡个好觉的秘诀

“防御性编程”是一种补救措施，它假设代码是脆弱的。而“类型驱动开发”是一种预防措施，它利用编译器构建坚固的堡垒。

当我们开始尊重类型，停止用 any 和隐式约定来糊弄编译器时，我们获得的回报是巨大的：

• 重构时的自信：修改一个类型，编译器会告诉你所有需要调整的地方。
• 更少的测试：你不需要测试“端口号是否为负数”，因为类型系统保证了它不可能为负。
• 更安稳的睡眠：因为你知道，那些导致半夜崩溃的低级错误，早在你按下 go build 的那一刻，就被忠诚的编译器拦截在了门外。

资料链接：https://blog.daniel-beskin.com/2025-12-22-the-compiler-is-your-best-friend-stop-lying-to-it

你的“撒谎”时刻

读完这篇文章，你是否也意识到了自己曾在代码中对编译器撒过的“谎”？在你的项目中，有哪些因为类型定义不清而导致的“血案”？或者，你有哪些利用类型系统来规避 Bug 的独门绝技？

欢迎在评论区分享你的反思与心得！ 让我们一起学会“诚实”编程，睡个好觉。

如果这篇文章颠覆了你对编译器的认知，别忘了点个【赞】和【在看】，并转发给你的团队，一起提升代码的“诚实度”！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。