建筑工作室的网站最难处理的，往往不是第一张大图。
真正麻烦的是关系：项目和理念之间的关系，中文、英文、意大利文之间的关系，浏览作品和发起咨询之间的关系，以及上线之后谁来维护这些内容。
如果这些关系没有先被整理清楚，网站会很快变成一个漂亮但脆弱的展示面。首页很好看，项目页也有图，但每次新增内容、补翻译、改联系方式、检查表单，都会牵动一串临时修补。
MILANO UNITO ARCHITETTURA 的网站复盘，核心不在于“做了一个建筑作品集”。我更在意的是，它怎样从一个公开品牌站，逐步变成一套可以维护、可以验证、也可以继续扩展的内容系统。
公开站点是 muastudio.design。中文路径下已经有首页、设计师资料、项目、材料和联系页。站点理念区的一句话是：“建筑不仅是空间的艺术，更是生活的容器。”这句话本来是在说建筑，但也很适合解释这个网站：页面不是单独存在的视觉空间，它们要承载真实的信息和动作。
这个站点真正要承接什么
一个建筑工作室官网至少要回答四个问题。
第一，工作室是谁。品牌名、空间气质、设计理念和视觉语言，需要在第一屏附近建立起来。建筑行业的官网不是 SaaS 落地页，不能只靠一句价值主张和一个按钮结束。
第二，做过什么。项目列表和详情页要能展示作品，也要能保留材料、地点、年份、状态和图像。否则项目页只是相册，不是作品档案。
第三，怎样沟通。潜在合作方可能来自中文、英文或意大利文语境，也可能通过邮箱、WhatsApp、微信或表单进入。联系入口如果只藏在页脚，网站就没有真正承接咨询。
第四，之后怎么维护。项目会增加，文案会调整，翻译会补充，联系信息也可能变化。一个不能被维护的网站，在交付当天看起来完成，过一段时间就会开始失真。
所以这个项目从一开始就不应该只按“页面数量”来判断进度。更重要的是，信息是否各自有位置，数据是否能被保存，路径是否能被验证。
首页不应该把所有任务都背在身上
这次开发里最关键的结构判断，是首页职责的收窄。
建筑工作室官网很容易把所有内容都塞进首页：完整团队介绍、完整项目说明、完整联系表单、完整材料展示。这样做看似信息充足，实际会让首页变成一个没有重点的长页面。每个模块都出现了，但每个模块都不够完整。
更稳定的做法，是让首页只承担第一印象和路径分发。
在这个站点里，首页保留 Hero、Studio Intro、精选项目入口和 Contact CTA。设计师背景交给 About / designer profile 页面，完整项目内容交给 projects，材料内容交给 materials，具体咨询动作交给 contact。
这不是简单的“移动模块”。它改变的是维护边界。
当首页只负责建立气质和引导路径，后续新增项目不会压垮首页；当联系页独立承接表单和沟通方式，首页就不需要同时处理转化细节；当设计师资料离开首页，它可以写得更完整，而不必压缩成几句装饰性文字。
一个小型网站开始变清楚，通常不是因为页面变多了，而是因为每个页面开始知道自己不该做什么。
多语言必须进入内容模型
这个项目有中文、英文和意大利文三套入口。多语言表面上是路由问题，实际上是数据问题。
只做 /zh、/en、/it 路由并不难。难的是让项目标题、描述、正文、地点、客户信息、按钮文案和 fallback 都按语言稳定存在。
如果多语言只停留在界面层，最常见的结果是“假国际化”：用户切换到了英文页面，但项目内容仍然依赖中文字段；或者某些页面翻译完整，某些页面退回占位文案；后台编辑时也不知道自己到底在改哪一种语言。
所以这个项目需要把语言放进内容模型里。
具体实现上，项目内容不只是单个字符串，而是按语言保存的字段。Supabase 里可以用 JSONB 这类结构保存 localized content，前端再根据当前 locale 读取对应内容，并在缺失时有明确 fallback。
这个选择的价值不在“技术更复杂”，而在于它让维护动作变得诚实。后台写入时知道自己在保存哪种语言；前台展示时知道自己在读取哪种语言；测试时也能检查翻译 key 是否对齐。
多语言网站如果没有内容模型，后面会越来越像人工复制。复制在第一版很快，维护时很慢。
技术选择只服务三个边界
这个项目的技术栈可以列很长：Next.js 14 App Router、React 18、TypeScript、Tailwind CSS、next-intl、Supabase、Vercel、Vitest、Playwright。
但对这篇复盘来说，值得展开的只有三个选择。
Next.js 14 App Router 稳定页面和路由边界。
公开页面、项目详情、联系页、后台路径、metadata、sitemap 和 API route 都在同一个应用里处理。对这种体量的品牌站来说，这比一开始拆成多个服务更容易交付，也更容易在上线前整体验证。
next-intl 和 localized content 稳定语言边界。
翻译 JSON、三语路由、后台写入字段和 fallback 逻辑一起工作。这样语言不是一个按钮，而是贯穿数据、页面和维护流程的结构。
Supabase、fixture/fallback 和测试脚本稳定交付边界。
Supabase 承接项目、设置和提交类数据；fixture/fallback 让本地开发和构建不会被远端数据源完全卡住；Vitest、Playwright、i18n parity、typecheck 和 build 检查让“页面能打开”变成“关键路径有证据”。
这三个边界合在一起，形成了一个比较轻的系统：前台负责表达，数据层负责内容，验证流程负责交付收口。
它没有一开始上复杂 CMS，也没有把所有东西都写死在页面里。这个中间状态对小型品牌站很重要，因为它既保留了速度，也留下了继续维护的空间。
上线前的验证不是装饰
网站能部署，不等于网站能交付。
这类项目上线前最容易漏掉的，不是大功能，而是关键路径里的小断点：某个语言页面 fallback 不对，项目详情入口跳错，联系表单没有真正提交，移动端导航遮挡内容，生产域名和本地环境表现不一致。
所以 Web studio 的后期工作里，验证不是最后看一眼页面，而是一个收口动作。
build 和 typecheck 确认代码层没有明显断裂；i18n parity 检查三语翻译 key 是否对齐；Vitest 覆盖基础逻辑；Playwright 检查浏览器路径；生产域名上线后还要做 live readback，确认公开页面真的返回内容，而不是只看部署平台显示成功。
这部分工作不显眼，但决定项目能不能交出去。
很多早期网站的问题，不是没有做功能，而是没有建立“我怎样知道它现在是好的”这条证据链。没有证据链，维护就会依赖记忆；依赖记忆的系统，迟早会变重。
留下来的系统形状
最终留下来的，不是一个只有首页的展示站，而是一组相互分工的路径。
首页建立品牌气质和建筑理念；设计师资料页补足信任背景；项目页和详情页承接作品档案；材料页沉淀内容资产；联系页承接咨询动作；后台和数据层负责让项目、设置和提交类信息可以继续维护。
这就是作品墙和内容系统的区别。
作品墙回答“我做过什么”。内容系统还要回答：内容从哪里来，放在哪里，谁能修改，缺失时怎么办，上线前怎么确认它没有坏。
对一个建筑工作室来说，这些问题不应该被视为额外复杂度。它们本来就是官网要承担的工作。
这次复盘里的判断
第一，建筑工作室官网的核心不是把项目图摆满，而是建立叙事和路径。好的首页应该让人理解工作室的气质，也应该知道下一步去哪里。
第二，多语言要从内容层开始设计。路由和按钮只是入口，真正影响维护的是字段、fallback、后台保存和测试。
第三，小型品牌站不一定需要很重的后台，但需要清楚的数据边界。早期最有价值的不是“功能很多”，而是每次新增内容时不会把结构弄乱。
第四，上线验证是交付的一部分。部署成功只是平台状态，关键路径通过才是产品状态。
如果以后再做类似的建筑、设计或本地服务品牌站，我会先问的不是“首页要多酷”，而是：哪些内容会长期变化，哪些页面应该承担主流程，多语言是否真的进入数据模型，以及交付时有什么证据能说明它已经可以被维护。
这些问题看起来比视觉稿慢一点，但它们会决定网站三个月后是继续变清楚，还是开始靠临时修补维持。