AI 时代写代码：架构这事，比以前更值钱了

软件开发这行，这两年变化是真快。一年前，大家还在讨论 AI 写代码靠不靠谱；现在？AI 编程助手早就成了标配。

但最近我想明白一件事：AI 能不能发挥出实力，很大程度上取决于代码库本身的质量。 你给 AI 一堆乱七八糟的服务、循环依赖、起名全靠猜的代码，它光理解你在干啥就要半天。但你要是给 AI 一个结构清晰、上下文一目了然的代码库——不管是 AI 还是真人，用起来都顺手。

说到这儿，就不得不提一个这两年在圈子里悄悄火起来的架构思路：Polylith。说实话，这玩意儿理解了之后会觉得"怎么早没想到"。

Polylith 是什么？

简单说：Polylith 追求的是微服务的模块化优势，加上单体仓库的简单管理。你既能享受服务隔离、边界清晰的好处，又不用维护一堆乱七八糟的代码仓库。

核心理念是把代码拆成积木块——就像乐高一样，有的小块专注一件事，有的大块负责组合功能，但都设计成能方便地拼在一起。在 Polylith 里，这些积木叫 brick，分两种：

• Component：应用的核心，业务逻辑、功能实现都放这儿
• Base：入口点，比如 API 服务、命令行工具这类，理想情况下保持轻薄，把活儿派给 component

这种划分的好处是，逼着你提前想清楚边界。Base 不需要知道 component 内部怎么实现的，调用就行。这种干净利落的关系，对人和对 AI 来说都好理解。

为什么 AI 特别吃这套架构？

这才是有意思的地方。

传统微服务架构确实强，但带来的复杂度连最聪明的 AI 都头疼：

• 代码散落在好几个仓库里
• 不同服务间逻辑重复
• 公共代码抽成库，又得多管几个仓库
• 依赖版本互相扯皮

AI 想改点东西？先在几个仓库之间跳来跳去，摸清功能在哪儿、依赖关系是什么，搞清楚这些才能开始写代码。还没动手，认知负担已经拉满了。

Polylith 的解法很直接：所有东西放一个仓库。上下文随时在手边，AI 不需要在仓库之间来回横跳，整个项目一眼看穿。这不只是用着方便，简直是给 AI 的效率加了buff。

工具链的支持

Polylith 还有一个加分项：配套工具做得不错。好用的工具能自动帮你守住架构规矩——警告边界被踩、揪出循环依赖、让代码库保持老实。

对 Python 开发者来说，工具支持主流的包管理工具，uv、poetry、pdm、pixi 都能用。还有专门给 AI 助手准备的 skill 支持，相当于手把手教 AI 怎么按 Polylith 的规矩干活。

这对 prompt 效率也是实打实的提升。AI 通过工具理解了架构约定，你就不用花一堆 token 解释上下文，剩下的 token 都能用来生成有用的代码。

有些东西是不会变的

好消息是：好的架构原则，不管谁来读代码——人还是 AI——都是香的。

简单比复杂强。边界清晰比关系混乱强。上下文完整比残缺不全强。这些道理 AI 时代之前就成立，之后也不会过时。只不过现在有了新动力——因为把这些做好，受益的不只是你自己，还有你的 AI 搭档。

回到本质

我们正在进入一个人和 AI 一起写代码的时代。这个变化让架构决策变得更重要了。以前架构主要影响开发体验，现在还得加上AI 体验。

Polylith 不是唯一的答案，但确实是个有意思的思路。它在人和 AI 这两边都照顾到了——通过强调简单和上下文完整，让代码库既让人用着舒服，也让 AI 更容易上手。

如果你正在开新项目，或者在考虑重构老项目，不妨想想这件事。我们选什么工具、做什么架构决策，会直接影响 AI 助手能帮我们多少。

AI 时代不是"即将到来"，是已经在这儿了。问题是——我们的架构准备好迎接它了吗？

你们在用 AI 编程助手的时候，发现哪些架构模式特别顺手？欢迎留言聊聊——挺好奇大家都在怎么应对这个转变的。