企业官网建设流程全解析

作品名称：玄境智居（人工智能室内风水顾问 / AI Interior Feng Shui Consultant）

团队名称：Visioneer ——Different vision united, we are one.（视角各异，同心同行）

赛事：NVIDIA DGX Spark Hackathon

一、为什么做这个题目

风水，作为一门流传千年的东方空间美学，本质上是一套关于"人与环境如何相处"的经验规则体系——采光、动线、私密性、心理安全感……剥离掉玄学的外壳，这些规则大多可以还原为可测量的几何关系：一扇窗的朝向、一张床与门的相对位置、一面镜子是否正对床铺、一根横梁是否压在座位正上方。

这正是我们选择这个题目的原因：它是一个天然适合"确定性计算 + 生成式模型"混合架构的场景。纯粹交给大模型"看图说话"式地判断风水，容易产生几何幻觉——模型可能"觉得"床对着门，但实际坐标关系并非如此；而纯粹的规则引擎又缺乏把冰冷的判定结果转化为有温度、可执行建议的能力。玄境智居的核心工程理念，就是让这两者各司其职：几何计算负责"对不对"，大模型负责"怎么说、怎么改"。

二、产品能力：两个真实场景

玄境智居面向房屋装修的两个典型阶段：

场景 A · 毛坯空间：上传一张未装修房间的照片，说明或语音输入房间用途（如"主卧""书房"），系统识别窗户、房门、墙体等结构元素，推断房间朝向，并给出符合风水原则的家具布局建议（床、书桌、衣柜的推荐摆放位置），同时生成一张对应的效果图。

场景 B · 已装修空间：上传一张已有家具的房间照片，系统检测床、沙发、镜子、横梁等物品，对照十条量化风水规则逐一核验，输出问题清单（例如"镜子正对床铺""横梁压顶""左右视觉高度失衡"），给出"宜/忌"行动建议，并直接在原图上生成编辑后的"效果对比图"——不是泛泛的文字建议，而是真的能看到"加一盏落地灯、加一个书架"之后房间会是什么样子。

整个界面支持中英文一键切换，且不只是界面文案的翻译——切换语言后，大模型生成的建议内容本身会用目标语言重新表达（用真实的中文风水术语验证过，而不是机器翻译腔），语音朗读功能也会切换到对应语言的音色。

三、技术架构：谁在本地跑，谁在云端跑

上图展示了玄境智居的完整技术架构。核心设计原则很简单：确定性计算放在本地，生成式推理交给云端——让每项任务跑在最合适的地方。整个系统由一条清晰的流水线串联，本地orchestrator.py作为总调度，根据用户选择的场景自动决定执行路径。下面从上到下快速过一遍各模块的职责：

感知层：YOLO-World —— 本地 GPU。这是系统的"眼睛"。上传房间照片后，YOLO-World 模型在本地识别出门、窗、床、沙发、镜子、横梁等关键元素，输出每个物体的精确位置坐标。放在本地的原因很直观：图像不必上传云端再等返回，省去了数百毫秒的网络延迟，而且模型体积小巧，在 DGX Spark 的 GB10 Blackwell GPU 上跑得飞快。

规则引擎：geometry.py + facts.py —— 本地 CPU。这是系统的"大脑"。拿到物体坐标后，规则引擎开始逐条核验十条量化风水规则：床和门的夹角对不对、镜子是不是正对床、横梁有没有压在座位上方、房间左右两侧的视觉高度是否失衡……这些计算——角度、距离、重叠判断——全部用确定性代码完成，不依赖任何 AI 模型的猜测。放在本地同样是零网络开销、零延迟，算完立刻出结果。最终输出一份结构化的 JSON，例如"床尾距门 1.2 米，夹角 15 度，判定为吉"。

大模型服务：DeepSeek Chat + Step-3.7-Flash —— 云端 API。这是系统的"嘴巴和画笔"。规则引擎输出的 JSON 虽然精准，但没人愿意读原始数据。我们把大模型处理拆成两步：

