AI编程的六大痛点：一线开发者真实吐槽与破局之道

AI 编程工具正在重塑软件开发，但一线开发者到底在为什么抓狂？YouTube 知名技术博主 Primeagen 最近发起了一个问题征集——"在使用 AI 进行软件工程时，你最挣扎的是什么？"这条帖子获得了 25.5 万次观看和 336 条评论。从 CI 崩溃到代码归属感缺失，从无用的文字垃圾到初级开发者的成长困境，评论区的吐槽几乎覆盖了 AI 编程的每一个角落。Primeagen 逐条给出了自己的专业分析和解决方案，其中有共鸣、有吐槽，也有值得每个开发者认真对待的建议。

CI 失控与端到端测试灾难

Primeagen 把"CI 烂透了"排在第一位，并且认为这个问题比表面看起来更严重。

AI 生成代码的一个典型模式是：你让它写一个功能，它顺手改了 100 个测试；你再让它加一个功能，它又写了一大堆端到端测试。反复几次之后，项目里积累了成千上万条端到端测试。这些测试运行缓慢、极不稳定，几乎每次都有各种问题。

"我不在乎有一个人跳出来说'我的端到端测试从来没出过问题'——我就没待过一家端到端测试不出问题的公司，"Primeagen 说。

核心问题在于：你不可能把所有东西都端到端测试。AI 不会替你思考"我到底在测什么"，它只会机械地堆砌测试用例。Primeagen 的建议很直接——一个简单的 CRUD 应用真的需要 5 万条端到端测试吗？开发者需要主动裁剪测试策略，而不是让 AI 无限膨胀测试套件。

端到端测试（End-to-End Testing，简称 E2E 测试）指从用户视角出发、模拟真实使用流程、贯穿整个系统（前端、后端、数据库、第三方服务等）的测试方式，典型工具包括 Cypress、Playwright、Selenium。与单元测试只验证单个函数或模块不同，E2E 测试覆盖的链路最长，因此最能反映真实行为，但代价也最高：需要启动完整环境、依赖网络与外部服务，单次执行往往耗时数十秒到数分钟，且容易受时序、数据状态、环境差异影响而出现偶发失败（flaky test）。

业界的普遍共识是"测试金字塔"——大量单元测试、适量集成测试、少量 E2E 测试，因为 E2E 的维护成本随数量呈非线性上升。当 AI 不加判断地为每个功能追加 E2E 用例时，测试套件会从"安全网"变成"拖累项"：CI 时间越来越长，随机失败越来越频繁，开发者逐渐对红灯麻木，最终失去对测试结果的信任，这恰恰抵消了自动化测试本应带来的价值。

上下文切换：AI 既是加速器也是绊脚石

Primeagen 坦言上下文切换是他个人感受最深的问题。

AI 的速度体验非常矛盾：它既比人快得多，又比人慢得多。你花时间深入思考一个问题，写好提示词，然后不得不等待 10 到 20 分钟。这段时间里，你很自然地想"不如再开一个任务"。结果就是你同时有四个并发任务在跑，整个人彻底迷失。

"我基本上是个单任务型的人，"Primeagen 说。他可以同时进行一两个任务，但到三个就开始失控，四个就完全不行了。不过他也承认，如果只是在等待而不需要深度编码，同时跑多个任务是可以接受的。这个观察其实揭示了一个更本质的问题：AI 编程工具的工作节奏与人脑的深度思考节奏并不匹配，开发者需要有意识地管理自己的注意力分配。

上下文切换（Context Switching）是认知心理学与软件工程中的经典概念，指人脑从一项任务转移到另一项任务时，需要重新加载相关工作记忆、目标状态和问题背景，这个过程存在显著的时间与注意力损耗，研究普遍认为一次完整恢复平均需要十几到二十分钟。对于需要维持复杂心智模型的编程任务而言，这种损耗尤其昂贵。

