【摘要】MIT提出WYSIWID架构，通过“概念”单元与“同步契约”机制，为LLM编码提供结构化约束，旨在解决增量开发中的功能回归与系统复杂度失控问题。

引言

大型语言模型（LLM）正以前所未有的深度渗透到软件开发的全生命周期。它不再仅仅是代码补全或语法检查的辅助工具，而是越来越多地承担起功能实现、代码重构乃至系统设计的角色。然而，这股浪潮之下，一股技术焦虑也在悄然蔓延。开发者社区中，关于LLM“好心办坏事”的抱怨不绝于耳。一个看似简单的功能追加，经由LLM之手，却可能演变为一场灾难性的“代码地震”，导致既有功能大面积失效。

这种现象的根源，并非LLM本身的技术缺陷，而是其工作模式与现代软件工程实践之间存在的深刻矛盾。现有软件系统，尤其是历经多年迭代的遗留系统，其内部往往充斥着模糊的模块边界、隐晦的数据依赖和复杂的调用链路。人类开发者尚且需要依赖大量的文档、经验和沟通才能小心翼翼地进行维护，而缺乏全局上下文理解能力的LLM，在这样的“代码沼泽”中进行外科手术式的精准修改，几乎是一项不可能完成的任务。其结果，便是我们常说的**“随意编码”**——变更范围不可控，回归风险常态化。

面对这一困境，业界的主流应对策略多集中在改进LLM本身，例如通过更精细的Prompt工程、引入代码库作为上下文、或发展多智能体协作。这些方法虽有一定效果，但终究是“在螺蛳壳里做道场”，未能触及问题的核心。麻省理工学院（MIT）的Eagon Meng与Daniel Jackson团队另辟蹊径，他们认为，与其不断提升LLM的“驾驶技术”，不如为它修建一条边界清晰、规则明确的“高速公路”。

这便是其在SPLASH 2025会议上发表的论文《What You See Is What It Does: A Structural Pattern for Legible Software》中提出的核心思想，一种全新的软件架构范式——WYSIWID（What You See Is What It Does）。该架构通过引入**“概念”（Concepts）和“同步契约”（Synchronization Contracts）**两大核心构件，试图从根本上重塑软件的结构，使其内在行为与外在结构高度一致，从而为人类与AI的协同开发提供一个稳固、透明且可预测的基石。这不仅是对LLM编码挑战的回应，更是对软件可读性、可维护性这一经典命题的深刻反思与前瞻性探索。

❖ 一、LLM编码的困境，从“助手”到“刺客”

在引入WYSIWID架构之前，我们必须深刻理解当前LLM在软件开发中遭遇的现实瓶颈。这些问题并非孤立的技术点，而是相互关联，共同构成了一个阻碍LLM效能进一步释放的系统性障碍。

1.1 增量开发的“不可能三角”

软件的生命力在于持续演进，而增量开发是其基本模式。理想的增量开发应同时满足三个关键属性。

  • 增量性（Incrementality）。每次变更都应是小步、受控的，对系统的影响范围可预测。

  • 完整性（Completeness）。新增功能应能正确、完整地实现，并与系统其他部分和谐共存。

  • 透明性（Transparency）。变更的逻辑、影响路径应清晰可见，易于理解和审查。

然而，在模块化不足的系统中，这三者往往构成一个“不可能三角”。为了保证功能的完整性，LLM可能需要修改多个模块，破坏了增量性。为了追求小步快跑，LLM可能只进行局部修改，又牺牲了功能的完整性，留下技术债。而无论哪种情况，模糊的系统结构都让变更过程缺乏透明性，代码审查者如同在雾中探路。

LLM的介入加剧了这一矛盾。由于缺乏对系统设计意图和长期演进路径的理解，LLM更倾向于采用“全量重写”或“打补丁”的策略，而非结构化的增量演进。这使得**“改一处、动全身”**的风险被显著放大。

