设计即代码

细胞自动机逻辑将如何重塑智能体设计系统,以及为什么 Web 开发的未来或许早已写在简单的规则里

设计系统、人工智能与计算理论的交汇处,正在发生一场深刻的变革。它如此根本,甚至动摇了我们对"设计"一词的理解——在自主智能体的时代,设计究竟意味着什么?

几十年来,我们一直把设计与代码视为两门各自独立的学科:设计是人类创造力与审美判断的领地,代码则是把这些想法机械地翻译成可执行形式。然而,随着 AI 智能体越来越多地自主组装用户界面,把设计系统当作机器可读的基础设施来使用,并根据语义化令牌生成代码,我们正在逼近一个交汇点,它呼应着计算理论中一个古老得多的观念。

那个观念是什么?设计即代码。

这不只是一句好听的口号。它是一种判断:我们或许正走向这样一个世界——设计系统像细胞自动机一样运转,简单的规则催生出复杂的涌现行为;"设计"一件东西与"编程"一件东西之间的界线彻底消融;自主智能体不只是使用设计系统,而是就是运转中的设计系统。

这篇博客文章将探讨细胞自动机、涌现行为与智能体设计系统未来之间的深层联系。我们会梳理其理论根基,从冯·诺依曼的自我复制机器,一直到今天的 AI 智能体集群。

我们还将考察 Drupal 与现代 CMS 平台如何通过 Schema.org Blueprints 和 Drupal AI 等模块集成 AI,并思考这一切对设计师、开发者以及数字产品创造的未来意味着什么。

细胞自动机与涌现的逻辑

简单规则之美

1970 年,数学家约翰·康威(John Conway)提出了"生命游戏"——一种"零玩家游戏",后来成为计算理论中研究最多的系统之一。它的规则简单得惊人:

1. 任何存活细胞,若周围存活邻居少于两个,则死亡(人口过少)
2. 任何存活细胞,若周围有两个或三个存活邻居,则继续存活
3. 任何存活细胞,若周围存活邻居多于三个,则死亡(人口过剩)
4. 任何死亡细胞,若周围恰好有三个存活邻居,则变为存活(繁殖)

这四条规则只需寥寥几个二元条件就能表达,却涌现出一个令人惊叹的复杂宇宙:滑翔机穿越无限网格,振荡器以永恒的节律脉动,"枪"在细胞空间中射出源源不断的图案。最了不起的是,生命游戏已被证明是图灵完备的:任何能够通过算法计算的东西,原则上都可以在康威这张简单的网格中计算出来。

图1:康威生命游戏中的高斯珀滑翔机枪。这个图案会源源不断地产生滑翔机,展示了简单的规则如何催生出无穷无尽、自我延续的复杂性。

这是元胞自动机给我们的第一课:复杂行为并不以复杂为前提。只要在一个基底上始终如一地应用简单的规则,就能涌现出没有人明确编写过的图案与行为。

兰顿环与自我复制

1984年,克里斯托弗·兰顿(Christopher Langton)将这一原理推进了一步,提出了能够自我复制的环——这种元胞自动机展现了真正的人工生命原理。康威生命游戏展示的是涌现的复杂性,而兰顿环展示的则是涌现的繁殖.

每个环都由一圈循环的边界构成,边界内封装着以单元格状态编码的“基因组”。这份基因组沿着环不停流动,并从一条构造臂中延伸出去,在151个时间步内构建出一个子环。子环完成后便与母环分离,两者继续各自复制。

图2:兰顿环的初始构型。遗传信息在环中循环流动,并通过不断伸出的臂指挥子环的构建。

“如果自我繁殖的机器能在元胞自动机中实现,那么生命本身或许也能由机器来实现。”

——克里斯托弗·兰顿,《用元胞自动机研究人工生命》(1986)

其意义深远。兰顿环表明,自我复制并不需要生物细胞那样的复杂度,也不需要冯·诺依曼原始设计中的通用构造能力。它只需要:

• 一组简单的局部规则
• 一种编码指令的机制
• 一个执行这些指令的过程

规则就是生物体本身。设计就是代码。

1999年,佐山弘树(Hiroki Sayama)提出了evoloops,这是一类引入了结构可分解性和表型相互作用的变体,能够产生自发突变和演化动态。这些环通过复制过程中的直接物理碰撞而演化,从而带来基因型变异、形态多样性的增加,以及世代间复杂度的增长。与兰顿固定不变的复制不同,evoloops 无需任何外部干预就能展现可遗传的突变。