AI 编程工具引入了新的切换诱因：以往等待编译或构建时，开发者通常只有几十秒，不足以启动新任务；而 AI 生成可能长达十几分钟，形成一段"看似空闲"的时间窗口，诱导人开启并发任务。问题在于，这种并发不是真正的时间复用，而是把单向的深度思考切割成多段浅层切换，最终导致每个任务的心智模型都不完整。理解这一点，有助于解释为什么"同时开四个 AI 任务"往往比串行处理更慢，也更容易让人感到疲惫和迷失。

过度炒作与 FOMO 文化

"如果你不做 X，你就完蛋了"——Primeagen 对这类言论的态度非常明确：当你听到有人这么说时，永远不要再想那个人的话。

他的论据很扎实：一年前使用 AI Agent 的方式和今天截然不同，两年前和一年前也完全不同。今天不存在某个必须掌握的具体工具或框架，不学就"赶不上"。他举了一个例子：在 React Miami 大会上，来自旧金山的一些开发者坚信 AI 在六个月内就能无错创建类似 Cloudflare 或 Forth 这样的复杂系统。

"你不是在创建 Cloudflare，你不可能靠对 AI 说'没有错误'就做出一个服务数百万用户的十年稳定运行的系统，"Primeagen 毫不客气地说。

他的观点是：AI 确实能让缺乏某领域知识的人产出看起来能用的软件，但构建长期可靠的基础设施服务是完全不同的挑战。对 AI 能力的理性讨论是稀缺的，大多数人在这件事上"功能性地疯了"。

无用的文字垃圾：AI 最令人抓狂的输出

"太多无用的文字"之所以让 Primeagen 暴怒，是因为他亲身经历过极其荒谬的场景。

他给 AI 的指令是："不要叙述，只列出仓库模式的清单，我们一个一个来构建。"AI 回复："好的。每个主题一个文件。打开你需要的那一个。每个文件包含事实和代码。"

Primeagen 的反应："我告诉你了不要叙述，然后你写了一段关于'不要叙述'的叙述。"

他甚至尝试了 Grugbrain 风格的提示词来压缩输出。确实有改善，但 Grugbrain 自己的表达方式又变成了另一种极端："我理解不能，这让人困惑，希望这样，决定必须有，重担在肩。"读起来同样让人抓狂——"兄弟，你就把话说清楚就行了。"

这个吐槽看似轻松，实际上指向一个真实的效率问题：开发者每天花大量时间阅读 AI 生成的冗余文本，而这些文字中真正有价值的信息可能只有一句话。

代码归属感：如何真正"拥有"AI 写出的代码

这是评论区最普遍的抱怨，也是 Primeagen 花最多时间给出实际建议的问题。

他的方法是"探索后重建"：

第一步，深入思考系统的形态和需求。然后用 AI 快速"vibe"出一个版本，让它跑起来，不断迭代。这个过程中会产出大量测试和代码，但你会获得对这个系统的深刻理解，知道需要什么组件、什么接口、什么架构。

第二步，基于这些理解，从零开始做 v2。认真设计每一步，仔细分类每个模块，用同样的功能集构建一个经过深思熟虑的精简版本。

Primeagen 正在做的项目，代码量从 10 万行缩减到预计 2.5 万到 3 万行，功能完全相同。"这意味着我真正想清楚了，重新构建了，数据库设计更好了，一切都更好了。"

他强调，这种方法其实就是传统软件工程中原型开发的思路。过去每个人都会先做个原型来探索，然后基于经验构建正式版本。现在只是把原型开发交给了 AI 来加速。

"我实际上通过 AI 第二次真正地做了软件工程，这种方法让我感到满足，让我真正有了归属感。"

代码归属感（Code Ownership）在传统软件工程中指的是开发者对某段代码承担长期责任、理解其设计意图、并愿意持续维护和演进它的心理状态。它通常与代码评审、模块负责人制度、以及"谁写的谁改"等实践绑定，是代码质量的重要隐性保障。

