国内大厂实践 vibe coding 遇到的问题和困扰。

最近 15 人小组实践 vibe coding 遇到了一系列问题。
一、项目背景：
业务性质： 这是一个涉及资金流（与钱直接挂钩）的企业级复杂架构项目，对系统的稳定性、一致性和高可用性有着严苛的要求。
应用场景： 专门为**“大促”（如双 11 等大型活动）准备，需要应对海量的瞬时高并发流量**，设计中必须包含完备的幂等、事务和并发处理机制。
交付压力： 这是一个典型的**“倒排期”项目**，上线时间点死板且不可逾越，任何延期都会被视为严重的生产事故。
技术挑战：
高复杂度逻辑： 除了基础接口调用，还必须设计多级核对机制（分钟/小时/天级）、异步消息补偿机制、技术应急预案以及客服处理预案,。
开发约束： 采用 SDD （规范驱动开发） 模式，基于公司内部自研框架开发，且因数据安全限制，AI 无法读取既有私有代码库，属于从 0 到 1 的全新代码仓库。

二、问题
1. 技术与代码质量问题
逻辑伪造与“将错就错”：AI 在面对缺失的知识、错误的接口文档或注释时，会伪造逻辑或猜测（ Mock ）返回格式,。遵循“垃圾进，垃圾出”（ GIGO ）原则，如果输入信息有误，AI 的产出必然也是错误的。
错误传播与测试盲区： 如果 AI 基于错误的架构分析生成代码，它也会基于同样的错误逻辑设计测试用例，导致单测和集测无法发现逻辑漏洞。
产生“史山代码”： 虽然 AI 初步生成的代码看似整洁，但在经过人工点对点的调试（ Web Coding ）修复问题后，代码会逐渐演变成难以维护的史山代码,。
缺乏企业内部知识： 由于数据安全限制，AI 无法读取既有的私有代码库，且对企业内部定制或自研的框架缺乏了解，导致其难以写出符合要求的代码。
不符合开发规范：AI 编写的代码往往不符合团队内部的开发规范或习惯（如事务处理方式），导致人类工程师在 CR （代码评审）或维护时感到非常困难。
2. 架构与设计层面的局限
输出不稳定与概率推断： 基于 Transformer 架构的 AI 本质上是概率推断模型，同样的输入和提示词（ Prompt ）产生的输出是不稳定的。
上下文限制与“遗忘”：AI 的上下文处理能力有限，在解决具体问题时可能会忘记之前的全局设计，导致代码复用性差，甚至在同一项目中针对相同问题重复编写不同的代码。
“只见树木不见森林”：AI 容易陷入局部逻辑，忽略全局影响，例如在修改代码逻辑后忘记更新注释或相关的单元测试。
文档过度冗长：AI 喜欢编写极其详尽、甚至带有重复内容的长文档，这增加了人类阅读和理解的成本,。
3. 工作流程与效率悖论
工作强度反而增加： 使用 AI 后，程序员的工作时长变得更长、更累，甚至需要工作到凌晨，这与“AI 减负”的初衷相悖。
由于过度约束导致的“犯傻”： 为了约束 AI ，开发人员会定义越来越多的 Agent 和复杂的 Workflow ，但约束过多会导致 AI 出现“过敏”或变得笨拙，丧失了发散性思维的能力。
Token 消耗巨大： 复杂的 Workflow 和长指令会导致 Token 消耗量激增（每天消耗上亿 Token ），导致成本异常昂贵。
陷入“面多加水”的死循环： 当 AI 做不好时，人类倾向于增加更多 Agent 或约束，这使得系统越来越复杂，最终效果反而变差,。
4. 心理压力与管理挑战
认知负荷与上下文切换： 领导层可能误认为 AI 能大幅提升生产力，从而给程序员安排更多并发项目，导致程序员需要在多个 AI 窗口和项目背景间频繁切换，造成脑力枯竭,。
巨大的“不安全感”：AI 的自评分往往虚高（如给自己打 98 分），但人类很难一眼看出其逻辑中的隐患。由于不理解 AI 某些设计的意图，人类工程师会产生强烈的不安全感和心理压力,。
信息爆炸：AI 产出的海量文档和代码需要人工进行大量审查（ Review ），这一过程极其消耗精力。


三、建议
1. 明确 AI 的适用场景：
推荐场景： 编写一次性脚本、处理数据报表、编写复杂的 SQL 、整理文档、画图、辅助理解不熟悉的既有代码、查 Bug 、以及编写基础的单元测试和集成测试代码。
限制场景： 涉及核心业务逻辑、复杂资金流、高可用架构设计时，必须由人类主导。
2. 坚持“人机协作”而非“全权委托”：
建议通过 Web Coding 的方式，让 AI 按照人类提供的模板类和示例代码进行学习和约束。
核心逻辑必须按照团队的开发规范和习惯进行重写，以确保代码的可维护性和安全性。