企业官网建设流程全解析

“把苹果放在杯子的右侧，然后把盘子移到苹果左边，最后告诉我盘子在杯子的什么方向？”——如果你把这类问题抛给当前的主流大模型，得到的答案可能让你意外：它大概率能写出流畅的推理过程，却在最终方向上给你一个完全相反的结论。

这不是个别模型的缺陷，而是 LLM 在空间推理（spatial reasoning）上普遍存在的短板。最近 Hacker News 上就有工程师发起“How do you correct spatial reasoning of LLMs?”的讨论，很多人发现：语言模型可以写诗、写代码、做数学题，但在“左”“右”“前方”“旋转后朝向哪里”这类基础空间问题上，会表现得不如一个三岁小孩。

本文的核心判断是：空间推理不能只靠“更聪明的提示词”来根治。真正有效的修正路线，是把语言推理和空间计算分开——该让模型理解的部分，用提示词和思维链强化；该算的部分，交给工具和环境反馈。

读完这篇文章，你会掌握一套从“诊断 LLM 空间推理缺陷”到“结构化提示词修复”“外接坐标计算”“回归评估”的完整实践方法，可以直接用在自己项目里。

1. 为什么空间推理成了 LLM 的“硬伤”

1.1 什么是空间推理，它到底解决什么问题

空间推理，指的是模型对物体位置、方向、距离、路径以及视角变化进行理解和推断的能力。

它不只是“知道苹果在桌子上”这种静态描述，而是能完成以下任务：

• 判断相对方位：A 在 B 的左边、右边、前方还是后方。
• 完成视角转换：小明面向北，他的左手边是什么方向。
• 解决路径规划：从一个点出发走几步、转几个弯，最后到了哪里。
• 理解三维空间：物体体积、遮挡关系、远近关系。

在现实项目中，空间推理直接影响很多应用的体验：

• 智能家居助理：用户说“把客厅左边那盏灯打开”，模型要能理解是哪个方向的灯。
• 机器人指令系统：让机械臂把零件放到目标的左侧，需要精确的方位换算。
• 自动驾驶与导航对话：乘客问“下一个路口向右转后，我的目的地在左边还是右边”。
• 游戏 AI / 虚拟现实：NPC 根据玩家位置做出方向性描述和移动决策。

换句话说，空间推理不是理论问题，而是已经写进产品需求里的硬功能。如果模型在这类问题上不可靠，整个对话系统的可信度都会被打折扣。

1.2 LLM 空间推理弱的三个根源

要修正一个缺陷，先得理解它为什么存在。LLM 在空间推理上的弱点，主要来自三个层面。

第一，语言模型的预测对象是 token，不是坐标。LLM 的核心能力是预测下一个词。它擅长从语料中学习语言的统计规律，但语言中的“左边”和“右边”是高度上下文相关的。同样一个“左边”，在不同观察者、不同朝向、不同坐标系下，含义完全不一样。模型没有物理世界的坐标参照，只靠文本中的相关性去推断，很容易选错参照系。

第二，训练语料中充满了视角歧义。人类语言在描述空间关系时，默认了大量的背景知识。例如“我的左边”“门的左边”“图片的左边”，这些说法一旦脱离实际场景，就存在至少两种解释。训练数据里的空间描述大概率没有统一标注视角，模型学到的就是一种“模糊的、平均化的空间语义”，在精确场景中自然出错。

第三，模型缺乏物理交互的反馈闭环。人类对空间的认知，很大程度上来自身体移动、视觉观察和触觉反馈。你推一下杯子，杯子倒了，你会建立“作用力和位移”的关系。LLM 没有这些体验，它只能从文字里间接学习空间规则，遇到需要真实几何推算的问题时，往往只能靠猜测。

这三个根源意味着：单纯换一个更大的模型，不一定能解决空间推理问题。因为模型变大解决的是统计规律拟合能力，而不是建立空间参照系的能力。这也是为什么社区里越来越多人开始寻找“修正”而非“升级”的方法。

