物界前沿当AI替你把代码写完了，架构师还剩下什么活？
先说结论：这篇关于Spec Growth Engine的论文，方向值得关注，落地才是关键。它试图解决的是我最近半年最头疼的问题，—AI写代码的速度上来了，但项目架构却在加速腐烂。
团队里现在十个工程师，八个天天用AI辅助写码。以前一个模块要写三天，现在半天搞定。听起来是好事对吧？但问题出在验收的时候。代码能跑，能过测试，可能架构已经乱成一锅粥。上周五我review一个新功能的PR，看到一段逻辑，绕了四层抽象，里面还硬塞了两个设计模式进去，问工程师为什么这么写，他说「AI给的方案，看着挺合理就用了」。
合理个屁。那是它把未来三个迭代的需求都提前设计进去了。
这篇论文的核心思路我很认同：给AI一个「规格锚点」，让它生成的代码时刻对着一份维护中的spec来写，同时反向要求spec跟着代码更新。简单说，就是把过去那种写完就吃灰的设计文档，变成一套活着的、机器可读的约束系统。哪个模块应该长什么样，依赖关系是什么，边界在哪里，AI每次改动前都先过一遍这个锚。
但这里有个问题，这套机制放到真实工程环境里，能不能跑起来，我不太乐观。
我们之前试过类似的方案，出发点是抑制AI「过度设计」的问题。M2 Max跑本地推理，Claude辅助写核心模块，给它的约束够清楚了，产出的代码结构还是会漂。AI擅长的是「看起来对」，不是「确实对」。它会把事情做得既多又杂，而不是恰好。
那个Dangerous Convenience的说法我特别有感触：AI让复杂架构模式变得触手可及，却不教你什么时候不该用。我们的代码库里已经出现「模式堆叠」的迹象——单例套工厂再套观察者，读起来累死，改起来要命。
Spec Growth Engine把「漂移强制」作为核心机制，这方向肯定是对的。但落地层面有几个坎：
- spec本身的维护成本。谁写？怎么写？写多细？太粗没用，太细就变成用自然语言写代码了
- 强约束和AI灵活性的矛盾。AI生成代码本来就是概率性的，你用一个确定性框架去框它，产出会不会变得僵化
- 这玩意和现有CI/CD、代码评审流程怎么融合，得推倒重来还是增量兼容
还有一件事比论文本身更值得琢磨。它实际是把软件开发的「非正式知识」，比如架构决策、设计意图、为什么不用另一种方案，全部显式化、结构化、变成工程的一部分。这和我们之前在Mac上跑AI聊到的问题其实是同一个底层：工具能不能把隐性知识变成工程资产。技术上可行，但组织上难。让工程师养成维护spec的习惯，比让AI遵守spec难十倍。
我们准备在供应链预测模型那个项目里试一下这套思路的轻量版，用文档即代码的方式跑两周看看。不一定按论文的实现来，但「代码必须贴着spec长」这个原则，我认同。
往后看，真正的分水岭可能是：那些能把架构约束做成工程基础设施的团队，和靠工程师自觉维持秩序的团队，一年后的代码库会变成两种完全不同的生物。哪一种是想要的，现在就得做决定。
你那边AI写出来的代码，架构开始乱了吗？
本文编译自 Hacker News，原文：[2606.27045] The Spec Growth Engine: Spec-Anchored, Code-Coupled, Drift-Enforced Architecture for AI-Assisted Software Development
版权归原作者所有，本文为基于公开报道的编译与独立分析。
