如果你打算把大脑直接交给 AI 托管，那你可能很快就会发现自己成了一个只会点「Accept」的高级打字员

很多人觉得现在有了 Cursor 或 Claude 3.5，写代码就变成了「描述需求 → 生成代码 → 运行」，这流程看起来极其丝滑。但说实话，如果你还是个初学者，或者习惯于这种「喂饭式」开发，你其实是在用最快速度加速自己的平庸。

我记得早几年折腾代码的时候，最典型的状态就是「Frankenstein 模式」：在 Stack Overflow 搜三个不同的答案，把代码碎片像补丁一样缝在一起，然后在里面塞进一堆乱七八糟的业务逻辑。这种方式虽然低效得令人发指，但它有个不可替代的优点：它强迫你面对报错，强迫你在无数次 undefined is not a function 中思考为什么。

现在 AI 时代，这种「阵痛期」被极大地压缩了。如果你不刻意地去「学习如何学习」，你很快会掉进一个陷阱：代码跑通了，但你完全不知道它为什么能跑通。

最让我意识到危机感的一点是：AI 其实根本不能「思考」，它只是一个极其强大的「模式补全机器」。如果你自己没搞清楚业务逻辑，没想明白数据流向，你给 AI 的 Prompt 质量就决定了它给你甩回来的垃圾程度。你问得模糊，它给的答案就敷衍；你根本不懂架构，它给你写一个 500 行的巨型函数，你可能还觉得它效率高。

所以现在的核心竞争力不再是「能写出这段代码」，而是「能定义这个问题」。

为了不让自己变成 AI 的附属品，我最近在死磕架构意识。说白了，架构就是决定代码在哪个地方出生，在哪个地方死去。如果你不懂架构，你让 AI 写出来的东西就是一堆难以维护的屎山，只不过这堆屎山是 AI 帮你堆得很快而已。

如果你也觉得现在写代码越来越像在「抽奖」，建议强迫自己去啃一下这些概念，而不是直接问 AI 「怎么写这个功能」：

• Domain-Driven Design (DDD)： 这玩意儿最核心的不是那些复杂的术语，而是「通用语言」的概念。你要确保代码里的类名、方法名和业务专家的描述是一致的。当你能用 DDD 的思维去拆分 Bounded Context（限界上下文）时，你给 AI 的指令会从「帮我写个用户模块」变成「在用户上下文的领域服务中实现这个校验逻辑」，这时候 AI 给出的代码质量会有质的飞跃。
• Clean Architecture： 强制把业务逻辑从框架中剥离出来。如果你发现你的业务逻辑里到处是 @SpringBoot 或者 useEffect 之类的框架特性，那就是架构崩了。试着让 AI 帮你重构，但你要能判断它是否真的实现了依赖反转（DIP）。

Layer:
  - Domain: 纯业务逻辑，禁止依赖任何外部库
  - Application: 处理用例，调用领域层
  - Infrastructure: 数据库持久化，API调用

然后我在 Prompt 里要求它：请严格按照 architecture.md 的分层定义实现登录功能，领域层必须保持纯净。

这样出来的代码，才是可维护的，而不是那种把数据库查询和 UI 渲染写在同一个文件里的「AI 缝合怪」。

说到底，AI 是一个放大器。如果你懂架构，它能让你一个人顶一个团队；如果你不懂，它只会让你在最短的时间内写出最难维护的代码。不要让 AI 替你思考，你要把它当成一个执行力极强但毫无主见的实习生，而你必须是那个掌控全局的架构师。