企业官网建设流程全解析

如果你正在用大模型做机器人抓取、UI 自动点击、3D 场景生成、室内导航甚至下棋，大概率已经碰到过同一个尴尬：它能写漂亮代码，能解释复杂业务逻辑，但一问“书架第三层右边那本书，被我往后推了 20 厘米，现在它的坐标大约是多少”就明显露怯。

这个现象不是某个模型的偶发 bug，而是空间推理（spatial reasoning）在大语言模型上的系统性短板。最近 Hacker News 上有人专门提出了一个很现实的问题：How do you correct spatial reasoning of LLMs?，评论区翻来覆去其实都在讨论同一件事——语言模型的空间感为什么这么差，以及能不能靠训练、提示词或外部工具把它“救回来”。

本文不打算复述原帖，而是按工程化的方式把这个问题拆开：先讲清楚空间推理难在哪，再对比提示词、微调、多模态、工具化四条改进路线，最后给出一套可以照做的评测和落地建议。无论你是做 Agent 应用、机器人控制，还是单纯在调数据，这篇文章都值得收藏备用。

1. 这篇文章真正要解决的问题

看到“LLM 空间推理差”这个结论，很多人的第一反应是：那多给点训练数据不就行了？实际上没那么简单。

这里先给一个明确判断：大模型空间推理差，根因不是数据量不够，而是“语言符号”和“空间几何”之间的信息表征不匹配。语言模型从训练目标里学到的是“下一个词最可能是什么”的统计规律，而空间推理要求模型在心智里维护一个连续的几何坐标系，这恰好是统计语言建模最不擅长的隐性任务。

因此，纠正空间推理不是靠“多问几遍”“加个温度参数”能解决的，必须同时调整三层：

• 输入层：如何把空间信息写清楚，让模型更容易解析。
• 推理层：如何引导模型用坐标、符号、代码而不是“感觉”来推理。
• 验证层：如何用可量化的空间任务测试模型是不是真的进步了。

本文适合三类读者：

• 正在做 Agent / 机器人 / 自动驾驶 / 具身智能应用，被“方向错乱”“物体位置算错”坑过的开发者。
• 需要给大模型构建空间推理评测集，验证模型能力边界的算法工程师。
• 想系统理解“为什么语言模型空间感弱”的产品和技术决策者。

读完这篇文章，你可以带走一套“诊断 + 改进 + 验证”的方法：能定位模型在哪种空间任务上失败，能选择至少三种可落地的改进路线，并且能用最小脚本判断改进是否有效。

2. 空间推理到底是什么，为什么对 LLM 如此困难

2.1 空间推理的含义与层次

空间推理并不是一种单一能力。按任务类型大致可以分四层：

人类做这些任务时依赖视觉、动觉和一个“内在空间地图”。语言模型没有这些东西，它只能从训练语料中的文字描述去反推空间关系。语料里有多少“杯子在桌子左边”，它才能学到多少统计关联。一旦组合方式在语料里少见，比如“坐标系有旋转且原点偏移”，它就很难推断。

2.2 模型为什么“答非所问”

用一句话概括：语言模型是离散符号系统，空间推理需要连续几何系统。

具体有三个技术原因：

• 第一，Tokenizer 会把数字拆碎。比如“3.14 米”会被拆成多个 token，模型在做数值进位、距离比较时，天然处于“按 token 猜数”的状态，而不是“按数值算”的状态。
• 第二，推理目标与几何约束不对齐。语言建模目标是最大化下一个词的似然，几何上“自洽”并不在训练目标里。模型没有内部损失惩罚“矛盾的位置关系”。
• 第三，没有视觉或动作反馈闭环。人一旦摆错方向，看一眼或碰一下就能修正，LLM 在纯文本输入下没有这种闭环。

这三点解释了为什么把 Prompt 换成“请仔细思考空间关系”往往无效——问题不在态度，而在机制。

2.3 和视觉模型、传统几何引擎的对比

