此方的秘密基地

外观

每周见闻(51)：有了大模型，还需要封装三方库吗？

约 2322 字大约 8 分钟

2026-01-18

每周见闻：2026-01-11 - 2026-01-18

有了大模型，还需要封装三方库吗？

常做开发的小伙伴一定熟悉三方库的封装。比如前端我们会封装 Axios 或者 fetch 用来统一做数据清晰、错误处理；服务端则会封装 MongoDB 或者 MySQL 来做一些数据库相关操作。

封装三方库一般会有以下几个好处：

  1. 统一对外接口：使开发者在使用不同的三方库时，不需要记住每个库的具体使用方法。
  2. 统一错误处理：封装三方库可以在内部处理错误，避免开发者在每次调用三方库时都需要处理错误。
  3. 方便代码维护：
    1. 统一对外的接口，能让不同开发者在调用时代码风格更加一致。
    2. 屏蔽了底层逻辑，更方便开发者在接手项目时快速上手。
    3. 如果遇到三方库需要升级或者替换，只需要修改封装层从而不影响业务层。

不过这周欧洲的同事却希望我们废除一个封装 AWS SDK 的仓库，其理由如下：

  1. 如今有了大模型，修改代码的成本很低，没必要再封装一层。
  2. 即便需要升级和替换，一切交给大模型即可。毕竟三方库代码都是开源的，大模型能学习到。
  3. 封装了之后代码在我们的私有仓库，不利于大模型可能不知道这些内部代码。
  4. 新的开发者可能只会调用封装的方法，而不会去学习三方库和底层逻辑。

对此，我的看法依旧是封装的好处更大。

  1. 在做升级和替换时，修改的范围可控。范围越小，修改的成本就越低。无论对人还是大模型都是一样的。
  2. 大模型不知道内部代码也不是问题。大模型有上下文，特别是 Cursor 能理解项目并找到封装的代码。
  3. 实际开发中更多的是业务层面的开发，过多的关注底层反而没有那么重要。底层的代码等真需要的时候去看，也来得及。
  4. 不同人对于大模型使用风格都是不同的，不封装更容易造成代码风格混乱。那为了统一代码风格，是不是要“封装”个 Rules ？

至于为什么有这么一个封装了 AWS SDK 的仓库，正是因为升级 V3 的过程中踩了修改范围过大、不同的人返回值处理不同等大坑。

希望这些理由可以说服欧洲同事。同时也想问问大家，你们是怎么看待这个问题的？

其他

1、Storyset | Customize, animate and download illustration for free[^1]

标签：Resource,Design

在 tw93 上期周刊看到的插图网站。非 AI 生成，画面很干净。可以免费使用，也支持导出为 SVG 格式。

2、日更博客的真正门槛[^9]

标签：思考

关注的博主从去年开始每天都有日更，非常厉害。因为突然间的提笔忘言，让他感受到了日更的门槛不在于素材的堆砌和时间，更多在于自己的观察和思考。

我发现碎片化的感触和能够转化为文字的深度思考完全是两回事。日常生活中我们会有很多转瞬即逝的想法，如果不去刻意捕捉、加工和推演，它们很快就会消散。

作者的观点让我很有感触。我自己做周刊时，也会为每周的题头部分而发愁。有时候想说的太多，不如另开一篇；或者有时候觉得想得太散，不好写；有时候甚至不知道写什么。这么一看，我还是平时思考得少了。

AI

1、Claude Skills 入门：一篇文章搞懂 AI 怎么从「嘴替」升级成「打工人」 - 少数派[^2]

标签：Coding,Prompt

最近 Skill 比较火，这篇是玉树老师对于 Function、Function Call 和 Skill 的入门讲解。通过类比的方式从概念上梳理三者的关系，非常生动和方便理解。对 Skill 感兴趣的朋友可以去阅读一下，文中的配图也非常到位。

Coding

1、How wrong can a JavaScript Date calculation go?[^3]

标签：JavaScript,Node.js

作者介绍了自己使用 Date 方法时遇到的错误，很有意思。不过随着 Temporal 对象即将出现，Date 或许就要变为历史。

作者遇到的问题很反直觉，可以先猜猜看下面代码的结果：

答案是： 2023-03-04-T00:00:00.000Z WTF?

其根本原因出在时区上，作者在美国西部时区。而 date.toISOString(); 用的是 UTC 时间，而对应美国西部时区则是 2023-12-31 ，因此在这个基础上执行 date.setMonth(1); 则会变为 2023-03-04 （因为 2月只有 28 天）。

