架构：让实现可以自然发生

本页整理接口边界、模块耦合和 AI 过度工程化相关讨论。它不主张用某一种固定架构解决所有项目。

人先掌握关键边界

在较早的 AI 编程实践里，他倾向于先准备重要接口、必要文档和主要测试，再让 AI 逐步实现并接入已有系统。

这背后的关注点不是谁敲代码，而是：目标与边界是否足够清楚，让实现可以被分解、验证和替换。

不同项目的复杂度不只是行数

一组相对独立的控件、接口和平台移植模块，与一个所有决策都围绕同一核心功能的编译器，可能具有完全不同的上下文需求。

在 2026 年的实践描述中，同一模型在 GacUI 和 Workflow 相关任务上的表现存在差异。后者决策关联更密集，容易出现改了这一处却遗漏另一处的问题。

因此，不能只从一个项目的成功，推导出模型能同样处理另一个同等行数的项目。

过度工程化是诊断线索

如果为了做一个小功能，AI 增加大量重复逻辑、奇怪的继承或额外机制，就值得停下来查原因。

可能是模型没有理解现有能力，也可能是架构缺了一层必要支持。继续沿着错误边界修补，会把问题藏进越来越多的实现细节里。

这种观察不是“看着不喜欢就否决”的通行证。有效判断依赖对代码库、原始需求和现有接口的理解。

正交与可组合性

当函数、接口和工具之间的责任划分清楚，验证结果更容易复用，修改的影响也更容易隔离。模型不需要同时记住所有细节，就能在一个可靠边界内完成任务。

这也解释了为什么工具、代码生成和项目文档可以成为 AI 能力的放大器：把某些复杂操作封装成可重复使用的能力，而不是每次重新猜测。

用这页评审一个方案

问三个问题：新增能力落在哪个边界内？为什么现有结构不能自然表达它？如果实现不断绕路，需要改的是 prompt、工具，还是架构？

如果证据说明问题来自设计，应允许重新设计或推倒重做，而不是只衡量已经投入了多少时间。