1. 当“造轮子”这件事被AI盯上“Is library building obsoleted by AI coding?”——这个问题第一次砸到我面前时我正在给一个内部工具写第三版日期处理模块。说实话那一瞬间我有点恍惚过去十年里我花在封装通用库、设计API、写文档、维护版本兼容上的时间加起来可能够我环游世界两圈。而现在一个AI助手能在几秒内生成一个看起来像模像样的日期解析函数甚至还能顺手补上单元测试。但“看起来像模像样”和“能扛住生产环境”之间隔着一条马里亚纳海沟。这篇文章不打算给你一个非黑即白的答案而是想把我自己从“手写库狂热者”到“AI辅助库构建实践者”的转变过程拆开聊聊哪些环节确实被AI加速了哪些环节反而因为AI的介入变得更需要人的判断力以及一个普通开发者现在到底该怎么看待“造库”这件事。如果你正在纠结“还要不要自己写工具库”“AI生成的代码能不能直接进项目”“怎么用AI把库开发效率提上去”那这篇内容就是写给你的。我会尽量少讲空话多讲我实际踩过的坑和验证过的做法。2. 先搞清楚AI到底在“替代”库构建的哪个环节2.1 库构建从来不只是“写代码”很多人把“library building”等同于“敲代码实现功能”这其实是个巨大的认知偏差。一个真正能被复用的库它的生命周期至少包含这些阶段需求抽象从多个业务场景里提炼出通用接口决定哪些参数该暴露、哪些该隐藏。API设计命名、参数顺序、返回值结构、错误处理策略这些决定了库好不好用。核心实现算法、数据结构、边界条件处理。测试覆盖单元测试、集成测试、模糊测试尤其是边界和异常路径。文档与示例README、API文档、快速上手指南、迁移指南。版本管理与兼容语义化版本、废弃策略、升级路径。分发与构建打包、产物格式、依赖管理、CI/CD。长期维护issue响应、安全补丁、社区运营。AI目前最擅长的是核心实现和测试用例生成这两个环节在文档初稿上也有不错的表现。但在需求抽象、API设计、版本兼容策略这些需要跨项目经验和长期判断的环节AI基本还是个“实习生水平”——它能给你建议但拍板的人必须是你。2.2 一个反直觉的结论AI让“小库”变多了而不是变少了我原本以为AI会让大家不再写库直接让AI生成一次性代码就完事。但实际观察下来情况恰恰相反因为AI把“写一个库”的启动成本降到了极低反而有更多人愿意把重复代码抽成小库了。以前你写个日期格式化函数可能觉得“就这几行复制粘贴算了”。现在你会想“反正AI能帮我生成测试和文档不如封装成一个内部小库以后统一改。”结果就是项目里的“微库”数量在增加每个库的职责更单一维护成本反而因为AI辅助而可控。这个现象背后的逻辑是AI降低的是“从想法到可用代码”的摩擦而不是“从代码到可靠库”的摩擦。前者是写代码后者是工程化。工程化的那部分AI能帮上忙但替代不了。2.3 哪些库最危险哪些库反而更稳了我把自己接触过的库粗略分了个类用下面这张表来说明AI对不同类型库的冲击程度库的类型典型例子AI替代风险原因纯算法工具排序、字符串处理、日期计算高AI生成质量已足够好边界测试也能补协议/格式解析JSON解析、CSV读写、URL处理中高标准明确AI能覆盖大部分场景框架适配层某框架的ORM封装、HTTP客户端中依赖具体框架版本AI知识可能滞后业务领域模型订单状态机、计费规则低强业务耦合AI缺乏上下文基础设施连接池、缓存、并发原语低对正确性和性能要求极高AI代码需大量验证开发者体验工具CLI、代码生成器、调试辅助中AI能生成骨架但交互设计仍需人这张表不是绝对的但它能帮你快速判断如果你正在维护的库属于“纯算法工具”那一栏确实需要认真思考它的长期价值了。但如果你做的是“业务领域模型”或“基础设施”AI更多是加速器而不是替代者。3. 我用AI辅助库开发的真实工作流3.1 从“先写实现”改成“先写接口契约”以前我写库的习惯是打开编辑器先写核心函数跑通了再补测试和文档。现在我把顺序倒过来了先用自然语言把接口契约描述清楚让AI生成接口定义和测试用例确认无误后再让AI填充实现。举个例子我最近要写一个“带过期时间的LRU缓存”小库。我没有直接让AI“写一个LRU缓存”而是先给它一段描述我需要一个TypeScript泛型类ExpiringLRU构造函数接受maxSize和defaultTTL两个参数。提供get、set、has、delete、clear五个方法。set方法可以覆盖默认TTL。过期条目在get和has时惰性删除同时每次操作后检查容量超出时按最近最少使用淘汰。请先只生成接口定义和对应的单元测试不要生成实现。AI给出的接口定义和测试用例我逐条审查后调整了两处一是把has方法的语义明确为“不触发过期检查”二是增加了size属性。然后我再让AI基于这份契约生成实现。这样做的好处是测试用例成了我和AI之间的“合同”实现必须满足测试而不是我事后去猜AI的实现有没有边界问题。3.2 让AI做“边界条件枚举器”而不是“代码生成器”AI在生成正常路径代码时表现很好但边界条件往往需要人提醒。我的做法是实现生成后专门开一个对话让AI扮演“恶意测试者”列出这个库可能出问题的所有边界场景。比如对于上面的LRU缓存AI列出的边界包括maxSize为0、maxSize为负数、TTL为0、TTL为负数、同一key反复set、get不存在的key、并发set同一个key、系统时间回拨等。然后我从中挑出真正需要处理的让AI补充对应的测试用例。这一步的价值在于AI能想到的边界比我多但它不知道哪些边界在我的使用场景里是重要的。我来做优先级判断它来做穷举。配合下来测试覆盖率比我手写高出一大截。3.3 文档生成AI写初稿人写“为什么”AI生成的API文档格式规范、参数齐全但读起来像说明书。真正有价值的文档需要回答“为什么这个参数要这样设计”“什么场景下不该用这个库”“和同类库比有什么取舍”。我的做法是让AI生成参数说明和示例代码然后我自己补一段“设计决策”放在文档开头。这段内容AI写不出来因为它没有经历过我当初的取舍过程。比如为什么TTL是惰性删除而不是定时器删除因为定时器在Node.js里会阻止进程退出而且大量缓存实例会创建大量定时器。这种“为什么”才是文档的灵魂。3.4 版本兼容AI最容易帮倒忙的地方这里要特别提醒不要让AI帮你决定版本号怎么升。我试过让AI根据代码变更判断是major、minor还是patch结果它经常把破坏性变更标成minor。原因很简单AI看不到你的用户是谁、他们怎么用你的库。我的做法是自己维护一个CHANGELOG每次发版前人工判断变更类型。AI可以用来检查CHANGELOG格式是否规范但不能用来做兼容性决策。这个环节一旦出错下游用户的构建就会炸信任一旦丢失很难挽回。4. 那些AI生成代码直接进库的惨痛教训4.1 一个“看起来完美”的深拷贝函数我曾经让AI生成一个深拷贝工具函数用于处理配置对象。AI给出的实现用了structuredClone并附带了降级方案。代码看起来无懈可击测试也通过了。但上线后第二天有用户反馈配置里的Date对象变成了字符串。排查后发现降级方案里AI用了JSON.parse(JSON.stringify())而JSON序列化会把Date转成ISO字符串。AI在生成时“知道”这个限制但它没有在代码里体现出来也没有在测试里覆盖Date类型。这就是典型的AI知道但不说的问题。教训AI生成的代码必须针对你的实际数据类型做验证。通用测试通过不代表你的场景通过。4.2 并发安全AI的盲区另一个坑是并发。我让AI写一个简单的内存计数器库AI用了let count 0加自增操作。在单线程JavaScript里没问题但这个库后来被用在了Worker线程共享的场景里结果计数丢失。AI生成并发代码时默认假设是单线程或加锁环境它不会主动考虑你实际运行时的并发模型。如果你的库涉及共享状态必须自己审查并发安全性或者明确在文档里声明“非线程安全”。4.3 依赖地狱AI喜欢引入新依赖AI在实现功能时倾向于引入它“熟悉”的第三方库。比如让它写一个日期处理它可能直接import dayjs。但你的库可能定位是“零依赖”或者你已经有自己的日期工具了。我的做法是在让AI生成实现前明确告诉它“不允许引入任何第三方依赖”或“只允许使用标准库”。这个约束必须写在提示词里否则AI会自作主张。4.4 许可证污染更隐蔽的坑是许可证。AI训练数据里包含各种开源代码它生成的代码可能和某个GPL库高度相似。虽然目前法律上对AI生成代码的许可证问题还没有定论但如果你要把库开源或商用最好用代码相似度检测工具扫一遍。我自己的习惯是核心算法部分尽量自己写AI只用来生成样板代码和测试。5. 现在到底该怎么定位“库构建”这件事5.1 把库分成“消耗品”和“资产”两类我现在会把要写的库先分个类消耗品库一次性使用、生命周期短、只服务当前项目。这类库我直接让AI生成不写文档、不发版本、不追求通用性用完就扔。资产库会被多个项目引用、需要长期维护、有外部用户。这类库我仍然会投入大量精力做API设计和文档AI只用来加速实现和测试。这个分类帮我省下了大量时间。以前我会纠结“这个函数要不要抽成库”现在我会先问自己它是消耗品还是资产消耗品就快速生成资产就认真对待。5.2 API设计能力反而更值钱了当AI能写出大部分实现代码时“设计一个好用的接口”这件事的稀缺性反而上升了。因为实现可以生成但接口设计需要判断力哪些参数该合并成对象错误该抛异常还是返回Result命名该用动词还是名词我最近在 review 一个AI生成的库时发现它的功能完全正确但API设计得很别扭getData、fetchData、retrieveData三个方法做几乎一样的事只是参数不同。这种库即使实现没问题用起来也会让人抓狂。而修正这种设计问题比修正一个bug要难得多因为你要考虑向后兼容。5.3 测试的重要性不降反升AI生成的代码越多测试就越重要。因为AI代码的“表面正确性”很高你很难通过读代码发现隐藏问题。只有测试能给你信心。我现在对AI生成的库代码要求测试覆盖率不低于90%而且必须包含边界测试和异常测试。这个标准比我手写代码时还高因为手写代码时我对每一行都有直觉而AI代码我需要靠测试来建立信任。5.4 文档的“人味”成了差异化优势当大家都能用AI生成API文档时一份带有设计思考、使用场景、踩坑记录的文档就变得稀缺了。我现在写库文档时会特意加一节“什么时候不该用这个库”以及“和同类方案相比的取舍”。这些内容AI写不出来但恰恰是用户最需要的。6. 一个具体的小库从AI辅助到人工打磨的完整过程6.1 需求一个带重试的异步任务执行器为了把上面的思路串起来我拿最近写的一个小库举例。需求很简单封装一个retry函数支持最大重试次数、退避策略、超时、以及自定义重试判断。6.2 第一步人工定义接口契约我没有直接让AI写代码而是先自己写了一段接口描述interface RetryOptions { maxAttempts: number; baseDelay: number; maxDelay: number; timeout?: number; shouldRetry?: (error: unknown, attempt: number) boolean; onRetry?: (error: unknown, attempt: number, delay: number) void; } function retryT(fn: () PromiseT, options: RetryOptions): PromiseT;然后我把这段描述给AI让它生成测试用例。AI生成了20多个测试我筛选后保留了12个覆盖了正常成功、首次失败后成功、达到最大次数失败、超时、shouldRetry返回false、onRetry回调、退避延迟计算等。6.3 第二步让AI生成实现但限制依赖提示词里我明确写了“只使用标准库不引入任何第三方依赖。使用指数退避加入抖动。超时用Promise.race实现注意清理定时器。”AI生成的实现基本可用但我发现两个问题一是超时后没有取消原始Promise这在JavaScript里很难做到但至少要在文档里说明二是抖动算法用了Math.random()导致测试不稳定。我把抖动改成可注入的随机函数默认用Math.random测试时传入固定值。6.4 第三步人工补充边界处理和文档AI没有处理的一个边界是maxAttempts为0或负数时应该直接抛错。我补上了这个检查。另外我在文档里加了一段“已知限制”超时不会取消底层操作如果底层操作有副作用需要调用方自己处理幂等性。6.5 第四步版本发布与后续维护这个库我发了1.0.0之后收到一个issue希望支持“重试间隔固定”而不是指数退避。我评估后认为这是新增功能不影响现有行为于是发了1.1.0。整个过程AI帮我写了CHANGELOG初稿和迁移说明但版本号是我自己定的。这个库总共花了大约3小时其中AI辅助编码占1小时人工设计、审查、文档占2小时。如果全手写我估计需要6到8小时。效率提升明显但人的判断仍然是核心。7. 如果你现在要开始一个库我的实操建议7.1 先问自己三个问题在动手之前我会问自己这个库是消耗品还是资产消耗品就快速AI生成资产就认真设计。它的核心价值在实现还是在接口如果核心价值在接口设计AI只能打辅助。我愿意为它维护多久如果答案少于半年建议不要做成库直接复制代码。7.2 提示词里必须写清楚的约束根据我的经验让AI辅助写库时提示词里一定要包含这些约束允许使用的依赖范围标准库/特定库/零依赖目标运行环境Node版本、浏览器版本、是否支持Worker并发模型单线程/多线程/需要加锁错误处理策略抛异常/返回Result/回调测试框架和覆盖率要求是否允许使用某些语言特性如structuredClone、Proxy这些约束不写清楚AI就会按它的“默认习惯”来而它的默认习惯往往和你的项目不匹配。7.3 审查AI代码时重点看什么我审查AI生成的库代码时会重点看这几个地方边界条件空值、零值、负数、超大值、重复调用。资源清理定时器、事件监听、文件句柄是否在异常路径下也能释放。并发安全共享状态是否有竞态条件。依赖引入是否引入了未声明的依赖。错误信息错误信息是否包含足够上下文方便排查。类型安全TypeScript类型是否过于宽松比如用了any。7.4 文档里必须有的三样东西不管库多小我都会在文档里放这三样快速上手示例复制粘贴就能跑。设计决策说明为什么这样设计取舍是什么。已知限制和不该用的场景帮用户避免误用。这三样里AI能帮你写第一样后两样必须自己来。8. 回到那个问题库构建被AI淘汰了吗我的答案是“写代码”这个环节被大幅加速了“构建可靠库”这件事反而更需要人了。AI把实现的门槛拉低了但把设计、验证、维护的门槛相对拉高了。以前你可以靠“实现能力强”来掩盖设计上的不足现在实现能力被AI拉平了设计能力和工程判断力就成了真正的分水岭。我现在的状态是小工具库基本让AI生成我花时间审查和补文档核心库仍然自己设计接口AI辅助实现和测试消耗品代码直接AI生成用完就扔。这个分工让我既能享受AI的效率又不至于让代码质量失控。最后分享一个我最近养成的习惯每次让AI生成库代码后我会隔一天再 review。隔一天的好处是我会忘记“这是我让AI写的”从而用更挑剔的眼光去看它。很多当时觉得没问题的代码隔天再看就能发现设计上的别扭之处。这个习惯帮我拦下了不少“能跑但不好用”的库。如果你也在纠结要不要继续写库我的建议是别纠结“要不要”先想清楚“为谁写、写多久”。想清楚了AI自然知道该放在哪个位置。