The Pragmatic Engineer Podcast

Building Claude Code
with Boris Cherny

Claude Code 创造者 Boris Cherny 深度访谈 -- 从 Meta 七年到 Anthropic,一个改变软件工程方式的工具是如何诞生的

The Pragmatic Engineer 97 min 17 Chapters 2025
Chapter 00

Boris 的起源故事

从 eBay 上卖宝可梦卡片发现 HTML,到计算器上写汇编作弊,Boris 的编程之路始于极其实用的动机。

💻
13岁学 HTML

在 eBay 卖宝可梦卡时发现了 blink 标签,用它让卡片从 49 分卖到 99 分。编程从一开始就是实用工具。

🎓
计算器写汇编

在 TI-83 上写答题器给全班用,随着考试变难,从 BASIC 降到汇编来提速。8年级就碰底层了。

🚀
创业基因

大学辍学做多个创业项目,包括大麻评测网站和 YC 医疗软件公司。每次失败都在验证产品市场匹配。

"Coding is a means to build things and to make useful things. I never thought that coding would be a career at all. It was always very practical to me." -- Boris Cherny

医疗软件的产品课

在 YC 创业公司 Agile Diagnosis,Boris 发现医生根本没时间用他们的决策树软件 -- 5分钟的间隙,3分钟等电脑启动,剩下的不够登录。他骑摩托车去 UCSF 跟随医生观察了两天才发现这个问题。这种"先理解用户,再写代码"的方式,定义了他之后的职业风格。

Takeaway
  • 编程是达成目标的手段,不是目标本身。Boris 从不为技术而技术。
  • 去现场观察用户比在办公室猜想重要一百倍 -- 这在 AI 时代依然成立。
  • 创业的本质是不断验证假设,想法几乎总是错的,关键是快速迭代。
⚡ 一人公司启示
  • Boris 13岁用 HTML 卖卡赚差价,16岁接外包买吉他 -- 一人公司的原始形态。不需要完美技能才能开始赚钱
  • 医疗软件的教训:花大力气做的东西用户可能根本不会用。先去找到真实的痛点,MVP 验证后再投入。
  • Boris 自己做工程、设计、用户研究、记账 -- 和一人公司创始人一模一样的全栈角色。
Chapter 01

Meta 七年:代码质量之路

从 Facebook Groups 到领导整个 Meta 的代码质量,Boris 在7年里获得4次晋升,并总结出代码质量对工程效率有两位数百分比的因果影响。

📈
Better Engineering 计划

Zuckerberg 要求每个工程师花 20% 时间修复技术债。Boris 建立了集中优先级排序和效果追踪体系,发现代码质量对工程效率有两位数百分比的因果贡献。

🌏
日本远程工作

妻子在日本农村工作,Boris 从那里远程为 Instagram 工作。时差反而成了优势 -- 没有会议,有更多时间做 code review,成为公司最高产的审查者之一。

从 Instagram 糟糕的技术栈说起

Facebook 拥有世界最好的 Web 技术栈(Hack + HHVM + GraphQL + React + Relay),而 Instagram 是"类型检查不工作、跳转定义不工作的 Python + Django"。Boris 到 Instagram 后无法高效工作,于是主动转去做 DevInfra,推动了 Python 到 Facebook monolith 的迁移和 REST 到 GraphQL 的迁移。

"Code quality actually contributes like double digit percent to productivity. It turns out even at the biggest scale." -- Boris Cherny
Takeaway
  • 代码质量不是奢侈品 -- Meta 的数据证明它对工程效率有双位数的因果影响。
  • 始终完成迁移:代码库处于半迁移状态时,工程师(和 LLM)都会选错框架。
  • 干净的代码库对 AI 也更友好 -- 模型在混乱的代码库里更容易做出错误选择。
⚡ 一人公司启示
  • 即使是 MVP 也要保持代码整洁。不是为了好看,而是因为你以后会让 AI 在上面继续开发。
  • Boris 的"自动化自己"哲学:code review 中重复出现3次的问题就写成 lint 规则。一人公司要把重复劳动变成自动化
  • 远程+时差反而让 Boris 更高产。环境限制有时是伪装的优势
