本文永久链接 – 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语言高效学习之旅！

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

本文永久链接 – https://tonybai.com/2026/03/04/package-management-unsolvable-problem-programming-languages

大家好，我是Tony Bai。

每天，全世界的开发者敲击下数以亿计的 npm install、go get、cargo build 或是 pip install。我们将这些包管理器视作理所当然的基础设施，仿佛它们就像水龙头一样，拧开就有源源不断的开源代码流出。然而，在这些看似简单的命令行背后，隐藏着计算机科学中最复杂、最容易引发争议，且永远无法找到“完美答案”的深水区。

近期，一篇名为《Package Management is a Wicked Problem》（包管理是一个“棘手”问题）的文章在技术社区引发了广泛关注，其姊妹篇《Package Management Namespaces》更是深度拆解了包命名的底层逻辑。作者以其多年参与包管理器数据和工具开发的经验，向我们揭示了一个残酷的真相：包管理不仅仅是一个纯粹的计算机科学问题，它是一个融合了社会工程学、经济学、安全性和向后兼容性的无底洞。 任何在这个层面上的微小改进，都会引发波及全球数千万个项目、数亿个版本的海啸。

本文将结合这两篇深度文章的核心观点，带你全景式地审视现代主流编程语言（如 Go、Rust、Python、JavaScript、Java）在包管理与“命名空间”上的激烈博弈与艰难演进。

包管理为何是一个“棘手问题”（Wicked Problem）？

为了准确描述包管理的困境，原作者借用了 1973 年社会规划学者 Horst Rittel 和 Melvin Webber 提出的“棘手问题”（Wicked Problem）这一经典概念。

在城市规划或公共政策领域，“棘手问题”通常指的是那些没有明确边界、没有唯一正确答案、且试图解决它的行为本身就会改变问题定义的问题。作者指出，在涉及万亿次下载和全球协作的今天，包管理完美地契合了 Rittel 和 Webber 提出的“棘手问题”的多个核心特征：

问题的表述与解决方案是同一件事

当我们谈论“包管理”时，我们到底在谈论什么？

作者敏锐地指出，这个词本身就是模棱两可的。对于前端开发者，它可能意味着用 npm 管理构建时的依赖树；对于系统管理员，它可能意味着用 apt 或 Homebrew 在操作系统上安装已编译好的二进制工具。

即使在同一个生态系统中，命名也充满了争议：我们称其为 package（包）、module（模块）、crate（板条箱）还是 distribution（发行版）？这些并非简单的同义词替换，它们各自编码了对“什么东西被版本化”、“什么东西被发布”以及“什么东西被安装”的深刻假设。正如作者所说：“包管理一路向下都关乎命名，而命名众所周知是计算机科学中的两大难题之一。”

当你决定引入 Lockfile（锁文件）时，你并不是在解决一个大家事先都同意的问题，你实际上是在重新定义“安装依赖”这个行为本身。这正是“棘手问题”的典型特征：解决方案定义了问题。

根本没有绝对的“对与错”，只有“好与坏”

在包管理的世界里，几乎没有任何技术决策可以被客观地评判为“真”或“假”。

作者以 Homebrew 为例：早期 Homebrew 选择直接使用 Git 作为其软件包数据库。这在当时是一个绝妙的设计，降低了门槛，极大促进了早期的繁荣。但随着规模的爆炸，Git 仓库的拉取成了巨大的性能瓶颈。那么，当初选择 Git 是错的吗？这取决于你是看重早期的简单性，还是看重长期的扩展性。

作者还深入剖析了语义化版本控制（SemVer）的困境。SemVer 试图将版本更新变成一种“非黑即白”的契约：引入破坏性变更（Breaking Change）就必须升级主版本号。但在实际操作中，这完全沦为了主观判断。

这里作者引入了著名的海勒姆定律（Hyrum’s Law）：“当一个 API 拥有足够多的用户时，你在契约中承诺什么已经不重要了，你系统的所有可观测行为都将被某些用户所依赖。”

这意味着，对于某个开发者来说仅仅是修复了一个底层的 Bug，但对于恰好依赖这个 Bug 特性运行的另一个用户来说，这就是一次彻头彻尾的破坏性变更。版本号的跳动永远无法客观地评估对所有人的影响，它只能是“对特定人群好”或“对特定人群坏”。

不可逆的深远后果与试错的代价

