AI能否拯救建筑事务所的集体记忆？

建筑行业有个老毛病：信息从来不缺，但没几个人说得清项目里到底发生了什么。一个中型项目，几年下来能攒出几千张图纸、无数封邮件、会议纪要、报告、模型和决策记录。它们都在，但散落各处。A记得某个方案为什么被毙掉，B知道结构工程师在电话里说过什么，C一直在追幕墙顾问的问题。真正需要的时候，没人能拼出全貌。

存储不等于知识。项目服务器可以告诉你文件在哪，但回答不了为什么做这个决定、哪些信息彼此相关、团队里谁已经知道什么。建筑事务所积累了海量经验，但一旦项目结束，这些经验就变成沉睡的档案。它们的价值依赖于“有人碰巧还记得它存在”。

AI进入建筑领域后，大家的注意力大多放在“生成”上：生成图像、文本、方案、复杂形态。我反而对反方向的问题发生了兴趣：

AI能不能帮事务所记住自己已经知道的东西？

不是项目结束后的归档，而是在项目进行中就能用。能不能把散落在团队里的信息串起来？能不能不用预先知道信息存在哪里，就能找到某个决策和参考？过了好几年，上一个项目积累的知识还能不能为下一个项目所用？

这个问题看似简单，实则棘手。建筑知识不存在于单一形式中。它有图纸、文档，也有图像、对话、先例、习惯和个人经验。有的可以精确记录，有的根本说不出口。

随之而来的实验，我把它叫做 BlackBox。

从存储到对话

BlackBox不是某个办公知识系统的提案，它最初连需求都没有。

2026年初，我对开源AI的快速演进越来越好奇。在此之前，我和大多数建筑师一样使用大模型：写文字、改稿、查资料、做PPT，偶尔写点代码。有用，但用的都是商业服务、个人账户。真正让我感兴趣的是把模型跑在本地。办公室正好有一台性能不错的工作站，我就开始瞎试。最开始的问题很基础：开源模型能做到什么程度？跟商业模型比差多远？如果AI住在办公室里面而不是外面某个云端，会发生什么？

早期的实验极简：安装本地语言模型，配一个共同的聊天界面。但这很快就不够看了。一个对办公室一无所知的聊天机器人，本质上还是聊天机器人。真正的问题在于：如果它能访问我们工作的上下文呢？它能读内部文档吗？能帮我们检索在营项目的信息吗？能按“建筑概念”而不是文件名搜索图库吗？一个人脑子里的认知，能不经过正式整理就传递给另一个人吗？

从这一刻起，BlackBox开始有了轮廓。我的兴趣不再是做一个ChatGPT的替代品。模型本身可以被替换，而且以AI的发展速度，大概率很快就会被替换。更持久的是构建在模型外部的环境：把通用AI与一个事务所的具体文档、图像、项目、流程和积累的经验连接起来。

这也改变了我对“事务所专属AI”的理解。最初我假设特殊性必须放在模型里，实验却指向相反的方向：模型可以保持通用，真正要特化的是它的上下文。

BlackBox逐渐从单一应用演变成一组通过对话界面连接起来的现有系统。文档待在自己的文档环境里，图片待在图片库里，语言模型按任务随时切换。我无意把所有东西搬进一个巨型数据库，只是想创造一种方式，让已经分散的信息可以被导航。

这个区别很重要。建筑信息天然异质：图纸不是会议纪要，参考图承担的知识和规格书不一样，一个项目决策可能需要同时读好几个来源才能理解。把一切强行塞进统一格式，远不如让各类信息留在原位，同时给AI留出触达它们的路径。

最直接的用途是文档。与其在文件夹里翻找、打开一堆文件、费力重构一个问题的来龙去脉，不如直接提问。在在营项目上，你可以问：“当初这个决定是怎么做出来的？”“那个遗留问题解决了吗？”“这项要求来自哪里？”系统会从整个项目的知识库里抓取相关资料。

听起来不算惊人，但它在解决一个建筑工作的持续痛点：项目越大，越没有一个人能掌握完整历史。信息不仅分布在文档里，更分布在那些生产、接收、解释文档的人身上。能跨着这些累积的材料提问，意味着AI换了一个角色：不再是另一个生产更多信息的参与者，而是维护已有信息连续性的工具。

