90% 代码用 AI 写？我拒了 Offer，也拒了所有华而不实的“网红技术”

0. 引言

都说 JavaScript 圈是一个娱乐圈，事实上这几年我感觉愈发如此。每次打开 GitHub、掘金、微信公众号，都能看到“下一代”的工具崛起了，这款工具脚踢 A，拳打 B，在它的宣传文案中。

也刷到了不少 AI 的文宣，一句话生成了那个比苹果还漂亮的 App，你看他好酷，前后端都可以似了 ——

就像水浒传里的鲁智深，今天解决掉了镇关西，明天拔了垂杨柳，后天又坐上了二龙山的宝座，活脱脱一个五边形战士。

在大半年前，我就和我的同行们抱怨过，

我觉得各种新技术真把我看焦虑了，现在前端岗本来就没以前吃香，我就希望能多会点卷过别人，结果每天看到各种新技术都冒出来，都说自己很 NB，感觉学不完，就和滚雪球一样。

这些新技术的作者和自媒体们不断地告诉你，你手上的东西已经落后了：“天哪，你会的东西在这个时代已经沦为了倒一！” —— 你应该去听我们的故事，学我们的新技术；你应该去报我们的课，我们来教你做什么。

看来技术的保鲜期越来越短，开发者的焦虑期却不断被拉长。

诸位读者如果读过我之前的文章应该能察觉出我其实是非常讨厌这种东西的，我感觉我对这些东西很哈气 —— 因为我曾经真相信了这些话术，现在算是一种反噬。

所以这篇文章，我想干脆摊开讲讲：

1. 我面了一家号称“90%代码用AI写的公司”，我拒了；
2. 为什么我对“下一代”技术比较警惕甚至反感；
3. 以及，在 2025 年，我到底怎么挑技术、怎么给自己的职业做一套长线布局

1. 确实有公司会因为网红营销而做了错误的决策

有人会说，老板、产品经理和架构师们可是会深思熟虑后才做决策的，不会被网红的东西忽悠过去的。

事实上做决定的人也会被话术和流量裹挟。

我拿氛围编程（Vibe Coding）举例吧。

10 月底的时候我在离家不算太远的城市的某家公司面试，在面试开始，面试官问了我这样一个问题：

你 AI 工具用的多吗，比如 Cursor？

我回答道：

我主要用 GitHub Copilot，也买了订阅，目前的话搭配着 GPT-5 模型在用，Cursor 我也用过，但因为习惯问题 Copilot 更多一些。

我当时还在奇怪为什么会问这个问题，后来面试官就拿着我的简历问了常规的一些东西，加上他们公司业务聊了一会儿。

到最后，他突然说

我们公司目前 90% 的代码都是用 Cursor 写的。

听到这句话的时候我脸色变了，我没想到网上的段子成了真。

面试结束之后，面试官给我发了一个网站，说你把这个复刻一下，写个 demo，用 AI 或者手写都行。

我当时领了这个任务，因为我还没想好是在这干还是拒绝，所以也在写，但是他“90% 用 AI”的话让我很是纠结，软件质量还要吗？

第二天我在 BOSS 上用了我拿到了 offer 的借口把这个公司回绝了，他们给的任务我也不做了。

其实不止这些，从知乎上来看，确实有公司因为氛围编程的网红热潮无脑选择了氛围编程，但现在氛围编程的热度已经退了，至于为什么热度会退，我们可以从一些很真实、甚至很残酷的负面反馈中看到：

1. 首先代码库更快地就变成了屎山，这一点我也有过体会。我曾经确实比较依赖于 AI，但是最后给我的感觉就是，AI 反而让最后的维护成本增加了一个数量级。LLM 生成的代码不少都是用力过度，对于实际业务场景根本用不上，如果再让 AI 改，那就更乱了。
2. 上面是我自己的体会，那我聊聊客观的代码流失率问题。所谓的“代码流失率”（Code churn），指的是代码被写出之后不久就被修改或者删除的比率。根据 GitClear 的报告，AI 编码代理普及之后代码流失率大大增加。
3. GitGuardian 发布的 《2024 年代码安全状况报告》显示因 AI 工具导致的公开存储库中敏感信息被泄露的时间越来越多，且和 AI 有关联。

2. 还有一些例子。。。

我们再聊聊 CSS-in-JS 这个曾经被炒得火热、后来一地鸡毛的网红。

