news 2026/10/4 14:14:33

设计形态学与第三自然:让形态“长”出来的生成设计实践

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
设计形态学与第三自然:让形态“长”出来的生成设计实践

团队工位一角常年堆着两样东西:一摞刻着连续曲面切片的草模,一本翻烂了的《On Growth and Form》。有人第一次来会误以为这是生物实验室,其实那本Thompson的经典书旁边就放着犀牛模型、KeyShot渲染图和一个写着"第三自然"的白板。这就是我们团队最真实的工作状态——一帮做设计的人,用生物学家的观察方式、数学家的建模习惯和手艺人的制作执念,去回答一个看起来不太像设计问题的问题:形态到底是怎么被"长"出来的,而不是被"画"出来的。

我在这里面负责计算性生成和数字制造端的工作,跟设计形态学、第三自然这两个词打了三年多交道。这三年踩过的坑、磨出来的方法论、团队内部吵过的架,都值得单独写一写。如果你也在做生成设计、参数化设计,或者你所在的团队正在尝试把"仿生""生物设计"这类词变成真正可落地的项目,这篇文章大概能帮你少走一段弯路。

1. "设计形态学"拆开看——这个团队在研究的,其实是形态的生成逻辑

1.1 形态不是画出来的,而是"长"出来的

先厘清一个最常见的误解。很多人一听到"形态学",下意识以为是从形态出发做美学造型——比如把某个建筑做成流线型,或者把椅子做成贝壳状。这不是设计形态学,这是"从形态到形态"的挪用,属于仿形设计。

我们团队研究的是另一个方向:形态背后那套生成规则。举一个特别直观的例子。同样是做一栋楼的支撑结构,传统流程是建筑师画出一根柱子、一个桁架,然后让结构工程师去验算。但形态学的思路是反过来:先定义场地荷载、材料性能、建造约束和日照/通风条件,再通过拓扑优化算法让计算机"生长"出一个结构形态来。这个结果往往长得像骨头或者树干——不是因为我们想要它像骨头,而是因为当受力逻辑被计算穷尽之后,在给定条件下最能省材料又满足受力的解,自然长成了那个样子。

这个思路叫form-finding(找形),相对的是传统设计流程里的 form-making(造形)。我们团队每个项目几乎都从这里开始:先问一个形态是"怎么来的",而不是"长什么样"。

1.2 形态学方法的三根支柱

团队内部复盘过很多次,最后把我们的方法论底座收敛成三根支柱:

  • 结构逻辑:形态必须对力有诚实回应。无论是悬挑、桁架还是膜结构,形态要先经过力学逻辑的推演,而非仅凭视觉直觉。
  • 生成过程:形态是某个确定算法或规则系统的产物,这个系统可以被参数化、被调节、被复制。换一组参数能得到一个相近但不同的新形态,这意味着设计具备连续演化的能力。
  • 环境响应:形态不是孤立的形式,它要回应光、风、水、人的行为等外部条件。环境参数直接进入生成逻辑,而不是生成完之后再做附加调整。

这三点并不只是学术立场,它们决定了团队的工作链条。举个例子,有一次做装置设计,业主想要一个"像鸟巢一样"的外观。按传统做法,我们直接建模就能交付。但按我们的方法论,这个"像鸟巢"的需求被拆解成了一个空间编织逻辑:先用多智能体模拟编织路径的交汇密度,再用最低能量约束让路径相互搭接,最后才生成我们想要的结构形态。形态最终确实像鸟巢,但每一步都有逻辑依据,而不是凭眼睛"描"出来的。

1.3 这样的工作方式,适合解决什么问题

形态学方法不是万能的,它的适用场景很明确:当设计的核心矛盾是"形态与性能的耦合"时,这套方法的价值最大。比如大跨结构、复杂曲面表皮优化、景观地形设计、产品的人机工程学曲面、甚至是时尚领域的生成式打版。反过来,如果项目核心是风格化的平面表达或者简单功能性产品,用这套流程就是杀鸡用牛刀,成本完全划不来。