图片库是另一场测试。建筑事务所收集的参考图以万计，尤其是竞赛和方案初期。攒图容易，找回极难。几个月后想找一张图，得先想起来它来自哪个项目、谁收集的、文件夹碰巧叫什么名字。

我试着让AI在图片入库时分析图片，生成基于建筑学特征的描述：空间组织、材料、氛围、类型、景观，以及以后设计师可能在乎的其他特质。目的不是让AI评判好坏，而是生成足够多的描述信息，让图库换一种接近方式。

于是我不再按文件名查找，而是直接问：

“展示探索‘虚空’概念的项目。”

系统能理解这个请求，在图库的描述和标签中搜索。以前依赖“有人记得东西放在哪”的视觉档案，现在可以通过建筑概念来检索。

让我感兴趣的并不是搜索技术有多高明，而是人与档案的关系变了：那些技术上一向存在的信息，真正变得可用了。

同样的原理可以延伸到办公标准、工作流、历史项目，以及使用AI过程中产生的新知识。BlackBox逐渐变成一层媒介：事务所的不同部分可以通过对话来接近，同时不必假装它们是同类信息。

但做到这一步，我开始意识到，最难的部分其实不是我以为的那个。

真正的难点

一开始我以为难点在AI本身：哪个模型够格？能不能本地跑？对建筑材料的理解准不准？能记住多少？检索是否可靠？

实际上，这些问题的答案大多比我预期的乐观。开源AI生态已经相当成熟，把语言模型连上文档、给图片生成描述，都是顺理成章的事。真正的障碍出现在AI的外围。

一旦BlackBox从个人实验向办公室可用工具迈进，访问权限、凭据、认证、维护、数据结构这些问题立刻冒出来。不同应用要可靠地通信，用户要看到对的信息，一次更新可能让集成崩溃，系统出了毛病还得有人明白全局。

这些事比起当下关于AI的时髦讨论实在乏味，但它改变了我的认识：在建筑事务所引入AI，到底意味着什么。做一个演示版很容易，做一个能用的工作环境则完全是另一回事。模型质量只是问题的一小部分，更关键的是系统能不能嵌入既有的组织、信息与责任结构。

信息本身也给我上了一课。起初很容易幻想：连上足够多材料给AI，组织记忆就自动生成了。不会的。

信息需要上下文。会议纪要可能只写了“决定已做”，却没人记下引发这个决定的讨论。图纸记录的是项目某一瞬间的状态，可能昨天就被一次对话推翻了。两份文档互相矛盾，因为它们诞生于不同阶段。而最重要的项目知识，可能从未被正式记录过。

AI不能消除这些模糊地带，某种程度上它反而让它们更明显。

这个认识把BlackBox的目标从“制造一个权威真相库”上移开。在营建筑项目的知识是临时的，它随设计进展和人员介入不断变化。一个有用的项目记忆，不仅要保留信息，还要保留它的语境：来自哪里、何时生成、与其他信息的关系，以及——关键中的关键——哪里还存在不确定性。

视觉档案暴露了同一问题的另一个变体。AI能比任何人工都一致地描述上千张图片，但描述不是判断。它能识别出庭院、某种材料条件或空间特征，却决定不了一张图为什么对项目重要。

因此我在AI生成的描述旁边保留了人工关键词。两种分类方式各有分工：自动化提供广度，让图库在现实中无法用人工实现的规模上可被搜索；人工输入记录那些只在事务所工作语境里才成立的、特殊的、私人的联想。

这成为一个反复出现的模式：一旦问题涉及规模——阅读、描述、比较、索引、检索——AI极其高效。但那些操作是否有用，依然取决于人来决定什么重要。

所以，也许更有意思的问题不是“有多少建筑知识可以交给AI”，而是“AI如何改变我们处理知识的能力，同时让我们保留下判断的责任”。

随着BlackBox推进，这个区别越来越关键。但实验的另一个副产品更让我意外：我居然亲手把BlackBox建了出来。

建筑师也能造工具

BlackBox内部还有一场我没预料到的实验：我在写软件。

我是一名对计算有长期兴趣的建筑师，但不是程序员。过去这条边界非常清晰：我能定义数字化问题、描述工具应该做什么、甚至能做部分原型，但要开发一个涉及数据库、API和不同软件服务的多用户系统，通常需要专业开发者。

