TokenPunk 参考案例目录说明

本目录保存 TokenPunk 项目用的参考对象档案。单篇笔记的目标不是把案例转译成玩法方案，而是把案例本身为什么值得看、哪里有设计闪光点、哪些结构能被复用讲清楚。

命名规则

文件名优先暴露三件事：参考类型、地点或来源、项目名与设计方。不要只写项目名，也不要把未核实视频、AIGC 图和真实建筑混成同一类。

标准格式

• 城市 / 片区方案：城市_<国家地区或城市>_<项目名>_<设计方或系列>.md
• 建筑 / 单体方案：建筑_<国家地区或城市>_<项目名>_<设计方>.md
• 竞赛 / 推演概念：建筑概念_<竞赛或平台>_<项目名>_<核心命题>.md
• 视觉 moodboard：视觉参考_<来源>_<主题>.md
• 视频线索待核：视频待核_<地点或项目>_<来源线索>.md
• PV / 角色参考：PV参考_<作品或组合>.md、角色参考_<对象>.md

使用原则

• 城市_ 用于片区、总体规划、未来城、城市更新、系列区域开发。
• 建筑_ 用于有明确地点、设计方、项目身份的单体或综合体。
• 建筑概念_ 用于竞赛、概念塔、推演型方案；不暗示可落地。
• 视觉参考_ 用于 AIGC、社媒图集、纯风格板；不写成建筑事实。
• 视频待核_ 用于只有视频或二次来源，尚未找到一手 source 的对象。

单篇笔记结构

优先使用 TPL_参考案例。正式案例建议保持以下顺序：

1. 收录判断：一句话说明为什么值得看。
2. 项目身份：项目名、设计方、地点、年份、状态、类型。
3. 来源：官方页优先，其次竞赛页、事务所页、公开视频、媒体补充。
4. 设计命题：这个方案试图解决什么问题，或提出什么城市 / 建筑想象。
5. 闪光点拆解：用专业维度讲清楚可借鉴之处。
6. 图像阅读：每张图说明它在证明什么，不只写“主视觉”。
7. 可参考点：沉淀为可复用的设计观察，不直接写 TokenPunk 方案。
8. 现实状态 / 复核边界：区分已建成、竞赛、概念、视频待核、AIGC。

闪光点提取维度

不是每篇都要覆盖全部维度，但至少选择 4-6 个最能解释该案例的角度。

• 城市关系：它如何处理地貌、交通、片区边界、公共路径和天际线。
• 体量策略：它如何把高度、尺度、密度、悬浮、桥接或地景化做成记忆点。
• 外立面 / 结构：表皮、承重、模块、植物、屏幕、反光材料或动态构件如何形成识别度。
• 功能机制：它的核心不是造型时，机制是什么，例如物流、医疗、储能、污染治理、赛事切换。
• 高科技呈现：AI、自动化、LED、可变结构、能源系统、无人机或传感媒介如何被可视化。
• 近人体验：人如何进入、停留、观看、消费、疗愈、运动或参与事件。
• 日夜 / 事件模式：同一个空间是否能从日常切换到演出、赛事、夜景、节庆或危机状态。
• 生态 / 可持续叙事：绿化、能源、水、材料、废弃物、生物栖息是否只是表皮，还是进入系统。
• 传播符号：是否有一眼能记住的剪影、名称、母题或社媒图像。
• 游戏化参考价值：它是否能转成关卡地标、路径节点、系统可视化、阵营空间、任务场景或世界观证据。

配图标准

• 正式建筑 / 城市案例：优先 4-6 张图，覆盖主视觉、场地关系、近人体验、功能图、剖面 / 系统图、夜景或事件模式。
• 概念竞赛案例：优先保留图板、剖面、流程图和问题定义图，不只保留最终渲染。
• AIGC / moodboard：可以多图，但必须明确“只作为视觉母题，不作为建筑事实”。
• 视频待核案例：可用封面和 storyboard 帧，但必须标明二次来源和待复核边界。

质量自检

一篇案例笔记完成前，至少回答这些问题：

• 读者能否在 30 秒内知道它为什么值得看？
• 除了“长得科幻”，是否讲清了它的空间、结构或系统机制？
• 图片说明是否解释了图像证明什么，而不是只描述图中有什么？
• 是否区分官方事实、媒体补充、视频线索、AI 生成和个人判断？
• 是否保留了对 TokenPunk 有用的观察，但没有直接写成玩法方案？