停止学习新框架，先学会淘汰旧代码

我们被“新工具”绑架了

过去三年，我参与了12个中型项目的技术选型，发现一个令人不安的规律：团队平均每8个月就会引入一个新框架，但代码库的“技术债”不降反升。以Cursor为例，2025年它因AI辅助编码风靡一时，可多数团队仅仅把它当作高级自动补全，而非重新思考代码结构的契机。

真正的效率杀手不是“不会用”，而是“不敢扔”。当你纠结于某段祖传代码是否该重写时，AI工具已经能生成100种替代方案——但前提是你愿意先删掉旧方案。技术分享的价值，不在于展示新工具多炫酷，而在于建立一套“淘汰机制”。

反常识真相：越能舍弃，效率越高

2024年Q4，我在一个金融科技项目里做了个残酷实验：强制要求团队每周删除5%的“看起来有用但无人调用”的代码。两个月后，系统响应速度提升31%，部署频率翻倍。删除代码不仅没增加风险，反而让AI助手（我们用的是Claude Code）的自动化重构成功率从43%飙升到82%。

为什么？因为现代AI编程工具（如Trae，或GLM-4）的推理能力依赖于“上下文窗口”，而冗余代码会稀释模型注意力。换句话说，每一次删除都是对AI的“减负”。这颠覆了“代码越多越好”的直觉——在AI时代，代码越少，工具越聪明。

案例：用“可弃性设计”重写登录模块

传统方案里，登录模块通常包含会话管理、第三方OAuth、验证码等10个子模块。我们的新设计将每个子模块独立成“微服务”，并约定“每个服务每季度必须通过一次模拟淘汰测试”。如果某个服务没有在上一季度被调用，就自动进入淘汰候选名单。

执行第一轮淘汰时，我们删除了一个“密码找回”服务——因为99%的用户改用短信验证码。这个决定看似简单，却让后续的AI代码审查（使用Claude Opus）能更精准地识别安全漏洞。

实操指南：构建你的“代码淘汰清单”

第一步：用数据说话。用IDE的“引用扫描”和“日志分析”找出3个月内零调用的函数。第二步：给代码“验尸”。对每个候选代码，问三个问题：是否被外部依赖？是否被测试引用？是否承载历史数据？全部否定，就删除。

第三步：建立“观察哨”。选一个非核心模块，强制实行“每周删除”制度。你会惊讶地发现，团队讨论的焦点会从“如何实现”转向“为什么存在”，这正是技术分享真正该有的样子。

别把你的技术团队培养成“新框架收藏家”。真正的专家，是那些敢于对过时代码说“不”的人。

从“学工具”到“建规则”

2025年，我看到很多团队沉迷于比较Claude Code和Cursor的代码生成质量，却忽略了自家代码库本身的健康度。就像给跑车加再好的油，但发动机里全是积碳，依然跑不快。

我建议每位技术负责人将“淘汰率”纳入KPI：每季度至少删除10%的“僵尸代码”。这不是浪费，而是对冲未来的技术债风险。毕竟，AI工具的迭代速度远超代码语言的进化，唯有轻装，才能跟上节奏。

当你下次准备分享一个新框架时，请先分享你删掉了什么。那份勇气，比任何API文档都更能定义你的技术深度。