以 styled-components 为代表的 CSS-in-JS 技术曾经被视作解决 CSS 模块化、样式冲突问题的终极方案，然而随着时间的推移开发者越来越意识到这是有性能问题的，尤其是在大型项目中。每次组件渲染时，库都需要序列化样式、生成哈希类名、插入 <style> 标签。这在复杂列表或频繁更新的动画中会导致显著的 JS 阻塞。现在主流的前端框架更倾向于用零运行时的方案，比如 Tailwind CSS、StyleX。

styled-components 客观来说是解决了当时的很多问题，没有说它不好。但是就算不从上帝视角来看，styled-components 后续带来的问题也是能预料到的，可是还是一股脑地选择了这个。

3. 网红技术对谁是好事我觉得得想清楚

在上一篇《从 Anthropic 收购 Bun 谈起，聊聊 Bun 的败局》的评论区中，有评论说到，Bun 对它的作者来说不亏，被收购也就意味着拿到钱了。

一个拿到了 VC，最后成功被收购的公司/项目，对它的创始人来说当然是好事；对布道师来说也是好事，他的课能卖掉了。

可直面业务一线的你，无论你是一线开发、还是架构师还是 PM，

大道理人人都懂，我们不妨直接直面一个问题：利益。

对于一些技术负责人和架构师来说，其实也是一个老招数，就是简历驱动开发。

我在公司推行一套最潮的 Rust 工具链，或者加上目前最火的某某某某大模型，无所谓，就加个对话就可以，成不成功也无所谓；但这样的话我在简历上就可以写，“基于 XXX 的现代化重构”，以此为跳板，进大厂月入 66666 万不成问题。

但是今年是 2025 年，这招行不通。

其实硅谷大厂也将寒气已经传递到了每一个人，在 2023 年经历了大规模裁员之后，2024 和 2025 并没有迎来报复性的招聘反弹。虽然老板可能一直都比较看重投入产出比、单纯重构并不受待见，但是用新技术升级这一套也已经不受待见了。

其实我在 BOSS 上看到，职位要求里面越来越少地提到了掌握哪些前沿的技术，靠学会这种新玩意跳槽涨薪，还是算了。

而且，2025 年了，业务能力比技术重要的多。业务能力这一块我们在 5.2 会展开聊。

4. 通货膨胀

在 2025 年 12 月，我们不得不承认一个事实：

JavaScript 生态圈经历了前所未有的通货膨胀。

或许是 JavaScript 开发、甚至是狭义上的前端，入门的门槛低¹，所以吸引了大量的开发者和创业者进入这个领域。各种轮子层出不穷。

有人说，JavaScript 生态圈里百花齐放、百家争鸣不是挺好的吗？百花齐放当然是好事，没有百花齐放的生态可能也没有今天的前端和今天的我。

请注意，百花齐放和“网红”归根到底不是一回事。

其实从营销手法来说，Vite 也带点网红（毕竟它在官网中是“下一代构建工具”），但我并没有去把它当作反面的例子来看待，为什么？Vite 实质上是做减法 —— 减掉了熵。

Webpack 在启动开发服务器的时候会执行一个相对完整的打包过程，导致时间上的浪费，Vite 则不然。Vite 确实很好地解决了 Webpack 的这一个痛点。

Biome 也差不多，实践证明代码质量检查（ESLint）和代码风格（Prettier）工具不需要分开，Biome 对这个进行了整合，让开发者配置更容易，而且 Rust 的高性能确实和 Biome 的业务情形比较匹配。

我在上篇文章中，我把 Bun 比喻成了网红餐饮，我觉得这里可以更继续拓展一下。

网红餐饮这一块，我曾经留意过某个加盟商的一个 IP，那个时候还是挺火的，几年之后的今天，我是没怎么见到这个 IP 了。

因为确实没有什么实质性的东西，一时觉得新鲜，到最后发现没有粘性，为什么没有粘性，因为没有满足我的需求。有些加盟商也其实是赚快钱，一阵风，赚到钱了，就走了。

其实在开发这一行，差不多。也是因为不好吃（解决不了痛点），所以也就没人买单了，也有的就是一阵风（趁这个 IP 火热赶紧收割），赚到钱了就走了²。

好了，该用什么标准来筛选掉 90% 没必要碰的东西？

5. 我的选择

2025 年对我来说必须承认一个现实：

现在解决业务的能力更重要，因此我也只能认真吃透少数几块技术，其他的只能略读或者无视。

我在提到要不要学 Rust 的时候说：

