一开始，大家都觉得 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 生成代码。

产品图能说明用户看到什么，但它不能完整说明系统之间怎么通信。它不会天然定义请求参数、响应字段、错误码、状态流转、边界条件和异常处理。

于是后端 AI 根据产品图猜了一套服务模型，前端 AI 根据产品图猜了一套页面交互。

两个 AI 都可能在局部看起来合理，但放到一起就不一定对。

创业团队最容易低估的，就是这个“共同契约”的重要性。

没有契约时，大家以为自己在做同一个系统，其实是在各自实现自己理解中的系统。

代码太多不是问题，没人拥有理解才是问题

四万行代码本身不是问题。

如果这四万行代码是团队一步步设计、review、测试、沉淀出来的，它只是规模变大了。

真正的问题是：这四万行代码增长得比团队理解它的速度更快。

当团队不再清楚模块边界，不清楚数据流，不清楚某个字段为什么存在，不清楚某段逻辑影响哪些地方时，代码就会从资产变成负担。

这时候最可怕的不是“不会改”，而是“知道要改哪里，但不敢改”。

因为没有安全感。

人敢改代码，靠的不是胆子大，而是有几个东西托底：

• 知道模块边界在哪里
• 知道接口契约是什么
• 知道改动会影响哪些调用方
• 知道测试能不能及时发现问题
• 知道出错后怎么回滚和定位

如果这些都没有，继续让 AI 自由修改，只会让系统变得更不可预测。

创业团队该怎么止血

我觉得解决方式不是停用 AI，而是把 AI 从“自由生成代码的人”，重新放回“受约束的工程助手”。

对于已经开始混乱的创业团队，可以先做几件事。

1. 暂停自由发挥式修改

不要再把“帮我修一下这个流程”“帮我把前后端联调好”这种大而模糊的问题直接丢给 AI。

每次让 AI 改代码前，先限定范围：

• 只允许改哪些文件
• 不能碰哪些模块
• 目标行为是什么
• 输入输出是什么
• 改完后怎么验证

AI 依然可以改，但不能让它在整个项目里自由发挥。

2. 先让 AI 画地图，而不是继续改代码

现在更重要的不是马上多写代码，而是重新理解已有代码。

可以让 AI 帮团队梳理：

• 项目模块结构
• 前后端接口调用链
• 核心业务流程
• 关键数据结构
• 状态流转
• 哪些代码是核心逻辑，哪些只是生成出来的辅助代码

人不需要逐行读完四万行，但必须重新掌握系统地图。

AI 不只应该用来写代码，也应该用来帮助团队重新理解代码。

3. 建立唯一接口契约

前后端不能再各自根据产品图理解系统。

至少要有一份大家都认的接口契约，哪怕一开始只是 Markdown，也比散落在聊天窗口里强。

这份契约要写清楚：

• 请求路径
• 请求参数
• 响应字段
• 字段类型
• 必填和可选
• 枚举值
• 错误码
• 示例 request 和 response

更理想的是用 OpenAPI、Swagger、Apifox、Postman collection 这类工具管理。

核心原则是：

前端和后端都只能基于同一份契约让 AI 写代码。

4. 给关键流程加最小测试护栏

创业团队不一定有时间补完整测试，但至少要给最关键的 3 到 5 条流程加护栏。

比如：

• 用户注册 / 登录
• 创建核心业务对象
• 提交流程
• 查询列表和详情
• 状态变更

这些可以是冒烟测试、接口测试、契约测试，不一定一开始就追求高覆盖率。

目的不是为了好看，而是为了让团队敢改。

让人敢改代码的，不是更强的 AI，而是更清楚的边界、更稳定的契约和更快的反馈。

5. 把反复告诉 AI 的东西沉淀下来

如果一个规则需要反复告诉 AI 三次，它就不应该继续只存在于聊天窗口里。

它应该变成：

• README
• 接口文档
• schema
• 测试用例
• 项目级 AI 规则
• 模块说明
• PR 描述模板

否则团队只是在训练每个人更会 prompt，而不是让系统变得更可维护。

AI 对话不是项目记忆。项目真正的记忆，应该存在于代码、文档、测试和契约里。

最后的反思

这次经历让我意识到，AI 开发真正的风险，不是 AI 写不出代码，而是它太能写代码了。

它让代码增长速度超过了团队理解速度。

对于创业团队来说，AI 当然应该用。不用 AI，很多 MVP 可能根本做不出来。但用 AI 的方式必须升级。

不能让每个人都在自己的 AI 对话里推进项目。

不能让产品图替代接口契约。

不能让 prompt 替代团队共识。

不能让“能跑”替代“敢改”。

AI 应该放大开发者的能力，而不是让开发者退化成上下文搬运工。

真正健康的 AI 开发，不是让 AI 接管整个项目，而是让人类重新掌握边界、契约、验证和判断。

一句话总结就是：

AI 可以帮我们更快写代码，但团队必须更认真地管理理解。