摘要AI 接手写代码后纯编码时间变短但总工时没少。本文把开发者时间拆成五块——讲需求、审代码、修 bug、做集成、管上下文并给四个可落地的杠杆讲清时间到底搬去了哪、怎么砍。现象写快了人没闲下来你让 AI 写个接口十秒吐出三百行。你没省下时间反而花了一下午读这三百行、改字段名、补空值判断、再把它接进现有事务。写的那一下变快了后面全变贵了。这不是个例。Lightrun 今年一项针对 SRE 与 DevOps 负责人的调查显示43% 的 AI 改动上线后仍要人工 debug88% 需要两到三次重部署才确认。同一份报告还有一个更扎心的数开发者平均要把一周 38% 的时间耗在 debug、验证和排障上——AI 没省掉这部分活只是换了形式。AI 省下的写很大一部分转移到了反复看它写对了没。本质时间从写搬到了判行业里常被引用的经验值是纯编码约占研发总工时的两到三成。AI 把这一成多再砍掉大半腾出来的时间没有消失而是流进了五块——它们共同的特点是都不在编辑器里都在判断里。一个反直觉的点AI 让你变慢的环节恰恰是你以前最擅长的。因为注意力现在花在它写的对不对上而这部分以前花在我自己怎么写上。你从生产者变成了验收者。实际落地五块时间分别花在哪第一桶把需求讲清楚时间花在让 AI 听懂你要什么。一句话需求换来三版不对味的代码返工成本比自己写还高。讲不清的根源是需求在你脑子里是语境在 AI 眼里只是字符。解法是需求前置先把规格写清楚规格驱动让 AI 照着判而不是边写边猜。一个 Java 后端的典型坑需求只说做个导出AI 生成两百行字段名按自己猜的来和你现有的 DTO 对不上。先把输入输出结构定死AI 才不会自由发挥。判断需求讲清了没有有个简单标准AI 第一次返回的东西你是不是能不改结构地直接用。如果还要大改字段和边界说明需求没讲清时间迟早要还。第二桶审 AI 写的代码这是新增最大的一块。前面那组 Lightrun 数字已经说明问题43% 上线后仍要人工 debug。审比写慢因为 AI 一次吐一大片你还得反推它的意图。可行的做法是让它小步提交、每步带自测你只 diff 关键路径把读全文变成读改动。还可以让 AI 自己先过一遍——生成时附带它认为的边界和假设你审的是它的假设而非它的代码这能把审的时间再压一层。第三桶修 AI 引入的 bugAI 写代码飞快但引入的缺陷往往更隐蔽。Chroma 的 Context Rot 研究指出65% 的企业级 AI 失败根因是上下文漂移或记忆丢失不是模型不会写。隐蔽缺陷最坑空值分支里的 NPE、并发下的竞态、被忽略的边界。它们不报错只在某些数据下炸。状态门禁能在执行时拦下更新命中零行这类假成功// 状态门禁更新必须真的命中行否则当失败处理introwsorderMapper.markCharged(orderId);if(rows0){// AI 说已处理但库里没动thrownewIllegalStateException(状态未变更疑似假成功);}更省心的做法是把修变成不让它写错关键路径用确定性脚手架AI 只填被约束好的空隐蔽缺陷从源头就少。第四桶集成与 Code Review代码能跑不算完。多工具、多 Agent 接进来CR 的重点从语法对不对变成上下文有没有串、边界有没有漏。具体痛点是接口契约对不齐AI 生成的调用方和提供方字段不一致要人肉对齐事务补偿。这块时间随系统复杂度线性上涨AI 暂时帮不上但它值得投——它是系统可靠性的真正护城河。CR 时多问一句这个改动会影响哪个上游调用方比多写十行测试更值钱。第五桶管上下文等 Agent上下文越长 AI 越容易忘事。异步 Agent 跑一个改动能耗掉大半天。METR 另一个数据Agent 能稳定完成的任务时长大约每七个月翻一倍。你在等它跑完的时间里也在持续投注意力。上下文预算要主动分系统提示占一成多工具 schema 占一两成其余留给检索代码地图。等长任务时设 checkpoint在关键节点回看别真离线。把长任务切成可验收的小段每段结束你只花一分钟确认方向比最后整体返工便宜得多。四个杠杆怎么砍这张账单杠杆一需求前置用规格驱动把输入输出定死AI 照判不自由发挥直接砍掉第一桶的返工。杠杆二门禁前置编译、契约、状态、链路四道门接进流水线审和修的时间被挡在执行时而不是上线后。杠杆三测试门禁用变异测试逼出真断言AI 写的测试才不会自己骗自己砍掉第三桶的隐蔽缺陷。杠杆四判断外包高频、低延迟的结构化判断交给 Jev 或小模型重复人工直接砍掉。边界什么团队该这么做这套账本对小团队和中大型都管用但前提是你已经在用 AI 写相当一部分代码。如果团队还停留在偶尔问一句先别谈时间分配先把采纳率提上来。代价也要说清门禁、规格、变异测试都是前期投入。前两周你会觉得更慢因为你在搭栏杆。栏杆立起来之后返工和救火的时间才会真的掉下来。总结时间没少只是从写搬到了判。模型越强你判的层级越高——从判代码变成判架构、判需求、判它该不该动手。时间管理的本质是判断力的管理。作者唐悦玮 | 从后端出发用 AI 拓展到全栈的工程师。