半年过去了，我们团队到底提效了多少 2024 年 10 月我们组 11 个人开始全面用 AI 编码助手，到今年三月底正好半年。这半年里我在各种场合听到的说法从"提效 50%"到"就是个高级补全"都有，差距大到不像在说同一个东西。所以我们拉了数据自己看了一遍，顺便把踩过的坑和定下的规矩记下来。 数据是
早上九点收到的一条额度告警 2025 年 2 月底的一个周一，我刚进公司就收到运维的消息："模型供应商账户额度用了 78%，平时这个时候只有 15%。" 紧接着业务群炸了，客服系统开始大面积报 429 Too Many Requests。 查了半小时，根因很朴素：上周五上线的智能质检功能有个循环调用
实习生问我：为什么文档喂得越多，答案越差 七月份团队来了个实习生，负责维护我们的文档问答系统。他有天跑来问我一个问题：「我把 topK 从 5 调到 20，召回率肯定上去了吧？但测试集准确率从 71% 掉到 63%，是不是哪儿写错了？」 我看了下代码，没写错。这不是 bug，这是我们一直没认真对待的
组里的实习生问我"Java 是不是没前途了" 2025 年春节后回来的第一周，组里新来的实习生私下问我："现在 AI 不都是 Python 写的吗，我学 Java 是不是选错方向了？" 这话我没法用一句"不会"糊弄过去，因为他说的是事实的一部分——过去两年所有模型层的创新确实都在 Python 生态
供应商挂了，我们的降级逻辑一行没生效 六月下旬的一个晚上，模型供应商华东区域故障，持续 23 分钟。我们有完整的降级设计（规则引擎兜底、熔断、重试），理论上最多影响一部分请求的响应时间。实际结果是：全线报错，客服系统完全不可用。 事后复盘，原因特别打脸：降级逻辑的入口写在了 catch (Model
财务拿着一张 14.7 万的账单来找我 六月初，财务同事拿着模型账单发消息给我："你们那个智能运维 Agent，上个月花了 14.7 万？预算不是 5 万吗？" 我一看确实超了快三倍，而且这个 Agent 上线才一个月，日均任务量只有 420 个左右。 我花了两天把账单拆开分析，发现问题比想象的有意
三个团队写了三套几乎一样的东西 今年三月做季度复盘时，我们数了一下公司的 AI 建设：客服知识库、智能质检、合同审核，三个项目分属三个团队，各自实现了一遍模型调用封装、限流、审计日志、向量库接入、prompt 管理。代码重复度我粗略估了一下有 40% 以上。 更现实的问题是：三个项目都踩了同样的坑（
我们用传统架构设计 AI 应用，处处别扭 过去一年半我做了三个 AI 项目：客服知识库、智能质检、合同审核助手。回头看，第一个项目（2023 年底的知识库）踩的坑最多，原因不是技术不熟，而是我在用设计传统后端系统的方式设计它。 具体表现是：设计了标准的三层架构（Controller / Servic
3200 行的 OrderService，AI 说拆成六个类 四月初我接手了一个历史模块的重构。OrderServiceImpl 单个文件 3218 行，包含下单、支付回调、退款、履约、对账、通知六种职责，方法之间互相调用，改一个地方要心惊胆战地检查半小时。这活儿我拖了两周没敢动。 后来试着把整个文
风控要在 200ms 内给出决策，而模型要 150ms 我们电商风控原来是一套 Drools 规则引擎，几百条规则，命中就拦截。去年底开始加模型：用用户最近 5 分钟的行为序列算实时特征，喂给一个轻量模型打分，超过阈值就拦截。 难在时间预算。风控决策必须在用户下单后 200ms 内返回，而模型推理本