Chapter 02

加入 Anthropic:第一个 PR 被拒

Boris 加入 Anthropic 后手写了第一个 PR,结果被 ramp buddy Adam Wolf 拒绝 -- "你应该用 Clyde 来做这个。"这成了他的第一个 AI 顿悟时刻。

为什么选择 Anthropic

Boris 面试了多家 AI 实验室,选择 Anthropic 的原因是安全使命。作为一个重度科幻读者,他深知 AI 可能走向灾难的路径,而 Anthropic 聚集了"认真思考这个问题的人"。

"I just know how bad this thing can go and I just felt like this is a place that has serious thinkers. People are taking this very seriously and thinking about what can we do to make this thing go better." -- Boris Cherny

Clyde:Claude Code 的前身

Clyde 是一个用 Python 写的研究工具,启动要 40 秒,不具备 agentic 能力,需要精确的 prompt 才能工作。但即便如此,它在半天的学习成本后,一次性生成了一个可工作的 PR。Boris 在 2024 年 8-9 月经历了他在 Anthropic 的第一个"天啊"时刻。

Takeaway
  • 即使是"很烂的"AI 工具也可能比手写代码更高效 -- 不要因为工具不完美就拒绝使用
  • 在 AI 公司,手写代码已经是"旧时代的做法" -- 思维方式的转变比工具本身更重要
⚡ 一人公司启示
  • Boris 在顶级 AI 公司的第一天就被强制使用 AI 写代码。如果你还在手写大部分代码,你已经落后了
  • 选择公司/合作伙伴时,使命和价值观比薪资更重要 -- Boris 选 Anthropic 是因为安全使命,这也是他能全力投入的原因。
Chapter 03

Claude Code 的诞生

从一个终端聊天机器人到给它 Bash 工具后的"第二个顿悟时刻",再到内部爆发式增长和"要不要对外发布"的辩论。

💬
阶段一:聊天机器人

Boris 想了解 Anthropic API,写了个终端聊天工具。"那时候 AI 就是聊天机器人。"

🔧
阶段二:给它 Bash

Tool Use 功能发布后,Boris 给聊天机器人加了一个 Bash 工具。问它"我在听什么音乐",Sonnet 3.5 一次性写了 AppleScript 去查音乐播放器。

🚀
阶段三:内部爆发

内部采用率曲线"垂直上升"。Dario 问"你是不是在强迫大家用?"Boris 说不是,人们用脚投票。如今 Anthropic 80% 的代码由 Claude Code 编写。

"The model just wants to use tools. If you give it a tool, it will figure out how to use it to get the thing done. Don't try to put the model in a box. Don't try to force it to behave a particular way." -- Boris Cherny

核心设计哲学

不要把模型当作程序的一个组件。当时所有人的思路都是"在程序里挖个洞,塞进一个 AI 模块"。Boris 的顿悟是反过来:让模型自己决定用什么工具、写什么程序。这是 Bitter Lesson 的一个推论。

"Always understand the layer under" -- Boris 给工程师的建议是始终理解你工作的底层。10年前是理解 VM 和框架,今天是理解模型。

为什么对外发布

内部有过激烈辩论:这个工具让 Anthropic 工程师极其高产,要不要公开?最终决定发布,因为在真实环境中研究安全(in the wild)能获得实验室和评测无法给出的洞察。事实证明这是正确的决定。

Takeaway
  • 不要把 LLM 当组件塞进传统架构,给它工具、给它自由、让它自己规划执行。
  • "理解底层"的建议永不过时,只是底层变了:从 VM 变成了模型。
  • 产品增长的秘诀:做出好东西 -> 内部先用 -> 听用户反馈 -> 不断改进。没有强制推广。
⚡ 一人公司启示
  • Claude Code 最初就是 Boris 一个人做了三个月的 side project。一个人也能做出改变行业的工具
  • "给模型工具,让它自己用" -- 在搭建自己的 AI 工作流时,给 Agent 足够的工具和权限比精细控制每一步更有效。
  • Anthropic 对外发布的逻辑是"通过真实使用来学习安全"。你的 MVP 也一样:发布才能学到真正的教训
