AI时代全栈开发困境：前端写后端接口，为什么后端同学让我补架构课

今天在群里看到一个非常典型的问题，拿出来和大家聊聊。

一位同学向我咨询了这么一件事：
他现在在一家做 Agent 的公司，职位是全栈工程师。

他坦言自己是前端出身，但这并不意味着他只写 CSS 。他领到的是完整的任务，里面该写前端写前端，该写接口写接口。 AI 能搞定的大部分代码都交给 AI ，自己主要负责把关。

听起来挺爽的，对吧？ AI 咔咔写代码，效率直接拉满。直到有一天，他写了一个涉及多表关联的接口，功能上能跑通，逻辑也对，于是交给后端同学做 Code Review （CR）。后端同学看了半天，丢过来一句话：“你这已经涉及到核心代码了，得补充一下架构方面的能力。 CR 的时候你可不能告诉我，这代码是跟‘神’对话写出来的。”

他当时就愣了一下。所谓的“神对话”，指的就是跟 AI 交流生成代码。我们经常讲，AI 时代不用什么都自己从头学了，让 AI 帮你写就行了。这事儿到底该怎么看？

简单的 CRUD ，AI 生成的代码拿过来改吧改吧确实就能跑。但一旦涉及到表结构设计、关联关系、索引优化这些问题，麻烦就来了——AI 确实能给你跑出一个看似正确的结果，但它产出的东西不一定符合你们团队长久以来形成的规范。

后端同学这句话，背后其实藏着两层意思：
第一层是纯粹的技术层面：多表关联不是写个 SQL 拼字符串那么简单。ER 图该如何设计、事务的边界在哪里、性能上有什么潜在风险，这些东西 AI 可以帮你生成代码，但架构的合理性这个锅，AI 不能替你背。

对于这件事，我的看法是这样的：

1、在没有生成式 AI 之前，跨角色、跨岗位做开发的难度要大得多。现在的 AI 编程极大地抹平了入门的门槛。你一个前端去写后端逻辑，甚至都不用去深入理解那些复杂的前端框架。

2、但是，那些过去专业领域的积累，绝对是加分项。你踩过的坑，就是别人不知道的经验盲区。这个时候，经验丰富的老司机反而更有竞争力，因为你在做的事情是提升产出的上限。

3、这个非常具体的 context ，背后折射出的其实是一种团队的惯性思维。比如，后端会习惯性地教育前端同学要注意什么， DBA 会教育后端同学，哪些“捞过界”的 SQL 必须优化。知识是要学的，但学习的思路可能要变一变了。

4、关于跨领域学习，它不再是过去那种“先学完再干”的纯学习模式。你先把自己变成他，学透彻了再来做项目？根本来不及，而且知识永远也学不完。现在更有效的方式是在实战过程中学习：你虽然不知道确切答案，但你知道如何向人工智能精准提问，然后学会如何评估各种方案的得失利弊。能做到这一点，就已经比现在强很多了。

话说回来，你的团队里有这种跨角色写代码的同事吗？你们在 CR 的时候，都遇到过哪些因为 AI 大量产出代码而引发的新问题？现在的 CR 流程，你们又是怎么做的呢？