系列第一篇。写给所有写过开源包的人：当 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 的？评论区聊聊。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
First in the series. Write to all who wrote the open source: What's the point when AI can write the code you saved five years in ten seconds?
I'm Long Kowloon, at the front end. I've written a few npm bags. I've worked on a couple of eco-based backstage regulations.
Let's start with the conclusion.
I did npm plugins for five years, once thought I had some technical barriers.
At the beginning of this year, the barrier was discovered to be false.
AI can write the parts that I wrote in a few seconds and give me an additional barrier-free treatment I didn't think of.
I almost gave up keeping these bags.
Then you figure out one thing and you start over: AI is not the enemy of the plugin, AI is the new user of the plugin.
I used to design the Plug-in for Man, and now I want to design the AI. The difference between these two things is much bigger than I thought.
This article is about this process. Not so much as a blow job -- data hasn't proven anything. Just tell me how I found out.
If you're maintaining an open source package, especially in the middle backstage direction, this might be useful to you. I'll end up saying which four things I did.
One, the reason for the bag, it's actually a good thing.
Since I started sending packages to npm, there are 10 -- a medium backstage collection, several components, a scaffold.
The reason is real:
The first is to work fast.
I've done a lot of backstage projects. Query, date formatting, dictionary echoes, dissensitization, thousands of places, State secret decryption... These codes have to be written over every item, and it's like, "Was it empty this time?"
The new item npm i is finished after the package is written.
The second is saving something.
On the front end of the line, the résumé says "Message Vue3". Write "I sent the npm bag" for at least two more words.
The third is the technical barriers — this is now a joke.
And I thought, "This is what I did for a few years. People have to pack my bags. This is the barrier."
This 10 packs cover the most important duplicate work in the middle backstage development. If you also do a project-by-line, ljs-tools install a package of tools functions - 15 tool modules plus 9 components.
In 2023, the idea was established.
By the end of 2025, it collapsed.
Two, AI written better and faster than me.
I usually write code. Every job done has a sense of achievement and pleasure. But then it didn't feel good.
One day I wanted a "number scroll" effect -- the number on the screen went up from zero to the kind of animation that targeted. I happen to have a moving-numbers-vu3 in my bag.
But I didn't do it that day.
Vue3 Write a screen number scroll from 0 to target, with 1,000 places
It gives the code to run. A thousand bits of processing has been added, a slow curve has been added and an accessibility downgrade has been added.
I looked at the screen for a while.
I wrote about two days of this requirement — how do we not roll back from the top when we deal with decimals, layouts when we deal with changes in the length of numbers, symbols, data updates?
AI took ten seconds. And it's barrier-free. I never thought about it.
My bag is really more complete in detail. Like, "How do you not roll back from 0" when you update the data? I'm dealing with it. But to be honest, this difference is simply not felt by the vast majority of users.
That night I went through my bag of download data.
S-timeline downloads 384 a week.
ball-swiper 372。
trends-table 371。
There's still water in these numbers. On October 23, when I issued the edition, moving-numbers-vue3 was downloaded 531 times a day -- all npm install from CI, not related to real users.
I was all numb. I was a traditional player, an antique of my friends, remembering that they already wrote the code, and I insisted on writing it myself, not thinking about it, and then writing it myself.
When I did, I realized that the times had changed, that AI had been able to handle 95% of business development, and that the remaining 5% had been caused by my lack of understanding.
The barriers that once believed themselves were gone, the protective clothing that had been worn had disappeared. Yes.
I want to understand one thing:
I'm proud of the "technical barriers", which are basically "bad information".
People used to write without knowing how to write, so they packed my bag. Now, AI knows how to write, and it's not too much trouble -- the barriers are gone.
The worst part is not "no one uses"
It doesn't make sense.
No one's using it anyway. AI can write anyway. What am I gonna do with it?
I really thought about it: Forget it, don't keep it.
After all these years of hard work, the AI.'s shock, and it's over.
It's sad all night. The warehouse wants to be deleted.
IV. The turning point is one sentence
Forget where I saw it.
AI is the new user of the plugin, not the enemy of the plugin.
I waited half a day.
A different question: Who's using my bag?
I used to think that people were using my bag.
Developer packs, looks at documents, writes code, meets bug to issue.
So what I'm perfecting is the human experience: README is clear, the parameters are full, the examples are enough.
But what if AI is a user?
It's first cam: I didn't know my bag existed.
Downloading 300 bags a week, training data probably doesn't have me. - I didn't get it.
Number two: I don't know what I can do if I know.
README is written to people, all the argument tables. - I didn't give it a readable description.
Third way: even if you know what you can do, you don't know what parameters to pass.
There are no types of statements, but guess. - I didn't define the type.
Number four: I don't know how to access it.
Global registration or partial introduction? Do you want the style to go manually? - I didn't give the access contract.
These four, each one is my responsibility, not AI.
The four were then put together into a set of "four floors of acceptance check" — capable of discovering, understanding, calling correctly and accessing directly. This is the most valuable reflection I've had in the past two years, and the second is devoted to how to land.
I realized at that moment that I've been complaining about AI taking my life, but never thought about it -- my stuff didn't even leave an interface for AI.
What should we do?
The main thing to do in the next few months is:
"Packages for people" and "Packs for AI."
Four specific things.
1. Making it detectable
There's a community agreement called llms.txt that allows AI to climb quickly to understand the project. In this format, I wrote a list of all 10 packages in the document station directory, each one of which is clear on the problem.
npm's keywords also rewrited. Turned out to be vue3 and component, the scene words are now added: ruoyi, admin-dashboard, sm2, watermark.
2. Making it understandable
Each package is accompanied by an AImd -- an instruction book written specifically for AI, not a list of parameters, but "when, how, and what pits."
Also completes the index.d.ts type declaration. This is key: AI defines the reading type much better than reading the document.
3. Enable direct access
This pit is the most. I wrote a scaffold, creating-ljs, an order to complete the project.
AGENTS.md - Project Manual for AI collaborators, describing the engagement, the red line, the common trap of the project, is placed in the template.
AGENTS.md has a lot of projects in use now. I was writing a reference to "document for a new coworker" -- what should I tell AI if it's a new coworker for this project? This analogy later became the skeleton of the whole system.
4. Opening all this up.
I hesitated the most.
I thought I had a hard time saving the code. What if it was taken away?
These codes are hard to save. Every word in every line doesn't look bright, but every sweat and tear in me.
Open source, isn't that right? If I don't open the door, I'll never shut the door!
And then again and again, I didn't wake up until the AI. hit Ko.
Then I figured out:
The code itself is not a barrier, and I'll determine which scene to use.
A beautiful aspect is not a barrier, a logical process, an analytical understanding of business.
And there's a more practical problem with not opening up -- my best work is hidden in a private warehouse, and nobody else can see it. If you don't see it, you don't.
VII. State of affairs
All 10 warehouses are open.
9 npm packages re-engineered publish, metadata completed, links to their respective source warehouses.
README rewrited -- it started with "# Profile / It's a dynamic form" and now it starts with "When to use it, when not."
I've only taken the first step, and the data haven't changed, but I'm in a better mood and I've changed my mind, and I'm friends with AI!
But one change is immediately visible: I can talk about this.
I used to say, "I've sent 10 npm bags," and they opened GitHub, 404. Open now to see the code, to see the history of the company, to see the design I made to make it friendly to AI.
At the end.
I can't say it's the right way. The data will prove everything or nothing.
But one thing I'm sure:
AI can write codes, I can't change this. What I can change is how friendly I wrote the code to AI.
This is a new question, and there is no standard answer. I'll try it my way. I'll try something out here.
The next one is about how the "Four Floors acceptance check" landed, and how they stepped on each of them.
Series of articles
- Part Two: Put AI on it: Four floors acceptance check.
- No. 3: The cleanup I made before opening the source.
If you're maintaining an open source package, how do you respond to AI? Talk to the comment section.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.