ARTICLE · 1091782
AI 工具越来越会干活,为什么我反而越来越累?
AI 工具越来越会干活,为什么我反而越来越累?有时候我关掉 AI 工具，比打开它之前还累。 屏幕上已经有结果了：Controller 写了，Service 写了，单元测试也补了几条。运行一下，接口确实能返回数据。 照理说，该高兴。 可我顺着改动往下看，脑子里开始冒问题：这个校验为什么放在 Controller？项目里不是有统一的异常处理吗？金额字段为什么又用 double？它新写的查询，数据一多会不会把库拖慢？ 一开始我以为这是模型还不够强。后来换了更强的模型，功能生成得更快了，我却没有明显轻松下来。 AI 帮我把“写出来”提前了，但“敢不敢交出去”还是得由我判断。 这也是我最近越来越想弄明白的事：AI 工具明明更会干活了，为什么我们反而觉得更累？ 拿一个假设的 Java 开发任务说明。 需求是给订单后台加一个批量退款接口。 如果让我从头写，我会先看已有的退款入口：谁有权限，金额如何计算，重复请求怎么处理，失败后有没有补偿，日志要记到什么程度。 让 AI 来做，第一版可能很快就齐了：接收订单 ID 列表，循环查询，调用退款服务，返回成功和失败数量。 看上去像完成了。 但代码越完整，我越不敢只看它“跑起来没有”。 批量退款一半成功、一半失败怎么办？客户端超时重试，会不会重复退？查询订单后、真正退款前，订单状态变了怎么办？测试里写了一个成功用例，能证明这些场景安全吗？ 我得去读现有实现、对业务规则、补边界测试、看 SQL、查异常路径。生成速度快到我刚看完第一个文件，AI 已经递来第二个文件。 以前写代码时，我一边写一边决定怎么处理这些问题。现在它先把答案摆出来，我要逆着代码找出它做过哪些决定。 有点像别人一口气替你答完一张卷子。你省了写字的时间，却得逐题核对，还要找出那些看上去特别像正确答案的错误。 生成越便宜，审查越不能按“看一眼”来算。 
后来我发现，我们和 AI 说的“完成”，经常不是一回事。 AI 容易展示的完成，是文件生成了、功能跑通了、页面能点了。 工程师要负责的完成，还包括：接进现有结构，符合业务约束，出了问题能追踪，下个月有人敢改。 比如同一个批量退款接口，AI 可以另起一套 DTO、转换器、错误码和日志格式。每一项单看都说得过去，放进项目就多了一条平行的路。 这类问题通常不会在演示时爆炸。它会在下一次需求变更时收账：原来的退款流程改了，新接口却没跟着改；线上出现异常，日志字段还跟其他接口对不上。 所以我觉得累，不只是因为要抓 bug。 还因为我得替一段陌生的实现补上它与整个项目的关系。 AI 交付的是一个结果；我负责的是这个结果进入系统以后的后果。 这不是说 AI 没有价值。把重复代码、初稿和探索任务交给它，确实能省时间。问题出在我们把产出速度，当成了交付速度。 做运营的朋友可能很熟悉另一种场景。 假设 AI 很快写出十版活动文案，每版都通顺，还顺手做了标题、海报字和推送语。运营省去了从空白页起稿的时间，却要逐条检查价格、优惠门槛、适用人群和承诺措辞。 十版文案不是一份工作做完了，有时是十份待审稿一起到了桌上。 做设计也是。 AI 一次给出二十张原型，页面很完整。设计师却需要判断：哪个信息该先出现？用户完成任务需要几步？这张“高级感”页面，为什么跟竞品换个 logo 就能通用？ 二十张图可以降低画图成本，也会增加比较和解释的成本。 财务场景更明显。AI 从票据里提取字段，汇总成表格很快。但报销类别、重复票据、金额异常和审批责任仍要人确认。自动提取一百张票据，如果其中几张错得很隐蔽，省下的录入时间可能又花在复核上。 这些不是三种互不相关的焦虑。 它们有同一个结构： AI 把产出变多、变快；人的注意力和责任，没有同步扩容。 
假设一个接口以前排两天，现在 AI 帮忙半天就有初稿。 如果团队把省出的时间留给测试、代码审查和文档，工作确实可能更轻松，质量也可能更好。 但现实里更容易发生的是：既然半天就有初稿，那这周能不能再做两个接口？原型也顺手出一下？客户突然改需求，反正改得快，再来一版？ 产出能力提高后，待办清单也跟着膨胀。 更麻烦的是，别人看见的是“AI 已经生成了”，看不见后面那些确认、返工和承担风险的时间。 于是进度预期被初稿速度拉快，交付标准却没有降低。 对我来说，这时的疲惫不全是工具造成的，还和团队怎样安排工作有关。 AI 省下多少时间，与人最终少工作多少时间，是两道不同的题。 我仍然在用 AI 写 Java 代码，也不想回到每个 DTO 都自己敲的日子。 只是我开始把任务分开看。 对于已有模式清楚、影响范围小的活，比如补一个字段映射、整理重复测试数据，我可以让它直接做，然后快速核对。 碰到退款、权限、库存、账务这类有业务后果的改动，我更愿意让它先找项目里的参考实现，列出要沿用的校验、事务、幂等和异常处理，再做一条最小流程。 这不是“给 AI 写更长的提示词”。关键是把检查点放到它动手之前。 例如我会先问它： 答不上来，就先别生成一堆文件。 等方向确认，再让它编码。完成后，我看的不只是测试有没有变绿，还会看改动范围、与原有实现的差异，以及哪些结论它没有验证。 其他岗位也可以用相同办法。 运营先给活动规则和禁用措辞，让 AI 只出两版真正不同的方向，再查事实；设计先说明用户、场景和核心任务，再出原型；财务先定哪些字段可自动提取、哪些异常必须人工复核。 让 AI 多做一步之前，先决定人要检查哪一步。 
下一次看到 AI 又把一个接口“做完”，我大概还是会高兴。 但我不会再用生成了多少文件，判断今天省了多少力气。 真正让我轻松的，是它找对了现有实现，解释清楚了取舍，帮我覆盖了容易漏掉的失败场景；我读完改动，知道它为什么这样写，也知道出了问题该从哪里查。 那时，AI 才是在分担工作，而不只是往我的审查队列里塞进更多成品。 我想要的下班画面也很普通：关电脑之前，不用对着一大堆“已完成”的文件，重新把每个决定猜一遍。
你现在用 AI 最耗时间的部分，是让它做出来，还是确认它做对了？
01 一小时交活，剩下的半天是谁在干
02 它“完成了”，只是完成了一种定义
03 别的岗位，也在付同一笔“检查费”
04 还有一种累：省出的时间，很快被新任务填满
05 我现在会先决定：哪些活值得让它一口气做完
这个仓库里最接近的接口在哪？哪些规则可以沿用？这次改动的失败路径是什么？你准备怎样验证重复请求？