2. 空间推理问题的四种典型形态

在动手修正之前，最好先给问题分类。在实际开发中，LLM 的空间推理失败可以归纳为四种形态。不同形态的修正策略完全不同。

第一种最普遍，问题出在模型没有把“相对关系”转成“可计算的中间状态”，直接凭语感回答。第二种更隐蔽，模型把“左手边”理解成了“画面左边”而不是“人物朝向的左边”。第三种暴露的是算术和几何组合推理的短板，语言模型擅长模式匹配，但不擅长逐步累积位置变化。第四种通常出现在嵌套较深的空间描述中，模型没有世界模型，只能靠语言联想。

理解了这些形态，就能制定有针对性的修正策略。

3. 修正空间推理的六条技术路线

3.1 路线一：提示词工程，把坐标系写进提示词

这是成本最低、见效最快的路线，适合相对方位和视角类问题。

核心思想是：不要在提示词里只问“它在左边还是右边”，而是要求模型先定义坐标系、标注观察者朝向、列出物体坐标，最后再得出结论。

一个典型的对比是：

• 弱提示词：“书在苹果的左边，笔在书的左边，问笔在苹果的哪一边？”
• 强提示词：“请列出场景中的物体，定义坐标系：以苹果为原点，X 轴向右，Y 轴向上，默认你站在苹果正前方。然后逐一标出书、笔的坐标，最后根据坐标判断笔相对苹果的方位。”

模型在“先定义坐标系”的约束下，至少不会默认一个错误的视角。这个方法的原理，不是教模型新知识，而是强迫它把隐含假设变成显式步骤，减少默认视角带来的歧义。

3.2 路线二：思维链，强迫模型分步推导

思维链（Chain-of-Thought，CoT）对空间推理有帮助，但关键不在于“多想一步”，而在于“每一步只做一件小事”。

很多空间推理题目，失败原因是模型跳步。比如从“小明面向北”推导“左手边是西方”，正确的推理链是：

1. 面向北，即朝向 +Y 轴。
2. 左手对应左侧方向。
3. 面向北时，左侧是西方。

跳步的模型可能会直接给出“左边是北方”这样荒谬的结论。所以提示词中应该明确要求“输出完整推导过程，并标注每一步的依据”。

更好的一种做法，是让模型用“伪代码”或“坐标表”来推理。例如要求：

第一步：列出所有物体和观察者朝向。 第二步：给每个物体分配坐标。 第三步：根据坐标计算相对方向。 第四步：输出结论。

这相当于把空间推理转化成了一种近似计算流程，模型的错误率会明显下降。

3.3 路线三：外部工具，让代码替你算

对于坐标、距离、路径类问题，最可靠的做法不是让模型“算”，而是让模型“把问题转化成代码”，然后用外部函数执行计算。

这是本篇文章最推荐的一种路线。理由很简单：空间计算的规则是明确的、可验证的，不需要模型的统计推断。求两个坐标之间的相对方向，写一个atan2公式就够了，模型没必要去“背”答案。

工程上的常见做法是：

1. 用 LLM 从用户的自然语言中抽取空间实体和坐标关系。
2. 将抽取结果传递给一个确定性的空间计算函数。
3. 将计算结果格式化成自然语言，回传给用户。

这种“LLM 做语义理解 + 工具做精确计算”的混合架构，已经可以解决大部分空间推理问题。它也更接近未来 Agent 系统的设计方向——让模型专注于理解意图，而不是代替一切。

3.4 路线四：多模态输入，让模型看见空间

如果任务本身涉及真实场景，比如一张图片、一张地图、一段摄像头画面，那么纯文本输入对模型来说信息已经丢失了大半。这时应该优先采用多模态模型，把图像输入给模型，让它在视觉信息上做空间判断。