1.2 回归风险的常态化

回归（Regression），即对软件的修改导致原有功能出现缺陷，是软件维护中的头号敌人。LLM在生成代码时，其犯下的错误类型与人类开发者有显著不同。

错误类型

人类开发者特点

LLM开发者特点

危害性

语法错误

较少，易被IDE和编译器发现

极少，模型本身基于语法结构训练

低

逻辑错误

常见，但通常局限于当前任务上下文

常见，尤其在复杂或边界条件下

中

语义错误

相对较少，依赖经验和领域知识

高发，因缺乏全局上下文和设计意图理解

高

语义错误是LLM编码的重灾区。例如，LLM可能为了实现一个新功能，修改了一个被多个模块共享的公共函数，却未意识到该修改对其他调用方造成的副作用。这种错误在代码层面可能完全合法，甚至通过了单元测试，但却在系统集成层面埋下了定时炸弹。

当开发者频繁使用LLM进行代码添加与修复时，由于修改范围的不可控性，这种隐藏的语义破坏会不断累积。最终导致回归测试的成本急剧上升，开发团队的信心受到严重打击。LLM此时的角色，已从一个高效的“编程助手”，悄然转变为一个难以捉摸的“代码刺客”。

1.3 隐性复杂度的螺旋上升

系统的复杂度分为两种。

  • 本质复杂度（Essential Complexity）。由业务需求本身决定，无法消除。

  • 偶然复杂度（Accidental Complexity）。由不佳的技术选型、架构设计或实现方式引入，可以也应该被管理和消除。

LLM在缺乏良好架构约束的情况下，其编码行为极易引入偶然复杂度。它可能为了走捷径，创建了不合理的模块依赖；为了修复一个bug，引入了新的全局状态；为了实现一个功能，复制粘贴了大量冗余代码。

这些行为的直接后果是，代码结构与系统行为之间的映射关系变得愈发模糊。开发者（无论是人类还是后续的AI）越来越难以通过阅读代码来准确推断其运行时行为。系统的认知负荷不断增加，维护成本呈指数级增长，最终陷入“修改-破坏-修复”的恶性循环，直至系统僵化，无法再进行有效迭代。

❖ 二、WYSIWID架构，一种结构化的解法

面对上述困境，WYSIWID架构提供了一套釜底抽薪的解决方案。它不试图去“教会”LLM如何理解复杂的遗留系统，而是从根本上重塑系统结构，使其变得简单、透明，让正确的操作变得容易，错误的操作变得困难。其核心思想可以概括为**“结构即行为”**。

2.1 核心基石 “概念”（Concepts）

WYSIWID架构的原子单元是**“概念”**。一个“概念”是一个高内聚的功能模块，它封装了与某个特定用户价值直接相关的全部逻辑、数据和状态。

  • 以用户价值为中心。“概念”的划分标准不是技术实现（如数据访问层、业务逻辑层），也不是通用的技术组件（如缓存、日志），而是用户能够直接感知和理解的功能单元。在社交应用的例子中，**“贴文”、“评论”、“好友关系”、“用户认证”**都是典型的“概念”。

  • 清晰的边界。每个“概念”都拥有明确的职责边界。与“贴文”相关的所有操作（发布、编辑、删除、查询）都应内聚在“贴文”概念内部。外部世界无法也无需知道其内部实现细节。

  • 彻底的解耦。“概念”之间不存在直接的编译时或运行时依赖。一个“概念”不能直接调用另一个“概念”的函数，也不能直接访问其数据。这种严格的隔离是WYSIWID架构与传统模块化或微服务架构的关键区别之一，它从源头上杜绝了复杂网状依赖的形成。

这种设计使得每个“概念”都成为一个独立的、可被完整理解和验证的单元。对于LLM而言，这意味着其工作范围被天然地限定在了一个“概念”的沙箱之内，极大地降低了产生意外副作用的风险。

