一、我变快了，也更累了
我的 ChatGPT Plus 账号，以前一周都用不完额度，现在高强度工作三天就见底了。
听起来像是效率提高了。
但奇怪的是，我并没有变轻松，反而更累了。
我是一个从其他技术方向转行做 iOS 的开发者，也是一个 AI 重度使用者。
转行初期，很多东西对我来说都是陌生的。查一个 API 的用法要翻半天文档，调一个布局问题要反复试，遇到一个不熟悉的 crash 可能一个下午都在排查。那时候效率确实不高，但节奏是自己的——写一会儿代码，查一会儿资料，偶尔站起来倒杯水，脑子里慢慢把问题理清楚。
有了 AI 之后，变化很明显。
以前一天只能推进一两个小需求，现在可以完成更多。以前遇到不熟悉的语法要查很久，现在直接问 AI，几秒钟就有答案。以前改一个界面要自己一点点调参数，现在可以让 AI 先给一版，再在上面微调。甚至一些 UI 适配、文案润色、测试说明这类周边工作，AI 也能帮上忙。
这些都是真实的。我不会否认 AI 给我带来的帮助。
但以前的工作节奏是慢的，有喘息的空间。现在的工作节奏是快的，我发现自己几乎一整天都在和 AI 对话——提需求、看输出、纠偏、再提、再看、再改。代码产出变多了，人的喘息空间变少了。
这让我开始思考一个问题。
二、AI 提升的是生产力，还是生产幻觉？
社会上有一个几乎默认成立的说法：
AI 大幅提升了生产力。
我以前也这么觉得。毕竟我自己就是受益者，每天都在用，每天都在靠 AI 完成更多的工作。
但当我把自己的真实工作状态摊开来看，我产生了一个疑问：
AI 到底提升的是完整的生产力，还是只提升了其中一个环节的速度？
这里说的完整生产力，不只是代码生成，而是从需求提出、开发、验证、上线到产生结果的完整闭环。
代码确实生成得更快了。但项目上线的速度，真的同等幅度变快了吗？需求从提出到交付的整条链路，真的被 AI 压缩了吗？
我慢慢意识到，人类对于 AI 最大的幻觉，可能不是高估了 AI 的能力，而是把"生成速度"误认为了"完整生产力"。
三、AI 新增了一层沟通成本
后来我试着把整个工作流程拆开来看。
以前，一个需求的链路大概是这样的：
同事提出需求 → 我理解需求 → 我写代码 → 我自测 → 同事测试 → 修改反馈 → 打包发版。
链路不算短，但每一步都是我和同事之间的直接沟通，中间没有额外的转译层。
现在有了 AI，链路变成了这样：
同事提出需求 → 我理解需求 → 我把需求翻译成 Prompt（也就是给 AI 的任务描述）→ AI 给出方案 → 我理解 AI 的输出 → 我判断 AI 是否理解对了→ AI 写代码 → 我审查代码 → 我自测 → 同事测试 → 修改反馈 → 打包发版。
你会发现，AI 并没有直接站在同事和项目之间，自动把工作完成。它需要我充当一个翻译器。
我要把人的模糊需求，翻译成 AI 能理解的任务描述。然后再把 AI 的输出，翻译回真实项目中可执行、可验证、可交付的代码。这两步翻译，都不是免费的。
举个例子。同事说："这个页面的广告有问题。"这句话我没办法直接扔给 AI。我得先判断"广告有问题"到底指什么——是广告没有填充？展示时机不对？关闭按钮异常？广告位尺寸把页面挤变形了？还是测试机网络问题、SDK 初始化问题、广告平台后台配置问题、远程开关问题、缓存逻辑问题？
把问题拆清楚之后，我还要把相关代码、日志、页面路径、预期行为和实际表现整理成 AI 能理解的 Prompt。
AI 给出方案之后，事情也没有结束。我还要判断它是不是改了正确的位置，有没有影响其他广告位，有没有破坏原来的展示策略，有没有引入新的审核风险。
AI 并不是直接替我解决了"这个页面的广告有问题"，它只是参与了中间的一段分析和生成。真正把模糊反馈翻译成可执行任务、再把 AI 的输出验证成可交付结果，仍然需要人来完成。
以前我只需要和同事沟通。现在我要同时和同事沟通、和 AI 沟通，还要在两者之间来回翻译。
AI 没有减少沟通，它新增了一层沟通。
四、生成速度，不等于交付速度
链路拆清楚之后，我注意到一个更具体的问题：AI 提升的是生成速度，不是完整的交付速度。
一个项目完成，不等于代码生成出来。
一个需求从提出到真正上线，中间包含很多环节：需求理解、需求澄清、任务拆分、Prompt 编排、理解 AI 反馈、审查 AI 代码、自测、联调、同事验收、修改反馈、打包、发版，最后还要承担线上出问题的风险。
AI 主要加速的，是"生成代码"这一段。这一段确实快了很多，有时候快了几倍甚至十几倍。
但其他环节呢？需求理解不会因为有 AI 就自动变清楚。同事验收不会因为代码是 AI 写的就自动通过。联调不会因为生成速度快就不需要了。线上风险不会因为代码写得快就自动消失。
甚至有些环节反而变得更复杂了——因为 AI 生成的内容变多了，需要审查和验证的东西也变多了。
AI 把"写出来"变快了，但没有把"做对、测对、交付对"同等幅度变快。
五、生成变便宜了，正确没有变便宜
这就引出了一个我反复体会到的现象：AI 降低了生成成本，却提高了验证成本。
以前自己手写代码，虽然慢，但每一行为什么存在、每一个判断为什么这样写，心里是有数的。代码是从我的理解中长出来的，出了问题我知道去哪里找原因。
现在不一样了。AI 一次可能改好几个文件，生成一大段逻辑，有时候还会主动"优化"一些它觉得可以改进的地方。我必须反过来审查这些输出：
它有没有理解错需求？有没有改坏原来的逻辑？有没有绕开项目现有的架构？有没有引入一些隐藏的 Bug？有没有写出那种"能跑但不好维护"的代码？有没有造成发版风险？
这些问题，每一个都需要我花时间去确认。而且越是 AI 改动量大的时候，确认的成本就越高。
以前写代码是"从零构建"，虽然慢，但过程可控。现在用 AI 是"先拿到一大堆输出，再反向验证"，速度快了，但验证、筛选、审查、兜底变成了新的重劳动。
AI 让生成变便宜了，但没有让正确变便宜。
六、业界已经开始解决验证问题
如果只是我一个人的体感，这可能只是一种主观疲惫。但有意思的是，最近业界也开始用工程化的方式解决类似的问题。
今年，OpenAI 发布了一篇关于 Harness Engineering 的文章，重新定义了工程师在 AI 时代的角色：不只是手写代码，更重要的是设计环境、表达意图、建立反馈循环，让 Codex 这类 agent 能更可靠地工作。Martin Fowler 也讨论了类似的概念——通过提前设置约束和实时反馈纠偏的方式，把 coding agent 的行为约束在更可控的工程系统里。
Harness Engineering 的出现，本质上说明了一件事：AI 的生成能力已经很强了，真正的问题变成了如何约束、验证和交付。
一些走在前沿的团队，讨论重点已经不只是"AI 能不能写代码"，而是"怎么让 AI 写出的代码真正可用"。这本身就说明，从生成到交付之间的距离，远比大多数人想象的要长。
七、生成能力不是完整生产力
不管行业怎么定义这个问题，落到每天的工作里，核心矛盾还是同一个：
当我们说"AI 大幅提升了生产力"的时候，我们到底在说什么？
AI 写代码快，不代表项目上线快。AI 写文案快，不代表产品卖得好。AI 画图快，不代表设计决策快。AI 生成方案快，不代表商业验证快。AI 写 PRD 快，不代表需求真的清楚了。
生产力不是"生成了多少东西"。生产力是：有多少东西被正确验证、正确交付、真正使用，并产生了结果。
把生成能力等同于生产力，这可能是当下最普遍、也最不容易被察觉的一种幻觉。
八、人的工作没有消失，只是换了形态
AI 当然改变了工作。这种改变，和很多人想象的不太一样。
很多人以为 AI 会让工作减少。但我的真实感受是：工作没有减少，工作的形态变了。
以前，开发者的核心工作是亲手写代码。你理解需求，你想方案，你写实现，你调试，你交付。整个过程你是直接生产者。
现在，开发者的角色变了。你变成了需求和 AI 之间的翻译器，AI 结果的审核人，项目交付的兜底人。你不再是从零开始写每一行代码的人，你是拿到 AI 的输出之后，判断它对不对、能不能用、要不要改的人。
人的劳动没有消失，只是从手上转移到了脑子里。
以前累的是手指和眼睛——盯着屏幕写代码、调样式、查文档。现在累的是注意力和判断力——要不停地评估 AI 的输出，在脑子里维持整个项目的上下文，确保每一次 AI 的改动不会破坏已有的东西。
AI 没有消灭人的劳动，它只是把人的劳动从"直接生产"转移到了"判断、调度和验证"。
九、为什么我们容易相信这个幻觉
那为什么大家还是容易相信"AI 大幅提升了生产力"？
因为 AI 的提升是显性的。你让它写一段代码，几秒钟就出来了。你让它生成一篇文案，马上就有了。你让它画一张图，瞬间就能看到结果。这种速度感是非常直观的，任何人都能感受到。
但没有被 AI 消灭的那些成本，是隐性的：
沟通成本——你要把同事的需求翻译成 AI 能理解的任务描述；
理解成本——你要读懂 AI 生成的代码，确认它做的是你要的事；
验证成本——你要测试 AI 的输出，确保它不会在边界情况出错；
返工成本——AI 理解错了，你要重新描述、重新生成、重新审查；
测试成本——生成的代码越多，需要测试的面积就越大；
发布风险——AI 写的代码出了线上问题，责任还是你的。
还有一些更难量化的东西：人的注意力损耗，长时间高强度人机对话带来的疲劳，以及那种"明明产出了很多，但总觉得哪里不踏实"的感觉。
旁观者容易看到 AI 写得很快，却看不到人为了让它真的能用，付出了多少隐形劳动。
十、AI 生产力通胀
还有一个我不太想说但又不得不说的现象。
以前一个需求，两三天完成，大家觉得正常。节奏是稳定的，预期也是合理的。
现在有了 AI，一种新的默认预期开始形成：既然有 AI 了，应该更快吧？
这种预期不一定来自谁的直接催促。很多时候，是自己给自己的压力。一天过去了，需求还没做完，你会下意识地想：我是不是没用好 AI？是不是我 Prompt 写得不够好？是不是别人用 AI 都比我快？
工具变快了，人也被期待更快。AI 的速度变成了一种新的基准线，而人的注意力、判断力和恢复能力并没有同步升级。
我把这个现象叫做"AI 生产力通胀"——工具的产出速度提高了，但人对自己的速度预期也膨胀了。你生成了更多的东西，但你也被要求消化更多的东西。到最后，效率的提升被新的预期吃掉了，人反而比以前更疲惫。
AI 让人类开始用机器的速度要求自己，但人终究不是机器。
十一、成熟的 AI 使用方式，是建立轨道
说到这里，我不想让这篇文章变成满腹牢骚。
问题存在，但方向也在逐渐清晰。
我自己在实际工作中慢慢摸索出来的经验是：成熟的 AI 使用方式，不是让 AI 无限加速、一次性自由发挥，写完一大堆代码再让人收拾。
更合理的方式是给 AI 建立轨道：
先让 AI 理解项目结构和上下文，而不是上来就让它写代码；
再让 AI 输出一个修改计划，而不是直接生成最终方案；
人先审核计划，确认方向没问题，再让 AI 小步修改；
每一步看 diff，每一步跑测试；
最后由人决定是否合并和发布。
这个过程看起来比"一句话让 AI 写完所有代码"要慢，但实际上它更可控、更安全、返工更少。
AI 越快，越需要工程系统来约束它。AI 越强，越不能让它无边界地自由发挥。
这不是对 AI 的不信任，而是对工程交付的尊重。
十二、重新定义效率
我也在重新想，应该怎么定义自己一天的效率。
以前我会问自己：今天有没有改完一个需求？有没有修完一批 Bug？
现在我觉得，这个标准需要调整。
不是每天都能把一个需求从头到尾做完。但下面这些事情，也应该被算作有效产出：
把一个模糊的需求变清楚了；
确认了一个方案不可行，避免了后面的弯路；
删掉了 AI 生成的一段错误代码，保住了项目稳定性；
定位了一个核心 Bug 的根因；
发现了一个潜在的发版风险；
把主流程跑通了；
建立了测试和验证的路径。
这些都不是"生成"，但它们都在把项目往可交付的状态推进。
AI 时代，真正稀缺的不是代码，而是判断力、验证能力和交付责任感。代码可以让 AI 生成，但"这个东西到底对不对、能不能上线、出了问题谁来兜底"，这些判断没有人可以外包。
十三、AI 是杠杆，不是鞭子
写到最后，我想把自己的想法做一个简单的总结。
AI 当然有价值。这一点我从来没有否认过，以后也不会否认。它确实提高了很多局部效率，帮我完成了很多以前做不到或者做起来很慢的事情。
但问题在于，我们不能把局部的生成速度，误认为完整的生产力。
代码生成得快，不代表项目交付得快。方案输出得多，不代表问题解决得好。AI 能写的东西越来越多，但最终决定一件事情能不能上线、能不能用、能不能扛住真实场景的，还是人的判断和验证。
人类对于 AI 最大的幻觉，不是以为 AI 无所不能，而是以为 AI 提升了生成速度，就等于提升了完整生产力。
AI 是杠杆，不是鞭子。
它应该帮助人放大能力，而不是让人用机器的速度消耗自己。
真正成熟的 AI 生产力，不是生成更多的东西，而是更稳定地把正确的东西交付出去。