Chapter 04

Boris 的日常工作流

5个终端标签、Plan Mode 起步、手机上开始一天的编码、每天 20-30 个 PR,零手写代码。

🖥
5 个并行 checkout

5个终端标签,每个有独立的代码仓库 checkout。循环启动 Claude Code,几乎总是从 Plan Mode 开始(Shift+Tab 两次)。溢出到桌面应用的 Work Tree 功能。

📱
手机上写代码

每天起床先在 iOS App 上启动几个 agent。Boris 自己估计大约三分之一到一半的代码是在手机上完成的。半年前他绝不会相信这件事。

"I wrote maybe 10-20 pull requests every day. Opus 4.5 and Claude Code wrote 100% of every single one. I didn't edit a single line manually. Opus introduced maybe two bugs, whereas if I had written that by hand, that would have been like 20 bugs." -- Boris Cherny

关键工作流细节

Plan Mode 先行:在进入实现前,先和 Claude 反复打磨计划。Opus 4.6 到了"有好计划就能一次完成实现"的水平。

没有唯一正确的方式:Claude Code 被设计为 hackable,因为每个工程师的工作流都不同。"We're like craftspeople -- you choose your tools."

Opus 4.5 是转折点:从那时起 Boris 卸载了 IDE,因为发现一个月都没打开过。模型写的代码比他自己手写的 bug 少 10 倍。

Takeaway
  • Plan Mode 是最重要的步骤 -- 花时间和 AI 对齐计划,实现几乎能一次完成。
  • 并行是生产力倍增器:5个标签轮转,一个在跑时去管下一个。
  • 工具要 hackable -- 通过 hooks 和配置适应自己的工作流,不要适应工具。
⚡ 一人公司启示
  • 在手机上写代码意味着碎片时间也能变成生产力。通勤、排队、等人的时候启动一个 agent。
  • 一人公司不需要"一整天坐在电脑前"才能高产。Boris 的工作流证明编排比执行更重要
  • 每天 20-30 个 PR、零手写 -- 这是一人 = 一个团队的真实案例。
Chapter 05

并行 Agent 策略

什么时候用 Learn Mode 深入跟踪,什么时候放手让多个 agent 并行,以及角色从"执行者"到"编排者"的转变。

两种模式,两种场景

新代码库 = Learn/Explanatory Mode:当你不熟悉代码库时,用 /config 设置 explanatory 输出风格,让 Claude 解释它在做什么。这也是 Anthropic 新人入职的推荐方式。

熟悉代码库 = 并行 Plan Mode:一旦熟悉了代码库,角色就从"跟踪执行"变成"编排多个 agent"。在第一个标签启动 Plan Mode、等它跑起来后去第二个标签、第三个标签......收到通知后回来审查。

"I don't really go deep into tasks anymore. I start a Claude in plan mode, have it kick something off. Once there is a good plan, it will oneshot the implementation almost every time." -- Boris Cherny
Takeaway
  • 学习期用 Learn Mode,生产期用并行 Plan Mode -- 两种模式不矛盾,按场景切换。
  • 高效的工程师不再"深入任务细节",而是做 agent 的项目经理
  • Plan Mode 的核心价值:在前期把计划磨对,后面的执行就是一次性的。
⚡ 一人公司启示
  • 一人公司创始人的角色正在从"写代码的人"变成"管 agent 的人"。这和管团队其实是一样的技能。
  • 不必对每个 agent 的每一步都紧盯。信任但验证:审查输出,不监控过程。
  • 你以前管不了5个项目同时推进,现在可以了 -- 5个终端标签就是5个"员工"。
Chapter 06

代码审查的新范式

从 Meta 时代的电子表格追踪 review pattern,到今天让 Claude 写 lint 规则、CI 里跑 Claude 审查,再加人类最终把关。

Boris 在 Meta 的 Code Review 方法

