标签 Golang 下的文章

从手写代码到日提 30 个 PR:Claude Code 缔造者的 AI 编程启示录

本文永久链接 – https://tonybai.com/2026/03/06/building-claude-code-with-boris-cherny

大家好,我是Tony Bai。

想象一下,你加入了一家全球顶级的 AI 实验室,满怀热情地提交了第一个 Pull Request (PR)。然而,你的 PR 却被直接拒绝了。原因不是代码写得不好,而是——这代码是你“手写”的

这不是科幻小说,这是 Boris Cherny 加入 Anthropic 时的真实经历。作为目前炙手可热的 AI 编程工具 Claude Code 的缔造者和工程负责人,Boris 曾是 Meta (前 Facebook) 最高产的程序员之一。但在 Opus 4.5 模型发布后,他的工作流发生了颠覆性的变化:现在,他每天可以提交 20 到 30 个 PR,且不再手动编辑任何一行代码。

近期的一期深度访谈中,Boris 分享了 Claude Code 从一个内部黑客项目到爆款工具的演进历程,以及他对于 AI 时代软件工程未来的深刻洞察。

Claude Code 的诞生:不要把 AI 关在盒子里

Claude Code 的前身是一个名为 “Clyde” 的内部原型。当 Boris 最初构思如何将 AI 融入编程时,他犯了一个很多开发者都会犯的错误:试图把 AI 当作系统中的一个组件。

在传统的思维模式下,我们倾向于把模型关在一个“盒子”里,为其定义严格的输入和输出接口(比如在 IDE 中高亮一段代码,然后让 AI 解释或补全)。但 Boris 很快意识到,这不是与大模型交互的正确方式。

“不要试图把它放进盒子里,不要强迫它以特定的方式行事。把模型看作一个独立的实体,给它工具,让它自己运行程序。”

这种被 Boris 称为“苦涩教训(Bitter Lesson)推论”的理念,成为了 Claude Code 的核心设计哲学。他赋予了模型执行 Bash 命令的权限,接着是读写文件系统的权限。当模型获得了与现实世界(操作系统)交互的能力后,奇迹发生了。

他举了一个早期的例子:他给了模型一个 Bash 工具,然后问它:“我正在听什么音乐?”模型竟然自己写了一段 AppleScript 脚本,调用 sed 等命令去查询本地的音乐播放器,并成功返回了答案。这一刻,Boris 感受到了真正的 AGI(通用人工智能)气息。

从手写到“指挥”:并行 Agent 的极致工作流

作为曾经 Meta 代码产量极高的工程师,Boris 现在的产出速度更是达到了令人咋舌的地步(每天 20-30 个 PR,从几行到几千行不等)。他是如何做到的?答案是大规模并行 Agent (Parallel Agents)。

他分享了自己目前极其硬核的终端工作流:

  1. 多开终端:在终端(如 tmux)中打开 5 个标签页,每个都是独立的代码库 Check-out(或者使用 Git Worktree)。
  2. 启动计划模式 (Plan Mode):在每个标签页中启动 Claude Code,并进入“计划模式”(按两次 Shift+Tab),向 Agent 描述需求。
  3. 轮询指挥:当第一个 Agent 开始思考和执行时,他立刻切换到第二个标签页启动另一个 Agent。如此循环。
  4. 验证与交付:当收到某个 Agent 完成任务的通知时,切回去检查结果。

在这种模式下,Boris 不再是一个“打字员”,而化身为一个“交响乐团指挥”。他的核心工作从“思考如何实现”,变成了“思考业务逻辑的类型签名(Type Signatures)”和“验证模型的输出”。

当 AI 编写了 80% 的代码,代码审查(Code Review)怎么做?

这是每个工程团队都会面临的灵魂拷问。在 Anthropic 内部,高达 80% 的代码现在由 Claude Code 生成。那么,他们是如何把控质量的?

答案是:用 AI 审查 AI,辅以人类的最后防线。

  1. Agent 自我测试:Claude Code 会在本地自动编写并运行测试。如果 Anthropic 工程师修改了 Claude Code 本身的源码,Agent 甚至会启动一个子进程来做端到端(E2E)测试。
  2. AI 初审 (Best of N):在 CI/CD 阶段,每一个 PR 都会先被 Claude 审查。为了解决 LLM 偶尔的非确定性和幻觉,他们采用了 Best of N 策略——启动多个并行的 Agent 进行审查,再用一个去重 Agent 汇总结果。这能拦截约 80% 的低级 Bug。
  3. 动态 Lint 规则:当发现同事的 PR 中出现了可被静态分析捕获的问题时,Boris 会直接要求 Claude 当场写一个 Lint 规则,从源头上杜绝此类问题。
  4. 人类拍板:尽管自动化程度极高,但对于企业级产品,目前 Anthropic 依然要求每个 PR 必须有真正的人类工程师进行第二轮审查并最终批准。

