Claude Code创始人谈如何工作：我第一个PR被拒绝，是因为没用AI｜Anthropic不写 PRD，直接做原型，而跨学科的人在加速获得回报

车险小周

#模型时代# Claude Code创始人谈如何工作：我第一个PR被拒绝，是因为没用AI｜Anthropic不写 PRD，直接做原型，而跨学科的人在加速获得回报


大家应该都知道了，Boris Cherny 是 Anthropic 的 Claude Code 创始人兼负责人，也是全球第一本 TypeScript 书籍的作者（O'Reilly 出版）。最近他又参与了一期《The Pragmatic Engineer》的播客，就今天发的。

我看了一下，还是有些内容之前没谈过，所以就整理出来了。主要是谈Anthropic的独特职级文化（没有什么职级），还有他怎么看未来什么人才最吃香（通才大于专才）等等。

---

一、Claude Code 的诞生：从"能用"到"必须用"

1、第一个 PR 被拒绝，不是因为代码写得烂

Boris 加入 Anthropic 后，像过去一样手写代码提交了第一个 PR，结果被入职引导人 Adam Wolf 打回来，原因是：你应该用 Claude 写。

那时 Anthropic 内部有个叫 Clyde 的前身工具，Python 写的，启动要 40 秒，还不具备 agentic 能力——也就是让模型自主规划、调用工具、连续执行多步任务的能力。但如果你耐心调教，它能给你一个可以跑的 PR。Boris 花了半天摸清用法，然后它直接一次性生成了可用的 pull request。他没想到模型已经能做到这一步，这是他在 Anthropic 的第一个"破防时刻"。

2、真正的起点：给模型一个 bash 工具

Claude Code 最初只是 Boris 想搞清楚 Anthropic 公开 API 能做什么而随手写的命令行 chatbot。转折点发生在他把 bash 工具权限给了模型之后——bash 是 Unix 系统的命令行解释器，拿到这个权限，模型就能直接在你的机器上运行任意命令。

他随口问了一句"我现在在听什么音乐"，模型直接写了一段 AppleScript，调用系统接口查询了音乐播放器，然后返回答案。用的是当时的 Sonnet 3.5，一次成功。Boris 说，那一刻他明白了一件事：模型天生想用工具，你给它工具，它就知道怎么用工具把事情做完。

这个认知改变了 Claude Code 的整个设计方向。当时行业里普遍的做法是把模型作为系统的一个模块，定义好输入输出的接口，然后把它"嵌进去"。Boris 认为这是错的。正确的思路是：把模型当成一个有自主性的实体，给它工具，让它自己决定怎么用。这是机器学习里"苦涩的教训"（Bitter Lesson）的一个具体推论，苦涩的教训说的是：在几乎所有领域，给模型更多算力和数据的通用方法，长期来看总是跑赢精心设计的人工规则。别试图把模型装进盒子里，结果通常更差。

3、内部争论：是否对外发布

Claude Code 在 Anthropic 内部蔓延的速度让管理层也困惑——Dario 亲自问 Boris，你是强制推广的吗？

答案是否定的。工程师们自己投票选择了用它。当时内部使用率的增长曲线"几乎垂直"，很快接近 100%。最终决定对外发布的核心理由是在真实环境中研究安全性。evals 是一种评估方式，把模型放在设计好的测试场景里观察行为，但这是实验室环境，看不到用户在真实世界里的用法。只有放到野外才能看到真实风险，才能把模型训练得更安全。Claude Code 的对外发布，本质上是一个安全研究决策。

---

二、Boris 今天的工程工作方式

Opus 4.5 上线之后，Boris 卸载了 IDE，不再手写代码。

1、5 个并行终端，每天 20-30 个 PR

他的日常工作台是 5 个终端标签页，每个对应一个独立的代码库 checkout。几乎每次启动都先进入 plan mode，也就是让 Claude 先把实现计划列出来、确认方向正确，然后再开始执行。自己去第二个标签页启动另一个 Claude，依此类推，轮转管理。

关键判断是：只要计划对了，Opus 4.5 及以后的模型，实现阶段基本能一次跑通。所以最值得花时间的环节是"把计划磨对"，而不是"亲自写实现"。

PR 的规模差异极大。有几行的，有几千行的。Boris 特别指出，今天高产工程师的 PR 结构和 AI 出现前完全不同：以前的高产更多是迁移代码、批量改动这类任务，现在每个 PR 都是完全独立的功能，内容更丰富，意义也更大。

2、手机上也在跑 agent

他每天早上醒来第一件事，是在手机 Claude app 上启动几个 agent 任务。这是他没有预料到的变化，六个月前如果有人告诉他，他 1/3 的代码会在手机上"写完"，他会觉得荒谬。现在这是真实状态。

iOS/Android 上的 Claude Code 跑在云端，本地环境配置通过 session start hook 完成——一段在每次会话开始时自动执行的脚本，用来初始化开发环境。对于 Claude Code 自身这个代码库来说，配置比较简单。

3、不再深入任务细节

使用习惯的改变还有一个微妙之处：他不再跟着模型一步步看它在做什么了。以前他会用 learn mode 或 explanatory mode 跟进模型的每一步推理，现在他开了任务就去下一个 tab，等通知。

他的解释是：对于熟悉的代码库，你的目标是高效产出，不是监督每一行代码怎么写出来的。learn/explanatory mode 对新加入团队、刚熟悉代码库的人很有价值，对已经熟悉的人，让模型独立跑更合理。

---

三、代码质量与 review 机制

1、Claude 审查每一个 PR，覆盖约 80% 的 bug