每次在 review 中发现重复问题就记录到电子表格。当同一类问题出现超过3-4次,就写一个 lint 规则自动化它。"I've always tried to automate myself away."

Claude Code 团队的三层审查

🤖
第一层:Claude 自测

Claude 写完代码后会自动运行测试,甚至会启动自己的子进程来端到端测试 Claude Code 本身。这是 Opus 4.5 开始自发出现的行为。

第二层:CI 中的 Claude

每个 PR 都由 Claude (Agent SDK) 在 CI 中做 code review,能捕获约 80% 的 bug。并行启动多个 agent + 去重 agent 做 best-of-N 来提高确定性。

👤
第三层:人类把关

最终仍然有工程师做第二轮审查并批准变更。"至少现在,必须有人在回路里。"

"Claude is actually so good at writing lint rules. Now, when a coworker puts up a PR and I think 'this is lintable', I'll just be like: @Claude, please write a lint rule for this." -- Boris Cherny
Takeaway
  • 确定性 + 非确定性混合:类型检查 + lint(确定性)+ Claude 审查(非确定性 + best-of-N)+ 人类(最终判断)。
  • 让 AI 写 lint 规则 -- 用 AI 来建立自动化护栏,而不是依赖 AI 每次都记得检查。
  • 个人项目可以直接 yolo 到 main,企业产品必须有人类在回路里。审查强度要匹配风险等级
⚡ 一人公司启示
  • 一人公司没有 code reviewer,但你可以用 Claude 做 CI review。在 GitHub Actions 里跑 Claude 审查你的每个 PR
  • Boris 的"电子表格 -> lint 规则"模式适用于一切重复工作:第三次手动做同一件事时,就该自动化它
  • best-of-N 策略(多个 agent 并行审查 + 去重)是提高 AI 审查可靠性的实用技巧。
Chapter 07

Claude Code 的架构

令人惊讶地简单:一个核心查询循环 + 不断增删的工具集 + 多层安全机制。复杂的是安全,不是功能。

极简架构

🔄
核心 Agent 循环

一个查询循环 + 一组工具。工具经常被添加和删除 -- 团队在不断实验。

💻
端到端层

处理用户交互、终端集成、IDE 扩展等前端体验。

🔒
安全层(最复杂)

多层安全机制:模型对齐、分类器检测、静态分析、用户权限控制 -- 瑞士奶酪模型。

Prompt Injection 的三层防护

以 Web Fetch 为例(Claude 读取网页可能遇到恶意指令):

1. 模型对齐:Opus 4.6 是"Anthropic 发布过的最对齐的模型",它本身就能识别并拒绝恶意指令。

2. 分类器:专门训练的检测模型,覆盖模型层可能遗漏的情况。

3. 人类确认:对高风险操作要求用户明确授权。

"For safety and security, there's no one perfect answer. It's always a Swiss cheese model. You need a bunch of layers and with enough layers, the probability of catching anything goes up." -- Boris Cherny
Takeaway
  • 简单架构 + 深度安全是正确的优先级。功能可以迭代,安全必须从第一天就多层。
  • 不要追求完美的单一防线 -- 瑞士奶酪模型:多层不完美的防护叠加出足够的安全。
  • 对齐(模型层)+ 检测(分类器层)+ 确认(人类层)是任何 AI Agent 安全的三板斧。
⚡ 一人公司启示
  • Claude Code 架构极简 -- 不要过度架构。一个循环 + 几个工具就能做出世界级产品。
  • 安全不是大公司的专利。你的 Agent 如果能执行 bash 命令,至少要有权限确认机制
  • "工具经常被添加和删除" -- 保持架构灵活,让实验成本趋近于零。
Chapter 08

权限与沙箱系统

即使是 find 和 sed 这样的"安全"命令也有执行任意代码的方式。权限系统从 Claude Code 的第一个版本就存在。

Unix 命令的安全陷阱

Claude Code 默认对权限非常保守。原因是:即使是看起来安全的 Unix 命令也可能被利用。find 命令有 -exec 标志可以执行任意代码,sed 也有类似的系统调用方式。很少有工具真正是"只读"的。

