# 从 AI 辅助编程回归手写代码：两年 vibe coding 的工程反思 > 剖析工程团队在两年 AI 辅助编码实践后回归手写代码的决策逻辑，探讨人机协作的质量边界与认知负荷管理。 ## 元数据 - 路径: /posts/2026/01/26/vibecoding-ai-assisted-return-manual/ - 发布时间: 2026-01-26T23:34:11+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 两年前，我所在的工程团队决定全面拥抱 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 只是辅助这一过程的手段，而非替代。 ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。