《用了3个月Cursor后，我删掉了自己写了10年的工具库》：从“造轮子自豪”到“承认AI写得更好”的心理崩塌与重建

引言：那个按下Delete键的凌晨三点

2026年6月的一个凌晨，我坐在显示器前，光标停留在一个名为 core-utils 的仓库上。这个仓库里有482个文件，12万行代码，是我从2016年开始，用10年时间一行行敲出来的“军火库”。里面有我引以为傲的高性能JSON解析器、有为了绕过某个框架缺陷而写的精巧补丁、有无数个深夜调试出来的并发安全队列。它们曾是我简历上最硬的鳞甲，是我在团队里说话算数的底气，是我作为“资深工程师”的身份图腾。

然后，我按下了删除键。

没有误操作，没有冲动。这是一个经过90天痛苦挣扎、反复验证、最终不得不接受的理性决策。触发这个决定的，不是某个竞争对手的开源项目，而是Cursor——一个AI编程助手。在过去三个月里，它用一种近乎残忍的方式向我证明：我那些被视为“匠心”的代码，在2026年的工程语境下，已经变成了“债务”。

这篇文章不是Cursor的软文，也不是对老工程师的嘲讽。它是一份心理验尸报告，记录了一个手艺人如何在技术范式转移中经历身份崩塌，又如何在废墟上重建职业尊严的过程。如果你也曾对着AI生成的完美代码感到过一阵空虚，如果你也在“造轮子的自豪”和“用AI的高效”之间撕裂过，那么这篇文字是写给你的。

第一章 傲慢期：“AI写的代码没有灵魂”

1.1 手艺人的条件反射

2026年3月，当团队开始全面推广Cursor时，我的第一反应是抵触。这种抵触不是出于对新技术的恐惧，而是出于对手艺的骄傲。我写了10年代码，深知每一行背后的权衡、每一个边界条件的来历、每一次重构的阵痛。我相信代码是有“灵魂”的——那种灵魂来自于人类在不确定性中做出的判断，来自于对业务上下文的深刻理解，来自于无数次踩坑后长出的直觉。

AI懂什么？它不过是个概率模型，是个高级自动补全。它能写出语法正确的代码，但它能理解为什么我们在2021年选择用环形缓冲区而不是链表吗？它能知道那个看似冗余的重试逻辑是为了应对某云厂商特定可用区的抖动吗？它不能。所以，我断定AI写的代码“没有灵魂”，而“没有灵魂”的代码在生产环境中是危险的。

1.2 选择性失明与确认偏误

在这种心态下，我开始了一场为期一个月的“找茬游戏”。每当Cursor生成一段代码，我就带着显微镜去审查，专挑它的毛病：这里没考虑空指针，那里并发不安全，这个命名不符合我们的规范。每找到一个错误，我就在心里冷笑一声：“看吧，果然不行。”

但我刻意忽略了另一些事实：那些被我挑出毛病的代码，往往是在我故意给出的模糊提示下生成的；而那些在我提供了完整上下文、明确约束条件的场景中，Cursor的输出质量已经超过了我的预期。我更忽略了，我自己写的代码也并非完美——只是我对自己的缺陷习以为常，对AI的缺陷却零容忍。

这是一种典型的确认偏误。我不是在客观评估AI，而是在捍卫一个即将被颠覆的自我认同。

1.3 傲慢的代价：第一次效率羞辱

转折发生在一个周五下午。一个新来的应届生用Cursor在两小时内完成了一个数据迁移脚本，包括完整的错误处理、日志记录和单元测试。同样的任务，如果我用自己的工具库手写，至少需要一天半——不是因为我的工具库不好，而是因为我要花时间回忆10年前写的设计文档、适配当前的新框架版本、处理工具库本身与新环境的兼容性问题。

更讽刺的是，那个应届生的脚本跑起来比我的工具库封装的方案还快15%。因为Cursor直接使用了2025年新发布的标准库特性，而我的工具库还在兼容2019年的运行时环境。

那一刻，我第一次感到了一种难以名状的羞耻。不是因为我被新人超越了，而是因为我意识到：我所珍视的“积累”，在某些维度上已经变成了“负担”。

第二章 崩塌期：当“护城河”变成“沉没成本”