规则110与通用计算

斯蒂芬·沃尔弗拉姆(Stephen Wolfram)对基本元胞自动机的探索最终得出了一个惊人的发现:规则110——在最简单的一维元胞自动机所有256种可能的规则中,它只是其中之一——却能够实现通用计算。

规则110只需列出一个单元格及其两个邻居共八种可能组合各自的结果，就能被完整地定义出来。然而，这条简单到近乎平凡的规则——八个二元判定——却能够模拟通用图灵机。

图3：规则110元胞自动机。尽管定义十分简单，规则110却表现出第4类行为——既不完全稳定、也不完全混沌的复杂图案——并且已被证明具有图灵完备性。

“要进行通用计算，根本不需要整台计算机CPU那样的东西。只需要这样一条小小的规则就够了。”

——斯蒂芬·沃尔夫勒姆（Stephen Wolfram），《一种新科学》（A New Kind of Science）

2004年，马修·库克（Matthew Cook）发表了一项证明：在特定的重复背景图案下，规则110具有图灵完备性。该证明表明，规则110可以模拟循环标签系统，而循环标签系统又可以模拟任何图灵机。在88种本质上不同的初等元胞自动机中，规则110是唯一一个被直接证明具有图灵完备性的。

沃尔夫勒姆提出的计算等价性原理则暗示了更为激进的观点：复杂度超过某个最低门槛的系统，其计算能力在本质上是等价的。人脑、天气系统和规则110，在某种深层意义上，在计算上是等价的。

0E0P 元胞：真正的自我复制

2018年10月，亚当·P·古彻（Adam P. Goucher）完成了0E0P 元胞（0E0P metacell）的构建——这是康威生命游戏中一种能够真正自我复制的图案。以往的元胞需要附近预先存在副本，而 0E0P 元胞可以从零开始构造出自身的副本，包括它自己的指令带。

这一成就是人工生命领域的一座里程碑：一个仅凭局部规则，就能在计算基底中自我传播的系统。2013年11月23日，戴夫·格林（Dave Greene）在生命游戏中构建了第一个能创建自身完整副本（包括指令带）的复制器——这证明了即便是康威那种简单的双状态自动机，也能支持不受限制的自我繁殖。

作为计算基底的设计系统

从原子设计到智能体设计

布拉德·弗罗斯特（Brad Frost）于2013年提出的原子设计（Atomic Design）方法论，彻底改变了我们看待设计系统的方式。它把界面拆解为原子（按钮、输入框等基本元素）、分子（简单的组合）、有机体（复杂的界面区块）、模板（页面布局）和页面（最终实现），为管理复杂性提供了一套层级结构。

但回头来看，值得注意的是：原子设计其实早已体现了元胞自动机的原理，只是并未明确意识到这一点。

“当设计系统足够‘无聊’时,设计师和开发者就能腾出手来做新鲜事、解决新问题。设计系统替他们扛下了那些无聊的活儿,他们自己就不必再操心了。”

- Josh Clark,《最令人兴奋的设计系统都很无聊》

2023 年 2 月,Brad Frost 写了一篇《人工智能时代的设计系统》:

“AI 天生就是设计系统的使用者……事实上,设计系统里的大量组件工作确实是机械且可预测的。我们已经在用 PlopJS 这类工具,生成与组件库其余部分形态一致的组件样板代码。如果 AI 能帮我生成大量常见的样板内容,我会很欢迎。”

- Brad Frost

设计系统机械且可预测的特性,恰恰使它适合以元胞自动机的方式运行。当规则清晰、局部化并被一致地执行时,智能体就能自主运作——就像康威生命游戏中的细胞,无需中央控制器,也能产生滑翔机和振荡器。

机器可读的必然要求

Storybook MCP(模型上下文协议,Model Context Protocol)倡议代表了这一方向上的关键演进。该倡议于 2025 年末发布,能让 AI 编程智能体从现有的 Storybook 配置中获取机器可读的组件元数据。

关键洞察在于:智能体需要的不是原始代码或可视化文档。它们需要:

