把 AI 塞进研发流程半年，哪些卡点活下来了 四月份我们开始在研发流程里加 AI 卡点，到这个月正好半年。团队 14 人，一共试过九个卡点，活下来五个。先说总体结论：AI 卡点的价值不在「生成了多少内容」，而在「拦截了多少问题」——纯生成类的（写文档、写注释）普遍活不下来。 我们试过的九个卡点 卡点
供应商挂了，我们的降级逻辑一行没生效 六月下旬的一个晚上，模型供应商华东区域故障，持续 23 分钟。我们有完整的降级设计（规则引擎兜底、熔断、重试），理论上最多影响一部分请求的响应时间。实际结果是：全线报错，客服系统完全不可用。 事后复盘，原因特别打脸：降级逻辑的入口写在了 catch (Model
3200 行的 OrderService，AI 说拆成六个类 四月初我接手了一个历史模块的重构。OrderServiceImpl 单个文件 3218 行，包含下单、支付回调、退款、履约、对账、通知六种职责，方法之间互相调用，改一个地方要心惊胆战地检查半小时。这活儿我拖了两周没敢动。 后来试着把整个文
安全部甩来 213 个漏洞，限期两周整改 11 月初，安全部门用他们的商用扫描器对我们的 14 个 Java 服务扫了一遍，发来一份 Excel：213 个"高危及以上"漏洞，要求两周内清零。 我们团队三个人，14 个服务，平均每人每周要处理 35 个漏洞。第一反应是不可能完成。但真正让我头疼的不是
三个人都点了 Approve，上线还是出了事故 9 月底的一次线上故障，起因是个不到 200 行的 PR：修改优惠券核销逻辑。三个人 review 过，两个 LGTM 加一个 Approved，上线两小时后，监控发现优惠券超发了 1.7 万张。 复盘时我把三个人的评论翻出来看，发现一个规律： 评审人
我们团队原来的 CI 是 Jenkins，一台老服务器，Job 用网页点出来的，配置存在它肚子里，谁也说不清有哪些步骤。新人想加一条发布流水线，得先找老员工"口述"。这种不可见的配置，迟早要还债。借着一次 GitLab 迁移，我把流水线整体搬到了 GitLab CI。 不是嫌 Jenkins 不好
三套系统各看各的 故障复盘最头疼的是：告警在 Prometheus 里，调用链在 SkyWalking，日志在 ELK，三套 ID 对不上，定位一个问题要在三个系统间反复横跳。有次一个下单超时，我在 SkyWalking 看到 span 慢，却没法直接拿到那次请求的日志，只能靠时间戳去 ELK 捞，
背景：团队新人又慌了 七月一次支付成功率骤降，新来的同学第一反应是「我先重启试试」。结果重启把现场冲了，后面复盘只能靠猜。这种事不是第一次，我干脆把我们的线上排查 SOP 固化成文档，要求所有人遇事先照流程走，别凭直觉乱动。 第一原则：止血优先 出问题第一时间想的不是「为什么」，是「怎么不让它继续坏
背景：一次排查花了三个小时 六月一次线上下单失败，从接到告警到定位根因花了三个小时。不是问题复杂，是信息散——日志在 ELK、指标在 Prometheus、链路在 SkyWalking，三套系统各看各的，人肉拼不出完整画面。那周我推动了可观测性体系重构，把三大支柱真正串起来。 三大支柱：日志、指标、
背景：一次全量构建喝了杯咖啡还没好 六月我们一个核心服务模块膨胀到 180 个 Maven 模块，mvn install 一次 6 分半。CI 排队严重，开发等得烦躁。我提议评估迁移 Gradle，但团队一半人不乐意——XML 写惯了，怕 DSL 学习成本。于是我做了个对照实验，用同一份源码分别用