三级权限模型

用户可以配置 allow list,对每个需要权限的命令选择:

运行一次 / 本次会话允许 / 全局允许

这个权限系统从 Claude Code 最初版本就存在。团队还对 allow list 本身做安全检查,确保用户不会无意中开放危险权限。

Takeaway
  • 默认保守,用户可以逐步放开 -- 这是正确的安全默认策略。
  • 不要假设任何命令是安全的 -- 即使是标准 Unix 工具也有隐藏的执行路径
  • 权限系统不是事后补丁,应该从 v1 就设计进去。
⚡ 一人公司启示
  • 如果你在做任何让 AI 执行系统命令的工具,权限确认是第一天就要做的功能
  • Claude Code 的三级权限(一次/会话/永久)是很好的 UX 模式 -- 可以复制到你自己的 Agent 产品里。
Chapter 09

Anthropic 的工程文化

统一头衔 "Member of Technical Staff"、通才优先、速度优先、以及 demo 文化如何驱动产品决策。

🌱
统一头衔:MTS

所有人都叫 "Member of Technical Staff"。效果:默认假设每个人都什么都能做。这打破了"你是工程师所以我不问你产品问题"的壁垒。

速度文化

团队极小,迭代极快。想法 -> 快速原型 -> 内部测试 -> 决定是否发布,整个流程可能只需几天。

通才 > 专才

Anthropic 大量招聘通才。一个典型的"软件工程师"可能同时在做产品设计、用户研究、写需求文档、写产品代码、写基础设施代码、甚至做一些 ML 研究。Boris 认为这就是软件工程的未来。

"When everyone's title is member of technical staff, by default you assume everyone does everything. It inverts the relationship between people even if you don't know each other well yet." -- Boris Cherny
Takeaway
  • 头衔塑造行为。统一头衔 = 通才文化自然生长。
  • Demo 驱动而不是文档驱动 -- 让人看到东西比让人读到东西更有说服力。
  • 跨学科能力越来越值钱:能同时理解工程、产品和商业的人将创造最大的价值。
⚡ 一人公司启示
  • 一人公司创始人天然就是 "Member of Technical Staff"。Anthropic 最强的工程文化恰好和一人公司完全一致
  • 速度文化的核心不是"加班",而是减少流程开销。一个人不需要 alignment meeting。
  • Demo 文化:每做完一个功能就自己录个 demo 或截图发出去,比写长文档有效。
Chapter 10

Claude Cowork:为非工程师而生

10天建成、从监控番茄到恢复婚礼照片、以及为什么"看到非工程师跳过障碍来使用你的工具"是最强的产品信号。

潜在需求的信号

大量非工程师在用 Claude Code:有人用它监控番茄植物(摄像头 + Claude 每天汇报生长状况),有人用它从损坏的硬盘恢复婚礼照片,Anthropic 的财务团队和销售团队也在用。当人们跳过层层障碍来使用一个不是为他们设计的产品时,就该为他们做一个专属产品了。

"In the product world, when you see latent demand -- you see people jumping through hoops to use a product that was not designed for them -- that's a really good sign it's time to build another product that is built just for them." -- Boris Cherny
Takeaway
  • 最强的产品信号:人们在"不应该"使用你的产品的场景中使用它。
  • 不要从零开始 -- 新产品应该站在现有基础设施之上,这就是10天能做出来的原因。
  • AI 工具的下一个大市场不是工程师,是所有知识工作者
⚡ 一人公司启示
  • 如果有人在以奇怪的方式使用你的产品,不要把它当 bug,把它当机会
  • 10天做一个产品 -- 在 AI 时代完全可能。一人公司的迭代速度应该以天为单位
  • 番茄监控的故事说明 AI Agent 的使用场景远比你想象的广泛。不要限制自己的想象力
Chapter 11

可观测性与隐私

作为企业产品,Anthropic 看不到用户的数据。这让 bug 调查变得极其困难,也倒逼了隐私优先的日志设计。

看不到用户数据