换个角度理解：如果任务只需要“识别图片里的杯子在哪”，视觉模型和检测模型做得很好；如果任务需要“在三维世界里精确移动物体”，传统几何引擎（仿真器、CAD 内核、SLAM）做得很好。LLM 夹在中间，它要解决的问题是“把人类语言转换成几何约束，再决定下一步动作”。它真正强的不是几何计算，而是语言解析与任务分解。

所以纠正空间推理的总体思路很清晰：不要让 LLM 直接做几何运算，而是让它擅长“翻译”和“编排”，把精确计算交给代码、工具或专用模型。

3. 纠正空间推理的四种路线

当前实践里，改进 LLM 空间推理大致有四条路，各有成本和适用边界。

不一定要互斥。实际项目里最常见的是“提示词 + 符号落地 + 多模态”组合：模型负责理解语言、拆分任务、生成代码，工具负责算坐标，视觉模型负责检测遮挡与姿态。下面按成本从低到高逐一展开。

4. 提示词层：用空间锚点与结构化描述先纠正一部分

4.1 为什么“认真一点”没有用

很多人遇到模型空间答错，第一反应是往 Prompt 里加“请仔细思考”。这种写法基本无效，因为模型不是不努力，而是缺少可引用的几何锚点。

试一下这个例子：

用户：房间里有桌子，桌上有杯子和书，杯子在书的左边30厘米。如果桌子整体右移50厘米，杯子在哪里？

模型可能把“右边”和“移动”混在一起，给出一个模棱两可的答案。原因是 Prompt 里没有给“以哪个点为原点”“是在俯视图还是正视图”这样的空间坐标框架。

4.2 空间锚点提示词模板

更有效的做法是：在 Prompt 里显式定义坐标系、方向和单位。

# 文件路径：prompts/spatial_system.py SPATIAL_SYSTEM_PROMPT = """你是一名空间推理助手，负责把自然语言空间描述转换为结构化坐标。 请遵循以下规则： 1. 默认使用二维俯视图坐标系，原点为房间(0,0)，x轴向右为正，y轴向上为正。 2. 物体位置用 (x, y) 表示，单位是米。 3. 如果用户提到左右，默认按观察者视角转换。 4. 只输出结构化JSON，不要输出多余解释。 示例： 用户：杯子在书的左边30厘米。 输出：{"objects":[{"name":"cup","position":[0.3,0],"anchor":"book"},{"name":"book","position":[0.6,0]}]} """

这个模板的价值不是让模型“变聪明”，而是把空间推理从“开放式问答”变成“受限的结构化翻译任务”，模型犯错的自由度被大幅压缩。

4.3 把推理步骤拆成中间表示

如果任务更复杂，比如旋转、遮挡、相对运动，可以引入“空间状态”中间变量。流程建议是：先让模型列出已知物体、定义坐标系、写出变换步骤，最后再计算。这一步在工程上叫“空间状态显式化”。

# 文件路径：prompts/spatial_cot.py STEP_PROMPT = """请你分四步解决这个问题，并把每一步单独输出： 第一步：列出场景中所有物体及其已知相对关系。 第二步：定义统一坐标系和正方向。 第三步：把用户描述的位置关系写成坐标方程。 第四步：解方程并给出最终坐标。 问题：书架上有三本书，A在B右边10cm，C在A上方20cm。如果整个书架向右平移30cm，C的新位置是什么？ """

用这种模板，即便最终数值算错，你也能从中间步骤定位模型是在坐标系定义、方程转换还是计算环节出错。这是后续评测和排错的基础。

小结：提示词工程只能纠正“语言描述不完整”导致的空间错误，它对真正的几何计算痛点帮助有限。下一步要引入代码。

5. 符号落地：把空间问题变成代码问题

5.1 核心思路

这是目前最推荐的工程路线。思路很简单：LLM 不擅长的连续几何计算，全部交给代码库或几何引擎。