2.2 交互的“语言” 同步契约（Synchronization Contracts）

既然“概念”之间彼此隔离，那么复杂的业务流程是如何实现的呢？答案是**“同步契约”**。

“同步契约”是一种声明式的规则，用于描述跨“概念”的交互逻辑。它不关心“如何”实现交互，只定义“什么”情况下，“哪些”概念之间需要发生“怎样”的同步。一个同步契约通常包含以下要素。

  • 触发条件（Triggers）。定义了契约被激活的事件。例如，“当一个‘贴文’概念的状态变为‘已删除’时”。

  • 参与方（Participants）。明确了哪些“概念”参与到这次同步中。例如，“‘贴文’概念和‘评论’概念”。

  • 约束与规则（Constraints & Rules）。定义了同步需要满足的行为和数据一致性规则。例如，“所有关联到该贴文的‘评论’概念实例，其状态必须同步更新为‘已隐藏’”。

  • 一致性模型（Consistency Model）。定义了同步的最终一致性或强一致性要求，以及可能的补偿机制。

所有这些契约都由一个上层的**“应用层”（Application Layer）**来统一编排和执行。应用层扮演着交通指挥的角色，它观察各个“概念”的状态变化，并根据预定义的同步契约来协调它们之间的行为。

下面是同步契约与其他常见交互模式的对比。

交互模式

耦合方式

依赖关系

透明性

可验证性

对LLM友好度

直接方法调用 (RPC)

紧耦合

调用方强依赖被调用方的接口和位置

低，调用链深且复杂

难，需端到端测试

低，易产生网状依赖

消息队列 (Events)

松耦合

生产者与消费者解耦，但依赖消息格式和主题

中，依赖关系隐式存在于订阅关系中

中，需验证消息契约

中，易产生事件风暴

同步契约 (WYSIWID)

协调式解耦

概念间无直接依赖，仅依赖应用层的契约定义

高，所有跨概念交互都显式声明

高，契约本身可被静态分析和形式化验证

高，提供清晰的生成目标

通过将交互逻辑从“概念”内部剥离出来，并以声明式的“契约”形式集中管理，WYSIWID架构极大地提升了系统的透明度和可预测性。

2.3 “所见即所做”的透明性原则

WYSIWID的最终目标是实现**“结构即行为”**。一个理想的WYSIWID系统，其高层行为完全可以从其“概念”布局和“同步契约”列表中推断出来。

  • 降低认知负荷。开发者无需深入每个模块的源代码，只需阅读高层的架构图（概念图+契约列表），就能快速理解系统的核心业务流程和数据流。

  • 简化影响分析。当需要修改或新增功能时，开发者可以清晰地看到该变更会触及哪些“概念”，激活哪些“同步契约”，从而精确评估其影响范围。

  • 赋能自动化工具。这种结构化的、声明式的信息，非常适合被自动化工具解析。无论是代码生成、测试用例生成，还是静态分析、安全审计，都可以在这个清晰的架构模型上高效进行。

对于LLM来说，这意味着它终于有了一张可以信赖的“地图”。它不再是在黑暗的森林中摸索，而是在一个标记清晰、规则明确的城市中执行任务。

❖ 三、架构实践，从理论到工程落地

理论的优雅需要通过工程实践来检验。WYSIWID架构并非空中楼阁，它提供了一套清晰的落地路径和工程化支撑体系。

3.1 实践范例 表情回应功能的演进

我们以论文中提到的社交应用为例，模拟如何在一个已有的、基于WYSIWID架构的系统中，增量添加一个**“表情回应”（Reactions）**功能。

3.1.1 步骤一 定义新概念与同步契约

首先，我们不会直接去修改“贴文”（Post）概念的代码。而是定义一个全新的**“表情回应”（Reaction）概念**。

  • Reaction 概念定义。

    • 数据。reactionId, postId, userId, emojiType。

    • 状态。active, deleted。

    • 行为。createReaction(), deleteReaction()。

