公司开始全面 vibe coding 之后感觉更累了

最近 15 人小组实践 vibe coding 遇到了一系列问题。整的我们连续加班了 1 个月。

项目背景： 公司里的核心项目。涉及资金流企业级复杂架构，对系统的稳定性和高可用性要求极其严苛。 这个项目是专门为大促（比如双 11 ）这种极端高并发流量设计的，里面充满复杂的业务逻辑，比如多层级的数据核对、消息补偿机制和各种应急预案。技术路线上使用公司自研框架上从 0 到 1 开发。 而且压力大的是，它是个倒排期项目，上线时间给定死了，一秒都不能拖。

准备阶段： 这次开始前我们内部讨论了很久，决定采用 SDD （规范驱动开发） 模式，即由规范和文档驱动 AI 进行架构设计、系统开发以及单测和集测的编写。 出于数据安全的考虑，团队申请了一个全新的项目仓库。明确要求 AI 不能读取公司既有的私有代码库，以规避潜在的合规风险。 由于 AI 缺乏对公司内部定制或自研框架的了解，我们手动编写了大量示例代码和 Todo 供 AI 学习。 团队预先定义了多个 Agent （智能体），并设计了详细的 Workflow （工作流），试图通过流程化来约束 AI 的发散行为。

惊喜的开始：

• 详尽且专业的架构文档：AI 产出的架构设计文档看起来非常完善，甚至比人类写的还要好得多。人类写文档时往往会基于“常识”而忽略一些细节或内部约定，但 AI 会写得非常详尽，不遗漏细节。 • 惊人的开发速度： 在纯开发阶段，AI 展示了极高的效率。内部估算，如果是由人类工程师完成该项目的纯开发工作，大约需要 15 到 20 人日，而 AI 仅用了 3 天时间 就完成了所有的代码编写。 • 高质量的代码注释与异常处理： 我们平时为了追求开发速度，有可能对注释和异常处理的相对简单，但 AI 编写的代码在注释质量和异常处理机制方面比人类工程师开发出来的要好很多。 • 清晰的设计与逻辑分层：AI 在接收到相关知识后，能够定义出非常清晰的类图、方法、依赖关系和分层结构。它会先进行详细的设计，明确每个类的职责，初步看过去代码质量非常不错。 • 代码初期的易读性：AI 初步生成的代码逻辑相对直接（偏“面条式”代码），没有过度使用复杂的架构模式或抽象，这使得人类在第一眼看过去时觉得逻辑非常清晰且好理解。

不过这样的蜜月期，并没有维持多久，很快我们开始遇到各类问题，加班也多了起来。

遇到的问题：

1. 技术与代码质量问题 • 逻辑伪造与“将错就错”：AI 在面对缺失的知识、错误的接口文档或注释时，会伪造逻辑或猜测（ Mock ）返回格式。遵循“垃圾进，垃圾出”（ GIGO ）原则，如果输入信息有误，AI 的产出必然也是错误的。 • 错误传播与测试盲区： 如果 AI 基于错误的架构分析生成代码，它也会基于同样的错误逻辑设计测试用例，导致单测和集测无法发现逻辑漏洞。 • 产生“屎山代码”： 虽然 AI 初步生成的代码看似整洁，但在经过人工点对点的调试修复问题后，代码会逐渐演变成难以维护的屎山代码,。 • 缺乏企业内部知识： 由于数据安全限制，AI 无法读取既有的私有代码库，且对企业内部定制或自研的框架缺乏了解，导致其难以写出符合要求的代码。 • 不符合开发规范：AI 编写的代码往往不符合团队内部的开发规范或习惯（如事务处理方式），导致人类工程师在 CR （代码评审）或维护时感到非常困难。

2. 架构与设计层面的局限 • 输出不稳定与概率推断： 基于 Transformer 架构的 AI 本质上是概率推断模型，同样的输入和提示词产生的输出是不稳定的。我们为了研究针对本项目最佳的 AI 沟通方式，不断的测试修改各种提示词，花费了不少时间。 • 上下文限制与“遗忘”：AI 的上下文处理能力有限，在解决具体问题时可能会忘记之前的全局设计，导致代码复用性差，甚至在同一项目中针对相同问题重复编写不同的代码。 • “只见树木不见森林”：AI 容易陷入局部逻辑，忽略全局影响，例如在修改代码逻辑后忘记更新注释或相关的单元测试。 • 文档过度冗长：AI 喜欢编写极其详尽、甚至带有重复内容的长文档，这增加了人类阅读和理解的成本,往往 AI 5 分钟输出的内容，我们要花 1 个小时去理解。

3. 工作流程与效率悖论 • 工作强度反而增加： 使用 AI 后，程序员的工作时长变得更长、更累，甚至需要工作到凌晨，这与“AI 减负”的初衷相悖。 • 由于过度约束导致的“犯傻”： 为了约束 AI ，开发人员会定义越来越多的 Agent 和复杂的 Workflow ，但约束过多会导致 AI 出现“过敏”或变得笨拙，丧失了发散性思维的能力。 • Token 消耗巨大： 复杂的 Workflow 和长指令会导致 Token 消耗量激增（每天消耗上亿 Token ），导致成本异常昂贵。 • 陷入“面多加水”的死循环： 当 AI 做不好时，人类倾向于增加更多 Agent 或约束，这使得系统越来越复杂，最终效果反而变差。

4. 心理压力与管理挑战 • 认知负荷与上下文切换： 领导层可能误认为 AI 能大幅提升生产力，从而给程序员安排更多并发项目，导致程序员需要在多个 AI 窗口和项目背景间频繁切换，造成脑力枯竭,。 • 巨大的“不安全感”：AI 的自评分往往虚高（比如 AI 设计的架构或算法，我们让 AI 给自己打分结果他给自己打 98 分），但人类很难一眼看出其逻辑中的隐患。由于不理解 AI 某些设计的意图，人类工程师会产生强烈的不安全感和心理压力,。 • 信息爆炸：AI 产出的海量文档和代码需要人工进行大量审查（ Review ），这一过程极其消耗精力。

后续反思

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