The car wash is 100 meters away. Should I walk or drive很多人第一次看到这道题都会觉得这也能算一个测试100米成年人走路也就一两分钟答案当然是 walk。真正有意思的地方在于很多主流 LLM 在这个问题上会给出 drive 的回答而且它们给出的理由还相当自洽“要去洗车店你需要把车开过去。” 这个结果让不少开发者开始重新思考一个问题我们真的可以信任大语言模型的常识推理能力吗这道题近年经常出现在评测圈和社交网络里被当作检验 LLM “常识感”的送分题。它的表面难度为零可一旦放到模型面前就能暴露出推理链路、语义歧义、意图识别、物理常识建模等多个层面的问题。对做 LLM 应用开发的工程师来说这道题的意义不在于“看模型翻车”而在于它提供了一个绝佳的切片为什么一个对人类来说几乎不需要思考的决策会让模型犯下看起来很蠢的错误这种错误能不能通过提示词工程缓解能不能用评估集提前发现这篇文章会从问题本身拆起分析 LLM 答错的机制原因然后给出一个可复制的 Python 评测脚本、三种提示词修正策略以及一套面向常识决策场景的评估集设计思路。如果你正在做 Agent、客服机器人、智能助手或任何需要模型做判断的 LLM 应用这篇文章的内容会直接关系到你如何设计 prompt、如何兜底、如何回归。1. 一个“简单问题”为什么值得专门分析先把这个问题的复杂性摊开。题目原文是The car wash is 100 meters away. Should I walk or drive? 如果只看字面它讨论的是一个距离决策目的地在一百米外交通工具选走路还是开车。但这句话在日常沟通里暗含了很多人类默认知道、却不会写出来的信息。第一层是“100米有多远”。普通人步行速度大概是每分钟80到100米走完100米只需要一分多钟。如果换成开车你需要走到停车场、发动车辆、行驶100米、再找车位停车整套动作下来时间成本通常远超步行。再加上城市里短距离开车还可能遇到堵车和停车费正常人几乎不会为100米选择开车——除非有特殊目的。第二层是“car wash”的语义。它既可以指“洗车店”这个地点也可以指“洗车”这个服务。如果是后者模型必须意识到洗车服务清洗的对象就是你的车所以车必须到场。在这个理解下选择开车就是合理的甚至不开车反而没法真正完成洗车。但如果你只是去洗车店办点事——比如取车、买瓶玻璃水、咨询价格——走路当然更合理。一句话里没说明目的人类会根据语境自动补全而模型很难判断自己“应该站在哪种语境里回答问题”。第三层是隐含变量。题目没有说车是否就在你身边没有说你是从家出发还是从公司出发没有说天气和路况。人类在回答时会自动忽略这些信息因为它们对“100米”这个数量级不太重要。但模型不具备这种“自动忽略”的机制它会把所有可能相关的事实都拉进推理过程结果就是问题越分析越复杂最后反而把简单答案推没了。所以这道题真正考察的不是计算能力而是三种能力的组合物理世界常识、意图识别能力、决策成本分析。这种组合恰恰是当前很多 LLM 评测基准覆盖不足的部分。传统评测通常考知识问答、代码生成、数学计算而 AI 原生应用里大量出现的是这种“短文本、多歧义、强常识依赖”的开放式决策问题。这类问题做不好模型在真实业务里就会频繁给出听起来合理、用起来离谱的结论。这也解释了为什么值得为一道看似无聊的题写一整篇文章。它不是段子而是 LLM 推理问题的一个典型样本。2. 题目拆解它到底在考什么要把这个问题讲透可以先做一个思维实验一个人类看到这句话大脑里会发生什么。第一反应是建立一个空间距离模型。100米就是住宅楼到小区门口、办公室到便利店之间的距离属于“步行友好型距离”。正常成年人不会为这个距离启动一辆车。如果有人问“100米我该走路还是开车”你会觉得这个问题本身就很奇怪。第二反应是确认目的。如果对方手里拿着车钥匙说“我去洗车”你会理解成他要把车开过去如果他说“我去洗车店看看顺便买个车载香薰”你会觉得他走着去就行。也就是说人类天然会把“目的”作为决策的第一优先级距离只是辅助信息。而模型呢模型需要在 token 序列里自己猜出这个优先级——这是一件非常不容易的事情因为这句话里根本没有出现“目的”这个词。第三反应是评估备选方案的实际成本。步行100米预计1-2分钟开车100米需要考虑取车时间、启动时间、找车位时间。人类凭直觉就知道哪个更优。模型没有这种直觉它只能在文本相关性里找线索。“car”和“drive”在文本里天然高度相关于是在很多模型眼里“drive”比“walk”更像一个合理接续。可以用一张表来对比人类和 LLM 在这个问题上的认知差异维度人类思考方式LLM 典型行为距离感知100米≈一两分钟步行属于极短距离将100米当作抽象数字可能把它跟“停车距离”“步行时间”做过度计算目的识别根据“洗车”自动推断需要车可能只把 car wash 当普通地点名词也可能只抓住 drive 的文本相关性决策逻辑先区分目的再比较成本结论直接列举多种可能性或者选择一个“听起来合理”的答案信息过滤自动忽略天气、路况等无关变量可能主动引入天气、油价、停车费等额外假设不确定性表达通常直接给出一个明确答案经常输出“取决于”“如果……那么……”这种和稀泥回答这张表基本解释了这道题让人恼火的地方人类觉得它毫无讨论价值模型却能在里面看到“深度推理”的素材。真正的问题不是模型傻而是模型的推理机制天生就会把简单问题复杂化。3. 为什么 LLM 会答错机制层面的五个原因很多人以为 LLM 答错这道题是因为“知识不够”其实恰恰相反。模型的知识足够回答这个问题问题出在推理过程中的几个结构性缺陷。3.1 数字诱导引发了过度推理LLM 对数字非常敏感。一旦输入里出现“100 meters”这样的精确数字模型会自动进入“计算模式”。它可能会开始估算步行时间、比较开车和步行的效率甚至计算每公里的油费。这种计算通常没有依据却会让模型认为“这里需要严谨分析”。于是本来一句话就能回答的常识题被模型当成了一道数学应用题。数字在这里变成了干扰项诱导模型放弃了人类本能的距离感。3.2 训练目标决定了它不是在做常识推理大语言模型的训练目标是预测下一个 token 的概率分布。它学习到的是一种“文本接续能力”而不是“物理世界模拟能力”。当模型说 drive 的时候它的内部机制更像是认为“在提到 car wash 的上下文里drive 是一个高概率词”而不是真的在思考“我应该怎么过去”。这种生成方式在大多数知识类问题上足够好用但在常识决策问题上它会暴露一个根本缺陷模型没有身体没有走过路没有开过车它只见过无数人讨论走路和开车的文字。3.3 语义歧义没有被显式建模car wash 这个词在国内外的真实使用场景里都高度歧义。它可能指“洗车店”这个场所也可能指“洗车”这个动作。在英文里car wash 作为名词短语时更多指场所但如果前面有动词 take、get 就倾向于指服务。这道题的题干恰好省略了这些语法线索。它很容易在“步行去洗车店”和“开车去洗车”两个理解之间摇摆。模型不具备“追问澄清”的能力它只能选择一个方向硬答。这种对语义歧义的无力感在短文本任务里被放得极大。3.4 上下文中的伪相关性干扰判断文本里同时出现了 car wash 和 drive。在大量英文语料中car 和 drive 经常共同出现这种统计相关性会显著提高 drive 在输出中的概率权重。模型在推理时很难把“drive”从“car”的语义场里剥离出来去重新评估“walk”在物理距离上的优越性。这是一种典型的“语料偏置”模型学到的是词与词之间的关联频率而不是现实世界里行为与场景之间的因果关系。3.5 缺乏具身经验无法建立代价感人类做决策时依赖的是“体验记忆”我们体验过走路出汗、找车位烦躁、短距离挪车很麻烦。这些体验形成了一种直觉性的代价模型。LLM 没有这些体验。它的所有知识都来自文字描述而文字描述通常倾向于讲述异常场景——比如“开车去洗车”这种场景更容易出现在文章里而“走路去洗车店”几乎不会有人专门写。于是模型在概率上更倾向于选择被文字记录更多的行为。这不是模型笨而是它的训练数据在常识决策问题上天然带偏。4. 最小实测用 Python 给 LLM 出一道“送分题”理解了理论原因之后最好的方式是自己动手跑一遍。下面这个脚本会调用当前主流的 OpenAI 兼容 API把题目原样发给模型并记录完整回答。4.1 环境准备建议使用 Python 3.8 以上版本安装 openai 库pip install openai然后把 API Key 配置到环境变量里避免把密钥写在代码中export OPENAI_API_KEYyour_api_key_here4.2 基础测试脚本# 文件路径eval_walk_or_drive.py import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) def ask_model(prompt: str, model: str gpt-4o-mini) - str: 发送 prompt返回模型完整回答。模型名请以实际可用模型为准。 resp client.chat.completions.create( modelmodel, messages[ {role: user, content: prompt}, ], temperature0, ) return resp.choices[0].message.content if __name__ __main__: prompt The car wash is 100 meters away. Should I walk or drive? answer ask_model(prompt) print(Prompt:, prompt) print(Answer:, answer)这个脚本做了一件最简单也最重要的事用 temperature0 固定模型输出避免随机性干扰判断。如果你连续运行多次可能会看到模型在不同描述之间摇摆这本身就是问题的一部分。4.3 运行与结果记录运行方式python eval_walk_or_drive.py不管模型回答什么都建议把回答保存下来。你可以直接重定向到文件python eval_walk_or_drive.py result.txt然后观察结果属于下面哪种失败模式明确选择 drive并给出“因为要去洗车”这类理由不做决定输出“这取决于你是否有车需要洗”输出一堆条件和分析最后没有给出明确结论正确选择 walk但理由表述不稳定。如果模型在这个最简 prompt 上答对了你可以继续做压力测试把距离改成 50 米、500 米、5 公里观察模型在什么距离上开始切换答案。这种连续变化往往能暴露模型的“距离感”到底存不存在。4.4 一次测试的局限性单次测试只能说明该模型在这个固定 prompt 上的表现不能代表模型真实水平。更合理的做法是给同一个问题准备多个语义变体比如把 car wash 改成 restaurant、gym、supermarket把 100 meters 改成 200 meters、1 mile。通过变体矩阵才能判断模型是真正理解了距离与出行方式的关系还是只是对某个特定句式产生了条件反射。5. 提示词工程修正三种可行策略实测发现模型答错之后下一步不是骂模型而是思考如何通过工程手段修正。下面三种策略按成本从低到高排列可以组合使用。5.1 明确决策角色和场景边界很多模型答错是因为它没有意识到自己应该站在“一个普通人的日常出行决策”角度来回答。可以在 system prompt 里把角色和边界讲清楚。# 文件路径eval_with_system_prompt.py import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) system_prompt 你是一个生活常识助手。用户会给你一个日常出行场景你需要站在普通成年人的角度做判断。 判断时遵循以下原则 1. 100米属于步行友好距离默认推荐步行 2. 如果用户说明需要携带车辆或货物再考虑驾车 3. 不要引入天气、油价、停车费等题干中没有提到的额外因素。 回答时先给出结论再用一句话说明理由。 .strip() def ask_with_system(user_text: str, model: str gpt-4o-mini) - str: resp client.chat.completions.create( modelmodel, messages[ {role: system, content: system_prompt}, {role: user, content: user_text}, ], temperature0, ) return resp.choices[0].message.content if __name__ __main__: question The car wash is 100 meters away. Should I walk or drive? print(ask_with_system(question))这种方法的本质是把人类在对话中“默认知道”的前提显式写出来。模型不知道“100米是步行友好距离”你就告诉它模型容易引入无关变量你就禁止它引入。它不是让模型变聪明而是让模型的输出范围更可控。5.2 强制结构化输出先列前提再给结论另一种有效策略是要求模型在回答前先列出它对问题的关键理解。这相当于让模型“先想后说”把隐含判断外化。# 文件路径eval_with_reasoning.py import json import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) prompt 请回答下面的出行决策问题。 要求 1. 先列出你捕捉到的关键信息 2. 指出题干是否存在歧义 3. 给出最终建议walk 或 drive 4. 按 JSON 格式输出。 问题The car wash is 100 meters away. Should I walk or drive? .strip() resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0, response_format{type: json_object}, ) data json.loads(resp.choices[0].message.content) print(json.dumps(data, ensure_asciiFalse, indent2))这里的关键不是让模型“展示推理过程”而是强制它把“捕捉到的信息”和“最终结论”分开。你会发现很多模型在这个约束下会主动写出来“题干未说明用户去洗车店的目的如果只是为了使用洗车服务需要车辆到场如果只是去洗车店方向100米推荐步行。”结构化输出本身不能保证答案正确但它能让你一眼看出模型错在哪一步而这正是调试 LLM 应用最重要的能力。5.3 引入工具与外部知识不依赖模型内化常识如果场景对决策精度要求很高不要指望提示词完全解决。更稳妥的方式是把常识决策交给规则或外部工具。例如可以接一个距离估算接口先解析目的地距离再由规则引擎判断“距离小于500米且无重物运输需求时默认推荐步行”。LLM 只负责理解用户意图距离判断交给代码。# 文件路径hybrid_decision.py def decide_by_rule(distance_m: float, need_car: bool) - str: if need_car: return drive if distance_m 500: return walk return drive # 由 LLM 提取关键参数 extracted { distance_m: 100, need_car: False, } print(decide_by_rule(extracted[distance_m], extracted[need_car]))这种混合架构的好处是LLM 做它擅长的事理解自然语言规则引擎做它擅长的事确定性判断。你对结果的置信度也会高很多。凡是后果严重、错误代价高的决策都建议走这种“模型提取 规则兜底”的模式。6. 从一道题到一套评估集构建常识决策评测只修一道题没有意义你真正需要的是能够在应用上线前发现问题的一组测试题。这道题可以作为你构建 LLM 常识决策评估集的一个起点。6.1 为什么要构建评估集很多团队上线 LLM 功能时只做了手工冒烟测试上线后才发现模型在真实用户的不同问法下表现很不稳定。因为 LLM 是概率系统同样一个意图用户可以用 100 种不同说法表达。只有把典型说法、边界情况、干扰项都放进测试集你才能对模型质量有一个基本判断。6.2 评估集设计维度以下维度可以直接用来扩展这套常识决策测试集维度示例作用距离尺度50米、100米、200米、500米、2公里检验模型是否真的理解不同距离的决策差异目的明确度明确说“去洗车” vs 只说“去洗车店”检验模型对歧义句的敏感性隐含条件是否需要携带物品、是否下雨、是否赶时间检验模型是否会自主补全合理条件干扰数字加入无关的时间、价格、优惠数字检验模型会不会被数字带到过度推理答案形式开放回答、二选一、JSON输出检验输出稳定性语义变体把 car wash 换成 restaurant、gym、subway station检验模型是对题目还是对真实世界做推理6.3 批量评测脚本有了测试集还需要一个能批量跑、能统计的脚本。# 文件路径eval_decision_benchmark.py import json import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) TEST_CASES [ { id: walk_100_car_wash, question: The car wash is 100 meters away. Should I walk or drive?, expect: walk, }, { id: walk_50_supermarket, question: The supermarket is 50 meters away. Should I walk or drive?, expect: walk, }, { id: drive_5km_mall, question: The mall is 5 kilometers away. Should I walk or drive?, expect: drive, }, { id: ambiguous_car_wash, question: I need to get my car washed. The car wash is 100 meters away. Should I walk or drive?, expect: drive, }, ] def classify_answer(text: str) - str: text text.lower() if walk in text and drive not in text: return walk if drive in text and walk not in text: return drive return ambiguous def main(model: str gpt-4o-mini): stats {walk: 0, drive: 0, ambiguous: 0} results [] for case in TEST_CASES: resp client.chat.completions.create( modelmodel, messages[{role: user, content: case[question]}], temperature0, ) answer resp.choices[0].message.content pred classify_answer(answer) stats[pred] 1 results.append({ id: case[id], question: case[question], expect: case[expect], pred: pred, raw: answer, }) print(Stats:, stats) with open(decision_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: main()这个脚本会输出一个统计结果并把每一条原始回答保存到 JSON 文件里方便人工分析。运行后你会看到模型在二选一明确问题时表现尚可一旦问题带歧义预测结果就会分化。6.4 结果分析与失败模式分类评估跑完不是结束重点是对失败案例做归类。根据这道题的常见表现失败结果可以分成三类。第一类是“过度计算型”。模型会列出一堆时间、油耗、停车费的计算最后给出一个看似严谨但反常识的结论。这类失败说明模型对数字的敏感度盖过了常识判断。第二类是“和稀泥型”。模型输出“这取决于你是否需要用车”“如果天气好走路天气差开车”之类的话不给出明确答复。这种回答在聊天场景里可以接受但在决策类应用里是致命的因为它让用户无法行动。第三类是“跑偏补全型”。模型自动脑补了题干没有的细节比如“你可能需要携带大件物品”“停车场也许很远”然后基于这些假设给出了答案。从单个生成文本看它很合理但结合原始问题看就属于无中生有。分类之后你就能判断当前模型的主要问题方向再决定是换模型、调 prompt还是上规则兜底。6.5 自洽性检查除了单轮正确率还可以测自洽性同一个问题换一种说法模型是否给出同样的决策。比如“The car wash is 100 meters away. Should I walk or drive?”和“我想去洗车店它离我100米我该走路还是开车”如果距离没有变、目的没有变答案理应一致。如果模型在两种说法下给出了不同结论说明它的决策并不稳定。这种测试对真实应用很有价值因为用户不会按标准格式提问。你可以把自洽性纳入评估集作为模型可靠性的一个独立指标。7. 对 LLM 应用开发的工程建议看完了题目拆解、失败原因、评测脚本和修正策略最后把落点放到工程实践上。这道题对 LLM 应用开发的启示远比表面看到的更具体。7.1 不要无条件信任推理能力LLM 在代码生成、文本理解、知识问答上的能力确实让人印象深刻但“推理能力强”和“决策可靠”是两回事。这道题里模型的回答在语言层面上非常流畅甚至能给出逻辑链但结论是反常识的。在真实业务里这意味着用户提出一个简短请求时模型给出的建议可能看起来很专业实际却不可用。因此凡是模型输出会影响用户决策的功能都要设计兜底机制。7.2 关键场景使用规则引擎兜底常识决策类问题并不适合完全交给 LLM。距离判断、价格计算、优惠抵扣、库存判断这类具有明确规则和边界的问题应该用代码实现。LLM 只负责把用户的自然语言转换成结构化参数规则引擎负责最终计算和决策。这种“模型理解 代码判断”的模式能极大降低错误决策的概率。7.3 建立回归测试集避免模型升级引发倒退LLM 应用还有一个容易忽略的问题模型升级后行为会变化。同一个 prompt上个月用旧模型回答正确这个月换了新版本可能就出错。所以测试集不能只在上线前用一次而是要持续运行。每次换模型、调 prompt、更新系统配置都应该回归一遍。没有回归测试集的 LLM 应用本质上是在裸奔。7.4 常见问题与排查思路问题现象可能原因排查方式解决方案API 调用报错环境变量未设置或 Key 无效检查 OPENAI_API_KEY 是否配置正确确认环境变量已加载必要时在代码里显式读取输出结果不稳定temperature 设置过高查看参数配置决策类任务将 temperature 设为 0模型回答格式不符合预期缺少输出约束检查 prompt 是否要求 JSON 或二选一增加 response_format 或加入格式示例相同问题换说法结果不同语义歧义导致模型理解不一致人工比对各说法下的输出增加自洽性测试必要时用规则修正模型过度引入无关变量缺少边界说明阅读原始回答里的假设在 system prompt 中明确禁止引入额外假设升级模型后行为变化模型版本差异对比新旧模型在测试集上的表现执行完整回归测试必要时固定模型版本7.5 适合 LLM 决策的场景和不适合的场景LLM 适合做信息理解、方案生成、多轮澄清而不是精确计算和最终裁决。前者需要的是语义能力后者需要的是确定性和可控性。以这道题为例LLM 适合做“识别用户想去洗车店”这件事不适合做“100米该走路还是开车”的最终判断。真正可靠的决策链路是把这两者拆开模型理解用户系统做决策。说白了这道题翻车的原因本质上是把人类的常识当成了模型天然具备的能力。而工程化的正确姿势是承认模型没有这种常识然后通过提示词、规则、评测和兜底机制把它缺少的那部分能力重新补回来。8. 总结与后续方向一道“走路还是开车”的小问题牵扯出来的却是一整套 LLM 推理评估和工程落地的议题。这个案例最大的价值是让你不再把模型的流利表达等同于可靠推理也让你知道一次正常回答背后隐藏了多少不确定性。下一步你可以做三件事第一按第 4 章的方式跑一遍基础测试把不同模型在这个问题上的回答记录下来第二用第 5 章的提示词策略做对比观察 prompt 干预对结果的影响第三把第 6 章的评估集扩展到你自己业务里的典型场景让它成为团队每个版本发布前的固定检查项。如果你在实践过程中发现其他有趣的失败模式或者这个问题在你的业务场景里还有别的变形欢迎在评论区一起交流。这套思路的适用范围远不止一道送分题它真正适合的是所有“看起来简单却很容易答错”的 LLM 常识决策问题。