两年前，我所在的工程团队决定全面拥抱 AI 辅助编程。我们引入了当时最先进的代码生成工具，将其嵌入到日常开发的每一个环节。从需求分析到代码实现，从测试编写到文档生成，AI 似乎无所不能。我们兴奋地宣称，传统的「手写代码」时代已经过去，未来的软件开发将由「vibecoding」主导 —— 开发者只需要描述清楚自己想要什么，AI 就能生成高质量的代码。
然而，两年后的今天，我却做出了一个看似「倒退」的决定：回归手写代码。这个决定并非出于对技术的抵触，而是源于实践中积累的深刻认知。AI 辅助编程在特定场景下确实能够显著提升效率，但它并非万能药方。当我们过度依赖 AI 时，一些隐蔽但致命的问题开始浮现，最终迫使我们重新审视人与机器在软件开发中的角色分工。
效率假象与认知退化
AI 辅助编程最直接的吸引力在于效率提升。在最初的几个月里，我们的交付速度确实令人印象深刻。一个需要两天完成的功能模块，在 AI 的帮助下可能只需要半天。这种速度上的飞跃让整个团队陷入了某种狂欢状态，我们开始将越来越多的工作交给 AI 处理，甚至包括那些需要深度技术判断的核心逻辑。
然而，效率的提升掩盖了一个危险的信号：团队成员的技术能力正在悄然退化。当开发者习惯了从 AI 获取代码片段而非自己思考实现方案时，他们对系统整体架构的理解开始变得碎片化。我观察到团队中出现了几种典型的症状：第一，工程师无法解释为什么某个实现方案是有效的，只能复述 AI 给出的解释；第二，当代码出现问题时，大家习惯性地求助于 AI 而不是查看源码或调试程序；第三，最令人担忧的是，新入职的工程师在加入团队时发现，他们无法从资深成员那里获得有深度的技术指导，因为资深成员本身也已经遗忘了许多底层细节。
这种认知退化并非个人的过错，而是人机协作模式设计中固有的风险。当 AI 能够即时给出看似正确的答案时，大脑会自然地选择省力的路径。神经科学研究表明，长期依赖外部认知工具会导致相应脑区的活跃度下降。这不是危言耸听，而是我们在实践中观察到的真实变化。
质量边界的隐性侵蚀
AI 生成的代码在表面质量上往往令人满意。它通常遵循良好的命名规范，代码结构清晰，甚至能够生成符合最佳实践的错误处理逻辑。但表面的光鲜掩盖了一个根本性的问题：AI 难以理解特定系统的上下文约束和隐藏的业务规则。
我们在一次重大故障中深刻体会到了这一点。一个看似简单的字段变更，AI 生成的代码通过了所有单元测试，却在生产环境中导致了数据一致性问题。问题的根源在于，这个字段在系统中有三个不同的含义，分别对应三个业务场景，而 AI 只理解了其中最常见的那一种。AI 生成的代码在孤立环境下完美无缺，但在实际系统中却引发了一系列连锁反应。
这个案例揭示了 AI 辅助编程的一个核心局限：它擅长处理显式的、可形式化的需求，却难以感知系统演化过程中积累的隐性知识。这些隐性知识往往没有文档化，甚至没有被明确意识到，它们存在于资深工程师的直觉中，体现在他们做出的每一个看似微小的决策中。当我们将这些决策全部交给 AI 时，实际上是在用一套通用的、抽象的模式替换掉那些经过千锤百炼的、特定于系统的解决方案。
上下文切换的认知成本
AI 辅助编程的另一个隐性成本是上下文切换。当开发者不断在自然语言描述和代码实现之间切换时，他们需要频繁地进行认知模式的转换。从「思考要做什么」到「描述给 AI」，再到「理解和验证 AI 的输出」，每一步转换都会消耗认知资源。这种消耗在短时间任务中可能不明显，但累积起来会显著影响深度思考的能力。
我个人的体验是，在密集使用 AI 辅助编程几个月后，我发现自己很难进入「心流状态」—— 那种完全沉浸在代码中、时间仿佛停止的深度工作状态。每当我试图解决一个复杂问题时，脑海中总会闪过一个念头：「为什么不让 AI 来做？」这个念头打断了我与问题之间的直接对话，让我无法建立起对问题的深层理解。
更重要的是，AI 的介入改变了问题的解决路径。传统编程中，开发者需要在脑海中构建问题的模型，然后将其翻译成代码。这个过程本身就是理解和消化的过程。而当 AI 直接生成代码时，这个翻译过程被跳过了，开发者获得的是一个他们并未亲身构建的解决方案。这种「知道答案但不理解答案」的状态，在面对新问题时会变得尤为脆弱。
回归手写并不意味着排斥 AI
做出回归手写代码的决定，并不意味着我们要完全放弃 AI 工具。相反，这是一个关于如何在人与机器之间建立健康边界的探索。经过两年的实践，我们形成了一套混合工作流，试图在效率和质量之间找到平衡点。
首先，我们明确了 AI 的适用边界。AI 最适合的任务是那些边界清晰、逻辑直接、上下文依赖少的实现。例如，标准的数据结构实现、常规的错误处理模式、简单的 CRUD 操作等。在这些场景下，AI 能够显著提升效率，而且出错的风险可控。但对于涉及复杂业务规则、需要深度系统理解、或者影响核心架构的决策，我们坚持由人来完成。
其次，我们建立了「理解优先于采用」的原则。当 AI 生成一段代码时，团队成员被要求在采纳之前必须完全理解这段代码的逻辑。如果无法解释这段代码为什么有效，就不能将其纳入系统。这个原则看似增加了工作量，实际上是在强制保持人类开发者对系统的掌控力。
最后，我们重新重视代码审查的作用。在 AI 辅助编程时代，代码审查往往流于形式，因为审查者很难判断一段陌生的代码是来自 AI 还是人类。新的实践要求代码作者不仅要解释代码的功能，还要说明选择这个实现方案的理由。这种深度审查虽然更耗时，但它确保了知识在团队中的流动和积累。
给工程团队的建议
基于我们的实践经验，我想为考虑或正在使用 AI 辅助编程的工程团队提供几点建议。第一，保持对自身技术能力的警觉。如果发现自己对系统的理解在变浅，这是一个危险信号，需要刻意调整工作方式。第二，为 AI 生成代码建立额外的验证机制，不要完全信任单元测试的结果，要从系统整体行为的角度进行验证。第三，投资于隐性知识的显性化，将那些原本存在于资深工程师头脑中的经验转化为文档、模式库或技术分享，让团队整体的技术判断力不会因为 AI 的介入而退化。
AI 辅助编程是一个强大的工具，但它和所有强大的工具一样，需要谨慎使用。盲目地拥抱或盲目地排斥都不是正确的态度。真正的工程智慧在于理解工具的边界，并在边界之内合理地使用它。两年的 vibecoding 实践让我深刻认识到，软件开发的核心始终是人的理解和判断，AI 只是辅助这一过程的手段，而非替代。