“我们就像 15 世纪的抄写员”

面对 AI 展现出的恐怖编程能力,即便是前特斯拉 AI 总监 Andrej Karpathy 也感叹自己“从未如此落后过”。许多程序员感到恐慌:我们寒窗苦读十载练就的编码技能,是不是要变成屠龙之技了(变得稀有且遥远)?

Boris 给出了一个非常精彩且充满希望的隐喻:印刷术的发明。

在 15 世纪印刷术出现之前,“识字和抄写”是极少数人的特权。他们被国王雇佣,经过多年训练才能胜任。而当时的许多国王,甚至自己都是文盲。

“我们现在的软件工程师,就像是那些抄写员。而业务方(CEO/PM)就像是那些不懂技术的国王。”

当印刷术出现后,书籍的成本下降了百倍,数量增加了万倍。抄写员并没有消失,他们变成了作家、编辑、出版商。随着识字率的普及,整个知识市场迎来了前所未有的大爆炸,催生了无数在那之前根本无法想象的职业和产业。

今天,AI 编程工具就是软件工程界的“印刷术”。编程的门槛正在被无限拉低,原本不懂代码的业务人员、设计师、财务人员(在 Anthropic 内部,非技术人员使用 Claude Code 的比例接近 100%)都能直接将想法转化为软件。这不会消灭软件工程,而是会让软件的产量和应用场景呈指数级爆发。

工程师的新生存法则:哪些技能在贬值,哪些在升值?

在这场范式转移中,作为开发者,我们需要对技能树进行重新评估。

正在快速贬值的技能:

  • 对语言和框架的宗教式狂热:不要再为“到底是用 React 还是 Vue”、“这应该用 Go 还是 Rust 写”而争得面红耳赤了。如果模型觉得当前框架不好,它随时可以用几分钟时间帮你用另一个语言重写一遍。
  • 沉溺于语法细节:未来将没有人再去手动敲击枯燥的样板代码。

愈发珍贵的核心能力:

  • 系统化与假设驱动思维:面对复杂的 Debug 场景,如何提出假设、逐步验证,这种科学的工程思维依然是 AI 目前难以完全替代的。
  • 跨界的好奇心:未来属于全栈通才。如果你懂前端、懂后端,同时还懂业务逻辑、设计心理学甚至财务模型,你就能借助 AI 工具,以“一人公司”的姿态构建出估值十亿美元的产品。
  • 高频上下文切换能力 (ADHD 式的工作法):在这个需要同时管理多个 AI 智能体的时代,不再那么强调长时间的“深度编码”,而是需要你能在多个高层上下文中快速穿梭、精准决策。

注:ADHD (注意力缺陷多动症) 式的工作法是一种灵活而高度分散注意力的工作风格,常常表现为多任务处理和非线性思维,能够快速切换多个任务并通过联想和直觉进行思考。这种方法倾向于将大的任务分解为小的、可管理的目标,以保持动力和成就感。同时,工作过程中的兴趣和关注点可能会快速变化,因此通常会采用短暂的工作间隔与休息时间。通过频繁调整和迭代的方式,ADHD式工作法能够帮助人们利用自身的优势,克服注意力集中的挑战。

小结:抛弃傲慢,拥抱变化

在采访的最后,Boris 坦言自己也经常感到挣扎:模型进化的速度太快了,几个月前验证失败的架构理念,换个新模型可能瞬间就跑通了。

在这个时代,“智力上的谦逊 (Intellectual Humility)” 比过往的经验更重要。不要再用旧时代的标尺去衡量新世界的工具。承认 AI 可能比你写得快、甚至写得好,放下作为“手写代码匠人”的骄傲,去学习如何更好地指挥这支由超级大脑组成的交响乐团吧。

毕竟,未来不属于那些拒绝使用 AI 的人,而是属于那些知道如何用 AI 构建下一个时代的人。

资料链接:https://www.youtube.com/watch?v=julbw1JuAz0


你敢交出“键盘”吗?

Boris 的经历让我们重新思考什么是“专业”。如果你提交的 PR 仅仅是因为“这是我手写的”而被拒绝,你的第一反应会是什么?在你的团队中,是否已经有人开始尝试这种“指挥家”式的工作流?

欢迎在评论区分享你的看法!


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

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

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


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

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

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

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

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