第一步，DeepSeek Chat将 JSON 转述为有温度、可执行的风水建议初稿——它会用上"藏风聚气""横梁压顶"这类传统术语，让建议听起来像是一位懂风水的顾问在说话。

第二步，阶跃星辰 Step-3.7-Flash将初稿校验为严格的 JSON 结构（LayoutPlan 或 AdjustmentReport），确保最终输出字段完整、格式可靠，前端可以直接解析和渲染。两个模型分工明确：一个管表达，一个管格式。

图像生成：Wan2.7-Image —— 云端。拿到校验后的布局方案后，Wan2.7-Image 负责生成毛坯空间的效果图，或对已装修房间的原图进行定向编辑。生成的图片直接返回前端，用户可以并排对比原图和 AI 优化后的效果。

语音服务：SenseVoice + edge-tts —— 云端。用户可以用麦克风说话，SenseVoice 将语音转成文字送入系统；也可以点击"朗读"按钮，edge-tts 将建议文本转成语音播放。切换语言时，TTS 音色也会自动匹配。

前端：Gradio Web 界面 —— 用户设备。前端是整个系统的"门面"，同时连接本地服务和云端 API，将各层输出整合为统一的体验：上传照片 → 检测结果可视化 → 风水判定清单 → 自然语言建议 → 前后对比视图。中英文一键切换不只是改界面文案，还会通过 orchestrator 切换大模型的目标语言，确保建议内容用真实的风水术语或地道的英文表达。

整体数据流向可以概括为一条清晰的链路：本地检测 → 本地计算 → 云端转述 → 云端校验 → 云端生成 → 前端整合。每一层都跑在最适合它的位置——需要低延迟、确定性结果的留在本地，需要语言理解和图像创造力的交给云端。

感知层与规则引擎运行在 DGX Spark 本地的 GB10 Blackwell GPU 上——这也引出了本文接下来要讲的一段开发历程：我们曾经计划把大模型推理也完全放在本地，但在真实工程约束面前做出了务实的取舍。

四、开发历程：一次关于"应该在哪里跑模型"的真实决策

这是我们认为最值得记录的一段经历，因为它不是"一路顺利"的成功学叙事，而是一次典型的、在真实约束下做工程判断的过程。

最初的目标：既然 DGX Spark 主打 128GB 统一内存，专为运行大参数量模型而生，我们的第一反应自然是把阶跃星辰的Step-3.7-Flash（一个 1980 亿参数的稀疏混合专家模型，每 token 激活约 110 亿参数）通过llama.cpp完整部署在本地。

量化选型的真实计算：我们没有停留在"应该能装下"的直觉判断，而是实测了各个 GGUF 量化版本的真实体积——Q4_0 约 113.6GB，Q4_K_S 约 117.1GB，Q4_K_M 约 121.6–124.8GB。即便关闭桌面图形界面、把可用内存挤到约 103GB，这些"理所当然"的 4-bit 量化版本依然装不下。这是一个纯算术约束，不是可以靠调参解决的性能取舍。最终我们选定 Q3_K_M（91.8GB）作为留有真实余量的可行方案，并且成功地从阶跃星辰面向 Blackwell 架构的 CUDA 加速llama.cpp分支构建出了可运行的推理服务。

真正的瓶颈：不是算力，是网络。构建完成后，我们卡在了一个完全没预料到的环节——这台设备实测的持续下载带宽只有约 5–8MB/s，下载一个 92GB 的模型文件需要数小时，这与限时冲刺的黑客松节奏完全不兼容。我们甚至一度因为带宽测量方法的误差（单连接 curl 测速被并发下载抢占带宽，导致误判为"几乎不可能完成"），来回调整了两次决策——这个过程本身也提醒我们：任何一个"不可行"的结论，都值得用真实数据反复验证，而不是凭一次测量下定论。

