有一天我做了个小实验：从早上到下班，整个需求全程开着 AI 助手，能问它的都问它，能让它写的都让它写。我原本的预期是“今天应该会很轻松”。
结果下班的时候，我累得比平时还厉害。不是手累，是脑子那种被掏空的累。回头看产出，确实比平时多一点，但远没有到“轻松翻倍”的程度。那天晚上我想了挺久：问题到底出在哪？
后来我又观察了自己几周，慢慢摸清楚了一些规律。这篇不讲什么高深技巧，就讲讲这种“沟通疲劳”是怎么来的，以及我试过的、确实有点用的几个办法。
累，到底累在哪
我把那天的感受拆了一下，大概有五个来源。
一是持续评审。 自己写代码时，脑子里是“我要怎么写”；跟 AI 结对时，脑子里一直是“它写得对不对”。读别人的代码本来就比写更费劲，何况它一次能吐出一大段，每一段我都得认真看。一整天下来，相当于我在给一个手特别快的同事做了几十次 Code Review。
二是碎片化的等待。 它生成的那十几秒、几十秒，看起来不长，但刚好够我切出去瞄一眼聊天软件，或者刷一下网页。等我切回来，刚才在想的东西已经断了一半。一天里这种小断点有几十上百个，注意力被切得稀碎。
三是反复解释。 上午我跟它说过“这个项目统一用构造器注入”，到下午它又写出了字段注入；我说过“异常要用我们自己的业务异常类”，它隔一会儿又抛了个运行时异常。每次都要重新提醒一遍，那种感觉就像跟一个总是忘事的同事合作，次数多了，火气也上来了。
四是决策疲劳。 我问一个问题，它经常给我三个方案，各有优缺点，让我选。单看每一次都很贴心，但一天下来要做几十个这样的小决定，到后面我已经懒得认真比较了，随手就选第一个——这恰恰是最危险的时候。
五是“不敢信”的紧绷感。 我知道它会出错，但不知道它什么时候出错。于是我一直处于一种轻度戒备的状态，看什么都要多想一下。这种戒备感本身就很耗能量。
图：和 AI 结对时疲劳的五个来源、典型信号与应对（原创示意图）
我的第一个调整：从“乒乓”改成“批量”
回头看那天的对话记录，我发现自己大部分时候在跟它打乒乓球：问一句，它答一句；我改一个要求，它改一版；再问，再改。每一个来回都很短，但来回的次数多得吓人，每一次都要我读、判断、再输入。
后来我尝试换成“批量”的方式：先花几分钟把需求想清楚，一次性写给它，包括要做什么、不做什么、验收标准是什么、需要遵守哪些约定。然后让它一口气做完一大块，我再集中看一次。
这么做最明显的变化是：我的注意力能连续起来了。原来是“看一眼—等—看一眼—等”，现在是“认真想十分钟—去干别的—认真看二十分钟”。总耗时不一定更短，但累的程度明显下降。
当然，批量也有代价：它可能一开始就理解偏了，然后在错误的方向上写了一大段，我最后发现只能整段推倒重来。我的应对是在需求里设一个检查点，比如“先只给我接口定义和测试用例的标题，我确认后你再写实现”。这样跑偏的成本被控制在一个小范围内。
图：乒乓式与批量式交互在同一段时间里的注意力对比（原创示意图）
举个例子，以前我会这么开头：“帮我写个导出接口。”然后它写完，我说“要分页”，它改；我说“字段要脱敏”，它再改；我说“用我们自己的响应包装类”，它又改。四个来回，每次都要重新读一遍整段代码。
现在我会先写成一段话：“写一个订单导出接口，按创建时间范围筛选，必须分页；手机号字段脱敏；返回值用项目里统一的响应包装类；先不用写 Excel 生成部分，留一个接口就行；写完附上你觉得最可能出问题的两个地方。”写这段话大概要我两三分钟，但后面省掉的来回，远不止两三分钟。最后那句“附上最可能出问题的地方”也很有用，它会帮我把评审的注意力集中到真正该看的地方。
第二个调整：把约定写成一张“小卡片”
针对“反复解释”这件事，我现在的做法是准备一张简短的约定卡片，每次开新对话就贴在最前面。内容不多，大概就是：
注入方式、异常类、日志写法这些项目约定；
这次任务的范围，哪些文件不要动；
输出格式，比如“只给 diff，不要解释”“不确定的地方请标出来”。
很多工具也支持在项目里放一个规则文件，让它每次自动读取，原理是一样的。这件事看起来很小，但它把“我要记得提醒它”这个负担，从我的脑子里挪到了一个文件里。人脑子里少装一件事，就少一分累。
另外，我会主动要求它少给选项。比如加一句“如果有多种方案，直接推荐一种并说明理由，除非差异很大”。这样我只需要判断“它推荐的这个行不行”，而不是在三个方案里比来比去。
第三个调整：给自己留“关掉它”的时间
这一点是我花了最长时间才接受的：不是所有时间都该开着 AI。
我现在会根据任务类型大致分一下：
机械活，比如写样板代码、改格式、补字段、写简单的转换逻辑，基本全交给它，我只做最后的检查；
探索活，比如调研一个陌生的库、排查一个奇怪的问题，我会让它陪着，但主导权在我；
关键设计，比如数据模型怎么定、模块边界怎么划，我会先关掉它，自己拿张纸想清楚，想完了再拿着方案去问它“这个设计有什么漏洞”。
为什么要关掉？因为在想设计的时候，AI 给的答案会过早地“锚定”我的思路。它给了一个看起来还不错的方案，我很容易就顺着它的框架去修修补补，而不是从问题本身出发。自己先想一遍，再让它来挑刺，这个顺序对我来说很重要。
一些不太好意思说的真实想法
我发现这种疲劳里，有一部分其实来自心理压力：“都有 AI 了，我是不是应该更快？”
当你觉得自己“应该”很快，但实际上并没有快那么多的时候，就会开始焦虑，然后用更高频的提问去“压榨”它，结果更累。我现在会提醒自己：AI 带来的提效，在不同任务上差别非常大，在有些任务上它甚至会让我变慢。承认这一点，反而让我心态放松了很多。
如果你带团队，我个人的看法是：别因为“大家都在用 AI 了”就直接把排期压缩一截。至少先让大家用一段时间，看看在你们的具体项目里，到底哪些活快了、哪些活没快。这是我个人的观点，每个团队情况不一样。
最后
那次实验之后，我依然每天都在用 AI 写代码，而且用得比以前更多。但我不再追求“全程开着它”，而是更在意怎么跟它协作才不累。
我的体会是：累的不是手，是注意力。 让 AI 帮你省下手上的功夫很容易，但如果协作方式不对，它会把省下来的精力，加倍地从你的注意力里拿回去。少打乒乓、多写约定、该关就关——这几件小事做下来，我下班时终于不再是那种被掏空的感觉了。
2026-10-14鱼鱼