作品名称玄境智居人工智能室内风水顾问 / 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.6GBQ4_K_S 约 117.1GBQ4_K_M 约 121.6–124.8GB。即便关闭桌面图形界面、把可用内存挤到约 103GB这些理所当然的 4-bit 量化版本依然装不下。这是一个纯算术约束不是可以靠调参解决的性能取舍。最终我们选定 Q3_K_M91.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_tokens800在生产环境下频繁返回空的content且没有报错——finish_reason显示为length说明模型的推理过程本身就把预算耗尽了根本没来得及写最终答案。这是一种极难排查的静默失败模式最终通过实测不同max_tokens取值、把预算提升到 4096 并显式设置reasoning_effort: low解决。坑二SDK 声称支持、实际并不生效的超时参数。阿里云 DashScope SDK 的MultiModalConversation.call()接受一个timeout参数但实测发现它并不会真正生效——即便传入timeout30仍然观察到约 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 在它真正擅长的地方语言表达、图像生成发挥价值把它不擅长的地方精确的空间几何判断交还给确定性的代码。这或许比追求一个模型解决一切更朴素但也更可靠。项目完整开源在 GitHubhttps://github.com/muhammad-wei/fengshui-ai​​​​​​​