多模态模型在有图像参考时，空间推理能力会比纯文本强一些，因为它可以从画面中获取物体位置、大小、遮挡关系等视觉线索。但要注意，视觉编码对细小位置信息仍然可能丢失，所以不能完全依赖模型“看”，最好让模型先“描述图中物体的坐标”，再基于描述做推理。

3.5 路线五：微调训练数据

当提示词和工具都无法满足需求时，就要考虑微调。这条路线成本最高，但效果也最可控。

微调的关键是数据格式。空间推理的训练数据不能只是“问题-答案”对，更好的格式是“问题-坐标系-分步推理-答案”。也就是说，要把上文提到的“显式坐标化”写进训练样本，让模型在微调阶段就学会先建立坐标系，再推导答案。

同时要注意数据中的视角标注。每条训练数据都应当明确观察者朝向、坐标系原点、方向约定，避免把多义的空间描述塞进训练集。

3.6 路线六：Agent 与环境交互

最后一种路线，是把空间推理放回环境中解决。通过 Agent 在仿真环境或真实环境中执行动作，观察反馈，再调整判断。

例如，让 Agent 在模拟房间里执行“走到桌子左边”的指令，如果坐标偏移了，环境会给出碰撞或到达错误位置的反馈，Agent 基于反馈修正内部空间模型。这种方法的优势是能建立起类似人类的“试错-反馈”闭环，但工程复杂度较高，一般用在机器人、自动驾驶、游戏 AI 等场景。

对于大多数 Web 应用和对话系统来说，前四条路线已经足够。这一条更适合做长期研究储备。

4. 环境准备与前置条件

为了让后续示例可以顺利跑通，建议准备以下环境：

• 操作系统：Linux / macOS / Windows 均可，本文示例是标准 Python 代码。
• Python 版本：3.9 及以上即可，代码不依赖新特性。
• LLM API：任意支持 Chat Completions 风格接口的大模型服务，本地部署或云端 API 均可。
• 依赖库：openai（如果你调用 OpenAI 兼容接口）、math（标准库）、json（标准库）。

如果你的项目使用 Spring AI、LangChain 或其他 LLM 编排框架，也不影响理解——本文的核心是空间推理修正的思路，而不是特定框架的专属写法。

5. 核心流程拆解：从诊断到修正

修正空间推理，不能上来就改提示词。正确流程是“先诊断，再修复，最后回归验证”。下面拆成五个步骤。

5.1 步骤一：构建空间推理测试集

你需要一个小而精的测试集，覆盖本章第 2 节提到的四类问题。建议至少准备 10 道题，每个类别 2 到 3 道。

测试集的价值在于：它把“模型空间推理差”这个模糊感受，变成了可量化的失败清单。修复之前先测一遍，记录每道题的错误类型，后面修改提示词或加入工具后，再跑同一套测试集看通过率变化。

5.2 步骤二：跑基准测试，记录失败模式

把测试集喂给模型，不要只看对错，要记录每题的错误类型。是左右混淆？是视角丢失？还是计算错误？这些失败模式直接决定你选择哪条修复路线。

例如，如果模型在“相对方位”类题目上大量混淆，优先优化提示词；如果问题集中在“路径坐标”上，直接引入外部计算工具。这一步能避免你盲目试错。

5.3 步骤三：设计结构化提示词

根据失败模式，编写包含“坐标系、观察者、分步推理”要求的结构化模板。这个模板要成为后续所有空间推理问题的统一前缀，让模型形成固定的推理习惯。

5.4 步骤四：加入工具计算辅助

对于坐标计算和路径类问题，不要指望提示词修复。直接把问题里的空间实体和坐标抽取出来，交给确定性函数计算，再把结果组织成自然语言回复。

这一步的关键是：让 LLM 负责“解析意图”和“组织语言”，让代码负责“计算正确结果”。

5.5 步骤五：回归验证

修改完成后，回到测试集，重新跑一遍。对比修改前后的通过率，并确认没有引入新的错误类型。空间推理问题往往牵一发而动全身——修复了“左右混淆”，可能暴露了“视角选择错误”，所以回归验证必须保留。