Anthropic 作为企业公司极度重视隐私。当用户报告 bug 时,Boris 无法查看用户的日志。这要求团队在设计日志和事件时就考虑隐私保护 -- 只记录必要的结构化数据,不记录用户内容。

增长拐点

Claude Code 最初不是一夜爆红。真正的增长拐点是 2025 年 5 月 Opus 4 和 Sonnet 4 发布时。而 Cowork 则从发布第一天就获得了压倒性的正面反馈 -- 说明市场已经被 Claude Code 教育好了。

Takeaway
  • 隐私不是功能,是约束 -- 在这个约束下设计系统,而不是事后打补丁。
  • 产品增长曲线不一定是 J 型的。慢启动 + 模型升级触发拐点也是有效路径。
⚡ 一人公司启示
  • 如果你的产品处理用户数据,从第一天就设计隐私保护的日志方案
  • 产品早期增长缓慢不代表失败。有时候你只是在等底层能力跟上来
Chapter 12

Agent Swarms:多 Agent 协作

从 sub-agent 到 Agent Teams,以及"不相关上下文窗口"的概念 -- 为什么有时候遗忘是一种优势。

不相关上下文窗口 (Uncorrelated Context Windows)

相关上下文

在同一个上下文窗口里做两个任务,第二个任务知道第一个任务的信息。Skill(/command)使用的就是父上下文。

不相关上下文

Sub-agent 的上下文窗口是全新的,除了来自父 agent 的 prompt 外,不知道父上下文的内容。有时候这种"遗忘"反而是优势。

Agent Teams

Agent Teams 允许一个 lead agent 将任务分配给多个 teammate agent。Boris 强调:不相关上下文窗口 + 更多上下文是两个独立的维度,把它们结合可能产生超线性的效果

"There's this interesting thing where uncorrelated context windows and just throwing more context at the problem -- these are two different approaches and combining them tends to produce superlinear results." -- Boris Cherny
Takeaway
  • 有时候让 agent 不知道全局反而更好 -- 不相关上下文减少干扰。
  • 扩展 AI 能力的三种方式:更多上下文、无限上下文(自动压缩)、多 agent 协作
  • Skill(共享上下文)和 Sub-agent(隔离上下文)是两种不同的工具,按需选择。
⚡ 一人公司启示
  • 把复杂任务拆成多个独立的 sub-agent 比塞进一个超长 prompt 更有效。
  • 让一个 agent 写代码、另一个 agent 审查,审查者不知道"心路历程",只看结果
  • Agent Teams = 一人公司的"虚拟团队"。你是 lead,AI 是 teammates。
Chapter 13

印刷术类比:LLM 与软件工程的未来

中世纪的抄写员变成了作家和编辑。软件工程师正在经历同样的转变。

"One metaphor I have for this moment in time is the printing press in the 1400s. There was a group of scribes that knew how to write. Some of the kings were illiterate who were employing the scribes. And if you think about what happened to the scribes, they ceased to become scribes, but now there's a category of writers and authors." -- Boris Cherny

Boris 的框架

抄写员没有消失,他们进化了。印刷术让抄写的技能贬值,但创造了全新的"作家"和"编辑"角色。同样,手写代码的能力在贬值,但理解要构建什么、如何验证、如何系统性思考的能力正在急剧升值。

印刷术还让文学市场扩大了无数倍。同样,AI 编码工具将让"软件"的市场扩大无数倍 -- 以前无法被软件化的领域现在都可以了。

Takeaway
  • 技能在贬值,判断力在升值。关注"做什么"和"为什么",而不是"怎么写"。
  • 市场在扩大 -- AI 不是在消灭工程师的岗位,而是在让更多事情变得可以被软件化
  • 允许自己为失去的东西感到悲伤,但不要停留在那里。进化,别怀旧
⚡ 一人公司启示
  • 这是一人公司的黄金时代。以前需要团队才能做的软件产品,现在一个人就够了。
  • 你的优势从来不是写代码本身,是理解问题 + 快速验证 + 交付价值
  • 印刷术让"作家"诞生。AI 编码工具让"一人 SaaS 创始人"诞生。你就是新时代的"作家"
