之前带过大大小小的业务线：
一个前端工程师，花了整整三个月，把团队一个跑了四年的祖传项目从 Webpack 4 迁移到了 Vite，顺手把 JavaScript 全量改成了 TypeScript，修了 300 多个类型错误，重构了整个请求层，接入了 Sentry 错误监控，搭建了完整的 CI/CD 自动化流水线。
迁移完成后，构建时间从 4 分钟降到了 12 秒，线上报错率下降了 60%，新人上手时间从两周缩短到了三天👋。
然后到了季度绩效评审，他却拿到了一个 符合预期😃。
做的越多越好吗？
基建工作有一个极其残酷的性质——它的成功，是以什么都没发生来衡量的。
你搭建的 CI/CD 流水线，在每次合并 PR 时自动跑完测试、自动构建、自动部署。当它正常运转时，没有人意识到它的存在。只有当它挂了的那天，所有人才会突然想起来：哦对，这个东西是谁维护的？🤔
你重构的请求层，把所有接口的错误处理、竞态取消、Token 刷新统一收口了。上线后，线上白屏事故从每周两三次降到了零。但没有事故这件事，在绩效评审的叙事里是不存在的——因为你没办法证明如果我没做这件事，会出多少事故。
绩效的底层逻辑什么？
你必须理解一个极其冷酷的事实：绝大多数公司的绩效评审系统，底层逻辑是 输入 → 产出 → 业务结果的线性因果链。
这条链对功能开发极其友好：
产品提了需求 → 我开发了分享按钮 → 分享率提升 15% → 商业价值
因果清晰，归因明确，老板一看就懂🤔。
但基建工作的价值链是这样的：
我迁移了
TypeScript→ 团队的类型错误减少了 → 线上 Bug 率下降了 → 用户投诉少了 → 客服成本降低了 → ……
你看到问题了吗？从你的工作到最终的商业结果之间，隔了四五个因果环节。每多一个环节，归因就模糊一层。到了老板那里，他看到的是本季度客服投诉下降了，但他会把功劳归给客服团队的培训优化，或者产品的流程改进，绝不会想到是三个月前一个前端工程师做的 TypeScript 迁移。
技术语言是最昂贵的沟通障碍！
我见过太多这样的述职 PPT：
本季度完成了项目从
Webpack到Vite的全量迁移，构建产物从CommonJS统一为ESM，开发环境冷启动时间从 240 秒优化到 12 秒，HMR 热更新从 3 秒降到 200 毫秒。同时完成了全量TypeScript迁移，strict模式覆盖率 100%，消除了 327 个隐式any类型。
评审委员会里坐着的，大多是业务方向的技术管理者。他们听完的第一反应是：
然后呢？这些对业务有什么影响？
你说构建时间从 240 秒降到 12 秒，他不知道 240 秒意味着什么。你说消除了 327 个 any，他不知道 any 是什么😑。你以为这些数字极其震撼，但在对方的认知框架里，这些就是一堆无法和商业价值挂钩的技术黑话。
如何破局
如果你已经在做基建工作，或者即将承担一项重大的技术迁移，以下是你必须在第一天就开始做的事情——不是写完之后补，是从立项那一刻就同步进行👇。
迁移之前，先去量化代价
在你动第一行代码之前，先花一天时间，把旧系统造成的痛苦用数字记录下来：
迁移之后呢？
同样的工作，换一种语言，在绩效评审中的得分是天壤之别。
最后说一句不太好听的话
如果你做完了以上所有事情——量化了价值、翻译了语言、做了过程可视化——你的 Leader 和公司依然觉得基建工作不值一提🤔……
那这不是你的表达能力问题，这是组织的价值观问题。
一个不愿意为基础设施投入尊重和资源的公司，最终一定会为此付出极其惨烈的代价——当线上事故因为年久失修的基建接连爆发时，那些曾经做过基建、被寒了心、最终离开的工程师，不会再回来救火🫡。
共勉🙌
喜欢我的文章，也欢迎关注我的微信公众号：【前端技术官】。
主要分享：前端架构 · AI 编程 · 职场认知 · 开发者成长
微信扫码关注 👆
不定期更新，不刷屏，聊点真正有用的干货。
