创业团队用 AI 开发失控后，怎么止血？
最近我们在一次创业项目开发中，遇到了一个很典型的问题。 一开始，大家都觉得 AI 开发很香。 后端同学根据产品图，让 AI 快速生成了一套后台服务；前端同学也根据产品图，让 AI 写出了界面和交互。过去可能要花几周才能搭出来的 MVP，现在很快就能看到雏形。 这也是我一直觉得 AI 有价值的地方：它能让小团队快速补齐不熟悉的领域，能让一个人跨过前端、后端、交互、部署这些原本需要多人配合的边界。 对于创业团队来说，这种速度太有吸引力了。 但开发到后面，我们开始明显感觉不对劲。 前端拿着后端的接口手册，让 AI 去理解并修改页面逻辑；后端也根据自己的理解继续调整服务。看起来每个人都在推进，但大家对系统的理解并不一致。 前端理解的流程，和后端设计的流程对不上。 前端传的参数，和后端期望的参数不一致。 产品图里没有明确表达的状态，被前后端的 AI 分别脑补成了不同的实现。 更麻烦的是，代码量很快膨胀到了四万多行。 到了这个阶段，人已经不太愿意从头读代码了。不是完全看不懂，而是阅读和修改的成本变得很高。就算知道问题大概在哪里，也不敢轻易改，因为不知道改了这里，会不会影响到别的地方。 于是我们进入了一个很危险的循环： 发现问题，描述给 AI。 AI 改一版，继续跑。 又出现新问题，再描述给 AI。 AI 再改一版。 一开始，AI 是开发者的助手。后来，AI 成了代码的主要作者。再后来，人想改代码时，发现自己也只能继续通过 AI 去改 AI 写出来的代码。 这时候，人就有点像上下文搬运工。 产品的问题，要转述给 AI。 接口的问题，要转述给 AI。 前端的报错，要转述给 AI。 后端的文档，也要转述给 AI。 每个人都很忙，但忙的不是在建立系统理解，而是在不同的 AI 对话、代码、文档、报错之间搬运上下文。 我并不反对 AI 开发。恰恰相反，我依然认为 AI 是趋势。AI 能帮助创业团队更快做出 MVP，能让开发者进入自己原本不熟悉的领域。 但这次经历让我意识到一个问题： AI 能帮我们写出更多代码，但不会自动帮团队形成共同理解。 如果没有共同理解，代码增长得越快，团队失控得也越快。 问题不在 AI，而在没有工程护栏 这次最明显的问题，是前端和后端都基于产品图让 AI 生成代码。 产品图能说明用户看到什么，但它不能完整说明系统之间怎么通信。它不会天然定义请求参数、响应字段、错误码、状态流转、边界条件和异常处理。 ...