最近 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 按照人类提供的模板类和示例代码进行学习和约束。
◦ 核心逻辑必须按照团队的开发规范和习惯进行重写，以确保代码的可维护性和安全性。