接下来，我们定义与此功能相关的同步契约。这些契约由应用层的协调器来执行。

  • 契约1：贴文删除时级联删除表情。

    • 触发。Post 概念实例状态变为 deleted。

    • 参与方。Post, Reaction。

    • 规则。所有 postId 匹配的 Reaction 概念实例，状态必须同步更新为 deleted。

  • 契约2：用户注销时清理表情。

    • 触发。User 概念实例状态变为 deactivated。

    • 参与方。User, Reaction。

    • 规则。所有 userId 匹配的 Reaction 概念实例，状态必须同步更新为 deleted。

  • 契约3：新增表情时发送通知。

    • 触发。Reaction 概念实例被创建。

    • 参与方。Reaction, Notification, Post。

    • 规则。为 Post 的作者创建一个 Notification 概念实例，内容为“有人对您的贴文做出了表情回应”。

这些契约可以用一种声明式的语言（如YAML或专用DSL）来描述。LLM完全有能力根据自然语言需求，直接生成这些结构化的契约定义。

3.1.2 步骤二 生成实现与测试

在概念和契约定义清晰之后，LLM的任务就变得非常具体和受控。

  1. 生成 Reaction 概念的内部实现。这包括数据存储、API接口等。由于该概念是独立的，LLM无需关心其他模块，可以专注、高效地完成代码生成。

  2. 生成 Reaction 概念的单元测试。确保其内部逻辑的正确性。

  3. （可选）生成应用层协调器中执行契约的代码。或者，如果协调器是基于规则引擎的，那么只需将契约定义加载进去即可。

  4. 生成集成测试。针对每个同步契约，生成相应的测试用例，验证跨概念的交互是否符合预期。例如，创建一个测试，先创建一篇贴文和几个表情，然后删除该贴文，最后验证所有相关表情是否都已被正确清理。

整个过程，LLM的每一步操作都有明确的边界和清晰的目标，其输出结果的可预测性和可靠性得到了极大提升。

3.1.3 步骤三 工程化验证

WYSIWID架构的优势在与持续集成（CI）流程结合时能得到最大程度的发挥。我们可以在CI流水线中加入针对性的质量门禁。

下面是一个集成了WYSIWID验证的CI流程示例。

  • 概念独立性测试。静态分析工具可以检查代码，确保没有任何一个“概念”模块直接导入或调用了另一个“概念”模块。这是保证架构纯洁性的关键。

  • 契约一致性检查。工具可以解析所有的同步契约定义，并与代码实现进行比对，确保契约中声明的事件、状态和数据在代码中都有对应的实现。

  • 变更影响分析。当一个“概念”或“契约”被修改时，工具可以自动分析出所有可能受影响的下游概念和业务流程，并生成一份影响报告，提醒审查者和测试人员关注。

通过这套工程化的组合拳，WYSIWID架构将软件的结构健康度从一种“艺术感觉”转变为一种可度量、可强制执行的工程标准。

❖ 四、架构的对话，与其他范式的兼容与思辨

任何一种新的架构范式都不是凭空产生的，它必然是在吸收、借鉴和反思已有思想的基础上发展而来。WYSIWID架构也不例外。理解它与领域驱动设计（DDD）、微服务、事件驱动架构（EDA）等主流范式的关系，有助于我们更深刻地把握其核心价值与适用场景。

4.1 与领域驱动设计（DDD）的共鸣与差异

WYSIWID与DDD在核心理念上高度契合。

  • 共同的追求。两者都强调软件设计应围绕业务领域展开，通过建立清晰的边界来控制复杂性。WYSIWID的“概念”与DDD的“聚合根”（Aggregate Root）在作为业务一致性边界这一点上，思想几乎是同构的。

  • 语言的统一。DDD强调建立“通用语言”（Ubiquitous Language），让业务专家和技术人员能够无歧义地沟通。WYSIWID的“概念”命名直接来源于用户可识别的价值单元，本身就是通用语言的最佳实践。

