别让 AI 盖出一座温彻斯特神秘屋
一栋盖了 38 年、却从未有过图纸的房子，和我们用同样方式交付的应用。每一个新功能各自为政，跟谁都接不上。本文给出六种架构层面的做法，让你已经盖好的那些房间，终于有了一张能遵守的蓝图。
Sarah Winchester 花了 38 年，一间房接一间房地往上盖，没有总图，没有截止日期。木工轮班干活，施工从不停工。这栋真实的房子就在加州圣何塞，紧挨着 I-280 高速。1906 年旧金山大地震震坏了部分房屋，她干脆把受损楼层封死，转去别处接着盖。今天留下的结构里，有爬着爬着钻进天花板的楼梯，也有打开就是一面墙的门。听着是不是很像企业软件？
大多数用 AI 快速原型搭出来的应用，就是这么盖的。现在加一个功能太便宜了。这个屏幕上挂个 copilot，那个屏幕上放个摘要器，别处再来个「帮我起草」按钮，外加一套根本说不通的数据模型，每个都是花一下午拼出来的。每个功能都单干。他们还专门给它做了虚拟导览。没开玩笑。退后一步看，你就有了一栋谁进去都找不到路的房子。
行业现状已经摆在那儿了。近九成的组织都在用 AI，但大多数还没围绕它重写自己的工作流。这个落差用一个数字就说清了全部问题。新功能来得比任何能承载它们的结构都快，于是每个功能上线时都自带一套术语、自己的输出格式，以及自己那套「出错了该怎么办」的私房主张。这本质上是信息架构问题，而架构恰恰是你们团队本来就会搭的东西。
那栋房子，还有大多数企业产品，都是这个样子。真不夸张。
2008 年，我在博客上转载过一封流传多年、作者无人知晓但值得大力致谢的信，标题叫《如果建筑师得像网页设计师那样干活》。一位客户给建筑师写信，要求盖一栋卧室数量在 2 到 45 之间灵活可调的房，图纸要能轻松加房间、删房间；而且真的设计还没开始，就得先交出全套蓝图，审批通过后 48 小时内必须封顶。它好笑，是因为它根本不可能。现在它可能了。
原型化让这些需求都变得很容易满足，而随着成本一起消失的，是过去那种逼着人先画图纸的阻力。接下来要讲的是改造，不是重建。针对你已经上线的应用，有六个动作可以做；只要稍加留意，今天正在开发的项目也一样适用。
对象模型要排在功能清单前面，否则功能会自己造出不在任何楼层上的房间
先把脚手架和框架固定下来
动手做第一个功能之前，先定义对象模型。注意，不是数据库 schema，而是团队共享的那一份：你的产品真正围绕哪些名词运转，每个名词又能对应哪些动词。
项目可以归档，文档可以分享；发票可以审批、可以付款，但永远不能被归档——因为你的业务本来就不是这么运转的。这些约束才是真正有价值的部分，而它们只有被人写下来才存在。这就是其他一切赖以搭建的脚手架，也是另外五个动作所挂靠的框架。
当一个功能声称能「创建跟进事项」时，这个需求必须落在某个真实存在的东西上：有明确的形态，也有存放它的地方。如果「跟进事项」根本没人定义过，那你就等于放任这个功能凭空变出一间不存在的房间。
这些约束才是真正有价值的部分，而它们只有被人写下来才存在。
命名占了这项工作的绝大部分，而团队内部对此的共识远没有大家以为的那么牢固。UX Components 对比过不同设计系统对同一事物的不同叫法，拿它来照照自己的词汇表会很有启发。
一份共享的对象模型会告诉每个功能：什么东西存在、可以对它做什么、不能做什么。这样开发出来的东西才会长在你自己的世界里，而不是一个平行的世界。
行动清单
先写名词清单，再写功能清单。 把真实存在的对象逐个列出来，并列出每个对象允许的动词。功能想做的事如果不在清单里，就把它当成一个待补齐的缺口，而不是可以糊弄过去的事。
把每个动作都对照真实对象检查一遍。 凡是出现「这个功能可以创建、更新或删除 X」的说法，就确认 X 有明确定义的形态，也有持久化的存放位置。如果没有，这个交互就是在凭空造物。
发布一份语义契约。
一页纸，写清对象、动词和关系，由工程和设计团队共同签字确认，确保双方基于同一个世界来构建。一组有名字的行为，加上一整套封闭的形状，二者都来自同一个库。
先组合已有模式与组件
在单个输出之上，托着一个小的交互模式库，用来约束一个功能在时间维度上的行为方式。
建议、起草、总结、分类、规划和确认。每个都是有名字的行为，定义了从进入、进行中、结果、恢复到关闭的状态流转。
大多数团队有40个功能却零个模式，所以每位工程师和设计师都在现场临时决定失败时该怎么办，40个人各自做决定，就会产出40个不同的答案。失败在这里不是边缘情况。在模式层面设计一次失败处理，每个功能都能继承。
这个库对功能“展示什么”的约束，应该和对功能“怎么表现”的约束一样严格，而且这也不是你要引入的什么外来学科。开发者一直在构建受控语言，设计师也是如此，只是大多数时候做得不够好。
一个只允许四个值、拒绝第五个值的枚举是一种受控语言。一个只要载荷不符合schema就报错的接口契约也是一种。工程师已经在收窄代码被允许表达的内容，因为不这么做的替代方案，就是一个所有调用方都在猜、每次集成都最终以没人能追踪的方式崩溃的系统。
一种受控语言，到处都说，不再为每个功能发明专属界面。设计系统就是同样的动作，只是对准输出而不是内部实现——一种刻意收窄的词汇表，就像简化技术英语（Simplified Technical English）让飞机手册保持无歧义一样。一个功能没资格渲染自由漂浮的散文块。
这就是组件受控词汇表的样子。我在UX Components这里有一整套目录。它返回结构化载荷，解析到你已经拥有的组件。一种受控语言，到处都说，不再为每个功能发明专属界面。
行动项
给你的交互模式命名。
别让 AI 盖出一座「温彻斯特神秘屋」
温彻斯特神秘屋（Winchester Mystery House）是一座不断加盖的宅子：楼梯通向半空，门后是一堵墙。别让 AI 把你的产品盖成这样。
先把已经上线的东西反向拆解成五六个有名字的行为模式，再写清每个模式从进入到恢复各自负责哪些状态。新功能从这套库里拼装：做下一个功能时，用现成的模式和组件来组装；确实缺一个不存在的，就特意补上一个，而不是临时就地糊一个。把各功能的恢复流程统一起来，在模式层面一次性设计好错误、空状态、低置信度和超时这几种状态，让全部四十个界面都继承同一套行为，并且持续重构。给输出组件设白名单，新增的要单独过审。把功能输出限定在一个封闭集合里——卡片、差异对比、表格、时间线行、表单预填——谁想另做一个定制界面，必须先说明集合里为什么没有一种能承载它。返回结构化数据，而不是一整段散文：把自由文本输出改写为结构化数据，让前端用已有组件渲染，数据结构直接由现有组件的属性推导出来。地图必须描述人们今天真正住着的那栋楼。
保持一份「活的」信息架构
大多数团队手里的信息架构，都只是上线时的一份产物。有人在首次发布前画了张图，贴进 PPT，之后再也没打开过那个文件。那之后上线了四十个功能，这张图一次都没动过。
这件事比听起来更要紧，因为后面每一步怎么走，都取决于你能不能看清产品现在的形状。你没有图，就无从对齐那些已经走样的地方；你没画过某一层，也就没法把功能规划到那一层。只存在于首次发布前的地图，描述的是一栋已经没人住的楼。它必须是一份活的文档。
一份持续维护的信息架构，是给人和 AI 代理（agent）共用的工作文档，而不是交付物：包含路由、层级、什么东西放在哪儿、每一层上会出现哪些对象；功能上线时就更新，而不是等有人来要才更新。
我之前说过，站点地图是一门失传的手艺，现在依然这么看。它能给你一张产品的鸟瞰图——而当功能一个屏幕一个屏幕地到来时，没人手里有这张图。
行动清单
功能上线时，重画这张图。
把「更新信息架构」写进完成定义（Definition of Done），让文档和产品同步前进，而不是落后一年。地图要直接从路由生成：从路由和导航代码里反推出当前结构，再跟画出来的版本对照——毕竟代码才是用户今天真正走过的那条路。每一层都要有明确的负责人，说清楚谁来决定哪一层放什么，否则新功能会一个接一个地塞进「当时刚好空着」的界面里。你还要继续住的房子，就是那栋你必须一直修的房子。
按固定节奏重构
1906 年的地震震坏了 Sarah Winchester 房子的一部分，她没有去修，而是把受损的楼层封起来，另找地方接着盖。这种本能，在每个「上线了替换功能、却把旧功能留在功能开关后面没人再管」的团队身上都能看到。前面说的三个动作只是一次快照，而快照会过期。语义契约里从没命名过的新对象会冒出来；项目赶工期，有人「就这一次」绕开了模式库；某个组件因为原版不太合适被复刻一份，于是现在有了两个行为不一样的版本。这些都不是失职，只是没人专门排时间做对齐时，东西自然堆积起来的样子。把受损的侧翼封起来，确实比修它便宜——直到你某天真的需要用到那部分房子。
所以「对齐」不能是排在路线图之后才做的事，因为那样永远轮不到它。它要进路线图，像其他工作一样估好工作量、定好档期。架构能保持准确，前提只是你愿意一直付这笔账。