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