想系统学习Go,构建扎实的知识体系?

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏,内容全面升级,同步至Go 1.24。首发期有专属五折优惠,不到40元即可入手,扫码即可拥有这本300页的Go语言入门宝典,即刻开启你的Go语言高效学习之旅!


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

数据说话:Go 1.26 或成近年来“问题最多”的大版本,现在升级安全吗?

本文永久链接 – https://tonybai.com/2026/03/06/go-1-26-most-problematic-release

大家好,我是Tony Bai。

2026 年 2 月,Go 1.26 如约而至。伴随着 new(expr) 语法糖的引入、Green Tea GC 的全面转正,以及go fix 现代化重构等一系列重磅特性,许多 Gopher 都按捺不住尝鲜的冲动。

然而,在经验丰富的 Go 团队和架构师群体中,流传着一条不成文的“潜规则”:永远不要在生产环境第一时间升级 X.Y.0 大版本,至少等到 X.Y.1 补丁发布后再做决定。

这条潜规则并非空穴来风。Go 的 1.N.0 版本虽然经过了长达半年的开发和 RC 阶段的测试,但只有当它真正被全球几百万开发者投入到千奇百怪的生产环境中时,那些隐藏在深处的边界 Bug 才会浮出水面。而 1.N.1 版本,正是官方对这“第一波真实世界火力测试”所暴露问题的集中修复。

因此,一个非常客观且有趣的推论诞生了:观察 1.N.1 里程碑下的 Issue 数量,可以作为衡量 1.N.0 初始质量的一张“晴雨表”。

最近,我在例行了解 Go 官方仓库的 GitHub 里程碑数据时,发现了一个令人警惕的信号:Go 1.26.1 的 Issue 数量,正在呈现出明显的“异常峰值”。

本文将用真实的数据说话,带你横向拉网式对比 Go 1.17 到 Go 1.26 这五年间、共十个大版本的初期质量水平,并深度拆解这些 Issue 的具体成分。Go 1.26 到底稳不稳定?现在升级安全吗?答案就在这些数据里。

核心数据全景:Go 1.26 的“异常峰值”

为了得出客观的结论,我利用 GitHub cli端gh工具 提取了从 Go 1.17.1 到 Go 1.26.1 的完整里程碑数据。这跨越了 Go 语言 2021 年至 2026 年的五年黄金发展期。

为了更直观地感受这组数据的冲击力,我们将其绘制成趋势图(数据采集于 2026 年 3 月4日晚):

从数据中读出的残酷真相

仔细审视这组数据,我们可以得出几个不容忽视的结论:

  1. 总量拉响警报:Go 1.26.1 的总 Issue 数目前已升至 39 个,直接打破了五年来历史最差的 Go 1.21.1 的记录(38 个)。这意味着它发布后暴露出的问题远超常规水平。
  2. 与“前任”形成鲜明对比:就在半年前发布的 Go 1.25,其 Go 1.25.1 补丁仅有 9 个 Issue,堪称近年来最稳定的“神仙版本”。Go 1.26 的问题数量是其四倍有余,这种断崖式的质量波动令人意外。
  3. 修复压力巨大:截至数据采集时,Go 1.26.1 仍有 17 个 Open Issue 亟待修复,官方团队正处于“救火”状态中,Go 1.26.1 补丁的发布可能还需要一些时间。

初步结论:Go 1.26 大版本的初始质量(Initial Quality)存在明显瑕疵,社区踩坑率偏高。


图Go 1.26.1 milestone下的issues列表

深度挖掘:为什么 Go 1.26 成了“重灾区”?

看到这里,你可能会问:Go 团队的开发流程一向严谨,为什么 1.26 会出现如此多的问题?

为了探寻真相,我没有停留在宏观数字上,而是将 Go 1.26.1 里程碑下的 全部 39 个 Issue 逐一扒开,按其性质进行了分类。不看不知道,一看吓一跳,这 39 个问题背后的成分大有玄机。

通过分类数据,我们可以清晰地看到导致 Go 1.26 翻车的“三大元凶”:

cmd/fix / modernize 相关:创新的“生长痛” (占比 33%)

这是 Go 1.26 核心新特性——全新的 go fix 自动代码现代化工具——直接引发的问题(约 13 个)。

静态分析并自动修改代码是一把双刃剑。在真实世界极其复杂的抽象语法树(AST)场景中,go fix 暴露出了一些“好心办坏事”的边界 Bug。例如:

  • stringsbuilder 重写规则破坏了某些合法代码。
  • rangeint 升级在某些跨平台场景下存在兼容问题。
  • minmax 替换规则意外破坏了 select 语句的结构。
  • waitgroup 检查器导致了误报的编译错误。
  • … …

