1. 先搞清楚大家在焦虑什么“AI 都能自己写代码了我们还有必要自己攒库、造轮子吗”这个问题最近被问到的频率几乎和“AI 会不会取代程序员”一样高。我身边不少做基础架构、做中台、做工具链的朋友最近都在重新盘自己手里的代码库哪些是真正沉淀下来的资产哪些只是当年为了 KPI 堆出来的“伪复用”。与此同时刚入门 AI coding 的新人又在另一个极端——什么都让模型生成结果项目里塞满了风格不一、依赖混乱、没人敢改的代码片段。先把结论摆在前面AI coding 没有让 library building 过时它改变的是“建什么库”和“怎么建库”。过去我们建库很大一部分精力花在“把重复代码抽出来”这种机械劳动上现在这部分确实被 AI 大幅压缩了。但库真正值钱的地方——边界的定义、契约的稳定性、错误的处理方式、性能的取舍、版本演进的策略——这些恰恰是 AI 目前最不擅长、也最需要人来拍板的部分。这篇文章适合三类人看一是手里维护着内部库、正在犹豫要不要继续投入的工程师二是刚开始用 AI coding、想知道怎么把生成结果沉淀成资产的入门者三是技术负责人需要判断团队在 AI 时代该怎么分配“造轮子”和“用轮子”的精力。我会从设计思路、核心细节、实操流程、踩坑排查四个层面把这件事讲透尽量给到可以直接抄作业的方法。2. 内容整体设计与思路拆解2.1 为什么“重复代码抽取”这件事被 AI 接管了要理解 AI 对 library building 的冲击得先看清传统建库的动机。过去我们建一个内部库最常见的触发点是同一个逻辑在三个以上的地方出现了复制粘贴开始让人难受于是抽出来。这个动机本质上是基于文本相似度的去重而 AI 恰恰是这方面的高手。你给模型一段重复代码让它抽象成函数、提取公共参数、生成泛型版本它做得又快又好。我实测过好几次把一段在五个文件里重复出现的日期格式化逻辑丢给模型让它抽成一个工具函数并统一调用点它给出的结果基本可以直接用连边界条件比如空值、时区都考虑到了。这意味着“因为重复所以抽取”这个层次的建库需求确实被大幅削弱了。但这里有个关键区分AI 擅长的是语法层面的归纳它看到的是“这几段代码长得像”然后帮你合并。它不理解的是“这几段代码为什么长得像”——是因为业务上它们本来就该共用一套规则还是只是巧合如果是巧合强行合并反而制造了错误的耦合。这个判断AI 给不了你只能靠人对业务的理解。2.2 库的真正价值不在“代码复用”而在“契约固化”我做了这么多年基础库越来越觉得一个库最核心的价值不是省了多少行代码而是它把一套约定固化下来了。举个例子一个团队的网络请求库它真正值钱的地方不是封装了 HTTP 调用这个 AI 分分钟能写而是它规定了超时怎么设、重试几次、错误怎么分类、日志怎么打、trace id 怎么透传。这些约定一旦固化进库全团队就自动对齐了新人进来不用问“我们这个项目请求失败是怎么处理的”看库的文档和实现就行。AI 能生成一个能跑的请求函数但它生成不了“你们团队应该采用什么样的错误处理哲学”。这个哲学是人在踩了无数次坑之后总结出来的是组织知识的结晶。AI coding 让“写代码”变便宜了反而让“定契约”变得更值钱因为代码越容易生成契约不一致带来的混乱就越严重——每个人都能让 AI 生成一套自己的写法最后项目里十种风格并存。所以我的判断是library building 的重心应该从“抽取重复代码”转向“固化关键契约”。前者 AI 能干后者必须人来干。2.3 一个判断框架什么样的库值得继续投入不是所有库都值得在 AI 时代继续维护。我总结了一个简单的判断框架帮你快速分类手里的库库的类型特征AI 时代的建议纯工具函数库字符串处理、日期格式化等大幅缩减让 AI 按需生成契约型库错误处理、日志、请求规范重点投入这是核心资产领域模型库业务实体、状态机谨慎维护AI 辅助但人把关胶水适配库对接第三方 SDK视情况AI 生成后人工审查性能敏感库底层数据结构、算法继续投入AI 难以保证质量这个框架的逻辑是越靠近“约定”和“性能”越需要人越靠近“机械转换”越可以交给 AI。你可以拿它对照一下自己手里的库大概率会发现真正该保留的可能只有原来的三分之一。3. 核心细节解析与实操要点3.1 契约型库到底该怎么设计既然契约型库是核心资产那具体怎么设计我拿一个真实的例子来讲一个团队级的错误处理库。这个库要解决的问题是全团队对“什么算错误、错误怎么分类、错误怎么上报”有统一的认识。第一步是定义错误分类。我们当时分了四类用户输入错误可预期需要提示用户、业务规则错误可预期需要业务处理、系统错误不可预期需要告警、外部依赖错误不可预期需要降级。这个分类不是拍脑袋来的是复盘了过去半年所有线上事故之后归纳的。AI 生成不了这个分类因为它不知道你们团队过去踩过哪些坑。第二步是定义每类错误的处理策略。用户输入错误直接返回提示不打错误日志业务规则错误记录业务日志返回业务码系统错误打错误日志并触发告警外部依赖错误记录依赖日志并走降级逻辑。这些策略写进库的实现里调用方只需要抛出对应类型的错误剩下的自动处理。第三步是定义扩展点。库不能写死要留出钩子让业务方定制。比如告警渠道、日志格式、降级策略都做成可配置的。这一步很关键因为契约型库最怕的就是“太死”业务方用不了就会绕过它绕过的人多了契约就失效了。提示契约型库的文档比代码更重要。代码 AI 能帮你写但“为什么这么设计”只有人能写清楚。文档写不好库就没人用。3.2 AI 生成代码后怎么沉淀成库这是入门 AI coding 的人最该掌握的技能。很多人用 AI 生成代码用完就扔下次遇到类似问题再生成一遍这其实是浪费。正确的做法是把 AI 生成的高质量片段经过审查后沉淀进库。具体流程是这样的先用 AI 生成一个能解决当前问题的实现跑通测试然后问自己三个问题——这个逻辑会不会在别处用到如果会它的接口应该长什么样它的边界条件处理得对吗如果三个问题的答案都是正向的就把它抽成库函数。这里有个实操技巧让 AI 帮你写库的测试用例。你把生成的函数丢给模型说“帮我写覆盖边界条件的单元测试”它给出的测试往往比你自己想的还全。我实测下来AI 写的边界测试能覆盖到空值、极值、类型错误这些容易漏的点省了不少事。但要注意AI 生成的库代码必须人工审查。我踩过的坑是模型生成的工具函数里有一次对时间的处理用了本地时区而我们的服务是跨时区部署的差点出问题。这种错误 AI 自己发现不了因为它不知道你的部署环境。3.3 版本演进AI 时代库维护的最大挑战库一旦被多个项目依赖版本演进就成了大问题。AI 时代这个问题更突出因为代码生成变快了库的迭代速度也跟着变快但下游项目的升级速度跟不上。我的经验是契约型库要严格遵循语义化版本破坏性变更必须升大版本并且提供迁移指南。而工具型库可以宽松一些因为它的影响面小。另外尽量用“新增”代替“修改”新功能加新函数老函数标记废弃但保留给下游足够的迁移时间。还有一个技巧用 AI 帮你生成迁移脚本。当你升级库的接口时让模型扫描下游代码自动生成替换方案。这个我试过对于机械的接口替换AI 的准确率很高能省掉大量手工改代码的时间。但涉及逻辑变更的迁移还是得人来。4. 实操过程与核心环节实现4.1 从零建一个契约型库的完整流程我拿最近帮一个团队建的“统一响应库”为例走一遍完整流程。这个库的目标是统一所有 API 的返回格式。第一步确定契约。我们定了响应体结构{ code, message, data, traceId }。code 是业务码message 是给用户看的提示data 是业务数据traceId 用于链路追踪。这个结构是跟前端、后端、测试一起对齐的不是后端单方面定的。第二步用 AI 生成基础实现。我把契约描述给模型让它生成一个 TypeScript 的响应封装类包含成功、失败、各类错误的工厂方法。模型给出的实现基本可用我做了两处调整一是把 traceId 的生成逻辑改成从上下文获取二是加了响应体的序列化钩子。第三步补充边界处理。这里 AI 帮了大忙。我让模型列出“这个库可能遇到的所有异常情况”它给出了十几条包括 data 为 undefined、message 超长、code 未定义等。我逐条确认后把需要处理的补进实现。第四步写文档和示例。文档我坚持自己写因为要讲清楚“为什么这么设计”。示例代码让 AI 生成我再改。文档里专门有一节讲“什么时候不该用这个库”比如文件下载、流式响应这些场景硬套统一格式反而添乱。第五步灰度接入。先在一个新项目里用跑两周没问题再推广到老项目。老项目接入时用 AI 生成适配层把老格式转成新格式避免大改。4.2 参数选择与配置的实操记录建库过程中有几个参数选择值得展开讲。第一个是错误码的位数。我们一开始想用三位数后来发现不够用改成五位数前两位表示模块后三位表示具体错误。这个规则定下来之后AI 生成错误码时就有据可循不会乱编。第二个是日志级别。契约型库要决定什么情况打什么级别的日志。我们的规则是用户输入错误打 info业务规则错误打 warn系统错误打 error外部依赖错误打 warn。这个规则写进库之后全团队的日志级别就统一了排查问题时按级别过滤很清晰。第三个是超时和重试。这个不能写死在库里要做成可配置但给一套默认值。我们的默认值是超时 3 秒、重试 2 次、退避系数 1.5。这套默认值是压测出来的不是拍脑袋。AI 生成重试逻辑时我特意让它把退避算法写对避免惊群。注意库的默认配置一定要保守。默认值太激进下游项目出问题会怪到库头上默认值太保守下游会自己改改着改着契约就散了。4.3 用 AI 辅助库的日常维护库建好之后日常维护也能用 AI 提效。我常用的几个场景一是生成变更日志把 git commit 丢给模型让它归纳成用户能看懂的 changelog二是回答使用问题把库的文档和代码喂给模型让它回答下游同学的提问准确率还不错三是扫描废弃接口的使用让模型分析下游代码找出还在用废弃接口的地方提醒迁移。但有一条红线AI 不能直接改库的公开接口。公开接口是契约改它必须人来做决定并且走评审。我见过有团队让 AI 自动重构库的接口结果下游一片红回滚都来不及。5. 常见问题与排查技巧实录5.1 常见问题速查表问题现象可能原因排查思路解决方式下游说库不好用绕过它契约太死扩展点不够访谈下游看他们绕过的方式增加扩展点或调整契约库升级后下游大面积报错破坏性变更没升大版本检查版本号和 changelog补升大版本提供迁移指南AI 生成的库代码有隐藏 bug模型不了解部署环境人工审查边界条件补测试特别是环境相关测试库越来越臃肿没人敢改什么都往里塞盘点库的职责拆分把非核心的移出去文档和实现不一致改了代码没改文档对比文档和代码把文档更新纳入 CI 检查5.2 几个我踩过的坑第一个坑是过度抽象。早年我建过一个“万能工具库”想把所有能复用的都塞进去结果库越来越大依赖越来越重最后没人敢用。教训是库的边界要清晰宁可多个小库不要一个大库。AI 时代更是如此小库更容易让 AI 理解和生成。第二个坑是忽视下游的升级成本。我曾经在一个库里改了一个函数的默认行为觉得是小事结果下游有十几个项目依赖这个默认行为升级后全出问题。教训是默认行为也是契约的一部分改它要当破坏性变更处理。第三个坑是让 AI 生成库的文档。我试过让模型根据代码生成文档结果它把实现细节当成了契约写进去下游照着文档用实现一改就出问题。教训是文档要写“承诺什么”不要写“怎么实现”这个区分 AI 目前还把握不好。5.3 独家避坑技巧分享几个我总结的技巧。第一给库建一个“契约测试”专门测试对外承诺的行为实现怎么改都行契约测试必须过。这个测试让 AI 帮你写它能覆盖很多你没想到的边界。第二在库里留一个“逃生舱”。当契约不适用时允许调用方绕过库直接操作。没有逃生舱的库遇到特殊情况就会被整体抛弃。逃生舱的设计要让 AI 帮忙想它列出的场景往往比你想的全。第三定期用 AI 做“契约漂移检测”。把库的文档和实际使用情况喂给模型让它找出“文档说一套、实际用另一套”的地方。这个我每季度做一次能发现不少隐性不一致。6. 我对这件事的最终判断回到标题的问题library building 被 AI coding 淘汰了吗我的答案是被淘汰的是“为了复用而复用”的建库方式被强化的是“为了固化契约而建库”的方式。AI 让写代码变便宜反而让“约定”变得更稀缺、更值钱。一个团队如果还在用“这个逻辑重复了三次所以抽个库”的思路建库那确实该重新想想了但如果能把建库的重心放在契约、边界、错误处理、性能取舍上那这个库在 AI 时代只会更重要。我自己的做法是把手里的库重新盘了一遍砍掉了近一半的纯工具函数库把省下来的精力投到契约型库上。同时我把 AI 深度接入了库的日常维护——生成测试、写 changelog、回答使用问题、检测契约漂移。这套组合拳打下来库的数量少了但下游的满意度反而高了因为留下来的都是真正解决问题的。最后分享一个小技巧如果你不确定一个库该不该继续维护就问自己一个问题——“如果这个库明天消失下游会出多大的乱子”如果答案是“没啥乱子重新生成一份就行”那它大概率可以被 AI 替代如果答案是“会乱套因为大家的行为约定都靠它”那它就是核心资产值得继续投入。这个判断标准比任何框架都简单好用。