2.1 工具库的真实审计

羞耻感驱使我做了一件从未做过的事：对 core-utils 进行一次彻底的、不带感情色彩的审计。我邀请了两位刚入职的工程师（他们没有对我代码的历史滤镜），让他们用Cursor重新实现工具库中的核心模块，然后进行盲测对比。

结果令人窒息：

• 性能：12个核心模块中，AI重写的版本在9个上性能持平或更优。原因很简单：AI训练数据包含了最新的优化论文和基准测试结果，而我的知识停留在上次深度阅读文献的2022年。
• 可维护性：AI生成的代码注释覆盖率100%，测试覆盖率95%以上，且严格遵循2026年社区最佳实践。我的代码注释率不足30%，测试覆盖率60%，风格混杂了10年间不同阶段的编码习惯。
• 安全性：AI版本自动规避了3个我已知的CVE漏洞和2个我尚未察觉的潜在风险。我的代码中有1个未修复的中危漏洞，是因为去年忙于业务需求没时间处理。
• 上手成本：新工程师理解AI重写版平均耗时2小时；理解我的原版平均耗时3天（包括阅读过时文档、询问已离职同事的背景）。

2.2 身份认同的瓦解

数据不会说谎，但接受数据需要勇气。当我不得不承认AI在多个维度上“写得更好”时，崩塌的不只是一个工具库，还有建立在它之上的自我叙事。

“我是那个最懂底层的人”——现在AI比我更懂最新的底层。 “我是那个最能扛复杂系统的人”——现在AI处理复杂度的带宽比我高两个数量级。 “我的经验是不可替代的”——现在我的经验正在被模型权重以毫秒级速度吸收和超越。

这种感觉不像被裁员那样剧烈，而是一种慢性的、深入骨髓的失重感。你发现自己花了十年磨的剑，在别人手里只是一把可以批量生产的螺丝刀。你不是不够好，你是“不再必要”。

2.3 哀悼的必要性

很多关于AI效率的文章都跳过了这个阶段，直接奔向“拥抱变化”的光明结局。但心理重建不能跳过哀悼。那10年的代码，那些熬夜的夜晚，那些解决难题后的狂喜，都是真实的生命体验。它们不该被一句“过时了”轻飘飘地否定。

我允许自己难过了一周。我把 core-utils 的最后版本打了个tag，写了一篇内部博客回顾它的诞生、演进和贡献。我感谢它曾经支撑过的业务、培养过的思维、连接过的战友。承认它的终结，不等于否认它的意义。 只有完成了这场告别，才能腾出空间容纳新的可能。

第三章 重建期：从“代码作者”到“意图架构师”

3.1 重新定义“好代码”的标准

崩塌之后，我必须回答一个问题：如果AI能写出更好的代码，那工程师的价值在哪里？

答案藏在审计报告中一个被忽略的细节里：AI重写的9个优胜模块，全部是在我提供了精确的意图描述、约束条件和验收标准后才实现的。而那3个AI表现不佳的模块，恰恰是我当时偷懒、只给了模糊指令的场景。

这让我意识到：2026年的“好代码”，其质量上限不再取决于编写者的手工技艺，而取决于意图表达者的认知清晰度。 AI是放大器，它放大的是你的思考质量，而非你的打字速度。如果你的思考是混沌的，AI只会高效地生产出精致的垃圾。

于是，我重新定义了工程师的核心能力模型：

3.2 建立“人机协同”的新肌肉记忆

有了新标准，下一步是训练新习惯。这比学一门新语言更难，因为它要求改变根深蒂固的思维惯性。

• 从“怎么写”到“要什么”：接到需求时，我不再立刻打开编辑器，而是先在文档中写下：目标是什么、约束有哪些、成功如何衡量、失败如何兜底。这份文档既是给人看的PRD，也是给AI看的System Prompt。
• 从“信任自己”到“验证一切”：过去我对自己写的代码有本能信任，只对别人的代码严格审查。现在我对AI输出和自己手写的代码执行同等甚至更严格的验证流程。建立了自动化校验管道：静态分析+动态测试+人工抽检三重防线。
• 从“个人积累”到“共享意图库”：不再维护私有工具库，转而建设团队级的“意图模板库”：将高频场景的问题定义、约束清单、验收标准沉淀为可复用的Prompt模板。这让整个团队的AI协作质量下限大幅提升。
• 从“解决问题”到“定义问题空间”：AI擅长在给定问题空间内寻找最优解，但不擅长判断问题空间本身是否合理。我的新价值在于：在AI动手之前，先质疑需求本身的合理性、识别被忽略的利益相关方、预判技术方案的组织影响。这些是AI训练数据中稀缺的“暗知识”。