LLM 的职责变成：

• 从用户语言中解析出物体、关系、坐标系。
• 生成可执行的 Python 代码或调用几何命令。
• 把代码执行结果格式化成用户可读的返回。

这样做的好处是：计算精度高、可追溯、可测试。缺点是依赖模型生成代码的正确性，所以仍然要配合严格校验。

5.2 一个可运行的坐标变换示例

下面用二维坐标变换演示一个最简实现。假设 LLM 负责把用户描述解析成变换参数，变换函数用 Python 实现。

# 文件路径：spatial_tool/geometry.py import math from dataclasses import dataclass @dataclass class Point: x: float y: float def translate(p: Point, dx: float, dy: float) -> Point: """平移变换""" return Point(p.x + dx, p.y + dy) def rotate(p: Point, angle_deg: float, center: Point = Point(0, 0)) -> Point: """绕指定中心旋转，角度单位：度""" rad = math.radians(angle_deg) # 先平移到原点旋转，再平移回去 dx = p.x - center.x dy = p.y - center.y new_x = dx * math.cos(rad) - dy * math.sin(rad) + center.x new_y = dx * math.sin(rad) + dy * math.cos(rad) + center.y return Point(new_x, new_y) # 示例：杯子在 (0.5, 0.2)，绕桌子中心 (0.3, 0.4) 旋转 90 度 cup = Point(0.5, 0.2) new_cup = rotate(cup, 90, center=Point(0.3, 0.4)) print(f"旋转后杯子位置：({new_cup.x:.2f}, {new_cup.y:.2f})")

# 运行方式：进入 spatial_tool 目录后执行 python geometry.py

预期输出：

旋转后杯子位置：(0.10, 0.60)

这个例子虽然只涉及平面旋转，但已经能说明问题：当模型不确定“旋转后坐标是多少”时，更好方式是让它调用这样一组可信函数，而不是凭空给答案。

5.3 让 LLM 生成工具调用

在 Agent 场景里，你可以把几何能力注册成一个工具：

{ "type": "function", "function": { "name": "rotate_point", "description": "绕指定中心旋转一个二维点，返回新坐标", "parameters": { "type": "object", "properties": { "x": {"type": "number", "description": "点x坐标"}, "y": {"type": "number", "description": "点y坐标"}, "center_x": {"type": "number"}, "center_y": {"type": "number"}, "angle_deg": {"type": "number", "description": "旋转角度，单位度"} }, "required": ["x", "y", "center_x", "center_y", "angle_deg"] } } }

模型负责把“把杯子绕桌子中心顺时针转 90 度”解析成rotate_point(x=0.5, y=0.2, center_x=0.3, center_y=0.4, angle_deg=90)，几何函数负责返回精确结果。这个组合能显著减少“模型一本正经算错坐标”的问题。

符号落地同样适用于三维场景：可以用numpy、transforms3d、open3d等库处理旋转矩阵、四元数、点云变换。模型只需要会调用 API，不需要自己掌握几何计算。

6. 数据层面：用微调纠正空间推理

6.1 什么时候值得微调

提示词和工具调用能覆盖大多数轻量场景，但有一个情况绕不开：你的模型需要在特定领域里频繁输出坐标或空间判断，而每次调用工具都要多一轮延迟，还容易受模型函数调用能力影响。这时可以考虑微调一个小型垂直模型。

微调空间推理的三种常见目标：

• 输出规范化：让模型学会输出固定格式的空间结构化 JSON。
• 坐标解析：让模型从长文本中稳定抽取物体位置关系。
• 受限推理：让模型在小范围数据集上学会特定几何变换规则。

6.2 微调数据格式示例

下面给出一个适合指令微调的数据格式示例。

{ "instruction": "请把下面这句话转换为空间坐标JSON。", "input": "书桌上有一台显示器，键盘在显示器正前方20厘米处，鼠标在键盘右边15厘米处。以显示器中心为原点，前方为y轴正方向。", "output": "{\"objects\":[{\"name\":\"keyboard\",\"position\":[0,-0.2]},{\"name\":\"mouse\",\"position\":[0.15,-0.2]}]}" }

