大家好啊我是 hoho。
先声明没有标题党啊，看图，代码总计 84917 行。
这个任务是怎么来的已经不重要了，总之某一天当我准备下班的时候老板突然叫住我，说有个大任务。某人 vibe coding 出了一个 outlook 插件的 demo，大老板看了非常激动，打算把这个东西产品化、标准化。你用 AI 看看能不能搞定，咱们组还有三个新来的实习生，都分给你来用。上面希望一周就能出 demo 给客户演示。
但是老板的命令就是圣旨啊，没办法只能开干。
先来看看实现了什么效果：
- 多端统一的架构设计（支持 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，key 写死在代码里的。
在项目架构搭建完成后，花了将近半周的时间才将所有插件的功能都迁移进来。而前端的视觉风格和样式逻辑直到今天都没有完全统一。
这不能全怪实习生，只能说 vibe coding 害死人。
2、对于项目约束的随意魔改
对于有经验的开发者来说，项目里会有很多红线，当模型准备尝试越过红线时，开发者会主动纠正（这基本意味着模型开始跑偏了）。但是对没有经验的实习生来说很难。列举几个我在 review 中遇到的问题：
- 把 .claude 目录加入 .gitignore，导致新的 skill 都无法提交
- 把 .gitignore 搞坏，导致其他人把自己的敏感文件提交到 git 上了
- 把公用的 manifest 文件修改指向自己的代理服务器，导致其他人一用就报错
- 把 eslint 校验暂时关闭后忘记打开
- 每次本地启动开发都要申请一个开发许可（正常情况下申请一次就永久生效了，至今没找到原因）
- ...
说实话，这种都不算什么大问题，但是排查起来还是有点难度的，因为你会下意识把这种"WTF"原因给排除掉。
好在我这几个实习生比较争气，现在已经不会犯一些比较抽象的错误了。
无法自动化测试 == 模型幻觉的温床
除了实习生的问题之外，纯 ai 编程的项目对自动化测试的依赖程度也导致了很多问题。
我这个项目又恰好是做的 office 插件。做过 office 插件的同学都知道，想要在 web 端测试 o365 插件需要来一套不算简单的操作体操，word 和 outlook 还不一样。而桌面端的测试则更加麻烦。再加上对 office 环境的依赖，导致完全没有办法使用测试 web app 的成熟方案（例如 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 Coding，相反，哪怕中间遇到了各种各样的问题，最终的实际效果还是非常令人惊讶的，在我们的事后复盘里，这个体量的功能至少需要两后端+三前端开发一个月才能开发完功能进入提测阶段。
但是如果真要进行团队建设的话，想要通过实习生来降低开发成本就一定要慎重了。
另外，AI 时代对于项目的前期设计的要求提升了不止一点，这对于架构者的能力提出了更高的要求。如果前期让 ai 生成了一堆屎出来，那么后面你就需要花费数倍的精力来偿还技术债。如果本文只能告诉你一句话的话，那就是：
永远不要期望能把一个 vibe coding 的 demo 完善成商业产品，验证可行性之后就把它丢进垃圾桶，然后在一个完善优秀的全新架构上重新开发。