然而，两者在侧重点和实现手段上存在显著差异。

对比维度

领域驱动设计 (DDD)

WYSIWID 架构

核心目标

业务复杂性管理，确保软件模型精准反映领域知识

可读性与可预测性优先，为人类和AI协同提供结构化基础

边界划分

强调“限界上下文”（Bounded Context），侧重于业务子域的划分

强调“概念”，粒度更细，直接对应用户可感知的独立功能

交互机制

模式多样，如防腐层、开放主机服务、发布/订阅等，实现方式灵活

强制使用“同步契约”，将跨边界交互显式化、声明化、集中化管理

对AI的考量

诞生于前AI时代，未直接考虑AI协同开发的需求

为LLM量身定制，其结构化和声明式特性天然适合AI生成与分析

可以说，WYSIWID是DDD思想在AI时代的一种具体化、工程化的演进。它继承了DDD对业务建模的重视，但通过引入强制性的“同步契约”机制，为解决LLM带来的全新挑战提供了更具操作性的“脚手架”。

4.2 与微服务及事件驱动架构（EDA）的联系

从表面上看，一个由多个独立“概念”组成的WYSIWID系统，似乎与微服务架构非常相似。每个“概念”都可以被部署为一个独立的服务。而“同步契约”的触发机制，也与事件驱动架构中的事件发布/订阅模式有异曲同工之妙。

但深究其里，WYSIWID的约束更为严格，目标也更为聚焦。

  • 微服务 vs. 概念。微服务架构的核心驱动力是团队自治和独立部署。服务的拆分粒度、通信方式（同步/异步）、数据一致性策略都由各个团队自行决定，这导致了微服务治理的巨大复杂性。而WYSIWID的核心驱动力是系统整体的可理解性。“概念”的拆分必须服务于“结构即行为”的目标，其交互方式被严格限定为通过应用层协调的“同步契约”。

  • EDA vs. 同步契约。在典型的EDA中，服务之间通过向消息总线发布事件来通信。这种模式虽然实现了生产者和消费者的解耦，但也带来了“事件风暴”和“隐式依赖”的问题。一个事件可能被多个未知的消费者订阅，其最终引发的连锁反应难以追踪。而“同步契约”是显式和集中的。在应用层，我们可以清晰地看到一个触发事件会激活哪些确定的契约，影响哪些确定的参与方。这种从“广播”到“精确制导”的转变，是提升系统可预测性的关键。

WYSIWID可以看作是一种**“有纪律的、以可读性为首要目标的微服务+事件驱动架构”**。它吸收了微服务和EDA的解耦优势，但通过引入更强的架构约束，解决了它们在系统透明度和可预测性上的固有短板。

4.3 方法的兼容性与选择

WYSIWID并非要完全取代现有架构，而是一种可以与之结合的思维模型和实现模式。

  • 在单体应用中。可以将不同的代码包（Package）视为“概念”，通过一个协调器模块来实现“同步契约”，从而在单体内部实现高度的逻辑隔离。

  • 在微服务体系中。可以将WYSIWID作为服务拆分和交互设计的指导原则。每个微服务对应一个或多个“概念”，服务间的通信不再是点对点的自由调用，而是通过一个中心化的契约编排服务来协调。

  • 与最终一致性/补偿机制结合。同步契约中可以明确定义Saga模式等分布式事务解决方案，将复杂的补偿逻辑以声明式的方式固定下来，使其更易于理解和维护。

选择的关键在于**“可读性优先”**。当系统的复杂性已经成为迭代的主要瓶颈，当LLM的引入带来了严重的回归风险时，牺牲一定的灵活性，换取系统结构和行为的确定性，WYSIWID便提供了一个极具吸引力的选项。

❖ 五、未来展望与现实挑战