在科学研究中，你可以提出假设并在实验室中进行 A/B 测试。但在包管理器设计中，你没有这种奢侈。作者强调：“每一个实施的解决方案都会留下无法消除的痕迹。”

当年 Python 的包索引（PyPI）决定接受无命名空间的扁平包名时，拼写抢注（Typosquatting）攻击就成为了这个生态不可避免的宿命。即便 PyPI 明天决定强制引入层级命名空间，它也无法改变全球数以千万计的存量 requirements.txt 文件，更不能直接使那些旧代码失效。

同样，RubyGems 至今仍托管着自 2007 年以来就未曾更新的古老包。在这个领域，没有推倒重来的机会（No do-overs）。

当年 npm 社区发生的 left-pad 事件（作者因为不满而撤下了一个仅有 11 行代码的基础库，导致全球无数基于 Babel、React 的项目构建失败），就是一个惨痛的教训。当你允许“取消发布”时，你不仅是在做一个功能，你是在制定一项将永久塑造开发者行为的政策。

利益相关者的根本冲突与多重因果

包管理到底应该优化什么？作者为我们罗列了一系列相互冲突的诉求：

• 注册中心运营者想要极简的存储和极致的稳定性。
• 安全研究员想要可审计性和不可变性。
• 库作者想要发布时的灵活性。
• 企业应用开发者想要绝对的构建可重复性。

这些目标是内在矛盾的。一个允许库作者轻松推送更新的系统，必然也是一个更容易受到供应链攻击的系统；一个能够捕获每一层深层依赖的 Lockfile，必然也是一个在执行安全升级时更痛苦的组件。

npm、Yarn 和 pnpm 能够在前端生态中三足鼎立，正是因为它们对这些冲突的诉求做出了不同的妥协。Yarn 的诞生是因为 Facebook 迫切需要 npm 早期未能提供的绝对可重复性；而 pnpm 的崛起则是因为开发者对磁盘空间和安装速度的渴望压倒了对传统 node_modules 结构的兼容性需求。

命名空间之战——安全与便利的生死博弈

在理解了包管理的“棘手”本质后，原作者将目光投向了包管理的核心战场：“命名机制”。你如何为一个包赋予一个全球唯一的标识符？这不仅决定了开发者的使用体验，更直接决定了整个生态的安全性架构。

作者在其姊妹篇《Package Management Namespaces》中，详细梳理了主流语言生态演化出的四种截然不同的命名范式。

扁平命名空间（Flat Namespaces）：“先到先得”的蛮荒时代

代表生态： RubyGems, PyPI (Python), crates.io (Rust)

这是历史最悠久、设计最直观的模式：一个巨大的、全局共享的名称池。规则很简单：先到先得。如果你抢到了 requests，那就是你的。

• 开发者的蜜月期：在生态初期，这种模式极度舒适。名称简短、好记，在命令行里敲下 gem install rails 或 cargo add serde 时，体验极其顺滑。
• 作者指出的致命缺陷：命名稀缺与安全梦魇。

随着生态规模的爆炸式增长（如 PyPI 目前已有超过 60 万个项目），好名字很快被耗尽。许多简短的、有意义的词汇被一些只有个位数下载量的废弃项目永久“占坑”。新开发者被迫使用 python-dateutil 或 beautifulsoup4 这样带有笨拙前缀或数字后缀的名称。

更严重的是，这种模式为拼写错误抢注（Typosquatting）提供了完美的温床。攻击者只需注册 reqeusts（对应合法的 requests）然后守株待兔。因为在用户的键盘敲击和注册表查找之间没有任何组织层级的校验，也没有层级结构需要导航，这种基于简单字符串匹配的攻击防不胜防。

作用域命名空间（Scoped Namespaces）：组织的介入与权力的转移

代表生态： npm (JavaScript), Packagist (PHP)

为了解决扁平命名的稀缺和冲突，npm 在 2014 年引入了作用域（Scopes）。你可以发布 @babel/core 而不是去争抢早已被占用的 babel-core。PHP 的 Packagist 更是从一开始就强制要求使用 vendor/package 的格式（如 symfony/console）。

• 空间的释放：这极大地缓解了命名冲突。不同的组织可以安全地使用相同的叶子节点名称，例如 @types/node 和 @anthropic/node 可以和平共处，互不干扰。
• 作者提示的挑战：治理成本的飙升与“上移的占坑”。

作用域引入了复杂的治理问题。谁有权决定 @babel 属于 Babel 团队？这就需要平台提供账号管理、所有权转移机制甚至处理商标纠纷的流程。

