AI 辅助开发的“死亡之谷”：比生产力更重要的，是失败经验的积累
在软件工程领域，关于 AI 能否提升开发效率的讨论从未停止。但近日在 Hacker News 上引发热议的一篇深度帖文提出了一个更具颠覆性的观点：比起“AI 生产力乘数”，开发者和公司真正需要积累的，是在 AI 辅助工作流中失败的认知经验。这篇文章并非鼓吹 AI 的万能，而是基于一线开发者的实战反馈，提出了一套令人耳目一新的软件估算框架——它可能直接回答了“为什么大项目用 AI 经常翻车”这个关键问题。
“Vibe Coding”实验：用失败来定义瓶颈
原作者分享了他最近有意为之的“vibe coding”实验——即故意让 AI 去写代码，以观察它在哪里失手。实验的核心成果是一套 P0 / P1 / P2 任务分级系统：P0（JWT 认证、业务逻辑、领域设计）必须由人类开发者亲手完成，估算标准与传统方式无异；P1（连接 P0 的胶水代码）工时减半，但需包含验证层；P2（非关键前端逻辑、次要 UI 行为）则可安全下放给 AI 处理。
一个极具说服力的数据是：当作者在并行模式下运行 GPT 时，5 分钟就能生成约 3000 行代码。但这位开发者冷静地指出，这种速度恰恰是陷阱——因为 AI 倾向于创造“上帝对象”（God Objects），导致长期维护性迅速恶化。他为此提出一个量化指标：“瓶颈分数”。简单 CRUD 的瓶颈分数很低，因为 GPT 可能比人类写得还好；但架构设计与重构的瓶颈分数必须给得很高，因为这是 AI 最擅长的搅局领域。
40万行代码的天花板：系统边界决定估算权
文章最具现实意义的部分，在于揭示了 AI 能力的“光谱”边界。原作者指出，AI 在高阶语言、不直接管理内存的领域表现强，但在内存管理、底层细节、以及资源所有权微妙的地方表现弱势。这意味着，一个合理的估算不是简单加减 50% 的时间，而是根据具体特性区域，混合使用“人类开发者视角”和“AI 代理视角”的双轨估算方法。
但他也划出了一条重要分界线：这套方法仅适用于大约 8 万行代码以下的项目。一旦项目容量突破 40 万至 50 万行代码，模块化与边界设计将呈现出指数级复杂的特征。到那时，估算权必须交还给深刻理解系统边界的资深开发者——因为只有他们能准确预判 AI 何时会踩进“资源所有权”的雷区。
对于还在盲目追求“AI 替代人”的团队而言，这篇文章其实是一个温和的警告：与其寻找一个神奇的“AI 生产力乘数”，不如在组织内有意识地培养一批“经历过 AI 失败”的工程师。他们对瓶颈位置的直觉，才是 2025 年及以后，任何严肃软件项目最稀缺的资源。
