先说个现实情况：这个项目的代码总量达到了84917行。
这个任务的起源已经不重要了，总之某天下班前被老板叫住，说有一个重大项目需要接手。有同事用 vibe coding（AI辅助编程）快速搭建了一个Outlook插件的演示原型，大老板看后非常兴奋，决定将其产品化并推广为标准方案。老板要求用AI技术评估可行性，还配备了三位新来的实习生，并限时一周内拿出可供客户演示的版本。
老板的指示就是最高优先级，只能迎难而上。
先看看最终实现了哪些核心功能：
- 多端统一的架构设计（支持 Word 插件、PPT 插件、Outlook 插件、Web 端管理后台）
- 集成主流的 6 大供应商以及模型并发负载均衡
- 13 种语言的国际化支持
- 企业级的客户许可管理流程
- 无缝的平台集成和 AAD 单点登录
- 支持横向扩容的全套 k8s、docker compose 部署方案
- 单副本（1核500MB）支持 100 qps 的流式响应
目前该产品已部署给三个客户，服务规模约4000人。
听起来是不是很唬人？那实际开发过程中遇到了哪些问题呢？
给猴子配枪：实习生与AI协作的隐患
借着这个机会，想回应一下那些认为“随便找实习生搭配AI就能替代资深程序员”的老板们。先说实习生带来的挑战。
实习生同学最大的问题不是技术能力不足，而是缺乏对项目风险的判断力。这也不能全怪他们——作为实习生，能把功能做出来且没有报错已经算合格了。我们客观分析问题。
大家都知道AI在编程时通常会提供多种方案，但实际开发中只能选择一种执行。AI默认给出的方案往往不是最优解，需要经验丰富的开发者根据自己的知识判断并引导AI进行调整，才能得到最符合业务需求的方案。
但实习生无法做到这一点。他们以“完成任务”为目标，像开着一辆搭载天顶星引擎的顶级跑车却蒙着眼睛。成熟的程序员能精准操控，快速稳定到达目的地；而实习生只关心是否到达，完全不理会是否剐蹭护栏、是否干扰其他车辆、是否压上了人行道——要么没发现，要么发现了也不懂其中的风险。
这种情况非常危险。
这种“猴子配枪”式的开发模式主要体现在两类问题上：
1、野蛮生长的DEMO阶段
项目初期，在完整的前后端架构尚未搭建完成时，每个插件都由实习生采用vibe coding方式从零开发，技术栈五花八门。有的后端用fastapi加前端千行HTML，有的纯前端react且密钥硬编码在代码里。架构搭建完成后，花了将近半周时间才将所有插件功能迁移整合。而前端的视觉风格和样式逻辑至今仍未完全统一。这不能全怪实习生，只能说vibe coding的快速原型方式存在天然缺陷。
2、对项目约束的随意修改
对于有经验的开发者来说，项目中有很多不可触碰的红线。当模型生成代码试图越界时，开发者能主动纠正（这通常意味着模型开始出错）。但实习生缺乏这种警惕性。以下是在代码评审中发现的典型问题：
- 将 .claude 目录加入 .gitignore，导致新的 skill 文件无法提交
- 损坏 .gitignore 文件，导致其他人将敏感文件误提交到 git 仓库
- 修改公共 manifest 文件，指向自己的私有服务器，导致其他人使用时直接报错
- 临时关闭 eslint 校验后忘记重新开启
- 每次本地启动开发都需要重新申请开发许可（正常情况下只需申请一次即可永久生效，原因至今未查明）
- ...
说实话，这些问题本身不算严重，但排查起来相当困难，因为开发人员往往下意识会排除这些“低级错误”的可能性。好在几位实习生后来不断进步，现在已经很少再犯这类离奇的错误了。
无法自动化测试 = 模型幻觉的温床
除了实习生的问题，纯AI编程项目对自动化测试的依赖缺失也带来了诸多麻烦。
本项目恰好是Office插件开发。做过Office插件的同学都知道，在Web端测试O365插件需要一套相对复杂的操作流程，Word和Outlook的测试方式还不相同。桌面端测试更加繁琐。加上对Office环境的强依赖，导致根本无法使用成熟的Web应用测试方案（如Playwright）进行自动化测试。
更准确地说，目前几乎没有针对Office插件的有效自动化测试方案。这导致开发过程中实习生需要手动截图并向模型描述异常情况，无法利用TDD（测试驱动开发）的自动纠错循环，模型的开发效率大幅下降。同时没有回归测试，频繁出现“修好A功能却搞坏B功能”的情况。实际上我们花了将近一半时间在手动测试上——依赖QA团队人工回归，再用模型通过vibe coding修补问题。而通过Web访问的管理后台几乎没有出现过bug。
前端 - 样式统一始终是个难题
从产品化角度出发，三个Office插件端的UI风格必须保持一致。最初的计划是：
- 让一名有前端经验的实习生使用pencil工具生成三款插件的设计稿
- 与交付团队保持密切沟通，确定最终设计方案
- 让AI根据设计稿生成一套统一的UI组件库和agent skill
- 三位实习生分别用AI重构各自负责的插件前端
然而实际执行严重超期。现在复盘来看，每个环节都遇到了预料之外的问题：
审美的主观性导致决策拖延
项目群里有好几位“老板”，每个人都提出了自己的设计想法。但没有明确的最终决策人，每次沟通的结果都是“你用AI再完善一下”。仅设计稿阶段就消耗了大量时间。
AI生成的代码与设计稿严重不符
pencil生成的设计稿虽然包含了很多CSS样式，但项目选用的是antd组件库。AI生成的组件默认样式与设计稿样式产生了大量冲突，而AI难以有效定位和排查问题。导致生成的组件几乎无法直接使用。这是整个项目延误风险最高的环节，最终不得不强行介入，暂停实习生的组件开发工作，由产品组的前端同事协助迁移部分组件才勉强完成。
demo阶段遗留的大量脏代码严重拖慢了重构进度
纯HTML加几千行CSS、React原生组件加LESS样式、antd组件加CSS modules样式……每个插件端的前端方案完全不同，导致旧代码几乎无法复用。最终只能全部重写，又花了将近一天时间才将到处是bug的功能修复到可用状态。
后端 - 问题最少，但隐患最大
由于后端的架构设计和核心模块实现由我亲自负责，这一部分反而问题最少。包括不同插件后端的迁移、后续几次中等规模的重写（国际化方案统一、横向扩容改造等）都快速完成。
现在回头看，后端相比百花齐放的前端已经总结出了最佳实践：采用三层架构加单元测试，基本能保证AI开发的效率和质量。加上prisma一把梭解决了数据库层面需求，vercel的ai sdk一把梭解决了模型相关需求。
然而，对后端的担忧反而是最大的。prisma使用起来非常简洁快速，容易让实习生对数据库开发的严肃性认识不足——迁移文件、数据库事务等，稍不注意就可能导致数据误删或系统死锁。目前除了严格要求agent在开发数据库相关内容时必须特别注意之外，还没有找到更好的规避方法。
写在最后
这篇文章并非反对AI编程。相反，尽管过程中遇到了各种问题，最终的实际效果依然令人惊艳。事后复盘发现，这类规模的功能如果按照传统开发模式，至少需要两名后端加三名前端开发一个月才能进入提测阶段。但若是要用实习生来降低开发成本，那么团队建设就必须非常慎重。
另外，AI时代对项目前期设计的要求提升了好几个档次，这对架构者的能力提出了更高的挑战。如果前期让AI生成了一大堆劣质代码，后期就需要花费数倍精力偿还技术债务。如果这篇文章只能传递一句话，那就是：
永远不要期望能将一个vibe coding产生的demo直接完善成商业产品。验证可行性后就果断丢弃，然后在一个设计完善、架构优秀的全新基础上重新开发。