很多刚入行的朋友问我,要进入这个方向需要学什么。我列一下我们团队成员的基础配置,供参考:

  • 知道怎么用Grasshopper或者类似节点式编程工具,能独立搭一套参数化模型
  • 理解有限的有限元基本概念:应力、应变、约束、荷载,不需要会手算,但要知道定义条件时每个参数在现实中是什么
  • 有一点编程能力,Python优先,主要用于批量处理数据和算法调用
  • 剩下的,其实是观察和归纳能力——能从一片叶子、一组泡沫、一张显微镜照片里提炼出背后规律

2. 从"看自然"到"算自然"——团队核心工作流程拆解

2.1 形态法则的提炼:从自然现象到可计算模型

整个工作流的第一步,也是最考验功底的一步:把观察到自然现象的规律,抽象成一套计算机能理解和执行的语言。

我举一个我们团队真正做过的案例——用黏菌网络优化一个社区步行系统。黏菌这种单细胞生物有一种让人惊讶的能力:它在觅食时会长出网状结构,把食物源连接起来。这个网状结构恰恰是对"高连通率、低总长度、具备冗余抗毁性"三个目标的平衡解,好过很多人工设计的路网。

但这里有个关键转换:黏菌是生物,不会听你的参数设置。我们需要把它"翻译"成算法。团队的做法是先把黏菌的网络生长过程拆成几个可描述的行为规则:局部感知、正反馈增强、能量约束下的路径回退。这些规则最终被写成一个基于最短路径成本的迭代优化模型。你没看错——原来自然界亿万年的演化智慧,背后往往也是几个简单规则的反复迭代。

这类"翻译"工作面对的挑战,其实是尺度差异。黏菌网和社区路网虽然拓扑规律相通,但尺度、速度、人的行为需求差着好几个量级。所以模型跑出来只是开始,后面还要加入人流分布热力图、地形坡度、老幼人群绕行成本等约束条件,把生物算法"重新拽回"现实。

形态法则入库之后,团队还有一个不成文的规矩:每次做出来的生成规则都必须沉淀进自家形态库,附上完整说明——这个形态法则源自什么现象、适用于什么尺度、哪些形态特征是必须保留的、哪些可以按参数调节。这个库如今已经积累了上百条,成了团队最重要的资产。

2.2 生成、仿真、验证的迭代循环

有了规则模型,接下来就是设计流程的常态:生成、仿真、验证,然后循环。

拿一个复杂曲面通风表皮项目举例。那是一个需要兼顾自然通风、立面韵律感和结构自支撑的幕墙系统。我们是这样干的:

  1. 生成阶段:使用反应扩散方程生成初始的孔隙分布图案。这能让开孔在大小和密度上呈现出平滑变化,而不是均匀的网格。
  2. 仿真阶段:把生成的面片网格转进CFD工具里跑风环境模拟,算每个区域的表面风压与风速分布;再把结构模型丢进有限元工具里做变形分析。
  3. 验证与迭代:如果某个区域通风换气系数不达标,或者某个转角处应力集中,反馈回路会把参数修正量传回生成端,在下一轮调整反应扩散的系数,形成迭代。

实测下来,这个"修改参数而不是手动改模型"的闭环是整个工作流里效率提升最明显的一步。以前改一个曲面要手动调控制点,调完还不确定性能是否达标;现在改的是生成参数,模型自动重算,仿真结果自动更新,设计空间被系统性得探索,而不是单点碰运气。

这一步表面上考验软件操作,实际上考验的是你对仿真结果的解读能力。仿真不是"出图工具",它是你理解形态逻辑的放大镜。很多人跑完一遍分析,看到某块区域压力值偏高却不知道原因——那是因为他们还没有建立"形态特征"与"性能结果"之间的对应概念。

2.3 原型测试:再精确的仿真也替代不了手感

仿真做得再漂亮,团队也会坚持做实体原型,而且是越大比例越好的那种。

原因在于仿真和现实之间永远有一道缝隙:材料的实际性能曲线、加工工艺造成的公差累积、连接节点的非线性行为……这些都会让理论和实际之间出现有趣但棘手的偏差。举一个例子,有一次我们做仿生螺旋的3D打印座椅。仿真里应力云图一切完美,但打印出来后,悬挑末端在模拟坐姿荷载下出现了肉眼可见的下挠。