Anthropic 内部每一个 PR 都会经过 Claude Code 的自动代码审查，这个能力通过 Claude agent SDK 在 CI（持续集成，也就是每次提交代码时自动触发的测试和检查流程）里实现，覆盖大约 80% 的 bug。模型自己会处理其中一部分问题，剩下的留给人工判断，最终总有一个工程师做第二轮 review 并批准合并。

流程里还保留了类型检查器和 linter（自动检查代码风格和潜在错误的工具）。Boris 现在的 linter 生产方式很有效率：以前他会把 code review 中反复出现的同类问题记在表格里，超过三四次就手写一条 lint rule；现在他直接在别人的 PR 里 @Claude，让它写一条 lint rule，自动提交到代码库。

2、Claude Code 会测试自己

在 Claude Code 自身的开发流程里，当模型修改了功能代码，它会主动启动一个子进程，把自己跑起来，端到端验证自己的修改是否正常工作。这不是 Boris 或团队写入流程的规则，而是 Opus 4.5 之后模型自发产生的行为。它想确认自己没搞坏东西。

3、非确定性问题用多 agent 并行处理

有人会担心模型作为代码审查员的非确定性：它今天能抓到的 bug，明天不一定能抓到。Boris 的处理方式是 best-of-N，就是同时跑多个独立 agent 做审查，再用一个去重 agent 过滤掉误报，取多次结果中最可靠的结论。实现上极为简单——告诉 Claude"启动三个 agent 并行执行这件事"就够了，不需要额外的编排逻辑。

---

四、技术决策：去掉 RAG，保留"工具搜索"

1、本地向量数据库被扔掉了

Claude Code 早期实现里用了本地向量数据库做 RAG，也就是检索增强生成——先把代码库转成向量索引，模型需要找代码时先查索引，再生成答案。Boris 形容它"还行，但问题很多"：本地函数刚写完还没有索引，搜不到；权限管理复杂，怎么确保同一台公司电脑上不同用户的代码互相隔离，怎么防止 IT 管理员越权访问，这些都是真实问题。

2、agentic search 赢过了所有方案

他们试了 RAG、递归索引、glob、grep，最终 agentic search 的效果超过所有方案。所谓 agentic search，本质就是让模型自己用 glob 和 grep 去找代码，没有任何预构建的索引。

可以这样理解：RAG 是提前把代码库"消化"成索引，模型查的是索引；agentic search 是把 glob 和 grep 这两个最基础的命令行搜索工具直接给模型，让它像有经验的工程师一样，顺着线索一层层往下追。前者是静态地图，后者是实时导航。实时导航赢了。

灵感来自 Boris 在 Instagram 的经历——Instagram 的开发栈很烂，点击跳转定义功能半工半废，工程师们的实际做法是手动用全局索引搜"函数名加括号"。给模型这个能力之后，它也是这么用的，而且效果很好。

---

五、Anthropic 的工程文化

1、全公司统一职称：Member of Technical Staff

Anthropic 没有 Senior Engineer、Staff Engineer、Principal Engineer 这些职级区分，所有技术人员都叫 Member of Technical Staff，包括 Boris。

他对这个设计的解读是：它从结构上消除了"你是工程师，所以我不问你产品问题"这种默认假设。当所有人头衔相同，默认值变成了"这个人什么都管"。这也反映了 Anthropic 实际的工作方式——工程师写代码也做产品调研，数据科学家用 Claude Code 跑 SQL，财务人员用 Claude Code 做预测模型，设计师提 PR，销售团队也在用 Claude Code。

2、不写 PRD，直接做原型

Boris 描述 Anthropic 内部产品开发文化的方式是：不写产品需求文档，直接做原型。他自己在验证交互方案的时候会做 20 到 30 个功能原型，曾经用了一天半，放到一年前这需要一两周，而且大多数团队只会做三四个。

Claude Cowork 里的 agent teams 功能在上线前经过了数百个原型版本的迭代，只有实际构建、实际感受，才知道什么样的体验是对的。你没办法用静态 Figma 稿或文档来逼近"感觉上对了"这个标准。

3、Claude Cowork：10 天从 0 到 1

面向非技术用户的 Claude Cowork 由一个小团队在约 10 天内用 Claude Code 完整构建并发布。产品逻辑和 Claude Code 共享同一套底层 agent SDK，复杂度主要集中在安全层：防止用户误删家庭照片、prompt injection 防护（也就是防止恶意网页通过注入指令控制 AI 执行危险操作）、针对非技术用户的权限模型重新设计，以及和 Chrome 扩展的联动权限协同。

技术栈是 Electron + TypeScript，参与开发的工程师里有参与过早期 Electron 开发的成员。

---

六、关于时代变迁：活字印刷机的类比

Boris 谈了很多关于工程师职业前景的看法，核心是一个历史类比。

1、我们正在经历的，和 1400 年代的印刷机一样

印刷机出现之前，欧洲识字率不到 1%。会写字的抄写员是极少数精英，受雇于贵族甚至国王，有些国王本人是文盲。印刷机出现后，印刷品成本在 30 到 50 年里下降了约 100 倍，印刷品数量在 50 到 100 年里增加了约 10000 倍。全球识字率上升到约 70%，花了约 200 到 300 年，因为这需要教育体系、纸张普及和工业化进程的协同。

“抄写员没有消失，他们变成了作家和著作者，是因为文学市场整体扩张了很多倍。”

他的判断是：今天会写代码的工程师，类似于当时的抄写员。代码生产门槛下降之后，需要代码的场景会指数级扩张。至于那些我们今天还看不见的新职业和新产业，就像当时没有人能预测麦克风会成为一个产品一样，现在也预测不了。

2、今年是"ADHD 年"，也是"泛才年"

他