基建类经历在简历上有个通病一行工具名。- 搭建了基于 Jenkins Docker Kubernetes 的 CI/CD 流水线这句话从 2020 年起可以出现在任何一份后端简历上。评审者读到它脑子里冒出来的是三个问题这是从零搭的还是照公司模板改了两行搭之前是怎么发布的搭完之后有多少人在用。三个问题简历上一个都没答。基建的价值只能靠「前后差」表达业务功能有需求方做出来就有人用价值自然可见。基建没有需求方它的价值在于替代了什么。所以写基建第一句必须是「之前」之前手动 scp jar 包、之前一次发布 40 分钟、之前每周回滚两次、之前只有一个人会发。没有「之前」读者就没有参照系你写的一切都只是一份工具清单。四个可量化的维度发布耗时从合并到线上生效多久。发布频率每周发几次改完之后每天几次。失败率多少次发布需要回滚回滚要多久。人的时间每周省了多少人时或者从「依赖某一个人」变成「任何有权限的人」。这四个维度和业界常提的那套交付指标是对应的但简历上不要写指标的名字写数字。没有精确数字就写量级「从小时级到分钟级」也比「提升效率」强。写出难的那部分配一份 pipeline yaml 不难面试官知道。CI/CD 真正难的地方是测试不稳定怎么处理数据库迁移怎么进流水线多环境配置怎么管老项目怎么容器化灰度和回滚怎么做。你的经历里一定碰到过其中至少一个。写出来这是「搭建者」和「使用者」的分水岭。改一条看改前- 搭建了基于 GitLab CI Docker Kubernetes 的持续集成与部署流水线提升了团队研发效率改后- 接手时 6 个服务由运维手工 scp 发布单次约 40 分钟且只有一人会操作 改为 GitLab CI 构建镜像 Helm 部署到 K8s发布缩到 6 分钟有权限的开发都能发周发布次数从 2 次到 10 次以上。 过程中的两个卡点Flyway 迁移改为独立 Job 在滚动更新前执行避免新旧版本同时跑在旧表结构上 集成测试里 3 个依赖系统时间的用例不稳定改为注入 Clock 后 pipeline 成功率从约 70% 到 98%改后的信息量之前的状态、之后的状态、两组数字、两个具体卡点。每一样都能往下问而且都是只有真做过的人才会碰到的细节。其他几类基建怎么写监控告警之前靠用户报障之后告警先于用户写清楚接了哪些指标、误报率怎么压下来的。日志链路之前登服务器 grep之后集中检索加 traceId 串联写一次靠它定位的问题。内部工具和脚手架多少人在用、省了什么重复劳动。规范落地PR 模板、lint、覆盖率门禁写采纳率和阻力比如「覆盖率门禁从 40% 起步每季度提 10%避免一刀切」。每一类都是同一个结构之前、之后、难点、有多少人在用。采纳率是基建特有的指标工具做出来没人用等于没做。「团队 12 人全部迁移」「另外 3 个团队主动接入」比任何技术细节都更能说明这件事做成了。反过来只有你自己在用的基建简历上要慎写。推广过程里遇到的阻力也值得写一句比如「老服务启动脚本不统一先做了标准基础镜像才迁得动」。这说明你处理过基建落地里最麻烦的部分存量系统和用它的人。别写的几种把公司已有平台的日常使用写成「搭建」把照着文档装了一遍写成「设计」一行里列超过五个工具名只写工具不写前后差把一次性迁移写成长期维护。面试追问会往哪走为什么选 Helm 不用 Kustomize回滚怎么做回滚时数据库怎么办secret 怎么管pipeline 本身挂了紧急发布走什么路径。这几个问题答得出来「搭建」这个词才站得住。写完可以整份扫一遍格式基建经历里工具名多大小写和写法K8s、k8s、Kubernetes最容易前后不一致。棱镜简历prismresume.cn/check免费体检不用注册粘贴文本或上传 PDF几十秒列出表述缺失、格式不一致这类问题。最后基建经历的价值不在工具名里在「之前是什么样、之后是什么样、中间卡在哪」这三句话里。写出这三句一行工具清单就变成了一段能撑住追问的经历。