1. 项目拆解城市规划决策支持中的“推理”到底指什么我最近在做的模拟项目X核心路子就是拿大语言模型去做城市规划决策支持里的“推理应用”。听着有点抽象拆开看就一句话让模型面对一个真实规划问题不光要会检索还要会判断、会推导、会给依据。比如某个地块的限高、容积率、退线三条控规条件摆在那同时来了一份建筑方案模型得回答这个方案合不合规不合规的话是怎么不合规卡在哪个指标上如果放宽其中一个条件其他约束会怎样连锁变化这些才是决策支持的日常。之前我做过不少传统规划辅助工具当时最大的体验是规则越多越难塞进代码。控制性详细规划文本动辄几十页里面全是自然语言表达——“沿城市主干道第一界面建筑高度不宜超过24米”“幼儿园同步建设并无偿移交”“地下面积不计入容积率但须满足防空要求”。这些句子里的例外、边界、前提用传统程序做规则引擎会把人写疯掉。大语言模型的语义理解能力适合啃这种非结构化文本但它天生会一本正经地胡说八道直接上会翻车。项目里真正花时间的是把模型“能理解”转化成“能证明”。1.1 规划决策支持的真实痛点在哪里规划决策支持系统并不是新鲜东西很早就有研究者把数学模型、GIS工具、人口预测模型接进去帮规划师算人口承载力、交通流量、容积率平衡。这些工具强在数值计算弱在“条文理解”。现实工作里一个地块的规划条件不是纯数字而是由控规图则、城市设计导则、专项规划、地方标准共同夹逼出来的。数字之外还有大量“宜”“不宜”“应”“不应”“不得”这类带情态动词的条文它们不像算法公式那么清晰需要结合规则解释。我印象最深的一次是在某新区的模拟地块测试控规条文写“低层、多层建筑退让绿线不少于5米高层建筑退让绿线不少于8米”同时还写“沿绿线一侧形成连续开放界面”。模型很容易只记住“不少于5米”把它当成所有建筑的退让要求忽略了后面“高层退让8米”的附加条件。这不是模型笨而是规则本身存在分类分级嵌套——建筑类型、高度分档、空间界面要求混在一段话里。传统工具很难处理这种嵌套大语言模型能处理但前提是你要教会它把复杂条文拆成“条件-对象-数值-例外”。另一个痛点是方案比选。规划决策不是只有“合规”“不合规”两种状态更多时候是多方案权衡A方案绿地率高但容积率偏低B方案容积率达标但公共空间退让不够宽每个方案都有取舍。决策支持要产出的是“为什么值得采用这个方案”的论证而不是一个生硬的分数。以前这类论证只能靠规划师逐条手写耗时又容易遗漏条款。大语言模型介入后可以把多目标拆解逐项列出满足哪些约束、牺牲哪些约束形成一份可以被人工复核的比选说明。1.2 “检索答案”和“推理输出”是两码事有朋友一听就问是不是用向量数据库做个检索增强生成把规划条文搜出来拼给模型让它照着念这是最朴素的用法也是很多项目交差的手段但它离“决策支持”还有不小的距离。检索增强擅长解决“哪条规则对我适用”不擅长解决“这些规则合在一起我的方案能不能通过”。搜出来的条款是静止的推理则是把条款做变量代入具体方案去推演结果。举个例子同样一句“建筑限高60米”放在不同场景下含义不一样。如果用地性质是二类居住用地60米限高可能对应20层住区如果位处机场净空保护区60米可能还要附加绝对海拔控制如果地块恰好位于山体周边限高还要换算成相对坡脚的视线分析。检索只能把“60米”所在条文找出来推理要做的则是判断在这个地块里“建筑高度”这个指标到底怎么计算从正负零算起还是从室外地面算起是否排除屋顶楼梯间和机房这些细节散落在规范注释、图则说明、技术管理规定里必须跨条文组合后形成结论。所以我在项目里把“推理应用”定义为模型主动拆解问题。它需要先识别当前场景的关键实体——地块、方案、指标、规则再在规则库中找出所有可能相关的条文而不是只找关键词匹配的那一条然后按逻辑顺序做约束判断最后生成一个带依据链的结论。如果中间某一环缺失模型应该明确说“我缺少这方面的依据”而不是硬编出一个答案。这种可解释性比准确率更重要。1.3 我给“推理应用”划的三类典型任务在模拟项目X里我没有一上来就做一个包罗万象的智能规划大脑而是把任务收敛成三类每一类有明确的输入输出和检查办法。任务类型输入示例输出示例使用场景约束合规检查地块规划指标、建筑方案主要参数是否合规违反哪些条文建议调整幅度方案初筛、报批前自查方案生成建议用地范围、开发需求、上位规划要求若干可行的指标组合和布局建议前期策划、多情景测试方案比选论证多个方案关键数据、决策偏好每个方案的达标情况、取舍点、推荐结论专家评审材料、领导汇报支撑这三类任务里模型承担的角色不太一样。合规检查更像“理解分类”模型把条文拆成判断条件逐条核对方案生成建议更像“约束求解”模型在给定边界内做创造性生成但生成结果必须能被规则引擎验证方案比选论证则最依赖完整推理链因为结论是开放性的需要列举正反依据。项目里我优先做第一类和第三类因为这两类效果容易度量——对不对看得见改了多少有数字。方案生成建议留到后面再做因为它的候选质量波动太大需要更精细的评测机制。2. 核心设计把推理链路做成可校验的流水线理解了“推理应用”要解决什么接下来就是系统设计。这一步我踩过最大的坑是以为把问题丢给大语言模型就能得到答案。实际上纯闲聊式的调用连“数值计算”都不一定可靠更不用说处理几十页控规文本了。如果一个结论没有经过外部校验它在规划决策里就没有说服力。所以整个系统的核心设计思路是模型负责“软推理”代码负责“硬校验”两边各展所长。2.1 为什么不能直接把问题丢给聊天模型先说几个真实翻车现场。我在测试时问过一个很简单的问题“某建筑单栋高度62米地块限高60米是否合规”模型回答“合规因为建筑高度62小于等于限高60”这属于基础比较错误明显是数字没看仔细。还有一次模型把“容积率2.8”当成“限高28米”然后一本正经分析日照间距。这类问题根源在于大语言模型不是计算器它的token粒度会导致数值模糊尤其是多位数字、单位混用、小数点位变化时出错率会明显升高。更麻烦的是“看似严谨实则虚构”。模型在举推理依据时会自己编造条文编号比如“根据第7.2.3条建筑退线距离不应小于10米”可实际上原文本里根本没有这一条。对规划师来说这种错误比直接说“不知道”更危险因为决策文件一旦引用错误条文责任归属就说不清了。因此我在设计里确定了一条铁律任何涉及数值比较、面积计算、条文编号引用的环节都不允许模型直接输出“最终答案”了事。模型要做的是把问题解析成结构化参数把推理过程写到步骤里但最后的数值判断交给Python计算函数条文核对交给检索模块。简单说模型是提出假设和解释假设的助手不是背书人。这样即使模型某个步骤说错了校验模块也能追着打脸避免错误结论一路贯彻到底。2.2 规则知识注入让模型真正读懂控规文本大语言模型没有读过某个城市的控规之前它只懂通用的规划常识不懂本地特殊规定。所以知识注入是推理链路的前置条件。我采用的方法不是把所有条文一次性塞进系统提示词而是先做“条文拆解”把自然语言转成结构化条目再按需检索。拆解时我让模型帮我做一遍粗拆但最终会由人工核对。具体做法是把每段条文按“适用对象—约束指标—边界条件—例外情况—违例后果”整理成一条条记录。例如{ rule_id: A-12-3, source_text: 高层建筑沿城市主干道一侧退让道路红线不少于15米。, objects: [高层建筑], condition: 沿城市主干道一侧, metric: 退让道路红线距离, operator: , threshold: 15, unit: 米, exception: 经规划论证并经批复的市政设施除外 }这样一条条整理出来以后放进向量数据库做语义检索同时也保留一份JSON用于规则引擎做数值判断。模型做推理时先从向量库里找相关条文再把这些条文的原始文本和结构化字段都写进提示词。有人可能觉得结构化之后直接用规则引擎跑不就行了但现实是很多条文没法完全结构化比如“形成连续开放界面”“体现滨水景观特色”这类主观描述必须依赖模型做语义理解。所以我的知识注入方案是“结构化为主、语义检索为辅”两套机制互补。2.3 五段式推理链路从任务解析到结论复核模拟项目X的推理链路被我固定成五步每一步都有独立输出方便人工介入和错误定位。这五步分别是任务解析、规则检索、多步推理、数值校验、结论生成。第一步任务解析是把用户问题里的关键信息抽出来。比如用户说“帮我看看这个方案在A-04地块能不能落地”系统要提取地块编号、方案数据、分析目标。这里我让模型输出一个JSON结构包含用地面积、建筑面积、建筑高度、绿地率、车位数量等字段如果用户没提供就直接给默认空值不猜。第二步规则检索是根据地块属性和指标从知识库中召回候选条文。这里不是把检索结果一股脑塞给模型而是按相关性排序后取前10条左右。第三步多步推理模型把这10条作为依据读一遍方案参数然后一步一步写“因为……所以……”。“因果链”必须明确写在输出里。第四步数值校验是把模型推理过程中提到的关键数值提取出来交给规则引擎做“大于/小于/满足/不满足”的硬判断如果模型算错这一步会直接返回差异。第五步结论生成把校验正确的推理过程和规则引擎结果合并成一份结构化结论附上引用的条文编号、原文摘录、计算过程。输出格式我固定设为JSON方便后续接入报告系统或GIS工具。整套链路跑下来你会明显感觉系统的答案不像聊天模型那么“顺滑”但每一句话都有出处规划师拿去做复核也不需要从头猜。3. 实操过程一个单地块合规审查Demo的完整实现光说设计不够我拿一个简化版的地块合规审查来演示完整实现过程。这个Demo是模拟项目X的第一阶段目标很简单输入一个地块的基础数据和一个建筑方案输出一份合规审查结论。所有代码和数据我都做过脱敏换成虚构样例但流程是完整的。3.1 准备数据从控规文本到知识库我先假设手上有一份“某高新片区控制性详细规划导则”里面包含了地块A-04的主要控制指标容积率上限2.8建筑限高80米绿地率下限30%其中商业地块配建机动车位每100平方米建筑面积不少于0.8个。这些条文形式比较典型我拿来做了第一批知识库。操作上分了四步从PDF里抽出文本保留图则之外的文字说明表格转成Markdown格式。用拆解模板把每条条文填充成刚才那种JSON结构人工校对一遍。将每条文按“条文原文、条文编号、适用地块、指标类型”生成语义文本用向量模型做嵌入存进向量数据库。把结构化规则另存为一个Python字典文件供规则引擎调用。这里要提醒一个细节规划文本经常有“旧版”和“新版”叠加的情况比如某条规则在新版导则里改了但旧版条文还挂在同一章里。知识库必须给每条规则打上版本号和生效日期推理时优先取最新生效版本。我一开始没做版本控制结果模型引用了旧条文把本来违规的方案判断成了合规差点被带偏。3.2 提示词设计让模型输出可解析的推理步骤提示词是整个推理链路质量的关键。我用的系统提示词大概长这样你是一位城市规划决策支持助手。你擅长对建设方案进行合规性分析。 工作原则 1. 只依据用户提供的规划条文和地块数据进行分析不得使用记忆中的规则。 2. 必须逐步推理每步先写“依据”再写“判断”。 3. 涉及数值比较时统一输出为数字不要带单位。 4. 如果某个依据在输入中找不到明确回答“未找到相关依据”不要编造。 5. 最终输出必须符合给定的JSON结构。用户输入部分我把“地块指标”“方案数据”“相关条文”都放进去。这里的关键是“相关条文”必须由系统检索模块提前给出而不是让模型自己回忆。否则模型会把某高校附近通用规范里的条文混进来产生严重幻觉。少样本示例我给了一个典型违规案例让模型看到“先逐条列依据再给结论”的写法效果比只给系统提示词稳定不少。为了降低解析成本我还让模型在输出时把“推理链”和“结论”分开存成两个字段。例如{ reasoning_chain: [ {step: 1, basis: A-04地块地上总建筑面积不超过26800平方米, calculation: 12000 * 2.8 33600}, {step: 2, basis: 方案地上总建筑面积为37200平方米, calculation: 37200}, {step: 3, judgment: 超出限值, actual: 37200, limit: 33600} ], conclusion: { is_compliant: false, violations: [ {indicator: 总建筑面积, actual: 37200, limit: 33600} ] } }这样做的好处是如果规则引擎发现“actual值算错”我可以精确到第几步去修正而不是把整段答案当废稿。3.3 规则校验模块用代码拦截幻觉模型输出推理链后我不会直接相信而是进入规则校验模块。这个模块逻辑非常简单就是用实数比较做复核。我从推理链里提取“指标名、实际值、限制值、约束类型”,然后跑一个函数族。def check_leq(actual: float, limit: float) - bool: return actual limit 1e-6 def check_geq(actual: float, limit: float) - bool: return actual limit - 1e-6 # 示例容积率核验 rate_plan 37200 / 12000 # 3.1 rate_limit 2.8 passed check_leq(rate_plan, rate_limit) # False这个小模块把“计算容积率”这种算术问题从模型那里彻底拿走。模型只负责判断“容积率这个指标要不要查”而真正算容积率、比大小的是Python误差率立刻降得比纯LLM调用低一个数量级。我实测发现加入这个模块后最常见的“少看一位小数点”“把小于等于当大于等于”问题全部被拦住剩下真正需要优化的是推理判断是否找对指标比如漏掉了绿地率或车位配建数。3.4 测试集与评测不能只盯着正确率说事我搭建了一个一百条左右的测试集分成三类明显合规、明显违规、边缘案例。明显合规和明显违规各占四十条边缘案例占二十条。边缘案例包括“刚好等于限值的80米”“绿地率30%但局部塔楼阳台突出形成灰空间”“容积率2.8但车库顶板覆土算入绿地”这类需要人工斟酌的题目。评测时我记录三个指标合规判断准确率、规则引用准确率、推理链完整率。合规判断准确率看最终“是否合规”结论对不对规则引用准确率看引用的条文编号和原文是否为知识库真实内容推理链完整率看模型是否把每一步依据都写出来有没有跳步。实测结果起来后合规判断准确率很容易做到九成以上但规则引用准确率一开始只有八成左右主要问题还是编造条文。后来我把检索结果限制成“只允许引用Prompt中给出的条文ID”规则引用准确率才提高到百分之九十八。边缘案例依然是重灾区待改进空间很大。所以在项目里边缘案例我设置为人工复核队列不让模型单独下结论。4. 踩坑实录和避坑建议做完这个项目最有价值的不是“能跑通”而是一串具体到能复现的坑。我按问题类别整理成一张速查表每个坑都对应实际解决方式。4.1 五个高频问题汇总问题现象根因分析排查思路解决方式模型把“不超过”判断成“超过”条文里“大于”“小于”和“不大于”这类方向词处理混乱把运算符从文本里抽取出来单独校验在提示词里强制模型输出“operator”字段由规则引擎统一判断把“80米”误读成“8米”数值和单位分开后单位丢失检查解析结果里的数字是否保留原始文本提示词要求输出数值和单位两个字段单位不参与计算引用了不存在的“第7.8.9条”模型在自由发挥在结论里抽取所有引用编号和知识库主键比对输出格式限定为只允许引用输入中已有的条文ID把废止的旧版规则取出来知识库没有版本控制检索结果里出现两个版本同编号条文每条规则标版本号按最新版本优先召回边缘案例上一会儿说合规一会儿说违规模型对边界条件理解不稳定检查推理链里的前提假设是否清楚进入人工复核队列取消自动结论我特别想强调第四行“旧版规则”的问题。很多控规修订不会整篇重写而是“原第X条废止新第X条生效”但文本导出时新旧条款可能都在。这时候知识库不做版本隔离模型就会随机选一条。我后来在检索阶段加了“有效期范围”过滤并在提示词里写明“只能使用当前有效版本”。这是一个会被人忽略但极其重要的细节。4.2 防幻觉的实操办法模型幻觉这个问题我在项目里磨合出几个比较土但很管用的办法。第一强制按证据说话。任何结论字段后面都要跟着“依据条文编号”和“原文摘录”如果模型找不到条文就让它输出“未找到依据”。这样即使错误也错得很透明。第二给模型画“知识边界”。用户输入里明确写了“这里只有10条条文超出范围的规则你不需要考虑”。这个约束能显著减少模型把自己训练语料里的城市规划规范搬过来发挥的情况。第三把“判断”和“计算”分离。模型可以判断“该地块需要配建停车位”但不需要自己算车位数量。计算留给代码模型只负责生成中间结论。第四用一致性测试抓幻觉。同一个问题换几种措辞问三遍如果三遍结论不一致就说明模型在这个样本上不稳定自动转入人工。这些办法单独用效果有限合在一起能把可控性拉高很多。4.3 如果你也想做这类系统我的建议从我实际经验看第一次触碰“大语言模型城市规划决策支持”时不建议直接追求一个覆盖全城的复杂系统。先拿一个地块、三条规则、五十条测试数据做Demo把“解析-检索-推理-校验-生成结论”这条链路真正跑通比任何华丽架构都重要。因为只有链路跑通你才会意识到把大语言模型放进决策支持里真正要解决的不是“会不会回答问题”而是“回答完能不能负责”。我一开始就是太着急想同时覆盖住宅、商业、工业、绿地四种用地场景结果被各种用地分类规则和过渡期条款拖垮。后来把范围砍到单一类型建设用地反而在两周内做出了可演示版本。再往外扩也是一类一类往里加每加一类就补一批测试集而不是让模型去读全城规划文件。最后再补一句这类项目的产出不要只盯着聊天框。当模型能给出可复核的推理链能被规则引擎拆穿错误能与指标库、GIS工具打通时它就不再是玩具。你把它放在报告生成、方案比选、初步合规筛查里省下的是规划师最值钱的注意力。我个人体会是宁可让回答慢一秒也要让每一步推理有据可查。