MIT提出的WYSIWID架构，为我们描绘了一幅人与AI高效、安全协同开发的蓝图。但从一个前沿的研究成果走向广泛的产业应用，仍有一段路要走。

5.1 长期愿景 沉淀可复用的“概念目录”

WYSIWID架构的终极价值，在于沉淀特定领域的“概念目录”。想象一下，在一个成熟的电商领域，我们可能拥有一个经过千锤百炼的“商品概念”、“订单概念”、“用户概念”、“支付概念”的目录。

  • 对人类开发者。他们可以像搭乐高积木一样，快速组合这些标准化的“概念”，构建出新的业务应用，极大地提升开发效率。

  • 对LLM。LLM可以学习这个目录，理解每个“概念”的功能、API和与之相关的典型“同步契约”。当接到新需求时，LLM可以直接调用或扩展这些已有的“概念”，而不是每次都从零开始生成代码。

这将形成一个正向循环。应用越广泛，“概念目录”就越丰富、越健壮。而一个强大的“概念目录”，又会反过来加速新应用的开发。这有望将软件开发从当前的“手工作坊”模式，推向更高层次的“工业化生产”阶段。

5.2 挑战与成本

通往这一美好愿景的道路并非坦途，WYSIWID的推广面临着现实的挑战。

  • 初期建模成本。如何准确地识别和划分“概念”，如何设计恰如其分的“同步契约”，需要团队具备相当高的业务理解能力和抽象设计能力。对于习惯了传统分层架构的团队来说，这需要一个思维模式的转变。

  • 团队习惯的转变。开发者需要放弃直接调用的便利性，习惯于通过声明契约来解决问题。这在项目初期可能会感觉“束手束脚”，需要团队对架构的长期价值有深刻的共识。

  • 工具链的成熟度。WYSIWID的威力在很大程度上依赖于配套工具链的支持，包括契约的DSL（领域特定语言）、静态验证器、可视化工具、代码生成器等。目前，这些工具尚处于研究和早期探索阶段，距离成熟的商业化产品还有距离。

  • 遗留系统的改造。对于庞大而复杂的遗留系统，如何进行渐进式的WYSIWID改造，是一个巨大的工程挑战。可能需要采用“绞杀者模式”，逐步将旧系统的功能迁移到新的“概念”中。

这些挑战是客观存在的，但它们并非不可逾越。随着LLM能力的进一步增强，以及业界对AI协同开发模式探索的深入，我们有理由相信，相应的解决方案和最佳实践将会逐步涌现。

结论

MIT提出的WYSIWID架构，不是又一个眼花缭乱的技术新名词，而是对当前软件工程核心矛盾的一次深刻洞察与回应。在LLM日益成为软件开发“第一等公民”的时代，我们不能再沿用为纯人类协作设计的旧有架构模式，去约束一个行为模式截然不同的新“物种”。

WYSIWID的核心贡献在于，它为LLM的“创造力”提供了一个结构化的“容器”。通过**“概念”单元定义了清晰的“操作边界”，通过“同步契约”机制提供了明确的“交互规则”**。这使得LLM的编码行为从不可预测的“黑箱”，转变为透明、受控、可验证的工程活动。它没有试图去限制LLM的能力，而是通过优化软件自身的结构，来引导LLM的能力朝着正确、安全、高效的方向发挥。

这是一种范式的转移，从关注“如何写出更聪明的代码”，转向关注“如何构建一个更易于理解和演进的系统”。这不仅是驯服LLM的关键，更是软件工程追求永恒主题——控制复杂性——在AI时代的必然选择。尽管前路尚有挑战，但WYSIWID无疑为我们指明了一个极具潜力的方向，一个人类智慧与机器智能真正深度融合、协同共创的未来。

📢💻 【省心锐评】

WYSIWID架构的核心，是用“结构化”的确定性，去驾驭LLM“生成式”的不确定性。它不是AI的“紧箍咒”，而是人机协同的“交通规则”，让软件开发回归透明与可控。