6. 完整示例与代码实现

下面用四个示例，把上面的流程落地成可运行的代码。

6.1 示例一：空间推理测试集与自动评估脚本

文件路径：spatial_eval.py

import json TEST_CASES = [ { "id": "relative_left_1", "type": "relative_position", "question": "桌子上有一个苹果，苹果左边有一本书，书的左边有一支笔。请问笔在苹果的哪一边？", "answer": "左边" }, { "id": "perspective_1", "type": "perspective_transform", "question": "小明面向北方站着，他的左手边是什么方向？", "answer": "西方" }, { "id": "path_coord_1", "type": "path_integration", "question": "从客厅出发，向北走 5 米，然后向东走 3 米，此时你相对于客厅在什么方向？", "answer": "东北方向" }, { "id": "embedded_relation_1", "type": "relative_position", "question": "书架在沙发的右侧，花盆在书架的右侧，请问花盆在沙发的哪一侧？", "answer": "右侧" } ] def load_test_cases(path="spatial_test_cases.json"): if path: with open(path, "r", encoding="utf-8") as f: return json.load(f) return TEST_CASES def run_evaluation(llm_call, test_cases=None): """对给定 LLM 调用函数跑一遍空间推理测试。 llm_call 是一个接收 question 字符串、返回模型回答字符串的函数。 你可以根据自己使用的模型服务来实现该函数。 """ test_cases = test_cases or TEST_CASES results = [] passed_count = 0 for case in test_cases: response = llm_call(case["question"]) passed = case["answer"] in response passed_count += int(passed) results.append({ "id": case["id"], "type": case["type"], "question": case["question"], "expected": case["answer"], "model_answer": response.strip(), "passed": passed }) summary = { "total": len(test_cases), "passed": passed_count, "failed": len(test_cases) - passed_count, "accuracy": round(passed_count / len(test_cases), 4) } return summary, results if __name__ == "__main__": # 演示用法：传入一个简单 mock 函数 def mock_llm(question): return "左边" summary, results = run_evaluation(mock_llm) print(json.dumps(summary, ensure_ascii=False, indent=2))

这段代码的核心是TEST_CASES测试集和run_evaluation评估函数。实际项目中，你需要把mock_llm替换成真实模型调用。

6.2 示例二：结构化空间推理提示词模板

文件路径：prompts.py

SPATIAL_REASONING_PROMPT = """请按以下固定步骤回答空间关系问题，每一步都不能省略。 第一步：列出题目中出现的所有物体或地点。 第二步：定义坐标系。选择题目中最重要的物体作为原点，X 轴指向右，Y 轴指向前方。 第三步：标注观察者。如果没有明确指定，默认你站在场景正前方，观察方向为 +Y 方向。 第四步：把每个物体或地点用坐标表示出来。 第五步：根据坐标，计算目标物体相对于参照物的方向。 第六步：输出最终结论，结论中必须包含方向和坐标依据。 注意： - “左边”和“右边”必须以观察者视角为准，不是阅读视角。 - 如果题目同时存在多种坐标系定义方式，先说明你的选择，再继续。 - 如果题目本身无法建立坐标系，请明确说明原因。 题目：{question} """ def build_spatial_prompt(question, system_prompt=None): """把用户问题和系统提示词组合成完整的请求体。""" if system_prompt: return system_prompt + "\n\n" + SPATIAL_REASONING_PROMPT.format(question=question) return SPATIAL_REASONING_PROMPT.format(question=question)

这个模板适用于大多数“相对方位”和“视角转换”类题目。如果你使用不同的模型服务，只需要把最终字符串传给模型即可。

6.3 示例三：坐标计算辅助函数

文件路径：spatial_tools.py

