系列第一篇。写给所有写过开源包的人：当 AI 能十几秒写出你攒了五年的代码，这东西还有什么意义？
我是龙九山，前端，写过几个 npm 包，搞过几套若依生态的后台管理框架。
先说结论
我做 npm 插件做了五年，一度以为自己攒下了点技术壁垒。
今年年初发现，这壁垒是假的。
AI 十几秒就能写出我当初花两天写的组件，还多给了我一个我没想到的无障碍处理。
我差点放弃维护这些包。
后来想明白一件事，才重新开始：AI 不是插件的敌人，AI 是插件的新用户。
以前我给"人"设计插件，现在要给"AI"设计。这两件事的差别，比我想的大得多。
这篇文章讲的就是这个过程。不吹改造完多厉害------数据还没证明什么。只讲我怎么发现问题的。
如果你也在维护开源包，尤其是中后台方向的，这篇可能对你有用。我最后会说我做了哪四件事。
一、做包的理由，其实很功利
从我开始往 npm 上发包，到现在，一共 10 个------一个中后台工具库、几个组件、一个脚手架。
原因很实在：
第一个是干活快。
我做过不少若依系的中后台项目。判空、日期格式化、字典回显、脱敏、千分位、国密加解密......这些代码每个项目都要写一遍，写的时候还得想"这次 0 算不算空"、"日期格式用 yyyy 还是 YYYY"。
写成包之后，新项目 npm i 完事。
第二个是攒点东西。
前端这行，简历写"熟悉 Vue3"没人信。写"我发过 npm 包"至少能多聊两句。
第三个是技术壁垒------这条现在看是笑话。
我当时真这么想：这些东西是我踩了几年坑攒的，别人要用就得装我的包，这就是壁垒。
这 10 个包覆盖了中后台开发里最主要的重复劳动。如果你也做若依系项目，ljs-tools 装一个基本能把工具函数这块包圆------15 个工具模块加 9 个组件。
2023 年，这个想法还成立。
到 2025 年底，塌了。
二、AI 写得比我好，而且比我快
我平时手写代码。每完成一项工作很有成就感，很爽。可后来有点不是滋味了。
有天我要一个"数字滚动"效果------大屏上数字从 0 涨到目标值那种动画。我包里正好有个 moving-numbers-vue3 就是干这个的。
但那天我没装它，随手问了一句 AI：
Vue3 写个大屏数字滚动，数字从 0 涨到目标值，带千分位
它给的代码能跑。加了千分位处理，加了缓动曲线，还顺手加了个 prefers-reduced-motion 的无障碍降级。
我盯着屏幕看了一会儿。
这个需求我当初写了大概两天------处理小数点、处理数字长度变化时的布局跳动、处理符号位、处理数据更新时怎么不从头重滚。
AI 用了十几秒。而且它的无障碍处理，我当初根本没想过。
我的包在细节上确实更完整。比如"数据更新时如何不重新从 0 开始滚"这个坑，我处理了，AI 那版是直接重来的。但说实话，这种差别，绝大多数用户根本感知不到。
那天晚上我翻自己包的下载数据。
s-timeline 周下载 384。
ball-swiper 372。
trends-table 371。
这些数字里还有水分。10 月 23 日我发版那天，moving-numbers-vue3 单日下载 531 次------全是 CI 里的 npm install，跟真实用户没关系。
当时我人都麻了！我是传统派选手，好友口中的老古董，想起他们已经AI写代码了，我还坚持自己写，不会的动脑子学，然后再自己写，逼不得已再AI（AI完，我也得认真看，仔细学）。
当自己真的用了后，才发现时代变了，AI已经能搞定95%的业务开发，剩下的5%也是因为我说的不明白才导致的
曾经自以为的壁垒瞬间不存在了，好不容易穿上的防护服消失了，裸奔的感觉真的不好受
我想明白一件事：
我引以为傲的"技术壁垒"，本质是"信息差"。
以前别人不知道怎么写、懒得写，所以装我的包。现在 AI 知道怎么写，也不嫌麻烦------壁垒没了。
三、最难受的不是"没人用"
是想不通"这事还有没有意义"。
反正没人用，反正 AI 都能写。我花时间改它干什么？
那段时间我真想过：算了，不维护了。
辛苦了那么多年，AI的冲击，一瞬间决堤
一晚一晚的难过，仓库都想删掉了
四、转折点是一句话
忘了在哪看到的，大意是：
AI 是插件的新用户，不是插件的敌人。
我愣了半天。
五、换个问题：到底谁在用我的包？
我以前的想法是：人在用我的包。
开发者装包、看文档、写代码、遇 bug 提 issue。
所以我优化的是人的体验：README 写清楚、参数表列全、示例给够。
但如果 AI 也是用户呢？
**它的第一道坎：不知道我的包存在。**
周下载三百的包，训练数据里大概率没有我。------是我没让它能被搜到。
**第二道坎：就算知道，也不知道能干什么。**
README 是写给人的，全是参数表。------是我没给它可读的能力描述。
**第三道坎：就算知道能干什么，不知道该传什么参数。**
没有类型声明，只能瞎猜。------是我没给类型定义。
**第四道坎：就算猜对，不知道怎么接入。**
全局注册还是局部引入？样式要不要手动引？------是我没给接入约定。
这四条，每一条都是我的责任，不是 AI 的。
这四条我后来整理成一套「四层验收」------能发现、能理解、能正确调用、能直接接入。这是我这两年最有价值的一次思考，第二篇专门讲怎么落地。
那一刻我才意识到：我一直在抱怨 AI 抢了我的活，但从没想过------我的东西根本没给 AI 留接口。
六、那怎么办
后面几个月主要做一件事：
把"给人用的包"，改成"给 AI 也能用的包"。
具体四件事。
1. 让它能被发现
有个叫 llms.txt 的社区约定，让 AI 爬取时能快速了解项目。我照这格式写了一份放在文档站根目录，10 个包全列进去，每个一句话说清解决什么问题。
npm 的 keywords 也重写了。原来 vue3、component 这种大词，现在加了场景词：ruoyi、admin-dashboard、sm2、watermark。
2. 让它能被理解
每个包加一份 AI.md------专门写给 AI 看的说明书，不是参数表，是"什么时候该用、怎么用、有哪些坑"。
同时补齐了 index.d.ts 类型声明。这条很关键：AI 读类型定义比读文档准得多。
3. 让它能直接接入
这块坑最多。我写了个脚手架 create-ljs，一条命令生成完整工程。
还写了 AGENTS.md------写给 AI 协作者的"项目手册"，说明这个项目的约定、红线、常见陷阱，放在模板里。
AGENTS.md 现在不少项目在用了。我当时写的参考是「给新同事上手用的文档」------如果 AI 是这个项目的新同事，我该告诉它什么？这个类比后来成了整套方法的骨架。
4. 把这一切开源
这条我犹豫最久。
以前舍不得，觉得代码是我辛苦攒的，开源了被抄走怎么办。
这些代码是我辛苦攒起来的，每一行每一个字看起来不闪亮，却沾着我每一滴汗水和眼泪
开源了，岂不是都被抄走了？不开源我永远是关着门再造车！
就这样反反复复，直到AI的重击KO，我才清醒过来
后来想通了：
代码本身不是壁垒，我判断什么场景该用哪段代码，才是；
一个漂亮的function不是壁垒，逻辑思考的过程、业务的分析理解能力，才是
而且不开源有个更实际的问题------我最有分量的作品藏在私有仓库里，别人（面试官、潜在客户、AI）根本看不到。看不到就等于不存在。
七、现在什么状态
10 个仓库全部开源了。
9 个 npm 包重新发布了，元数据补齐，链接指向各自的源码仓。
README 重写了------原来开头是"# 简介 / 这是个动态表格"，现在开头是"什么时候该用它、什么时候不该用"。
虽然我才迈出第一步，数据还没变化，但是我的心情变好了，心态转变了，我和AI做了朋友！！！
但有个变化是立刻可见的：我能聊这东西了。
以前说"我发过 10 个 npm 包"，对方打开 GitHub，404。现在打开能看到代码、能看到 commit 历史、能看到我为了让它对 AI 友好做的设计。
写在最后
我不敢说这条路走对了。数据会证明一切，也可能什么都证明不了。
但有件事我确定了：
AI 能写代码，这件事我改变不了。我能改变的，是我写的代码对 AI 有多友好。
这是个新问题，还没有标准答案。我先按自己的想法试，试出来的东西会陆续写在这里。
下一篇讲具体做法------「四层验收」怎么落地，每一步踩了什么坑。
系列文章
- 第二篇：让 AI 用起来：四层验收（待发）
- 第三篇：开源前，我做的那些清理（待发）
如果你也在维护开源包，你是怎么应对 AI 的？评论区聊聊。