哈佛上个月那份研究挺扎心700多家公司、70万开发者AI编码代理上线后代码量涨了30%但交付的功能数几乎没变。多出来的代码全堵在更长的审查流程里。大厂能扛这种30%的冗余——人多、流程厚、容错高。但我带的是一个不大的研发团队清一色资深研发能力挺突出我作为技术负责人。在团队全员用AI编程已经满一年了本以为一支「能打」的队伍配上AI会大幅提效结果满一年回头算账体感不是「提效」是「账算不平了」——钱、审查时间、调试时间、维护债全都肉眼可见地涨真正上线的功能却没跟上。作为技术负责人的身份把这用AI一整年真实踩的坑捋了一遍。AI编码的「能效失控」不是某一个点的问题而是一连串真实痛点叠出来的。下面逐个拆每个都附我给团队定下的落地规则。能效 产出 ÷ 投入。代码量是「投入」的假象交付才是「产出」。这篇复盘所有结论都围绕这一条。痛点一Token账单在悄悄失控最容易被忽略的成本。一个看起来不大的需求Agent在目录里来回读文件、自我修正、跑了三十几轮不知不觉烧掉几美元而同一个需求一个熟手两小时就能写完。机制很明确上下文窗口一膨胀每次补全AI都要把大文件重读一遍成本随对话轮次线性甚至指数往上走更糟的是agentic loop往往没有退出条件——它「觉得自己还没改对」就一直转。团队里大家各自开订阅满一年我拉过几次账单AI花的钱已经是一笔不小的固定开支占掉我们本可以投在工具链和人力上的预算。作为技术负责人这种「没人实时盯着值不值」的状态我必须止住。我给团队定的规则每个任务设token上限超了就停检索 / 分类 / triage 用便宜模型贵模型只留给关键实现。CLAUDE.md里写死单次任务循环不超过15轮重复同一错误立即转人工。我每周看一次总账单按任务类型归类——某类需求consistently烧钱就说明该拆小或换做法。痛点二审查反噬老手也成了瓶颈哈佛那个「30%代码、0%功能」的结论根因就是审查工位被堆爆了。以前一天审10个PR现在AI一天吐 20 个人审不过来。我们团队这个瓶颈很反直觉人人都是资深本来能写能审按理说审查不该是问题。但 AI让每个人的产出都翻倍PR队列从「当天清」变成「排一周」要么我硬着头皮降质量合入要么整个交付堵死。这事儿最后一定压到我这儿。更阴的是AI代码的「看起来对」——结构工整、命名规范、注释齐全但你不能因为好看就合。我们这群老手反而更费眼AI出错的位置从来不在我们预期的地方而资深工程师最容易被「它写得很规范」骗过去扫一眼就合。人写的代码虽然糙但我知道哪该重点看AI的代码得逐行确认它真理解了需求、边界处理对了、没埋hidden bug。我给团队定的规则小步提交需求拆成 ≤ 半天能完成的小任务AI实现我只审diff和接口契约不审「它怎么写出来的」。PR模板强制「本PR改了哪些接口 / 依赖」我先验这部分——架构和公共契约必须由人拍板AI不许擅自引入新依赖、新表。审查左移让AI自己跑lint / 类型检查 / 测试并在PR描述写清「我改了什么、为什么、风险点」。我只审三件事意图对不对、接口稳不稳、有没有越界。痛点三膨胀的代码 膨胀的维护债AI有个天性倾向于「写更多」而不是「写更少」。能50行搞定的它可能给你 100行因为这样「看起来更全面」。GitHub上火的caveman类Skill就是反着来的——强制极简、无填充Token省65%、速度快3倍作者说简洁约束下准确率反而更高。大厂多写的代码有人重构、有架构师收口我们团队虽强但没有专职重构 / 架构岗AI写的「胖」代码维护债照样摊到每个人头上新功能改不动因为那段逻辑没人完全懂大家都不想碰AI的生成物更多代码还意味着更大的bug 面、更大的攻击面、更长的构建和测试时间。作为负责人这笔债最后都是我来兜底收拾哪怕团队人人资深也没人自愿去清理别人或AI留下的代码。我给团队定的规则Prompt纪律写死「只实现被要求的功能不写额外代码 / 注释 / 抽象复用现有工具不引入新依赖。」让AI先写测试再写实现或至少给最小验证路径——测试是逼它聚焦、防止过度生成的最实用手段。「禁止投机功能」写进项目规则文件新会话第一天就加载不靠每次口头提醒。痛点四调试黑洞——不是你写的老手也调不动这是最反直觉、却最少被讨论的一点。我们都是资深研发本该什么坑都见过。但AI生成的代码一旦出bug谁都不是作者得先「读」一遍AI的思路才能定位问题。资深不代表能秒懂AI的黑盒逻辑——反而因为我们习惯自己掌控每一处细节被一段AI代码卡住时更难受AI用了个冷门库或过期API本地能跑一上生产就报错排查全靠搜。更糟的是AI写错方向时老手也难判断该修还是该重写因为对它的「设计意图」没有肌肉记忆。满一年我最大的感慨是AI没有降低我们的调试成本只是把「写」的成本转移成了「读和猜」的成本。我给团队定的规则关键模块坚持「人写骨架、AI 填肉」接口、数据模型、错误处理的契约由人来定AI只补实现。出了事人至少知道骨架在哪。每个AI生成的PR要求附「关键决策说明」为什么选这个方案、踩了哪些坑。把隐性知识逼到台面上而不是锁在它的上下文里。建团队内部的「AI踩坑本」把反复出现的坑某库版本、某API用法固化成规则下次直接规避。痛点五虚假进度和我对老板没法交待最容易骗自己的地方。AI上来之后commit数、LOC、PR数全涨了周会很好看。但真相是需求到上线的周期cycle time没短线上缺陷率可能还升了。我是那个要跟老板交帐的人。如果只拿LOC和PR数说事老板会觉得「AI真香再加预算」可真实的交付节奏没变快能效还在往下掉。直到某次生产事故把账一次性算清那才是真亏。我给团队和老板定的规则不看LOC。盯三个真指标每功能成本$/story 或 token/PR、cycle time、线上缺陷率。一张极简看板我每周看一次。一条铁律用了AI一个月$/story 没降、cycle time没短就是失控信号。这情况下就要先停手复盘不盲目加量。为什么一支能打的团队照样被能效失控放倒把这五个痛点放一起你会发现它们跟「团队强不强」几乎无关而是被三件事放大在小团队里格外尖锐容错低一个大生产事故就能拖垮我们而AI引入的隐性缺陷最危险——它不报错只是悄悄错。资深不代表不犯错只是犯得贵。治理缺没有统一工具、规范、计量。讽刺的是人人资深意味着每人都有自己的习惯和prompt反而更难统一标准、沉淀最佳实践。这件事只能我来推。人力薄没有专职 QA / 架构 / SRE 兜底所有成本最终压在「我 几个骨干」身上。我们虽强但强在「各自能打」不擅长「替AI兜底」——这件事谁都不想接。大厂能用流程和人力把AI的副作用兜住我们兜不住所以作为技术负责人我更得在「用之前」就把边界想清楚。能效 产出 ÷ 投入不是代码量复盘完这五个痛点结论很朴素AI不是银弹也不是骗局。它是放大器——团队交付链路健康它加速链路有洞它把洞放大成坑。我们这支清一色资深的团队用AI满一年最深的体会是能效失控跟团队强不强无关只跟「有没有看清链路」有关。我们小团队最该做的不是「多用AI」而是先把自己的交付链路看清钱花在哪、时间卡在哪、债积在哪再决定AI放在哪一环、怎么收费、怎么兜底。具体规则上面每个痛点都给了。汇总成一句话也是我给团队立的规矩先把「能效」变成可盯的数字再给AI设预算和边界人盯架构与接口、AI盯实现约束它写瘦代码把审查左移到自动化。做到这五条AI才可能从「越写越亏」变回「真的提效」。相关阅读用 AI 编程一年提效只发生在治理搭对之后——AI 提效的前提是治理不是工具本身本文「治理缺」痛点的延伸RAG 分块策略实测01换分块策略并不能提升 20 个点我用 100 道题说话——瓶颈会自己移动这个规律在 AI 编码里一样成立AI 员工时代真的来了paperclip / hindsight / dots 三家横向扫一眼——多 Agent 协作工具现状能不能把审查也自动化