神奇的是这个问题在 UTC 或者美西以东的地区都是正常的。因为 Date 会同时控制日期和时间。 而新的 Temporal 对象有单独控制日期的方法，从而避免类似错误的发生。

const startDate = Temporal.PlainDate.from(2024-01-01);
// = Temporal.PlainDate 2024-01-01
const nextMonth = startDate.add({ months: 1 });
// = Temporal.PlainDate 2024-02-01
const endDate = nextMonth.subtract({ days: 1 });
// = Temporal.PlainDate 2024-01-31

不过由于 Temporal 比较新，并没有被很多 JS 引擎支持，在使用时最好加上 polyfill。

2、Stop turning everything into arrays (and do less work instead) - Matt Smith[^4]

标签：JavaScript,前端

作者建议在部分场景下（只需要部分数据时）可以使用迭代器代替数组操作，把数据转换为数组操作会造成额外的开销，以及增加非必要的操作。

比如下面这个例子：

两者的差异在于数组的 filter, map, slice 每次都会返回新的数组。自然就会有额外的内存开销。而迭代器则是需要时再调用，没有额外的数组，整体开销更小。

我查了一下 MDN 迭代器也已经有 drop, filter, find 等类似数组的方法。可以替代以前数组的用法，不过依旧属于比较新的标准。在使用时要注意兼容性。

作者在最后也提醒，迭代器的使用也是有局限性:

  1. 单次迭代器，不能使用两次
  2. 惰性执行：直到需要时才运行
  3. 仅支持顺序: 像items[5]这样的模式无法转换

3、JavaScript's for-of loops are actually fast (V8)[^5]

标签：JavaScript,Node.js

作者采用了整数、浮点数、字符串、对象和混合值五个类型的数组，对不同的循环做了性能测试。由于有 V8 对于循环优化的加持，for...of 在性能上和传统循环一样快。并且比起传统的 for++ 循环，for…of 也更易读，所以更推荐使用。

4、Introduction · Node.js package configuration guide[^6]

标签：Node.js

Node.js 团队官方出品关于 package.json 的配置文档，目前还在持续更新中。介绍了基本的用法以及从 CommonJS 迁移到 ESM 的一些方法等。

5、dbreunig/whenwords: A relative time formatting library, with no code.[^7]

标签：AI,Tools

一个没有传统意义“源码”的日期格式化仓库，取而代之的是几份关于需求、测试的 Markdown 文档。程序员阅读其中的文档，剩下的交给 AI 根据文档实现代码，让 AI 根据需求用不同的语言实现打破语言的限制。

很有意思的仓库，说不定未来就是从比源码到比提示词了。

6、I Replaced Redis with PostgreSQL (And It's Faster)[^8]

标签：架构,Design

作者使用 PostgreSQL 替换了原来的 Redis 用来做缓存。在运行了三个月之后，作者收获了以下结果：

  1. 成本每月节省 100 美金
  2. 50% 的维护精力（技术栈统一）
  3. 减少了一个服务监控
  4. 更简单的发布

往期周刊：

参考文章:

  • [1] Storyset | Customize, animate and download illustration for free: https://storyset.com/bro
  • [2] Claude Skills 入门：一篇文章搞懂 AI 怎么从「嘴替」升级成「打工人」 - 少数派: https://sspai.com/post/105284
  • [3] How wrong can a JavaScript Date calculation go?: https://philna.sh/blog/2026/01/11/javascript-date-calculation/
  • [4] Stop turning everything into arrays (and do less work instead) - Matt Smith: https://allthingssmitty.com/2026/01/12/stop-turning-everything-into-arrays-and-do-less-work-instead/
  • [5] JavaScript's for-of loops are actually fast (V8): https://waspdev.com/articles/2026-01-01/javascript-for-of-loops-are-actually-fast
  • [6] Introduction · Node.js package configuration guide: https://nodejs.github.io/package-examples/
  • [7] dbreunig/whenwords: A relative time formatting library, with no code.: https://github.com/dbreunig/whenwords
  • [8] I Replaced Redis with PostgreSQL (And It's Faster): https://dev.to/polliog/i-replaced-redis-with-postgresql-and-its-faster-4942
  • [9] 日更博客的真正门槛: https://blog.solazy.me/20260116/

版权归属：konata9

许可证：署名-相同方式共享 4.0 国际 (CC-BY-SA-4.0)

贡献者: konata9