import math def relative_direction(origin, target, observer_heading_deg=0): """计算 target 相对 origin 的八方向方位。 Args: origin: (x, y) 坐标，参照物。 target: (x, y) 坐标，目标物。 observer_heading_deg: 观察者朝向，0 表示面向 +Y（北）， 90 表示面向 +X（东），以此类推。 Returns: 八方向字符串，例如 "前方"、"右前方"、"右方" 等。 """ dx = target[0] - origin[0] dy = target[1] - origin[1] # 先计算在标准坐标下的方位角（以 +Y 为 0 度，顺时针） angle_deg = math.degrees(math.atan2(dx, dy)) # 根据观察者朝向旋转 angle_deg = (angle_deg - observer_heading_deg) % 360 directions = ["前方", "右前方", "右方", "右后方", "后方", "左后方", "左方", "左前方"] index = round(angle_deg / 45) % 8 return directions[index] def extract_origin_target_from_text(llm, question): """让 LLM 从自然语言中抽取坐标关系。注意：这个函数依赖你的 LLM 接口。""" extract_prompt = f""" 从下面这个空间问题中，抽取“参照物坐标”和“目标物坐标”。 如果题目没有明确给出坐标，请自行设定一个合理的坐标系，并输出 JSON。 格式要求： {{ "origin": [x, y], "target": [x, y], "observer_heading_deg": 0, "reason": "你选择的坐标系说明" } 问题：{question} """ # 这里调用你的 LLM 接口，解析 JSON 返回 # 示例中省略具体模型调用，返回一个占位结果 return extract_prompt

relative_direction是确定性函数，不依赖模型，结果稳定可复现。只要坐标抽取正确，它的判断是可靠的。

6.4 示例四：融合提示词和工具的主流程

文件路径：main.py

import json from spatial_eval import run_evaluation from prompts import build_spatial_prompt from spatial_tools import relative_direction class SpatialReasoningPipeline: def __init__(self, llm_call, use_tool=True): self.llm_call = llm_call self.use_tool = use_tool def answer(self, question): """统一入口：先抽取类型，再决定使用提示词还是工具。""" # 1. 判断题目类型：是否涉及明确的坐标计算 type_prompt = f"判断下面这个问题的类型，只输出 one of [relative_position, perspective_transform, path_coordinates, other]：\n{question}" q_type = self.llm_call(type_prompt).strip() # 2. 如果涉及路径/坐标计算，走工具分支 if q_type == "path_coordinates" and self.use_tool: coords_result = self._extract_coords(question) if coords_result: direction = relative_direction( origin=coords_result["origin"], target=coords_result["target"], observer_heading_deg=coords_result.get("observer_heading_deg", 0) ) return f"根据坐标计算，目标方位是：{direction}" # 3. 其他情况走结构化提示词分支 structured_prompt = build_spatial_prompt(question) return self.llm_call(structured_prompt).strip() def _extract_coords(self, question): """从 LLM 输出里解析坐标。实际项目中需要处理 JSON 解析异常。""" # 这里按照你的模型服务，调用后解析 JSON return None if __name__ == "__main__": # 真实项目中，llm_call 换成你的模型服务 def llm_call(prompt: str) -> str: return "左边" # 占位返回 pipeline = SpatialReasoningPipeline(llm_call=llm_call) print(pipeline.answer("苹果左边有一本书，笔在书的左边，笔在苹果的哪一边？"))

这里的SpatialReasoningPipeline展示了最核心的架构思想：先判断题型，再选择不同处理路径。坐标类问题走工具，相对方位类问题走结构化提示词。这样既兼顾了精度，也控制了调用成本。

7. 运行结果与效果验证

7.1 如何运行

在项目根目录执行：

cd your_project # 运行评估脚本，观察 mock 场景下的输出结构 python spatial_eval.py

预期输出类似：

{ "total": 4, "passed": 1, "failed": 3, "accuracy": 0.25 }

这里展示的是未接入真实模型前的框架运行效果。接入真实模型后，准确率会反映出模型原有空间推理水平。一般基准测试通过率在 25% 到 50% 之间都是常见现象，不必惊慌，这正是修正流程要解决的问题。