排查了很久,最后发现原因很隐蔽:打印件内部的填充路径方向恰好和结构主应力方向呈45度,层间结合强度在这个方向上远低于模型预设的各向同性数值。这是一个在仿真的灰色地带——其实有限元软件里可以设置各向异性材料属性,但默认设置很容易让人忽略这个问题。

从那以后,团队定了一条硬规矩:每个项目至少做一次1:1或尽可能大比例的关键节点实样打印/加工。这一步费用不低,但相比在现场出现结构问题,这笔钱花得相当值。

原型测试还会反过来倒逼算法更新。打印中发现,曲线曲率过大的区域容易出现打印丝剥离——于是生成算法里被加入了一个"最小曲率半径"约束,后续所有项目自动避坑。这类由物理测试反哺数字模型的机制,是整个团队最值钱的工作习惯之一。

3. "第三自然"怎么落地——从哲学概念到可建造的决策标准

3.1 先对齐定义:第一自然、第二自然、第三自然

"第三自然"这个词听上去挺玄乎,但团队内部对它的理解非常务实。我们沿用的是景观理论里一套经典谱系:

  • 第一自然:没有人类干预的荒野。——原生态的雨林、沙漠、冰原,自组织的生态过程。
  • 第二自然:为了生产功能而被人为改造的自然。——农田、牧场、水利系统。它服务于效率,秩序感强,生物多样性往往不高。
  • 第三自然:人工系统和自然规律对话之后生成的新自然。——城市公园、生态修复区、棕地改造,以及更广义上"既不是纯荒野,也不是纯人工产物"的混合状态。它的核心不是去复制自然,也不是纯粹征服自然,而是让两套逻辑在碰撞中生成第三种状态。

我们团队在做设计时挂在嘴边的一句话是:不要做自然的仿制品,要做自然的"同代人"。意思是,既然自然界有风、水、光、生物这些力量,那就让它们作为合作者参与设计过程,让最终生成的东西既带有人工的秩序,又有自然的意外感。

3.2 把理念转译成三条可操作的决策标准

理念如果停在口头,就只会沦为汇报PPT里的一页形容词。团队在做项目时会把"第三自然"翻译成三条决策标准:

  • 生态机能的真实介入:形态设计直接参与生态过程,比如雨水收集与净化、鸟类停栖的微生境、遮阳庇荫产生的小气候。不是装饰性的绿色,而是功能性生态。
  • 过程性而非静态性:设计的形态必须允许时间介入。植物会生长、材料会风化、水土会重新分布,最终呈现的效果和竣工时是有机演化的关系——竣工不是结束,而是开始。
  • 可维护性闭环:第三自然不是放任不管的"野生感",而是需要靠一套可持续运维方式维持的平衡。设计阶段就要想清楚:这个形态在5年后是否仍能承受荷载,水系统清淤维护是否够得着,植物群落演替是否会破坏结构。

这第三条往往被忽略。很多所谓"生态设计"交付豆是实际使用阶段维护成本高到离谱,最后项目荒废。我们团队的做法是在方案阶段就让施工单位、物业管理人员参与方案评审,让管养端的经验反过来约束形态生成参数。

3.3 一个项目的转译过程:雨水花园里的形态实验

拿去年做完的一个社区中心雨水花园项目来演示这套理念:

形态生成层面,我们把汇水面积、当地降雨强度、土壤渗透率作为输入参数,用元胞自动机模拟了多个"场地-水流"演化情景。这些情景决定了下沉式绿地的边界在哪、溢流口标高定在哪、地形起伏的幅度怎么分布。这个地形不是设计师随手勾的等高线,它是在模拟中"被水流塑造"出来的。

生态介入层面,我们在地形低洼处预埋了模块化生物滞留介质的骨架结构,同时用起伏地形的自然高差替代了大体量的硬质挡墙——这样既完成了雨水的分级净化,又让场地有了连续的、可以坐靠休憩的地形景观,还减少了一大笔混凝土成本。