务实的转向：既然阶跃星辰官方的云端 "Step Plan" API 提供的正是同一个 Step-3.7-Flash 模型，我们把本地部署与量化选型的工程成果作为可复现的文档保留下来（api_clients/step_client.py中预留了随时切回本地部署的接口设计），转而使用云端 API 完成实际的提交版本——把 DGX Spark 的本地算力集中投入到真正适合本地运行、且能直接受益于低延迟的环节：YOLO-World 检测与几何规则计算。

五、藏在细节里的优化：三个真实踩过的坑

坑一：推理模型的"沉默失败"。Step-3.7-Flash 是一个推理模型，会先在独立的reasoning字段里"打草稿"，再输出最终content。我们最初给格式化任务设置的max_tokens=800在生产环境下频繁返回空的content，且没有报错——finish_reason显示为"length"，说明模型的推理过程本身就把预算耗尽了，根本没来得及写最终答案。这是一种极难排查的静默失败模式，最终通过实测不同max_tokens取值、把预算提升到 4096 并显式设置reasoning_effort: "low"解决。

坑二：SDK 声称支持、实际并不生效的超时参数。阿里云 DashScope SDK 的MultiModalConversation.call()接受一个timeout参数，但实测发现它并不会真正生效——即便传入timeout=30，仍然观察到约 300 秒的静默挂起。这类问题最危险的地方在于：它在大多数正常请求下完全不会暴露，只有在网络抖动或上游排队时才会触发，而一旦触发就会让整个演示卡死。我们最终用ThreadPoolExecutor在客户端强制包了一层真正生效的硬超时，确保任何一次卡死的请求都不会无限期阻塞用户。

坑三：让模型"编辑"图片时，指令要给动作，不要给诊断。场景 B 最初把"问题诊断文字"（例如"左侧明显低于右侧"）直接作为图像编辑指令传给 Wan2.7-Image，结果生成的图片与原图几乎没有区别——因为模型收到的是一段"这里有问题"的描述，而不是"具体要做什么"的指令。改为传入"宜"清单中的可执行建议（"在左侧摆放一个高书架和一盏落地灯"）之后，生成结果立刻变成了真实、有针对性的画面改动，在多张真实房间照片上都得到了验证。

这三个问题有一个共同点：它们都不是"写不出代码"的问题，而是"系统在特定条件下会悄悄给出错误结果"的问题——这类 bug 只有通过真实调用、真实数据、真实边界条件的反复测试才能发现，也是我们认为最值得写进这篇文章的工程细节。

六、团队 Visioneer

我们是Visioneer——名字来自 "vision" 与 "pioneer" 的组合，团队口号是"Different vision united, we are one."（视角各异，同心同行）。这也恰好呼应了这个项目本身的技术哲学：确定性几何计算与生成式大模型、本地算力与云端服务、东方传统智慧与现代 AI 工程——不同的"视角"，最终汇聚成同一套能真正跑起来、真正解决问题的系统。

七、致谢

感谢NVIDIA提供的 DGX Spark 硬件平台与算力支持，感谢赞奇科技（XSUPERZONE）对本次黑客松的组织与平台支持，感谢StepFun（阶跃星辰）提供的 Step-3.7-Flash 模型与云端 API 接入。正是这些支持，让我们能够完整地走完从"本地部署尝试"到"务实工程决策"再到"真实可用产品"的全过程。

八、结语

玄境智居目前仍是一个黑客松原型：延迟尚未压到理想区间，部分检测精度仍有提升空间，但它验证了一个我们认为值得坚持的方向——让 AI 在它真正擅长的地方（语言表达、图像生成）发挥价值，把它不擅长的地方（精确的空间几何判断）交还给确定性的代码。这或许比追求"一个模型解决一切"更朴素，但也更可靠。

项目完整开源在 GitHub：https://github.com/muhammad-wei/fengshui-ai

​​​​​​​