其实我看 Rust 发展势头还可以，也不像前几年那样像个“编程原神”，但是未来怎么样还是得花一年半载观察，所以我就算要学的话也是过几年再说。我感觉我从纯前端开始涉及后端直到 Go 就够我喝一壶了，至少这段时间我是没精力再学新的了。

5.1 它如果出了纰漏，我能不能自己收拾烂摊子？

一项技术值不值得用，对我来说，不能只看它“装起来有多快、Demo 跑起来有多炫”，还得想想：几年之后这套房要不要我自己拆墙重装？ 我不在乎它刚开始多顺滑，我在乎的是：等哪天它开始到处渗水、漏风的时候，我有没有本事把这套精装修拆了，自己接盘收拾。

如果作者撂挑子不干了，或者在我有必要快速迁走的时候，我能快点抛掉烫手山芋。

我记得上篇文章中我也说过，因为 JavaScript 生态本身就是去中心化的，所以试图大一统工具链是不合理的。我当时是从技术角度来论证不合理，其实还有一个更现实的角度：供应商锁定风险。

我们来看一个很典型的“网红”叙事，市面上开始出现了一些号称“下一代”的统一工具链，我们姑且称之为 “Tool Plus Pro Max Ultra”。

别再浪费时间配置 ESLint、Prettier、Jest 和 Turborepo 了！ Tool Plus Pro Max Ultra 是一个基于 Rust 的下一代前端工具链。你只需要安装它，然后运行： toolpro lint：比 ESLint 快 100 倍！ toolpro test：零配置运行测试！ toolpro lib：一键打包你的库！ toolpro run：智能运行器！ 我们也是开源的，个人开发者和中小企业免费，其他用户购买订阅。

看起来是不是很诱人？

你只需要付出一丁点的学习成本，甚至不需要写任何配置文件，不需要去纠结 eslint 和 prettier 怎么打架，一行命令，它全帮你搞定了。生产力似乎瞬间爆表，一个小时干完了一天的基建工作。

那高月供是什么？当你把项目里所有的 scripts 都改成了 toolpro xxx 之后，你实际上签署了一份霸王条款：

1. 你发现它的全家桶里有个功能没适配，你去联系他公司或者发 issue 催更，结果对方告诉你“敬请期待”
2. 它是一个商业项目，总归需要赚钱的。使用是会产生粘性的，随着你公司业务增长，或者它背后公司决定收紧 —— 它会要求你掏钱 —— 当然你不买也可以，业务做大了被他们发现了就是律师函警告。
3. 违约金。你说：“那我不借了，我换回开源社区的方案”。这时候你才发现，你已经没有独立的配置文件了。你的项目结构、你的测试用例写法、你的构建逻辑，全部是按照 toolpro 的“最佳实践”（即私有协议）来写的。想拆？你得把整个地基挖开，重新配置 Webpack/Vite，重新写 ESLint 规则，重新调试测试环境。

这就好比你为了省事，买了一套精装修的房子，结果发现墙里的水管接口是开发商特制的，市面上买不到配件。一旦漏水，你只能花高价请开发商来修，或者把墙全砸了重铺。

或者是，你发现它其中一个功能不好用，结果你换了别的工具，但是 Tool Plus Pro Max Ultra 封装地太好了，你要去改，你改了之后发现我还不如用原来的脚手架自己配置一个，Tool Plus Pro Max Ultra 我白用了。

我也此前也一直强调，业务更重要，而且业务更重要 != 一条龙服务。

既然承认“业务更重要”，那更合理的做法应该是：用最通用、最可替换的工具，保证业务在任何工具故障、商业策略变化时，都能相对平滑地迁移，而不是反着来：鼓励你把整条业务交付流水线，都写进它自己定义的世界观里。你的业务交付节奏和组织协作方式，已经深度和这个产品绑在一起了。这个时候再谈“业务优先”，其实是“供应商优先”：你做产品决策之前，要先想一想 Tool Plus Pro Max Ultra 支不支持。

这样的工具也没有解决掉痛点，它所要解决的只是一些痒点 ——

GitHub 上其实有大把作者们封装好的 Starter，那些 Starter 是通过一系列精心编写的配置文件，把好用的开源工具组合在一起，而不是用代码组成一个黑盒，这类 Starter 可以开箱即用，也可以按照自己的需求去改造。我们也之前说 AI 是小镇做题家，对于这类 Starter 的配置，AI 其实可以告诉你该怎么去修改的，那么综上所述。Starter 才真正解决了这样的样点，至于那种黑盒工具链，可能只是暂时止了痒，未来恐怕更痛。