• 组件清单(Component manifests):关于每个组件的结构化元数据——属性(props)、变体、设计令牌绑定和使用示例
• 语义化命名:富含意图的令牌,例如 action.primary.confirm,向智能体传达的是含义,而不只是数值
• 验证循环:能够运行测试、查看失败项并自行纠正

“Storybook MCP 帮助智能体遵循你的模式并通过你的测试。它为智能体提供了两样前所未有的东西:机器可读的组件元数据,以及可自我修复错误的迭代循环。”

- Storybook 团队

Storybook MCP 包含一个自主纠错循环。它让智能体运行你的组件测试(交互测试和无障碍测试),查看哪里失败,并自行修复 bug。开发者只需在测试通过后介入。再也不用盯着提示词“保姆式”操作了。

这正是应用于设计领域的元胞自动机架构:局部规则(组件规范)、邻域交互(组合模式)和迭代更新(验证与自我纠正)。

我的组件清单即基因组

当我们考虑组件清单如何发挥作用时,与兰顿环(Langton's Loops)的类比就更加贴切了。在兰顿的系统中,循环流动的细胞里编码的“基因组”包含着构建新环的指令。在机器可读的设计系统中,组件清单则包含着组装界面的指令。

组件清单可能会规定:

{
  "name": "Button",
  "variants": ["primary", "secondary", "destructive"],
  "sizes": ["sm", "md", "lg"],
  "props": {
    "label": "string",
    "disabled": "boolean",
    "onClick": "function"
  },
  "tokens": {
    "background": "color.action.primary",
    "borderRadius": "radius.md",
    "padding": "space.3"
  },
  "constraints": [
    "Must have accessible contrast ratio",
    "Label required for non-icon buttons",
    "Minimum touch target 44x44px"
  ],
  "examples": [
    { "variant": "primary", "label": "Submit", "size": "md" },
    { "variant": "destructive", "label": "Delete", "size": "sm" }
  ]
}

这份清单既是设计规范,也是可执行的代码——更准确地说,是可以据此生成可执行代码的指令。读取这份清单的智能体不必像人类那样理解美学或用户体验。它只需遵循规则,按照约束组合各个元素,并产出有效的结果。

我赞同 Brad Frost 的看法,使用 yaml 格式。

Drupal 的组件(Components)用的就是 yaml 格式。大致像这样:

$schema: https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas/v1/metadata.schema.json
name: Button
status: experimental
description: Use Bootstrap custom button styles for actions in forms, dialogs, and more with support for multiple sizes, states, and more.
props:
  type: object
  properties:
    html_tag:
      type: string
      title: The HTML tag to use for the button (button | a). Defaults to `button`.
      default: button
      enum:
        - button
        - a
    url:
      type: string
      title: URL Link
      description: URL link for the button when the HTML tag is an anchor link.
      $ref: "ui-patterns://url"
    color:
      type: string
      title: Color
      description: Bootstrap includes several predefined button styles, each serving its own semantic purpose, with a few extras thrown in for more control.
      default: ''
      enum:
        - ''
        - primary
        - secondary
        - success
        - danger
        - warning
        - info
        - dark
        - light
        - link
    outline:
      type: boolean
      title: Outline
      description: In need of a button, but not the hefty background colors they bring? Replace the default modifier classes with the .btn-outline-* ones to remove all background images and colors on any button.
      default: false
    size:
      type: string
      title: Size
      description: Bootstrap button size
      default: ''
      enum:
        - ''
        - btn-sm
        - btn-lg
    disabled:
      type: boolean
      title: Disabled
      description: Disabled button
      default: false
    button_utility_classes:
      type: array
      title: Utility Classes
      default: []
      items:
        type: 'string'
      description: An array of utility classes that can be used to add extra Bootstrap utility classes or custom classes to this component.
    attributes:
      type: object
      title: Attributes
      description: HTML attributes for the containing element.
      $ref: 'ui-patterns://attributes'
slots:
  content:
    type: string
    title: Content
    description: The content for the button
    minLength: 1
    examples:
      - Press
      - Submit now
      - Save
      - Login
      - Read more

设计就是代码。

• 变体(Variants)
• 令牌(Tokens)
• 属性(Props)

• 约束(Constraints)(我们可以把它加入组件中)

• 插槽规则(Slots rules)(哪些内容可以放入其他插槽,或者哪些内容允许放入我的插槽)

• 规则(Rules)

• 示例 

• 动画(Animations)  (允许使用或建议使用)

然后观察并试验它的行为。

例如 https://storybook.demo.varbase.vardot.com/?path=/story/atoms-button--primary 

作为环境变量的设计令牌

设计令牌是这块拼图中另一个关键部分。在元胞自动机中,每个细胞都会对它的直接环境作出反应,也就是相邻细胞的状态。在设计系统中,组件则对设计令牌作出反应,这些上下文取值决定了组件的外观和行为。

现代令牌架构采用多层结构:

• 核心令牌:原始值,例如 color.blue.500: #3B82F6
• 语义令牌:以意图为导向的引用,例如 color.action.primary: color.blue.500
• 组件令牌:限定范围的应用,例如 button.background.primary: color.action.primary

智能体生成 Button 组件时,不需要知道“primary”意味着蓝色。它只需引用 button.background.primary,并相信令牌系统会解析出正确的值。环境(令牌层)承载信息,组件(细胞)只需对其作出响应。

像 Tokens Studio 这样的工具已经发展到把设计令牌视为带有解析器的计算图,其中的节点会根据上下文,对使用哪些基础令牌做出语义层面的决策。这样,设计令牌就从静态的值变成了动态的、基于规则的系统。

Drupal 生态系统与 AI 集成

把 AI 集成到内容管理系统中,是探索“设计即代码”原则的绝佳实验场。像 Drupal 这样的 CMS 本身就体现了其核心概念:结构化的内容类型、字段定义、关系,以及组合规则。

我从没想过我们能说出这样的话。对我来说,这曾经是艺术的巅峰。

 这就是我们能拥有的终极电脑配置。有些开发者仿佛来自未来的《星际迷航》,对着电脑说话,让它替自己编程。

智能体体验(AX)与新型用户

为机器而设计

2025 年初,Netlify 首席执行官 Mathias Biilmann 提出了“智能体体验”(Agent Experience,AX)这一概念,这是一门新兴学科,关注 AI 智能体如何与产品和平台交互。

这是一种根本性的转变。几十年来,UX(用户体验)针对人类的认知、感知和行为进行优化,DX(开发者体验)针对构建软件的人类开发者进行优化。而 AX 认识到,智能体正在成为数字系统的主要用户,它们的需求截然不同:

• 它们不在乎视觉美感,只要结构化、可解析的数据
• 它们不浏览界面,它们调用 API、读取清单
• 它们不像人类那样阅读文档,它们需要机器可读的上下文
• 它们不做主观判断,它们遵循规则和约束

“AI 智能体不是人：它们不在乎按钮的大小、字体是否易读、网站配色是否好看，也不在乎应用里花哨的动画。那么，AI 智能体到底‘在乎’什么？这个问题今天还没有确切的答案，但在未来几年会变得越来越重要。”

- AX 研究

答案是：清晰的规则、可预测的行为、结构良好的数据，以及让它们能够验证并纠正自身行为的反馈回路。

双重界面的挑战

为 AX 做设计，意味着要同时构建两种界面：

1. 人到智能体界面： 人类在这里监督、批准、编辑并引导智能体的行为，也就是“任务控制中心”层。想想仪表盘和审批队列，而不是表单和按钮。
2. 智能体到系统界面： 智能体在这里与 API、数据库和工具交互，也就是“运行”层。它必须稳健、文档完善，并针对机器效率做过优化。

这与细胞自动机的架构如出一辙，两种截然不同的视角并存：

• 一是局部视角： 每个细胞（智能体）只根据相邻的细胞遵循简单规则
• 二是全局视角： 复杂的模式涌现出来，只有在大规模下才看得见

“智能体体验设计（AX）应当让智能体用得顺手，也让围绕智能体的使用变得出色。因此，出色的 AX 会带来出色的用户体验（UX）。如果 AI 智能体遇到流程中断、协议错误，甚至不同系统之间措辞不一致，它就无法完成任务。这对智能体来说是糟糕的体验，进而又会造成糟糕的客户或员工体验。”

- Kat Holmes，Salesforce 首席体验官

从 UX 到 AX：数字设计的演进

共识主动性与间接沟通

群体智能中最强大的概念之一是 共识主动性（stigmergy）——即通过环境痕迹实现的间接协调。蚂蚁不会直接交流食物的位置，而是留下信息素轨迹，供其他蚂蚁跟随。环境本身成了一种沟通媒介。

在智能体式设计系统中，共识主动性表现为：

• 共享组件库： 智能体能够“看到”有哪些组件，以及它们是如何被使用的
• 设计令牌： 把设计决策编码为环境事实的语义化取值
• 模式文档： 充当信息素轨迹、供后续智能体参考的使用示例
• 测试套件： 约束有效输出空间的验证规则
• Git 历史： 智能体可以查阅的过往决策记录

当智能体用某个组件生成界面时，它会留下痕迹：在代码库里，在文档里，在它确立的模式里。之后遇到类似任务的智能体会受到这些痕迹的影响，由此形成一种任何单个智能体都不具备的集体智能。

智能体式设计模式

Andrew Ng 等人总结了智能体式 AI 系统的四种关键模式：

1. 反思： AI 评估自己的输出，并不断迭代改进
2. 工具使用： AI 与外部工具、API 和系统交互
3. 规划：让AI把复杂任务拆解为子任务,并按顺序依次执行
4. 多智能体: 多个各有专长的智能体协同完成复杂任务

这些模式可以直接对应到元胞自动机的概念:

设计即代码:更深入的解读

“设计即代码”究竟意味着什么

当我们说“设计即代码”时,其实同时提出了几个主张:

1. 语义等价

设计决策一旦被恰当地编码,就变得可以执行。设计令牌(design token)不只是一个数值,而是一条指令;组件规范不只是文档,而是一段程序。当智能体读取这些产物时,它们既在实现设计,也在执行设计。

2. 生成能力

正如规则 110 能够计算一切可计算的东西,一套足够完备的设计系统也能生成任何有效的界面。系统本身蕴含着它所有有效表达的可能性,最终涌现出什么,只取决于初始条件(需求)和规则(约束)。

3. 涌现的复杂性

最精妙的界面并不是自上而下设计出来的,而是从简单规则的一致应用中涌现出来的。一个设计良好的按钮,只要用得一致,就会形成连贯的视觉语言,而无需任何人刻意去规划这种连贯。

4. 计算不可约性

有些设计结果,不真正运行一遍系统就无法预测。不让智能体亲手组装,你就无从知道由它组装出来的界面会是什么样子。这正是沃尔弗拉姆(Wolfram)的计算不可约性原理在设计上的应用。

5. 自我修改

就像在复制过程中发生突变的 evoloop(演化环)一样,面向智能体的设计系统也能在使用中不断演化。智能体生成的组件会成为组件库的一部分,供后来的智能体取用。系统会学习、适应,并不断成长。

元胞自动机隐喻的延伸

超越隐喻:真实的融合

但这不只是隐喻。这种融合是真实的,而且正在发生:

• Storybook MCP 把组件库变成机器可读的指令,供智能体执行
• Model Context Protocol 规范了智能体获取工具和上下文的方式,为智能体化的运作建立起一个通用的底层基础
• 多智能体架构 在各有专长的智能体(架构师、编码者、审查者)之间分工,它们按照协议相互作用,就像功能各异的元胞
• 自愈循环允许智能体运行测试、检测错误并不断迭代——这与元胞自动机演化出稳定构型所用的反馈机制如出一辙
• Schema.org Blueprints让内容结构可被机器读取,并具有语义上的意义
• Drupal AI为 AI 智能体自主创建、修改和管理内容提供基础设施

我们并不是把“设计即代码”当作一种哲学立场,而是把它当作技术基础设施来构建。

影响与未来之路

对设计师而言

设计师的角色正从“画矩形的人”转变为“定义规则的人”。正如 Brad Frost 所观察到的:

“把自己的工作看作画矩形的设计师和开发者,确实有很多值得担心的地方。但是,如果设计师和开发者把自己的工作看作解决问题——只是为了解决问题,顺带需要创建或摆弄一些矩形——那他们就没那么需要担心了。”

——Brad Frost

在智能体时代,设计师将会:

• 定义语义化的设计令牌及其相互关系
• 建立组合约束与模式
• 创建智能体必须满足的验证规则
• 维护并演进那些支配“涌现”的规则
• 设计让系统能够自我纠错的反馈机制
• 塑造“适应度函数”,以判定哪些产出是可以接受的

这是更高抽象层次上的设计——设计的是产生设计的规则,而不是设计本身。就像定义元胞自动机的规则,而不是逐个去画每一个细胞。

对开发者而言

开发者将成为智能体系统的架构师。正如 Anthropic 所描述的:

“软件开发领域已经展现出 LLM 功能的巨大潜力,其能力已从代码补全发展到自主解决问题。”

开发者需要:

• 在智能体与系统之间建立机器可读的接口
• 设计反馈回路和验证机制
• 搭建“涌现行为”得以发生的脚手架
• 保留人类监督,作为最终的裁决者
• 定义智能体之间通信所遵循的协议
• 实现连接不同智能体系统的“胶水代码”

对 Web 开发与 CMS 平台而言

AI 融入 Drupal 等平台,指向这样一个未来:

• 内容模型可供智能体直接使用,依托 Schema.org 等标准
• 编辑工作流获得智能体协助,包括 AI 驱动的起草、审核与优化
• 搜索不断演进,从关键词匹配走向基于嵌入(embeddings)和向量数据库的语义理解
• 个性化走向自主化,智能体学习用户偏好,并实时调整内容
• 开发全面提速,智能体负责生成组件、测试和文档

Drupal 生态对 AI 的拥抱——通过 Drupal AI、Drupal Canvas、Schema.org Blueprints 以及 AI 提供商集成等模块——表明这样的未来已经在建设之中。

对组织而言

竞争优势将属于那些设计系统最“为智能体做好准备”(agent-ready)的组织。这类系统具备以下特征:

• 组件状态与变体的全面覆盖
• 能够传达意图的语义化命名
• 机器可读的文档与上下文
• 验证与测试基础设施
• 为有效输出划定边界的清晰约束
• 为智能体使用而设计的 API(AX 优先)
• 以 Schema.org 为先的内容架构

面向数字产品的未来

最终的形态,大概是一种数字生态:无数智能体遵循本地规则运行,涌现出没有任何设计师或开发者事先规划过的界面。但只要底层规则可靠,这些界面仍会自然地连贯起来。

这听起来并不遥远。生物系统就是这样运转的,城市就是这样生长的,市场也是这样运作的。问题不在于我们会不会走到这一步,而在于我们如何度过这段过渡期。

结语:代码是活的

约翰·冯·诺依曼是细胞自动机的发明者,也是一位通才。他一直被一个根本性的问题驱动:自我复制所需的最低复杂度是多少?他给出的答案,即冯·诺依曼通用构造器,证明了自我复制并不需要生物机制,只需要一套能够编码自身运用方式的规则。

七十年后,我们发现同样的原理也适用于设计系统。自主生成界面的最低要求,并不是通用人工智能,也不是人类水平的创造力,而是一套完整、一致、机器可读、智能体能够执行的规则。

当朗顿环(Langton's Loops)在细胞网格中不断复制时,我们不会说这些环在“设计”新的环。复制只是规则自然产生的结果。然而,最终出现的不断扩张、彼此相似的图案群落,无疑具有生成性,在某种功能意义上也称得上有创造力。

当 AI 智能体遵循语义化令牌和组合约束,用设计系统的组件拼装界面时,它们做的事情与此相似。这里的“创造力”不在智能体本身,而在它们所执行的规则,这些规则由人类设计,如今却能自主运行。

我们正站在数字创作新时代的门槛上。智能体已经到来,协议正在成形,设计系统正在成为人工生命的基底。

设计即代码。
而代码正在苏醒。

重点文章与项目

• AI 时代的设计系统 - Brad Frost
• Storybook MCP 抢先看 - Storybook
• AX 简介:为什么智能体体验很重要 - Mathias Biilmann
• 构建高效的智能体 - Anthropic

Drupal AI 资源

• Drupal AI

• Schema.org Blueprints 模块

   

细胞自动机资源

• 康威生命游戏词典 - 约 1500 种图形
• 生命游戏中可运行的图灵机
• 朗顿环 - 维基百科
• 细胞自动机的规则集
• 《一种新科学》在线版 - Stephen Wolfram
• 细胞自动机 - 《代码本色》(Nature of Code)

探讨计算理论、设计系统、人工智能与网页开发交汇处的想法。

 文中观点是对新兴趋势的推测性探索,而非对确定未来的预测。

我看到,我们正在创造在循环中工作的 AI 智能体,它们又在更多的循环中与其他 AI 智能体互动。

当系统在选定的画布和规则集中,像生命周期的循环那样运行时,设计就是代码。