3.3 找回尊严的时刻

重建不是一蹴而就的。直到两个月后的一次生产事故复盘，我才真正感受到新身份的稳固。

一个AI生成的缓存模块在高并发下出现了罕见的竞态条件。如果是三个月前的我，可能会陷入“AI果然不可靠”的情绪漩涡。但现在的我，冷静地带领团队完成了三件事：① 定位根因（AI未考虑到我们特有的分布式锁超时配置）；② 修复并补充了针对该场景的验证用例；③ 将此次教训更新到团队的“AI协作避坑指南”中，防止同类问题复发。

事后，CTO在邮件中说：“这次响应体现了真正的工程成熟度——不是不出错，而是出错后能快速学习并系统化防御。”

那一刻我明白：尊严不再来自“永不犯错的神话”，而来自“在不确定性中持续创造确定性的能力”。 AI可以写出更好的代码，但只有人能定义什么是“更好”，并承担“不够好”的后果。

第四章 给老工程师的生存指南：如何避免成为“悲情注脚”

我的经历不是个例。在2026年的技术转型浪潮中，无数资深工程师正经历类似的阵痛。以下是我从血泪中提炼的四条建议，希望能帮你少走弯路。

4.1 警惕“经验陷阱”：你的优势可能是最大的盲区

10年经验让你能快速识别模式，但也让你更容易陷入确认偏误。当你觉得“AI这地方肯定不行”时，先问自己：这是基于当前事实的判断，还是基于过去经验的投射？定期邀请“无知者”（新人、跨领域同事）参与评审，他们的“不懂”恰恰是校准你认知偏差的良药。

4.2 区分“可替代技能”与“不可替代智慧”

编码实现、API记忆、语法熟练度——这些是可替代技能，AI做得比你快是正常的，不必为此焦虑。问题定义、权衡取舍、组织洞察、伦理判断——这些是不可替代智慧，它们存在于你的失败教训、人际网络、业务直觉中。把精力从打磨前者转移到深耕后者。你的价值不在手指上，而在脑子里和心里。

4.3 主动“杀死”过去的自己

不要等到被外界逼迫才放手。每季度给自己安排一次“技能葬礼”：识别一项你引以为豪但已趋边缘化的能力，主动用它换取一项新兴能力的学习时间。自我颠覆的痛苦远小于被动淘汰的绝望。 删除10年工具库很痛，但比起一年后整个岗位被裁，这痛是值得的投资。

4.4 建立“成长型身份”：你不是你的代码

许多老工程师将自我价值与代码产出深度绑定。当代码被AI超越时，自我也随之崩塌。请将身份锚点从“产出物”转移到“学习力”和“适应力”上。 你不是“那个写了10年工具库的人”，你是“那个能在范式转移中快速重建价值的人”。前者会过时，后者永不过时。

结语：在废墟之上，看见更辽阔的风景

删掉 core-utils 的那个凌晨，我以为失去了一切。三个月后回望，我才发现那是一次迟到的解放。

那10年的代码从未真正消失。它们化作了我的思维方式、我的判断直觉、我对工程本质的理解。AI可以复制代码，但无法复制代码背后那个在黑暗中摸索、在失败中成长、在不确定中坚持的人。

2026年的工程师，不再是孤独的造物主，而是人机共生系统中的“意义赋予者”。我们不再亲手砌每一块砖，但我们决定了建筑为何而建、为谁而建、如何在风雨中屹立不倒。

这或许少了些手作的温度，却多了些系统的辽阔。

如果你也正站在崩塌的边缘，请相信：废墟不是终点，而是地基。当你放下对旧身份的执念，双手才能真正腾出来，去触摸那个更大、更复杂、也更值得探索的新世界。

而那个世界里，依然需要你——不是作为过去的影子，而是作为未来的同行者。