AI 生成代码削弱归属感的机制在于：代码从产出到进入仓库之间跳过了"作者逐行理解"这一步。开发者看到的是一个能跑通的整体，却说不清每个决策从何而来，于是在面对 bug 或需求变更时缺乏介入的抓手。Primeagen 提出的"探索后重建"本质上是在人为补回这一环节——先用 AI 快速试错、暴露设计空间，再由开发者亲手重写核心部分，从而把"我拥有这段代码"从法律意义上的署名，转变为认知意义上的掌控。这种方法与敏捷开发中的"原型—重构"循环、以及 Joel Spolsky 提出的"永远重写一次"（rewrite once）思想一脉相承。

初级开发者的困境：AI 时代最大的悲剧

这是 Primeagen 表示"最让人难过"的一条评论：作为初级开发者，想手写代码学习新东西，但周围没人愿意让你这么做，因为大家都追求即时结果和快速交付。结果就是无法在工作中找到专业成长的路径。

Primeagen 认为这是 AI 带来的最大也最糟糕的困境。过去，公司不得不给新人成长空间，因为别无选择。但现在，一个新人加上 AI 就能达到 Claude 水平的生产力，这对很多人来说已经"够用"了。

更糟糕的是，AI 不会像资深工程师那样质疑你的设计："嘿兄弟，我知道你提了这个方案，但根据架构来看，我觉得这样做会更好，我们先讨论一下再改。"AI 只会给你一个 1000 行的 PR，说"按你要求做了"。而由于你不熟悉代码库，做了一堆糟糕的决定，到处塞满了垃圾代码。

"初级开发者现在拿到的是最短的那根棍子，"Primeagen 说。他们被期望像资深工程师一样快速交付，手里有一个据说能产出资深级别代码的工具，但他们没有获得真正的理解。

他的建议是反直觉的但值得认真考虑：花时间阅读、亲手敲键盘、构建原型、思考边界情况、学习 mocking 以及为什么你讨厌它但又有时需要它、学习依赖注入以及它为什么能解决问题又为什么可能是邪恶的。这些事在 AI 时代听起来不那么性感，但他坚信，以最大速度前进同时零学习、什么都不理解，对长期发展没有好处。

Primeagen 用一个招聘场景收尾：如果今天要雇人，你想要一个纯粹充当代理的人——你说什么他把什么输入到代码框里，看着它转圈然后说 merge——还是一个真正思考问题、判断哪些测试不需要、如何布局服务器、CLI 该长什么样的人？

"我百分百想要后者。仅仅做一个信息中转站从来不是好主意。永远努力成为比文本框中转站更有价值的人。"

初级开发者的成长长期以来依赖一种隐性契约：公司允许他们在真实项目中"低效地"犯错、阅读他人代码、被资深工程师评审和纠正，以此换取技能积累。这套机制的运转前提是新人产出速度明显低于资深工程师，因此成长空间是一种投资而非负担。

AI 改变了这个前提。当一位新人借助 AI 就能达到接近成熟模型的生产力水平时，团队便失去了"容忍低效"的经济动机，新人被直接推上交付前线。但产出速度并不等于理解深度——初级开发者缺少的恰恰是"为什么这样设计"的判断力，而这只能通过亲手写、亲手调试、亲身踩坑来建立。结果是双输：团队得到看似够用的代码，却积累了难以维护的技术债；新人则耗尽了本该用于成长的窗口期。这也是为何许多工程组织开始重新讨论"AI 时代如何设计新人培养路径"这一议题。

总结

Primeagen 的这场吐槽与分析触及了 AI 编程当前最真实的矛盾：工具能力在快速提升，但围绕它的工作方式、团队文化和人才培养机制还远未跟上。CI 膨胀、上下文切换、过度炒作、输出冗余、归属感缺失和初级开发者困境，这六个问题没有简单的技术解法，它们需要开发者主动调整工作方法，也需要团队重新思考效率和成长之间的平衡。