Chapter 14

杰出工程师的画像

Boris 在 Anthropic 看到的三种杰出原型:快速原型者、产品市场匹配者、跨界混合人才。

🌟
快速原型者

从0到0.5的人 -- 能快速验证一个想法是否可行,理解技术能做什么不能做什么。

🎯
PMF 专家

从0.5到1的人 -- 能把原型变成有真实用户的产品。理解用户需求,能找到产品市场匹配。

💎
跨界混合人才

横跨产品+工程+基础设施,或设计+工程,或工程+商业的人。越来越多,也越来越有价值。

信念的改变

Boris 对安全问题的态度从"可能重要"变成了"最重要的事情"。从内部看到过去一年出现的新风险后,他对 AI 安全的担忧大幅增加了。

⚡ 一人公司启示
  • 一人公司创始人必须同时具备这三种能力:快速原型(验证想法)、找 PMF(商业化)、跨界思维(产品+技术+商业)。AI 可以弥补你不擅长的部分。
  • 三种原型对应三个阶段:想到 -> 做出来 -> 卖出去。你在哪个阶段最弱?
Chapter 15

哪些技能依然重要

代码风格和语言之争可以扔掉了。方法论思维、好奇心、跨学科能力比以前更重要。

可以放下的

语言之争和代码风格之争。模型可以用任何语言和框架,如果你不喜欢,让它重写就好。这些争论不再有意义。

比以前更重要的

🔍
方法论思维

假设驱动、系统化思考 -- 对产品设计、调试、验证 AI 输出都至关重要。

💡
好奇心与跨界

理解业务端就能做出真正好的产品。下一个十亿美元产品可能来自一个同时懂工程、产品和商业的人。

📖
类型化思维

Boris 推荐函数式编程,因为它教会你用类型思考 -- 这种思维方式在指导 AI 时同样有效。

"I think the next billion dollar product, the next trillion dollar startup, it might just be one person that has some cool idea and their brain is able to think across engineering and product and business, or design and finance and something else." -- Boris Cherny
Takeaway
  • 停止争论语言和框架。这是 AI 时代最不重要的选择了。
  • 方法论思维(假设 -> 验证 -> 迭代)在任何时代都是核心技能。
  • 跨学科 = 超级能力。能横跨 2-3 个领域的人将创造最大的价值。
⚡ 一人公司启示
  • Boris 在描述"下一个万亿美元公司可能是一个人"的时候,他就是在描述一人公司创始人
  • 不要花时间学第N个框架了。把时间花在理解商业、理解用户、理解市场上。技术执行交给 AI。
  • "好奇心"是 Boris 多次提到的关键词。一人公司创始人最大的竞争优势就是对世界的好奇心 + 快速执行的能力
Chapter 16

Boris 的书籍推荐

科幻读物理解未来,函数式编程修炼思维。

📚
刘慈欣短篇小说集

《三体》作者的短篇集。Boris 是刘慈欣的粉丝,推荐不仅限于三体本身。

📚
Accelerando

Charles Stross 的科幻小说。"本质上就是未来50年的产品路线图。"从 AI 起飞写到木星轨道上的龙虾意识体。关键是它捕捉到了加速的感觉

📚
Functional Programming in Scala

即使语言选择不再重要,Boris 依然强烈推荐。"它教会你用类型思考。做所有习题,我做了三遍。"

"Accelerando is essentially the product roadmap for the next 50 years. It starts with takeoff starting to happen and ends up with group lobster consciousnesses orbiting Jupiter. The thing it really captures is just the pace -- this quickening quickening quickening pace." -- Boris Cherny
⚡ 一人公司启示
  • Boris 的书单:科幻提供想象力(看到可能性),函数式编程提供纪律(结构化思维)
  • Accelerando 描绘的"加速感"正是现在的感觉。学会在加速中保持方向感比掌握任何具体技能都重要。
  • 推荐一人公司创始人也读科幻 -- 它训练你想象"现在不可能但明年就可能"的场景,这正是找到新产品机会的关键思维。