训练数据准备阶段要注意三点：

• 坐标系必须统一。同一个训练集里不要一会儿用“左上角为原点”，一会儿用“中心为原点”。
• 单位必须统一。混用厘米、米、像素会让模型学到混乱的映射。
• 必须包含反例。比如用户描述里有歧义时，模型应该输出“坐标信息不足”，而不是强行编一个坐标。

6.3 微调实践建议

• 数据规模：先准备 3000～5000 条高质量样本跑通流程，再根据评测结果递增。
• 基座选择：优先选择指令遵循能力强的中小模型，而不是超大模型，便于迭代。
• 评测集隔离：训练集和评测集必须来自不同场景，避免模型背题。
• 回归测试：每次微调后都要跑一遍旧有空间任务评测集，防止“改了空间，丢了语言”。

7. 多模态与具身：把图像和物理反馈引进来

7.1 为什么纯文本有天花板

纯文本输入存在一个信息瓶颈：物体在真实世界里的姿态、遮挡、光照和拓扑关系，很难用语言完整表达。比如“杯子在书后面”这句话在语言上只有一层关系，但视觉上“挡住多少”“露出多少”会直接影响“能否抓取”这样的下游决策。纯语言模型无法得到这类信息。

7.2 视觉-语言模型的基本改造思路

当项目需要处理真实图像时，建议把 LLM 放在一个更大的“感知 - 推理 - 执行”链路里：

• 感知层：用目标检测模型或视觉语言模型输出物体的 2D/3D 位置。
• 推理层：LLM 接收这些定位结果，结合用户语言生成动作计划。
• 执行层：规划好的坐标与路径交给运动控制或仿真器执行。

这里的关键变化是：空间感知从“模型脑补”变成“传感器返回”。LLM 不再需要猜测物体在哪，它只需要根据传感器数据推理下一步动作。这种改造的实际效果通常远好于让纯文本 LLM 直接输出“物体大概在图片中间偏右”。

7.3 具身智能给我们的重要启示

具身智能领域有一个共识：智能体需要通过与环境的交互闭环来建立空间概念。模型预测的坐标如果和真实环境不符，环境反馈会立刻暴露错误，从而让模型有机会修正。

这种做法的工程化形式包括：

• 在仿真环境中不断生成空间任务，让模型根据碰撞、遮挡、距离误差等反馈更新空间状态。
• 用强化学习或行为克隆把“空间判断 → 动作”的映射固化进模型。

对绝大多数 CSDN 读者来说，直接上具身方案成本很高，但可以借鉴它的思想：给你的 LLM 空间推理加一个外部校验器。模型输出坐标后，用一个简单的几何规则让它自检，就能减少不少低级错误。

8. 如何评测空间推理是否真的被纠正

8.1 建立自己的评测集

空间推理最怕“看起来变聪明，一测就露馅”。所以改进前，建议先搭一个最小评测集。评测集至少覆盖三类任务：

• 物体关系判断：左右、前后、上下。
• 数值变换：平移、旋转、缩放后的坐标。
• 多步任务：结合多个相对关系的推导。

每个任务准备 20～50 题，分成 A/B 组，避免模型记忆顺序。

8.2 自动评测脚本

一个朴素的自动评测方法是：让模型输出 JSON 坐标，再用程序比较与真值的差值，控制在阈值内算通过。