5.2 在编程行业里，走一条“偏稳”的路线

要是把我们的精力看成有限的体力条，那至少要有一块是投在“永远吃得开”的本事上。就算那些新技术最后被证明是昙花一现，我好歹还有几样真本事能养活自己。

众所周知 jQuery 已经完蛋了，为什么完蛋了，因为它仅仅是这个时代的产物，ECMA 规范越来越完善，API 越来越多，jQuery 这种东西就已经没什么意义了，需要点放之四海而皆准的东西。我觉得主流的前端库还是得把握住比较好，还有就是基本功，这些不会随着 AI 普及而取代。React 到现在也十几年了，为什么不死，就是因为它的设计理念是放之四海而皆准的，并不是升级了哪个标准、哪个浏览器引擎，它就丧失意义了。

写到这里我知道可能有读者会觉得：

你这是小孩子都懂的大道理，老生常谈。主流技术我也都会了，你说这些正确的废话有什么用？

就是因为这些是大家都会的，所以都忽视了。

我这一小节我也不会花篇幅告诉你这些主流技术多重要，如果我老生常谈，写到这里的时候我还会洋洋洒洒地和你继续论证上面那些大道理。

好，那我问你：

你的不可替代性到底在哪里？

难道是：

我精通 Next.js、Nuxt、Rolldown、SWC、Prisma、DrizzleORM、Hono、Deno …

我们读有些古代文学作品的时候会发现，作者没有多少自己独特的表述，而是掉书袋，动不动就是圣人云，或者就是大幅度引用谁谁谁的话。有的时候会说明这个作者本身没有独特的见解。

AI 写的比你更好。AI 看过的 API 文档比你多，搓出来的样板代码比你快，AI 在掉书袋能力上吊打你。如果你的工作内容仅仅是把你的领导的需求翻译成某个框架的 API 调用，那你本质上只是一个代码中介，你这层中介换成张三做也可以、李四做也可以，或者干脆不要中介也可以。

电视剧《征服》中，刘华强对封彪说：

和我刘华强拼，你有这个实力吗？

我承认，至少从我而言，我如果真的只会技术，我真拼不过 AI。

好了，言归正传。

在这个周期，所有公司都在干一件事：去中介化。

我总说 Transformer 模型并不能真正思考，Transformer 有的时候是能提供一些想法，或者它是能模拟人类的思路思考问题，但它这些东西是背下来的，所以就是做题家。

但是很多业务问题，虽然也是各种经验的累积，但也是经过详细思考才能给出答案。

一个运行多年的项目，代码里的一个很莫名其妙的 if-else，我觉得只有精通业务的人才能真的明白为什么这样做，可能是为了兼容三年前的一个错误数据，也可能是为了配合财务部门的一个奇葩流程。这种基于对业务深刻理解的“脏活”，AI 处理不了，我觉得只有懂业务、懂基础原理的开发能处理。

还有，我们还可以拿 Cloudflare 上个月暴雷的那个问题说事。Cloudflare 那个问题就是很典型的，不精通业务做的事情。

那个写下 unwrap() 的开发，他可能觉得，这个配置文件反正是内部的，无所谓，直接用就是了。结果数据库那边权限一个变更，就炸了。

但是你如果真的精通业务的话，你的不可替代的价值在于，当脑袋里闪过 unwrap() 这个 API，觉得可以快速搞定功能时，你凭借着对业务复杂度的理解，回归了理性：

不行。这里必须做错误兜底。因为财务系统那边每个月月底会锁表，这个文件可能会读取超时；或者运维那边可能会调整容器的内存限制。我们不能假设环境是完美的。

这种经验，是 AI 学不来的，才是真正不可替代的。我也是开发，我真感觉我们大家都不容易，所以与其在各种不断贬值的网红技术中随波逐流，不如把精力投资在拿不走、不过时的东西上。

6. 注释和参考资料

Footnotes

1. 之前也提到我是培训班出身的，其实深有体会，JavaScript /前端入门挺容易的。当然，虽然入门容易但是精通也比较难，这里仅仅说入门门槛低的问题。 ↩

2. 有个例子关于一些 AI 创业公司的，可以去看下：https://dev.to/dev_tips/the-graveyard-of-ai-startups-startups-that-forgot-to-build-real-value-5ad9 ↩