好消息是:这个类别虽然问题多,但大多数是被工具链“误伤”的语法层面的问题,且 绝大部分已被 Go 团队快速修复(目前该类别仅剩少数处于 Open 状态)。这说明 Go 团队对新特性的反馈响应非常迅速。

compiler/runtime 相关:最令人担忧的核心动荡 (占比 44%)

这是本次分析中最令人担忧的类别。多达 17 个 Issue 直指 Go 的心脏——编译器和运行时。

引入 Green Tea GC 全面转正、栈分配优化以及实验性的 SIMD 等底层变动,不可避免地触碰了最敏感的神经:

  • 出现了多个 Internal Compiler Error (ICE),这意味着编译器在处理特定代码时直接崩溃了。
  • 曝出了 runtime segfault / panic,这是运行时层面的致命错误。
  • 32 位架构上的 timespec 定义错误。
  • SIMD 实验特性的相关 Bug。

这些直击核心的问题中,有大约一半目前仍处于 Open(待修复)状态。底层 Bug 的修复往往需要极其谨慎的测试和论证,这可能会直接影响 Go 1.26 在高并发、复杂内存场景下的稳定性。

Regression (回归问题):亮起最高级别的红灯 (占比 10%)

虽然只有 4 个 Issue 被打上了 regression(回归)标签,但这是最严重的信号。回归意味着:在 Go 1.25 中能够正常编译和完美运行的代码,在什么都不改的情况下,升级到 Go 1.26 后却出错了!

这打破了 Go 最引以为傲的“向后兼容”承诺。这些回归问题包括:

  • Synology Linux 环境下 fork syscall 发生冲突。
  • 32 位 Android 系统下的 seccomp 问题。
  • mipsle 架构下出现的 segfault。
  • Windows 平台上 os.RemoveAll 行为异常(已修复)。

4 个 regression 问题中有 3 个至今尚未修复(Open)。这意味着,如果你恰好使用了相关的平台或系统接口,升级 Go 1.26 后将掉入一个“大坑”。

数据背后的真相总结

综合以上硬核拆解,我们得到了一张更为清晰的“风险热力图”:

理性决策:现在该升级 Go 1.26 吗?

数据虽然冰冷,但它为我们的技术决策提供了极其理性的支撑。面对目前 Go 1.26 这样一份成分复杂的“体检报告”,我为不同场景的开发者提供以下实操建议:

场景一:公司核心生产环境

强烈建议:暂缓升级,绝对按兵不动!

不要拿核心业务去为新编译器和新 Runtime 做“小白鼠”。鉴于存在多个未解决的 Compiler/Runtime Bug 和严重的 Regression 问题,至少要等到 Go 1.26.1 正式发布,仔细阅读其 Release Notes 确认相关雷区被排除后,再做评估。如果可能的话,我甚至建议那些对稳定性要求极高的金融或电商系统,等到 Go 1.26.2 发布后再进行灰度迁移。

场景二:团队的辅助工具 / 内部系统

建议:可以在本地或测试环境准备迁移,但不要上生产。

现在是让团队架构师开始在本地测试 Go 1.26 兼容性的好时机。你可以利用这段时间跑一遍全量的单元测试和集成测试,看看新的 Green Tea GC 是否对你们的特定负载有负面影响,或者有没有踩中那几个未修复的 Regression 雷区。

场景三:个人项目 / 新技术学习

建议:大胆升级,享受新特性。

对于没有历史包袱的个人项目,new(expr) 和强大的 go fix 绝对值得立刻体验。遇到 Bug 怎么办?去 GitHub 提 Issue!这也是参与开源社区建设、为 Go 生态排雷的绝佳方式。

小结:读懂版本号背后的语言演进

软件工程没有魔法,没有哪个大版本能在经历了底层大换血后依然完美无瑕。

Go 1.26.1 高达 39 个的 Issue 数量,以及占比极高的底层 Runtime/Compiler 报错,并不是在说“Go 团队不行了”,而恰恰反映了这门语言仍在保持着极其旺盛的生命力、以及为了追求更高性能而积极重构底层债务的勇气

只不过,作为一线开发者和架构师,我们需要学会读懂这些数据发出的信号。在“享受技术红利”和“保障业务稳定”之间,让数据帮助我们找到最完美的平衡点。

最后,做个小调查:你目前在使用 Go 的哪个版本?是否有计划在近期升级到 1.26?欢迎在评论区分享你的看法!


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

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

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


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

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

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

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

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


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats