这个月面了 12 个人，一个 offer 都没发 7 月我们团队要扩两个人，我前后面了 12 个候选。八年以上经验、带过项目、简历上都写着"熟悉大模型应用开发"。 结果不太好看。问"RAG 怎么做的"，八个人能完整背出切分、向量化、召回、重排这条链路；再问"你怎么验证召回效果变好了"，六个人答不上来
入行第八年，我把这八年做过的选型列了张表 2026 年 3 月，我入行整八年。过年期间我把这些年参与过的重大技术选型整理了一遍，一共 34 项，标上当时的决策理由、实际结果、以及现在的回头看评价。 结果有点难堪：34 项里，现在看是正确决策的 19 项，过早的 6 项，过晚的 5 项，纯错的 4 项
入行第八年，回头看自己踩过的坑 十月底做年度复盘，翻出了 2018 年到现在的 git 提交记录和几份老的设计文档。有些代码现在看会脸红，但正是那些代码让我走到了现在。这篇不写技术，写成长路径上几个真实的转折点和代价。 前两年：我以为技术就是知道更多 API 2018 年刚入行，在一家做仓储系统的公
三个团队写了三套几乎一样的东西 今年三月做季度复盘时，我们数了一下公司的 AI 建设：客服知识库、智能质检、合同审核，三个项目分属三个团队，各自实现了一遍模型调用封装、限流、审计日志、向量库接入、prompt 管理。代码重复度我粗略估了一下有 40% 以上。 更现实的问题是：三个项目都踩了同样的坑（
我们用传统架构设计 AI 应用，处处别扭 过去一年半我做了三个 AI 项目：客服知识库、智能质检、合同审核助手。回头看，第一个项目（2023 年底的知识库）踩的坑最多，原因不是技术不熟，而是我在用设计传统后端系统的方式设计它。 具体表现是：设计了标准的三层架构（Controller / Servic
大促前一晚压测，一个重要下游依赖突然超时，我们的服务跟着雪崩，错误率冲到 40%。复盘时发现：我们根本没有像样的降级，依赖挂了就硬等、硬等就堆积、堆积就拖死。这次事故后，我把降级与兜底当成架构的一等公民来设计。 降级层次：从浅到深 降级不是"有/无"两个状态，而是分层的连续体。我按影响面从轻到重设计
团队想给客服系统加 AI 能力，产品经理一句"接个大模型"听起来轻巧。真要做时，我发现最大的问题不是模型效果，而是：AI 该放在系统哪一层？和现有业务怎么融？出错了怎么办？这层边界不清，迟早把核心交易拖下水。 边界划分：AI 是增强，不是核心 我的第一原则是：AI 能力必须处在非关键路径。下单、扣款
去年底老板拍板：核心交易系统去 Oracle。理由很直接——一年 380 万的授权费，加上审计合规越来越严。我接手时第一反应是：这活儿坑比想象多，不是导出 SQL 再导入就完事。 先盘家底 系统跑了九年，Oracle 里不止 SQL。我用了两周做依赖盘点，列了一张表： 依赖类型 数量 风险 存储过程
一次全量上线引发的事故 三个月前我们直接全量发了订单服务 v2，结果一个新分支的序列化逻辑和旧版不兼容，老客户端解不出字段，半小时 rollback 了，期间丢了几十笔订单的回调。复盘会上被喷得不轻。痛定思痛，我搭了一套灰度发布体系，核心四件事：流量染色、网关路由、数据兼容、回滚机制。这套跑顺之后，
背景：大促前的压测暴露了长尾 八月底大促压测，核心的下单查询接口平均 RT 只有 120ms，看着挺好，但 P99 飙到 800ms，监控里偶发还有 1.5 秒的尖刺。平均好看掩盖了长尾，而用户体验恰恰被那 1% 的慢请求毁掉。我接了这活，目标是把 P99 压到 150ms 以内。 全链路耗时分析：
