1. 从“解放双手”到“疲于奔命”一个开发者的AI困惑最近和几个同行聊天话题总绕不开AI。大家普遍的感觉是自从ChatGPT、Copilot这类工具火起来之后我们这些写代码的好像并没有变得更轻松反而时常陷入一种新的疲惫感。这种感觉很微妙不是996那种体力上的累而是一种认知上的“过载”和“拉扯”。明明AI承诺的是“自动化”、“提效”、“解放生产力”怎么用着用着反而觉得更累了呢这不仅仅是我的个人感受。看看网络上的讨论从“AI编程”到“AI Agent”从“动态组件加载”到“代码评审”AI的影子无处不在。它确实能快速生成一段“拉格朗日乘数法代码”或者帮你搭建一个“Vue3孙组件ref访问”的架子甚至能“一键清理bat代码”。但问题也随之而来生成的代码你敢直接用吗为了让它生成你想要的“Python量化交易策略代码”你需要花多少时间去描述需求、调整提示词当“Antd中的Table组件在筛选时会自动触发pagination的onchange事件”这种诡异问题出现时你是指望AI帮你排查还是得自己一行行看源码我们似乎进入了一个怪圈以前是自己吭哧吭哧写代码现在是吭哧吭哧地“指导”AI写代码然后花更多时间“评审”AI写的代码。工具本身没有错它强大得令人惊叹。但当我们把AI从一个“辅助工具”的位置不自觉地摆到了一个“初级开发者”甚至“合作者”的位置时疲惫感就产生了。这种累源于期望与现实的落差源于工作流程的重构更源于我们与工具关系的错位。这篇文章我想结合自己这段时间的实践聊聊这种“AI疲劳”的几个具体来源以及我个人摸索出的一些应对思路。2. 效率幻觉当“生成速度”不等于“交付速度”AI最吸引人的一点无疑是其惊人的内容生成速度。你描述一个需求比如“用Python写一个计算长方体体积的函数”它几乎能在瞬间给出答案。这种即时反馈的爽感很容易让我们产生“效率爆棚”的错觉。但真实项目开发中从“有一个想法”到“交付可用的代码”中间隔着十万八千里。AI帮我们跨越的往往只是最初、最简单的那一小段路。2.1 “代码搬运工”的困境从创造到拼装以前我们写代码是从需求分析、架构设计到逻辑实现、细节打磨的一个连贯的创造过程。大脑需要深度参与构建完整的心智模型。现在AI介入后这个过程被切割和重构了。很多时候我们的工作变成了先想清楚某个功能点然后构思如何用自然语言向AI描述写提示词接着评估AI返回的多个代码片段最后将这些片段手动集成到自己的项目中。举个例子你需要开发一个带有“模糊过渡效果”的前端组件。以前你会去研究CSSfilter: blur()和transition的配合或者考虑使用Web Animation API这是一个学习并应用知识的过程。现在你可能会直接问AI“Vue3中如何实现组件内容刷新时的模糊过渡效果” AI可能会给你一段看起来不错的代码用了transition和自定义的CSS类。但接下来呢你需要检查这段代码是否符合你的项目结构是否用了Composition API样式是Scoped吗动画性能如何会不会引起重排在移动端兼容性怎样这个过程从“知识应用与创造”变成了“信息检索与质量审核”。你的认知负荷并没有减少只是转移了。你不再需要记忆所有API的细节但你需要具备更强大的代码评审能力、更敏锐的“代码异味”嗅觉以及将零散片段整合成有机整体的架构能力。这其实对开发者提出了更高的要求。你得像一个技术主管一样去评审一个不知疲倦但时常犯一些诡异错误的“实习生”的代码。2.2 提示词工程一门新的“元编程”为了让AI输出可用的结果我们不得不学习一门新技能提示词工程Prompt Engineering。这就像在跟一个理解能力超强但缺乏常识和上下文的外星人沟通。你需要精确地定义边界条件、输入输出格式、甚至代码风格。比如你想要一段“Shell脚本编程100例”中那样的日志轮转脚本。简单的提示“写一个日志轮转的shell脚本”可能得到一个基础版本。但如果你需要它处理符号链接、保留特定天数的压缩备份、并在轮转后发送通知你的提示词就会变得极其冗长和精确堪比一份微型需求文档。调试一段不工作的提示词所花的时间有时甚至超过了手动编写那段代码的时间。更令人疲惫的是不同模型、不同时间对同一提示词的反应可能不同。今天它能正确理解“使用递归实现二叉树遍历”明天同一个提示可能它就给你一个迭代版本。这种不确定性迫使你不得不花费额外的心智去“揣摩”AI的“脾气”并准备多个版本的提示词以备不时之需。这本质上是在进行一种“元编程”——我们不再直接编写解决业务问题的代码而是在编写如何让AI生成代码的“代码”即提示词。这个间接层就是新的认知负担来源。注意不要陷入“提示词完美主义”陷阱。对于一次性任务花费30分钟打磨一个完美提示词可能不如花10分钟写个基础提示再用20分钟手动修改AI生成的代码。提示词的目标是“足够好”而不是“绝对完美”。3. 质量焦虑信任缺失与审查成本的飙升AI生成的代码就像开盲盒。有时惊艳有时惊悚。这种不确定性直接导致了严重的“质量焦虑”。你不敢对它生成的东西完全放心尤其是涉及业务逻辑、安全或性能的关键部分。3.1 “看似正确”的陷阱与逻辑谬误AI最擅长生成“看起来”正确的代码。语法通常没问题风格可能很规范注释也写得头头是道。但它对代码背后的业务逻辑、边界条件和真实意图的理解是肤浅的。它可能基于训练数据中的统计规律进行组合而非真正的“理解”。我曾让AI帮我写一段“C语言文件读写操作代码”要求是读取一个配置文件解析其中键值对。它很快给出一段使用fgets和sscanf的代码。乍一看没问题运行简单的测试用例也能通过。但当我扔给它一个值中包含等号如keyvalueextra的畸形行时它的解析逻辑就崩了。更可怕的是它生成的代码可能完全没有错误处理fopen失败怎么办或者使用了不安全的函数如gets。这些深层次的逻辑漏洞和安全隐患AI目前很难自主避免。这就迫使我们必须对AI生成的每一行代码进行严格的、人工的审查。这种审查的强度甚至超过了对人类同事代码的审查。因为你要提防的不仅是逻辑错误还有那些“看似合理”的谬误、对过时API的调用、以及因训练数据偏差而产生的奇怪实现。审查AI代码你需要像侦探一样带着最大的怀疑精神去审视每一处可能藏有陷阱的角落。这个过程极其耗费心力也是“更累了”的核心原因之一。3.2 技术债的隐形加速器AI是生成代码的“快枪手”但它不负责维护。它快速生成的代码片段如果不经深思熟虑就集成到项目中很容易成为未来难以察觉的“技术债”。例如一个新手开发者用AI快速生成了一个“动态组件加载”的方案。AI可能基于某个旧的博客文章给出了使用require.ensureWebpack旧语法的实现。开发者直接复制粘贴功能跑通了很开心。几个月后项目升级Webpack 5这套动态加载语法需要重构而当初生成这段代码的开发者可能早已忘记其来龙去脉或者已经离职。此时这段“AI遗产”就变成了一个需要花费额外成本去理解和修复的债务。AI让“写代码”变得容易也让“制造混乱”变得容易。如果没有配套的、更严格的代码准入标准和架构规范项目很容易被大量风格不一、质量参差、依赖模糊的AI生成代码侵蚀后期的维护和调试成本会指数级上升。管理者和你自己都会为这些隐形债务感到疲惫。4. 技能栈震荡学不完的新工具与不变的核心AI的浪潮带来了眼花缭乱的新工具链“AI编程”助手如Copilot、Cursor、“AI Agent”框架、“无限制AI生图”平台、“AI测试”工具等等。每天都有新的模型、新的插件、新的最佳实践涌现。这种快速迭代让人兴奋也让人焦虑。4.1 工具切换的成本与心智负担为了“跟上潮流”我们可能不断尝试新的AI工具。今天试用这个“Cline编程助手”明天研究那个“Agnes AI官网”。每个工具都有自己的交互方式、配置项和“脾气”。频繁切换工具意味着需要不断适应新的上下文记忆新的快捷键理解新的输出风格。这种持续的学习和适应过程本身就是一种认知消耗。更重要的是这些工具尚未完全标准化。它们与现有开发环境IDE、构建工具、版本管理的集成度不一有时甚至会引入冲突。比如某个AI编码插件可能与你的代码格式化工具Prettier在保存时产生行为冲突或者其自动补全建议干扰了你原有的编码节奏。调试这些工具本身的问题又成了一项新的、与核心业务无关的“运维”工作。4.2 什么在变什么不变在工具喧嚣的背后我们必须清醒地问自己作为一个开发者哪些核心能力是AI无法替代的我认为以下几点反而在AI时代变得更加重要深度分析与抽象能力AI能处理具象的指令但无法替代你从模糊的业务需求中抽象出清晰、可执行的技术方案的能力。你需要比以往更擅长定义问题而不是仅仅寻找答案。系统设计与架构能力AI可以生成一个“Vue3组件”但它无法为你设计一个高内聚、低耦合、可扩展的前端应用架构。如何划分模块、管理状态、设计数据流这些大局观依然牢牢掌握在人类手中。批判性思维与调试能力当AI生成的代码运行失败或者出现“暗影精灵代码43”这种诡异错误时强大的调试和逻辑推理能力是定位问题的唯一依靠。你需要能读懂AI的“思路”并纠正它。领域知识无论是金融领域的“Python量化交易策略”还是游戏模组领域的“星露谷物语Python编程”深厚的领域知识是评估AI输出是否合理、是否可用的最终标尺。AI无法理解你业务中那些微妙的规则和约束。感到累部分原因可能是我们花了太多时间去追逐变化的工具而忽略了巩固这些不变的核心基石。当我们将AI定位为“增强”这些核心能力的工具而非“替代”我们思考的主体时心态会平和许多。5. 工作流的重构与适应从个人编码到人机协作引入AI不仅仅是多了一个工具它要求我们重构整个个人乃至团队的工作流。不适应这套新工作流就会处处掣肘感到疲惫。5.1 设计适合人机协作的开发流程传统的“编码-编译-测试-调试”循环依然有效但其中“编码”环节的内涵变了。它可能细化为“构思-提示-生成-审查-修改-集成”的新循环。我们需要为“提示”和“审查”这两个新环节分配专门的时间和注意力。在团队协作中这影响更大。比如代码评审Code Review以前评审的是同事的逻辑。现在可能需要评审一段由同事提示AI生成的、但同事自己也未必完全理解的代码。评审者需要问的问题可能变成了“你这个提示词是否足够精确”“有没有考虑过AI在这里可能引入的边界情况”“为什么选择这个AI生成的方案而不是另一个”团队可能需要建立新的规范比如要求提交AI生成的代码时必须附带原始提示词对于关键模块限制AI的使用范围或要求更高的测试覆盖率甚至像管理第三方库一样对项目中使用的AI模型版本、生成时间进行记录。建立这些规范需要讨论和磨合初期肯定会增加沟通成本让人感到“麻烦”和“累”但这是走向高效人机协作的必经之路。5.2 将AI用于正确的场景而非万能锤子不是所有任务都适合交给AI。识别哪些任务AI擅长哪些不擅长是减轻疲劳的关键。AI擅长的场景高收益/低审查成本样板代码生成重复的CRUD接口、简单的数据模型定义、单元测试框架搭建。语法转换与现代化将旧代码风格转换为新风格如ES5转ES6或者为旧代码添加类型声明如为JS代码添加JSDoc或转换成TypeScript。文档与注释根据代码生成初步的函数/模块说明或者为复杂逻辑添加解释性注释。探索与学习快速生成某个算法如“拉格朗日乘数法代码”或API用法的示例作为学习的起点。AI不擅长或需高度谨慎的场景高审查成本/高风险复杂的业务逻辑核心涉及大量领域规则和状态流转的核心算法。安全敏感代码身份认证、授权、加密解密、直接处理用户输入的逻辑。性能关键路径需要精细优化的底层循环、算法选择。全新的、无先例的架构设计AI基于已有数据生成难以进行真正的创新设计。把AI当成一个强大的“代码搜索引擎”和“初级实现助手”而不是“全栈工程师”。让它去做那些枯燥、重复、有大量范例可循的工作而把创造性的、决策性的、高风险的环节留给自己。这样分工才能最大化利用AI的优势同时控制其带来的风险和心智负担。6. 心态调整与AI共舞而非被其驱使最后也是最关键的一点是心态的调整。技术疲劳往往源于我们对技术不切实际的期望以及随之而来的失控感。6.1 管理预期接受AI的不完美我们必须从心底接受当前阶段的AI是一个有巨大潜力但也有严重缺陷的协作对象。它会犯错会“一本正经地胡说八道”会写出看似完美实则漏洞百出的代码。这不是AI的失败而是其技术原理下的必然。降低对它的预期从“希望它写出完美代码”降到“希望它提供一个不错的初稿或灵感”你的挫败感和疲惫感会大大减轻。当它犯错时你不会感到愤怒或失望而是会像纠正一个常见的语法错误一样平静地去修复它。6.2 掌控感回归你才是驾驶员不要让AI带着你跑。明确你才是项目的主导者是问题的最终定义者和解决方案的决策者。AI只是一个副驾驶一个信息提供者。你可以随时询问它的意见但方向盘和刹车必须牢牢掌握在自己手里。具体操作上这意味着从小处着手不要一开始就试图让AI设计整个系统。从一个函数、一个工具类、一段数据转换脚本开始。保持批判性对AI给出的任何建议、代码、解释都保持“怀疑一切”的态度用你的知识和测试去验证。设定边界明确告诉自己和团队在项目的哪些部分绝对不使用AI哪些部分可以有限度地使用。持续学习AI不能替代你学习。相反为了更有效地使用和审查AI你可能需要更深入地理解某些概念。例如为了判断AI生成的“动态组件加载”方案是否最优你需要比以往更懂Webpack/Vite的打包原理和代码分割策略。感到累说明我们正处在与新技术磨合的阵痛期。这种累是旧的思维模式和工作习惯被打破时的不适。它提醒我们需要停下来思考如何重新定义我们与工具的关系。AI不是来取代开发者的它更像是给我们每个开发者配了一个能力超强但经验不足的实习生。管理好这个实习生教会它用好它同时不断提升自己作为“导师”和“架构师”的核心能力或许才是走出当前疲惫感真正迈向人机协同新未来的关键。这个过程注定不会轻松但认清问题所在就是改变的开始。我个人现在的做法是每天划定一个“AI时间盒”比如不超过两小时集中处理那些适合AI的任务其余时间则屏蔽干扰进行深度思考和复杂编码。试着找到属于你自己的节奏别让工具主宰了你的工作与生活。