7.2 如何判断修正是否生效

判断标准不是“这一次答对了”，而是以下三点：

1. 测试集整体通过率提升。
2. 同类错误出现频率下降。
3. 没有引入新的错误类型。

例如，加入结构化提示词之前，相对方位类题目答对 1 题；加入之后答对 3 题，这时可以认为提示词修正有效。如果相对方位正确率明显提高，但视角转换类新出现了错误，说明模板里对观察者朝向的定义还不够清晰，需要继续迭代。

7.3 失败时的第一步排查

如果修正后效果没有提升，第一件事不是继续改提示词，而是检查你调用的模型是否真的执行了新提示词。

很多 LLM 接口在配置了 system prompt 时，用户消息中的指令优先级可能不同。你要确认模型输出是否完整走了六步结构，还是仍然只输出一个结论。如果模型无视模板直接回答了，说明提示词模板没有有效覆盖到模型行为。

第二个排查点是：工具分支的坐标抽取是否准确。如果抽取出来的 origin 和 target 坐标本身就是错的，后面的relative_direction再正确也没有意义。建议先把抽取结果打印出来，人工核对。

8. 常见问题与排查思路

表格里的每一条都来自实际项目中最常见的踩坑点。尤其是第一条和第二条，几乎在每一次空间推理修正中都会遇到。

9. 最佳实践与工程建议

9.1 先建测试集，再谈修正

这是最重要的一条。没有测试集，你对“空间推理差”的感知是模糊的；有了测试集，你可以精确知道差在哪类题目、哪个方向。测试集会成为你后续所有迭代的基准线。

9.2 区分“理解问题”和“计算问题”

如果模型把题目理解错了，比如分不清谁是参照物，那是理解问题，应该优化提示词。如果模型理解正确但算错了方向，那就是计算问题，应该交给工具函数。两者混为一谈，会让修正过程非常痛苦。

9.3 能算的不要猜

空间关系中的坐标计算、方向换算、路径积分，都是确定性操作。这类操作不需要模型发挥“创造力”，直接用代码计算是最可靠的。

9.4 坐标系声明是提示词的核心

很多修正失败的案例，根源不是模型能力不够，而是提示词没有定义坐标系。你在提示词里把坐标系、观察者朝向、方向约定都写清楚，模型的错误率会显著下降。

9.5 保留回归测试集

空间推理的修正常常是“按下葫芦浮起瓢”。修复了左右混淆，可能暴露了视角选择问题。保留一套与训练无关的回归测试集，每次修改后都跑一遍，才能防止旧问题复发。

9.6 生产环境要做降级策略

即使做了工具辅助和提示词优化，模型仍然可能犯错。在面向用户的生产系统里，建议对空间推理类的关键指令设置确认环节，例如“你确定是想打开客厅左边那盏灯吗？”这比让模型直接执行要安全得多。

10. 总结与后续学习方向

修正 LLM 的空间推理能力，不存在一个万能技巧。更靠谱的路径是把它当作一个系统工程：先用测试集定位失败类型，再用结构化提示词解决语义层面的歧义，用工具函数解决数学计算层面的误差，最后通过回归测试验证效果。

从行业趋势看，空间推理问题正在从“单纯考验模型参数规模”演变成“考验系统架构设计”。那些把空间计算从语言模型中剥离出来的项目，往往比单纯换更大模型更早获得稳定效果。

如果这篇文章对你有帮助，建议直接收藏备用。下一步，你可以：

• 把自己业务中真实的空间问题整理成测试集，先测一轮。
• 在现有 Agent 框架中接入一个方向计算工具函数，替代模型猜答案。
• 如果团队有条件，再尝试构造带坐标系标注的微调数据，探索路线五。

空间推理的战场很小，但它是检验“LLM 能否真正理解物理世界”的一个关键路口。希望这篇文章能帮你少走一段弯路。