BlackBox期间，这条边界变得模糊了。

很多开发工作是从对话开始的。我描述想实现的目标，和AI讨论可行方案，质疑和细化问题，最终得到一个可以落地的方案。代理式编程工具可以直接处理软件：创建集成、修改代码、帮忙诊断问题。

这个过程不是全自动的。事实上我很快学到一个教训：一次要求太多往往得到糟糕结果。开发最好做成一系列小步骤。先定义一个问题，实现它，看看实际发生了什么，再决定保留、修改还是回退。

失败品比比皆是。有些看似简单的改动，会在别处捅娄子。有些方案虽然能用，但带来了我不想要的依赖关系。偶尔AI解决的与我描述的是略有不同的问题。版本控制因此变得不可或缺：试验速度快到什么程度呢？能回到一个已知可用的状态，和能向前推进几乎同样重要。

这没有让软件开发变成小儿科。BlackBox反而让我看到，一个用起来简单的工具背后藏着多少东西：安全、部署、维护、文档，谁写代码都得面对。

真正改变的是“开始”的门槛。

建筑事务所充斥着各种数字小问题，没人会为它们开发商业软件——它们对某个办公室、某个项目、某种工作方式而言过于特殊。以前我们只能将就，因为开发一个定制方案的成本和问题本身不成比例。

一个事务所可能想要更好的跨项目决策追踪、搜索二十年的竞赛资料、维护某个内部流程，或者把两个不兼容系统里的信息连起来。这些需求都不构成软件产品，但对十个人来说可能是非常趁手的工具。

AI辅助开发改变了这项决策的经济性。如果测试一个想法的成本足够低，“这个值不值得做软件”就不再是问题，问题变成“这问题值不值得花几天研究一下”。

对建筑师而言，这一点可能和生成式AI本身同等重要。建筑行业一向精于把通用软件改造成高度专用的工作方式：模板、脚本、Grasshopper定义、插件、临时拼凑的工作流。智能体开发把这条路大大拓宽了。可能性不是建筑师突然成了软件工程师，而是人们对自己实践的数字环境拥有了更多主导权。

BlackBox对我来说正是这一变化的证据。系统本身很重要，但“我居然能把它造出来”这件事同样重要。

而这件事最终带我回到实验的起点：一个建筑事务所究竟应该保留什么？

从档案到对话

BlackBox始于“建筑事务所如何保留所学”的提问。实验结束时，我不太确定“保留”是不是正确的词。

我们已经保留了海量信息。项目留下图纸、报告、通信、图像和模型，事务所积累标准、参考、工作流和经验。难点从来不是保存，而是维持和这些东西的关系。

项目进行中这个问题就在。团队变大，项目变复杂，知识在人群和系统间散开，没有人掌握全局，关键联系日益依赖个人记忆。项目结束后，这种碎片化就变成档案，离“真正学到什么”又远了一步。

BlackBox没有解决这个问题。它只是证明AI提供了一种不同的对策。

能跨着累积材料提问，改变了存储和检索之间的关系。一张参考图不需要因为有人记得文件夹才能被找到。以前的工作可以成为当下问题的背景。不同位置的信息，可以通过一个共同的对话层被遇到。

这也为AI在建筑实践中的角色指了一条不同的路。当下多数关注都放在生成和自动化上，这很正常。但建筑并不缺少信息，相反，它已不堪重负。AI更有意思的角色，也许是帮我们在已有的信息中航向。

当然，边界很明显。获取信息不等于理解信息。从文件拼出的项目历史永远不完整。隐性知识无法简单地从持有它的人身上提取，无论检索能力多强，判断某件事是否相关、是否最新、是否正确，终究需要人来完成。

对我来说，这正是实验有趣的地方。BlackBox永远不可能成为某种装着建筑事务所智慧的机器。它能成为的，是一个环境：让更多那种智慧保持可接近——对不同的人、在不同的时刻、最终跨过不同的项目。

用来搭建原型的特定技术很快会被取代，有些大概会消失。底下的问题则顽固得多。建筑实践将继续生产任何个人都无法跟踪的信息，知识将继续零散在项目、团队和时间之中。

所以机会也许不在于建一座更好的档案馆，而在于改变档案馆的功能。

让组织记忆变成一场持续对话。