此外，作者犀利地指出，在 Packagist 这种强制模式中，虽然包名（package）不冲突了，但“供应商（Vendor）”名称本身依然是先到先得的。如果有人提前在 Packagist 上抢注了 google 这个供应商名称，那么 Google 官方的所有包都会被拦截在生态之外。这等于是把“占坑”的问题向上推了一个维度，其潜在的破坏力实际上更大。

层级命名空间（Hierarchical Namespaces）：绑定全球 DNS 体系

代表生态： Maven Central (Java, Clojure)

Java 生态极其聪明地将包命名的治理权“外包”给了全球最大的、已经建立共识的分布式治理系统——DNS（域名系统）。你必须拥有 example.com 的域名所有权，才能发布前缀为 com.example 的包。

• 秩序的建立：这几乎彻底消除了无意义的恶意占坑。像 Apache、Google 这样的庞大组织拥有了极其清晰、权威的代码家园。
• 作者揭示的致命隐患：MavenGate 与域名复活攻击。

这种看似无懈可击的设计，依然存在致命的盲区。域名的所有权并不是永恒的，公司会倒闭，域名会过期。作者引用了安全公司 Oversecured 在 2024 年初发布的 “MavenGate” 报告：在与 Maven 关联的 3 万多个域名中，有近 18%（约 6170 个）域名已经过期或重新流入市场挂牌出售！

这其中甚至包含了被广泛使用的 co.fs2、com.opencsv 等知名库的根域名。这意味着，恶意攻击者只需花费极低的成本（几十美元）买下这些过期的域名，就能顺利通过 Maven Central 的 DNS TXT 记录验证，以合法原作者的身份接管整个命名空间，并发布带有后门的恶意新版本。由于大多数自动化构建工具倾向于拉取最新版本，这种基于“域名复活”的供应链攻击将具有毁灭性的穿透力和隐蔽性。

基于 URL 的标识符：去中心化的乌托邦与残酷现实

代表生态： Go, SwiftPM

Go 模块（Go Modules）做出了一个在当时看来非常激进的选择：直接使用代码托管地址（如 github.com/gorilla/mux）作为包名标识符，彻底取消中心化的“注册（Registry）”步骤。

• 优雅的直达：这实现了零注册摩擦。URL 在结构上天然保证了全球唯一性，且通过对 Git 仓库的所有权，自然而然地确立了对代码包的所有权。
• 作者分析的隐藏代价：被基础设施绑架与脆弱的信任链。

这种模式将包的命运与底层的托管平台（特别是 GitHub）进行了深度且危险的绑定。如果一个 GitHub 组织改名了，或者一个生气的开发者删除了他的仓库，所有依赖这些路径的下游系统都会瞬间崩溃。

为了弥补这个“去中心化”带来的巨大可用性缺陷，Go 团队不得不花费数年时间，在核心机制之外构建了极其庞大的辅助基础设施：

1. Module Proxy（模块代理）：用于持久化缓存源码。这样即使 GitHub 上的原仓库被彻底删除，只要代理中有缓存，全球的 Go 构建就不会中断。
2. Checksum Database (SumDB)：这是一个基于透明日志（Transparency Log）的校验和数据库。它提供了一个不可篡改的全局信任锚点，保证了任何人、在任何时间、从任何代理拉取同一个版本的 Go 模块，得到的哈希值必须绝对一致。它防止了作者恶意 force-push 篡改代码，甚至连运营该数据库的 Google 自己也无法在不被察觉的情况下篡改历史记录。

作者通过对比指出，苹果生态的 SwiftPM 起初也采用了类似的 Git URL 模式，但并未配套建立 Proxy 和校验数据库。这导致如果 GitHub 仓库消失，Swift 的构建就会直接面临失败。更糟糕的是，2022 年的安全研究发现，大量 Go 和 Swift 包容易受到“仓库劫持”（Repo-jacking）攻击（即攻击者重新注册已注销的 GitHub 用户名，并重建同名的旧仓库）。Go 因为有强悍的 Proxy 和 SumDB 作为护城河，成功抵御了此类攻击；而 SwiftPM 至今仍暴露在巨大的软件供应链风险之中。

深重历史包袱下的“痛苦迁徙”

我们现在已经通过学术分析和前车之鉴，知道了理想的包管理应该是什么样。但原作者指出了一个无情的现实：大部分语言的包管理器早在十多年前就已经定型，它们带着最初的缺陷狂奔至今，积累了如同天文数字般的历史包袱。 如今想要修复这些缺陷，无异于给一架正在高速飞行的跨洋客机在空中更换引擎。