最受甲方争议的是时间设计的部分:我们故意在部分区域不铺设草皮,引入野花组合种子和先锋草本植物,让场地在竣工后6个月内逐渐呈现出与周边荒地相近的物种演替状态。这在图纸阶段几乎无法用效果图表现,只能靠叙事和实验数据说服甲方。最终甲方被一组对照实验说服了:经过先锋植物群落覆盖的土壤,渗透率比新铺草皮区域高40%以上,后期维护频率反而更低。

4. 跨学科团队怎么协作——最难的不是技术问题,而是语言问题

4.1 不是"各做各的再合图",而是要建立翻译层

做形态学方向,团队成员背景五花八门:建筑学出身的设计负责人,计算性设计背景的程序员,结构工程师,还有植物学或生态学背景的研究员。这种组合战斗力很强,但一开始协作效率极低。

传统设计团队的合作模式是"接力赛"——建筑画好图给结构,结构算完给设备。到了我们这里,形态生成必须由多方同步介入,这个模式就失效了。为什么?因为生成算法里的每一个约束,都需要相应专业的输入条件,结构工程师早一天加入就能避免算法后期因为承重问题整个推倒重来。

最后团队定下的核心协作机制,是建立一个"参数接口表"——本质上是一张定义各专业输入输出格式的清单。表格里明确写上:

  • 每个专业在生成阶段需要输入什么参数(比如结构的荷载边界、生态的物种选型范围)
  • 这些参数以什么格式进入算法(标量、向量、约束网格……)
  • 生成结果用怎样的格式返回给各专业验证(网格、点云、语义描述……)

有了这张表,各专业就能并行工作,而不是串行等待。现在新成员加入,第一周要做的事不是学软件,而是读懂这张参数接口表。

4.2 当"精确的工程师"遇到"模糊的设计师"

跨学科协作最大的摩擦点,其实源自本体论差异。

结构工程师和算法工程师习惯的是精确的、有明确目标函数的思维方式。但你问他荷载输入是多少,他报出一个数之后往往要加一句"这只是初步估算,后面要再看"。设计师则相反,对模糊有高度的容忍度,能接受"大概是这样一种感觉"作为起点,但随着项目推进需要越来越精确的把控。这两种思维方式在项目里的碰撞每天都在发生。

我们的解决方式,是用"版本化推演"替代"一次性决策"。在生成阶段,团队允许不同专业的人各自跑自己的"分支版本"——结构工程师可以跑一个以最小用钢量为目标的版本,景观设计师跑一个以植物存活率为目标的版本,然后定期把各个版本放在同一张桌子上做多目标权衡。这个过程中,没有谁必须赢,形态是通过几个版本的差异比较中逐渐浮现出来的。

这法子不算高深,但它巧妙转移了争论焦点:从"听谁的",变成"看哪个更接近项目目标集合"。

4.3 对外汇报时,怎么解释"生成出来的形态"

还有一类必须处理的协作,是面向甲方、评审专家的。大家要意识到,对客户展示一个由算法生成、带有随机感的复杂曲面时,对方的第一反应不一定是惊喜,也可能是困惑:“这个形态怎么来的?跟我们的需求有什么关系?”

我们吃过几次亏之后,总结出一套对外沟通框架:

  • 先讲约束条件:场地有哪些限制、功能上有哪些硬指标,让甲方看到所有设计决策都有客观依据。
  • 再讲推演过程:不用讲算法细节,只需要展示从约束条件出发如何逐步生成候选方案——比如展示三组不同参数生成的对比方案,直观表现参数一变、形态就变。
  • 最后才讲形态特征:把最终方案的形态语言和甲方品牌特质、场地文化做关联阐释。

这套顺序里,最容易被跳过的其实是第一二步。很多设计师习惯上来先展示形态效果图,一旦甲方不理解就会陷入反复修改的死循环。而先讲约束和推演,等于帮甲方建立了一套理解框架——当对方能基于逻辑而不是纯粹审美来参与讨论时,沟通效率会高非常多。

5. 踩过不少坑之后,沉淀下来的一些判断和工具习惯

5.1 警惕"形态主义"陷阱——最怕的不是丑,而是空洞

做形态学方向的团队很容易掉进一个陷阱,我们内部叫它"形态主义":为了复杂而复杂,为了像自然物而像自然物。某个形态不是从功能逻辑里长出来的,而是为了看起来有"自然感"硬生生套上去的,这比传统的仿形设计更得不偿失——因为仿形至少知道自己在仿什么,而形态主义常常连自己从哪里出发都忘了。