# 文件路径：eval/spatial_eval.py import json import math def distance(p1, p2): return math.sqrt((p1["x"] - p2["x"])**2 + (p1["y"] - p2["y"])**2) def evaluate(model_output, expected, threshold=0.05): """model_output: 模型生成的JSON字符串，expected: 标准答案JSON""" try: pred = json.loads(model_output) except json.JSONDecodeError: return False, "JSON解析失败" if "objects" not in pred: return False, "缺少objects字段" for obj in pred["objects"]: name = obj["name"] if name not in expected: continue dist = distance(obj["position"], expected[name]) if dist > threshold: return False, f"{name}坐标误差{dist:.3f}超过阈值" return True, "通过" # 示例 expected = {"keyboard": {"x": 0, "y": -0.2}, "mouse": {"x": 0.15, "y": -0.2}} model_out = '{"objects":[{"name":"keyboard","position":[0.0,-0.21]},{"name":"mouse","position":[0.14,-0.19]}]}' ok, msg = evaluate(model_out, expected) print(ok, msg)

运行：

python eval/spatial_eval.py

预期输出：

True 通过

如果模型输出解析失败或坐标偏差过大，脚本会直接给出失败原因，方便你定位问题。

8.3 如何解读评测结果

• 如果模型在“一阶关系”全对，但在“旋转”全错，说明它对坐标变换的几何规则没有掌握，优先走“符号落地”路线。
• 如果模型在“结构化 JSON 输出”环节频繁解析失败，优先做输出格式微调。
• 如果模型在“真实图像”任务上失败，说明它缺少视觉信号，必须引入多模态感知。

评测的价值不在于得出“模型空间推理 80 分”，而在于告诉你“在哪个环节丢分”，从而决定下一步怎么改进。

9. 常见问题与排查思路

10. 最佳实践与工程建议

从工程角度看，我建议把“纠正空间推理”当成一个系统问题，而不是单独优化模型。

第一，永远让精度敏感运算远离大模型。空间推理里的加减乘除、旋转矩阵、路径计算，尽可能交给人可读、可测试的代码模块。大模型负责“语义解析”和“任务编排”，这就已经覆盖了大部分收益。

第二，Prompt 要模板化而不是靠感觉。把“空间锚点 + 坐标系定义 + 结构化输出”固化成一个模板，不同任务复用同一套坐标系约定，比每次临时写提示词稳定得多。

第三，建立回归测试。空间推理是典型的“改一处坏一片”问题。每次调整 Prompt、微调模型或换基座模型，都要跑一遍已有的空间评测集，避免顾此失彼。

第四，对模糊输入要拒绝回答。真实用户描述空间关系经常有歧义，比如“右边”没有说明是观察者视角还是物体自身视角。好的系统应该提示用户补充，而不是让模型“猜”。这就需要在评测集里加入“信息不足应该拒绝输出”的样本。

第五，安全边界。如果空间推理被用于机器人、自动驾驶、无人机等物理世界场景，必须设计兜底机制：模型输出的坐标或路径要经过几何合法性检查，误差超过阈值就中止执行，绝不能直接把未校验的结果送到执行器。

11. 总结与后续学习方向

这篇文章想表达的核心判断是：LLM 空间推理弱是表征不匹配的结果，纠正它的关键不是让模型更努力，而是调整信息形式、推理路径与验证方式。提示词工程能解决“描述不完整”的问题，符号落地能解决“几何计算不精确”的问题，微调能解决“输出不规范”的问题，多模态和具身能解决“缺少真实感知”的问题。四者不是单选题，而是按成本从低到高的组合拳。

如果你接下来要动手，我建议按这个顺序实践：

1. 先搭一个 20 题左右的空间推理评测集，跑一遍当前模型，找出失败集中在哪一类任务。
2. 给 Prompt 加上坐标系、锚点和结构化输出要求，看一类问题能否改善。
3. 把数值计算部分替换成代码工具或函数调用，再跑一遍评测。
4. 如果还不够，再考虑微调或引入视觉感知。

后续可以深入的方向包括：三维旋转与四元数表示、复杂路径规划、空间常识知识的注入，以及将空间推理能力与机器人实际控制闭环打通。空间推理不会成为大模型天生强项，但它完全可以通过合理的系统设计，变成可预测、可评测、可交付的工程能力。