作者以 Rust (Cargo/crates.io) 的演进为例，生动地展示了这种深度重构的痛苦与艰难。

Rust 社区作为一个极其注重工程严谨性的生态，早在 2014 年起就在讨论引入命名空间。由于一开始选择了扁平命名，优质的单词已被大量占用。直到 2025 年，Rust 社区才终于正式推进了由 Manish Goregaokar 起草的 RFC 3243（可选命名空间） 提案。

他们的过渡方案设计得极其精妙且克制：不引入新的顶级前缀，而是将现有的合法包名升级为潜在的命名空间根节点。

这意味着，如果你当前拥有 serde 这个基础包的所有权，你就可以顺理成章地发布 serde::derive（使用双冒号 :: 是为了与 Rust 原生的模块语法保持高度一致）。这种设计完美地做到了向后兼容：现有的扁平命名继续有效，新的层级命名以一种非常“Rust”的方式平滑引入。

但这依然无法避免阵痛。

作者举例说，像 tokio-macros 这样已经广泛存在于扁平空间中的包，如果未来想将其规范化迁移到 tokio::macros，所有依赖它的下游用户的代码都需要跟着进行繁琐的改写。而对于那些名字被别人占用的项目（比如知名的异步运行时 async-std 团队，其实并不拥有 async 这个基础包名的所有权），这个优雅的方案对他们来说依然是无解的。

Rust 社区作为一个资源充足、治理严密的顶级生态，依然需要花费数年的时间、跨越编译器、Cargo 工具和注册中心三大团队来协调设计和实施这个补救方案。

这充分印证了作者的观点：如果在发布 Registry 的第一天，你没有保留哪怕一丁点命名空间的扩展性（比如预留一个特殊的分隔符），那么一旦生态成型，后续的重构成本将是难以估量的。 同样，Python 的 PyPI 目前也在通过 PEP 752 提案如履薄冰般地尝试让大厂保留包名前缀（如 google-cloud-），但这只对未来的新包有效，对于存量系统依然是一笔难以理清的糊涂账。

小结——放弃“完美”，拥抱“演进”

纵观这两篇深度探讨，无论是 npm 为了处理历史包袱而维护的并行命名系统，还是 Go 利用强大的 SumDB 来硬核弥补 URL 导入天然缺陷的工程奇迹，亦或是 Rust 正在小心翼翼进行的痛苦命名空间迁移，所有的现象都在向我们诉说同一个真理：

包管理（Package Management）作为一个“棘手问题”，永远不会被真正“解决”。

我们无法像推导一个数学定理那样，给出一个让所有人都满意的、完美的包管理公式。我们所能做的，是在不断变化的安全性要求、开发者的灵活性需求、系统的可用性以及沉重的历史包袱之间，寻找属于这个时代的最优解（Trade-offs）。

对于语言和工具的设计者而言，在系统上线的第一天保持足够的克制和选项预留价值千金；而对于广大的应用开发者而言，正如作者所呼吁的，我们需要深刻理解这些构建工具背后的“棘手”本质。

当我们面对依赖冲突或奇怪的版本解析时，少一些诸如“为什么这个工具这么蠢”的情绪化抱怨，多一些对供应链安全的审慎态度（如定期审查依赖树、使用内部可信代理、开启严格的校验和哈希验证），才是面对现代软件工程深水区时，我们应有的专业素养与敬畏之心。

下一次，当你敲下那行习以为常的 go get、npm install 或 cargo build 时，不妨停下来思考一秒钟：为了将这几 KB 的代码安全、无误地送到你的硬盘里，背后那套由无数妥协与智慧构筑的庞大机器，是如何在无声中疯狂运转的。

资料链接：

• https://nesbitt.io/2026/01/23/package-management-is-a-wicked-problem.html
• https://nesbitt.io/2026/02/14/package-management-namespaces.html

你最想吐槽哪家的包管理？

每一个“依赖地狱”的背后，都有一位在深夜叹气的程序员。在你的开发经历中，哪门语言的包管理最让你感到顺手？哪门又最让你抓狂？你认为 Go 的“URL 导入+校验和数据库”模式是目前的终极答案吗？

欢迎在评论区分享你的“包管理血泪史”！

还在为“复制粘贴喂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语言高效学习之旅！

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