团队为此定了一个审查标准:评审的时候先遮住效果图,只看项目说明和性能数据。如果仅仅通过逻辑叙述已经能让听众理解这个形态存在的必要性,那效果图只是锦上添花;如果说明逻辑不够,需要用效果图来"圆场",那这个方案就要打回去重新从生成逻辑出发考虑。

5.2 "长得像骨头"不是好设计的标准,"推导链路完整"才是

在对外展示的时候,最怕的一句话是"这个形状好像一个动物"。每当有甲方或者评审说出这句话,团队内部反而会紧张——因为这意味着对方可能只看到了形态表层,没有注意到背后的推导逻辑。

我自己的判断标准是这样的:一个成功的生成设计,方案本身应该自带辩护能力。你可以把生成过程全链条打开——约束条件在这里,算法逻辑在这里,物理验证在这里,成本测算在这里——任何一个环节拿出来都能自圆其说。至于它最终长得像骨头还是像树枝,其实是这套逻辑推演后的副产品。

这一点想清楚了,团队的内外沟通会有一个质的改变:你们不再需要依赖一个漂亮的故事来解释设计,设计方案本身就会替你说话。

5.3 给同样在这个方向上尝试的人几条实操建议

按自己的使用频率,把值得刻在工位上的经验排个序:

  • 建立自己的形态语料库,坚持做形态观察记录。我们鼓励每位成员每周在共享图库里至少存三张自然/人工物的形态照片,并写明它背后的生成规则猜想。坚持一年,你再看形态的眼光会和从前完全不一样。
  • 算法生成结果必须做归因炼习:不管跑出什么形态,都问自己"为什么这个区域产生了这个特征"。如果答案需要想很久,说明你的参数约束还不够精炼。
  • 仿真精度够用就好,不要一上来就追求最精细的网格和最全的物理模型。先跑线性分析辅助判断主力传力路径,等方案收敛后再升级模型做详细校核,效率能翻倍。
  • 材料加工参数要提前嵌入生成算法,不要生成完再去想怎么造出来。最小曲率半径、最大悬挑角度、可用板材尺寸这些参数在生成阶段就有大量约束是常态,而不是例外。
  • 把每次失败的原因记录下来。团队现在有一套完整的"避坑档案",任何一次节点失效、一次仿真偏差、一次加工事故都会被记录在案。这些档案比任何培训教材都管用,新成员上手速度明显提升。

最后再分享一个小经验。做形态学方法最大的快乐不是做出一个惊艳的形态,而是看着一套规则在你面前跑出一连串意料之外、情理之中的结果——那一刻你真的会相信,设计这件事是可以被结构化、被传授、被系统化的。保持观察、保持记录、保持对"为什么长成这样"的好奇,这个方向自然会带你越走越远。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/4 14:09:45

办公 AI 助手到底值不值得用?从任务收益到真实局限的完整拆解:TaoToken 统一 Key 接入 TraeWork 的 Work 模式与 Code 模式实测

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/10/4 14:07:49

Coding Agent长期记忆:从易失忆到可持久化的实战拆解

我自己用 Coding Agent 半年多,最大的感受不是它多能写代码,而是它实在太容易“失忆”。上午让它修完一个 Bug,下午换个会话再让它优化同一段逻辑,它能给你写出一版与上午完全冲突的方案。长期记忆这件事,正在成为 Cod…

作者头像 李华
网站建设 2026/10/4 14:07:27

学习IEC 61850:用TaoToken统一Key跑通MMS报文解析与GOOSE订阅实验

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

作者头像 李华
网站建设 2026/10/4 14:07:20

桥梁裂缝数据集处理:COCO转YOLO格式与训练避坑指南

简介:一份面向桥梁结构健康监测与计算机视觉研究者的图像分割数据集,采用COCO标注格式,聚焦混凝土桥梁表面裂缝缺陷的精准定位与分割。数据集包含约4500张训练图像和200张验证图像,覆盖不同光照、角度、拍摄距离及复杂背景下的裂缝…

作者头像 李华