本文转载自微信公众号「全帧派」，原文发布于 2026-10-11。

项目地址：https://atomgit.com/qzp001/codexdrafter

拿到手是一个代码包，解压后有四个文件夹：app 程序本体、tests 测试、tools 验证脚本、docs 说明。不需要注册就能看——页面若弹登录框，关掉即可。 需要准备：Python（本项目用 3.13 版）与 PostgreSQL（开源数据库，存规范与审查记录）。

我们做过不少「AI 帮设计院审图」的演示，效果通常不错：给一段文字，吐出几条疑似问题，标着红黄底。

但每次演示结束，总有人问同一句：

「这条『不合规』，它凭什么这么说？」

这一问，所有演示都站不住了。所以这篇文章不讲功能，讲更小的一件事：一条疑点从一行文字走到「可追溯」，要过哪几道关口，哪几处最容易出错。

一、先把问题问对

「AI 审图准不准」是个太大的问题，回答它只要一个数字：召回率多少、误报率多少。可这两个数字我们现在拿不出来——没有真实项目数据，测了也是自说自话。

先把问题拆小。设计院里的「审图」，实际是三件事：

• 查规范条文。 日常翻纸质规范或 PDF。出错时的代价是记错条号，自己发现得了。
• 看设计说明有没有漏项。 日常凭经验逐条对。出错时的代价是漏一条就发出去，图就废了。
• 签发文件。 日常总工逐页核。出错时的代价是签字人要担法律责任。

风险不同，AI 的介入方式就不该一样。于是把问题重新问成：

一个只会说「好」的工具，和一个会明确说「这条我没依据」的工具，哪个更有用？

第二、三、四节分别回答：为什么「不知道」必须是正式功能、怎么让每条结论带回出处、这套思路在哪一定会崩。

怎么用这篇：想直接拿去部署，看第三节；想知道这套东西的边界在哪，看第四节。第五节是可以照着做的三步。

二、让「不知道」成为正式功能

先讲一个反直觉的判断：一个总是有答案的规范检索工具，比一个经常说「没有」的更危险。

原因不难理解。设计师问你「地下室车库的最小坡度是多少」，如果系统给了个数字，你查一下觉得不对劲，会去找规范原文核对。但如果系统说「库里没有这一条」，你直接去翻书——这个动作本身就是核验。

真正的危险在中间地带：系统给了个答案，看起来很像真的，你不去核对。

所以我们给检索加了第三种状态：

• 正常情况：库里查到了，命中，并且把条文原文和标准号一起返回。
• 不该出现：库里查到了，但没有条文原文——这不是命中，是幻觉。
• 弃权：检索得分低于阈值，直接输出「未检索到依据」。

弃权不是「异常时的兜底做法」（fallback，指出错了才启用的备用方案），而是一个正常的、需要出现在最终输出里的结论。它必须出现在界面上、必须能被审查者看到。

这里有个只有真动手才会碰到的细节：检索靠向量（把文字变成一串数字，好让电脑比较两段话像不像）。本机装不上数据库的向量扩展，就改用 numpy（Python 的数值库）算精确相似度。

但精确不等于可用——算得准不代表理解语义。于是系统界面明写「向量覆盖 100%」，同时标注：当前文本嵌入是哈希式的，不是真语义。

不粉饰能力边界，比展示能力更值钱。 一个诚实说「我这里用的不是真语义」的工具，用户知道怎么用；一个不说的，第一次被坑就不会再用第二次。

法条依据方面，《注册建筑师条例》第二十四条、第二十八条规定了执业责任。我们把它写成了系统约束：AI 输出的措辞不允许出现合规判定，只能说「疑点」。

这一条可以被机器验证：测试不测「系统会不会拒绝」，而是主动尝试让系统违反约束，再证明它真的拒绝了。

三、每条结论，都要能带回它的出处

设计说明里写了一句「疏散走道净宽度为 1000mm」，系统要报它，依据是某条规范里的「疏散走道的净宽度不应小于 1.1m」。中间要串起来，至少四个字段：

抽取值 1.0（米） 判据 不应小于 1.1 标准号与条号 某规范某条 置信度 0.95

任何一环缺了，这条疑点就不能落库。

约束的实现位置：数据库层。证据引用字段不允许是空数组，靠数据库的校验规则拦住——那是一种在建表时就写死的检查条件，不是代码里写个判断，是数据库直接拒绝。

为什么放数据库那一层？因为代码可以被改、被绕过、被注释掉；数据库的校验规则是最后一道线。

一个把作者自己坑了的坑

这个项目里有一条审查规则，名字叫「消防控制室设置面积」，绑定了某规范的某一条，阈值写的是 20 平方米。

看起来完全合规：填了标准号、填了条号、阈值是数字、测试通过、代码规范。

后来我们拿条号去联网核实，发现那条讲的是完全无关的内容——里面根本没有「面积」这两个字。

那个 20 是我编的。

严重性在于：一条依据错误的规则，比没有规则更糟。没有规则，你知道自己的局限；有一条假依据的规则，你会以为系统在校验，而它实际在拿一个编出来的数字做比较。

补这道口子花了三步：

1. 核实记录外置——条文内容登记在文件里，附核实人与日期，该文件不公开
2. 门禁常驻——每次跑测试自动核对：阈值数字必须真的出现在它引用的条文里，不出现就报错退出
3. 反向验证门禁本身——注入一条编造规则看它拦不拦

第 3 步最值钱。实测把疏散宽度阈值从 1.10 改成 3.50，门禁立刻报「阈值 3.5 不在条文数字中」。

断言会绿不代表它在测东西。 有的门禁写完一直绿，真注入违规数据它还是绿——因为压根没被执行到。

一个只有动过手才知道的细节

审查规则的抽取环节有个坑，实测才发现的。

原设计是：看到关键词「疏散走道净宽度」，取它后面 40 个字符里的数字。

如果文本是「疏散走道净宽度为 1000mm，疏散楼梯净宽度为 1100mm」——它会把楼梯的 1100 也抽出来当成走道的宽度。

后果是：楼梯更窄而走道合规时，系统会报一个根本不存在的走道问题。

改法是遇标点提前截断。但立刻冒出第二个坑：「疏散走道净宽度，不小于 1.0m」这种写法（逗号紧邻关键词）会一个值都抽不到——「抽不到」意味着规则无法判定，强条就漏检。所以截断后必须检查是否取到值，取不到就退回不截断。

更危险的一种：关键词不存在时原设计退回全文抽取。查「疏散走道净宽度」而文本只有「建筑面积 1200m²」，抽出来的是 1200 平方米，规则拿它去比 1.1 米的阈值——凭空造出一条依据。抽错值是误报；凭空造值会误报，而且看起来很像真的。现在直接返回空。

你该怎么用：自己写规则时，阈值不要凭印象填，必须回条文原文核对。这一条省不掉。

四、这套思路在哪里一定会崩

讲到这里必须泼冷水。这是全文最要紧的一节。

崩口一：库是空的

我们内置的规范条文条数，读者可以在仓库里自己数——是占位内容，不是真实规范。原因很简单，第六节讲。

那么真实使用者拿到这个工具，第一件事就是导入自己的规范库。而导入之后，检索才有意义。

现在的问题是：设计院常用的几本规范，光是强制性条文就有几百条。规则要覆盖到什么程度才够用，这笔账要算清楚——我们粗估覆盖两本常用规范需要两三百条规则，按每条 20 到 40 分钟（含核对条文、写配置、测一遍），总工需要投入 70 到 130 小时。

这个数字比听起来更重：总工每周 4 到 8 小时，意味着 9 到 16 周。这不是工具能解决的问题。

崩口二：覆盖面现在很小

我们当前库里是 4 本规范、15 条条文、7 条审查规则（3 条为占位示例）。按一本常用防火规范约 300 条强条算，覆盖率不到 2%。

拿一段接近真实的建筑电气设计说明跑一遍，系统能准确发现疏散楼梯净宽不足（确实超限），但消火栓间距、水泵接合器数量、防火分区上限——全都查不到。

实测五个高频问题三个查不到。查不到比查错更伤信任——查错人会核对，查不到人直接放弃。

崩口三：测试全绿 ≠ 生产可用

有一次我们发现数据库里少了一张表——服务正在运行，规则接口直接报 500。而当时的单元测试是全部通过的。

原因不复杂：测试自己建表、自己测，跑在隔离库里，压根看不见生产库少了一张表。

后来加了一道结构检查：服务启动前对着真实数据库比对模型定义，不一致就拒绝启动。

教训不是「要写结构检查」，是 「测试全绿」不构成生产可用性证据。任何说「测过了所以没问题」的，都该被追问：测的是哪个环境。

崩口四：隐私数据的路由

工程图纸常含涉密信息。我们按「能否出内网」把数据的密级分成三档，并且涉密档只走本地模型：本地没启用就直接拒绝，绝不降级到云端。

宁可不能提供能力，也不把涉密数据送出内网。

这一条在演示时经常被问「这样是不是太保守了」。我们的判断是：这类判断出错一次就够赔一年，保守的代价是少一个功能，放松的代价是泄密。

你该怎么用：如果你的单位有数据出内网的明确规定，请把密级分级改成你们自己的口径，不要沿用我们的三档。

五、今天下午就能做的三件事

如果你手上正好有一个设计院的项目，可以按这个顺序试。

第一步：先只测检索。 挑 20 个总工最常查的问题逐个问，重点看它有没有说「查不到」。超过一半查不到，说明现在只配当索引用，不该用于审查。

第二步：导出约束清单。 系统会列出当前生效的全部约束，每条标注强制方式（代码 / 数据库 / 文档）与对应验证用例。验收方据此逐条核对，而不是听开发方说「我们做了」。当前 17 条，靠人自觉的是 0 条。

第三步：只让它出「疑点」，不出「结论」。 措辞层面的限制由数据库强制，不是提示词里写软的。

任何一步结果不如预期，先别改工具——先确认数据有没有导进去。我们的排查顺序就是：先查结构、再查数据、最后才怀疑逻辑。

六、这个项目的版权边界

《国家标准管理办法》第十条：标准及外文版依法受版权保护，标准的批准发布主体享有标准的版权。

所以这个仓库不含任何国家标准的原文或实质性摘录。 具体做了三件事：

• 内置语料用虚构编号，前缀是 EX-，条文文本是自己编的占位内容。
• 运行时拦截——加载语料时如果检测到真实标准编号，直接抛错拒绝。
• 常驻测试——任何被 Git 跟踪的文件如果含真实标准编号，测试直接失败。

需要处理真实规范的使用者，自行取得合法授权或官方授权数据，放到仓库里预留的数据目录（该目录内容不随仓库分发）。

发布前踩过一个坑，正好说明第三件事为什么必要：第一次推送时忽略规则只按后缀排除，一份含 74 处真实标准编号的日志进了公开仓库。改完规则，内容已经推上去了，只能重建仓库历史——现在仓库只有一个提交，旧内容不可达。

我们把这个过程写成了工具：验收脚本匿名克隆仓库到临时目录，逐项核对文件清单、历史深度、有无真实编号。它不看本地任何状态——推送脚本自己报「成功」不算数。

实测：提交数 1，文件数 83，真实标准编号 0 处。

我们不做、也不承诺的事

• 不做合规判定。 输出是疑点线索，认定权在相应专业注册工程师。
• 不使用任何标准原文，也不代为获取。
• 不承诺覆盖率。 现在按行内口径不到 2%，会变，但今天就是这个数。
• 不承诺召回率。 没有真实项目数据之前，「召回率」这三个字我们不写。
• 不评价同业产品。
• 提供的是参考工具，不是交付物。 上生产前请让你们的法务与信息安全部门各看一遍。

结语

回到开头那个问题：一条「不合规」，凭什么这么说？

现在这套东西给的回答是：它给不出这个回答。它只说「这里有疑点，这是我们抽到的数，这是它对照的条文，这是可信度」，然后把结论留给签字的人。

听起来像退了一步。但我们认为这是它唯一正确的姿势——

一个会明确说「我没依据」的工具，比一个总能给出答案的工具，更配得上签字那份责任。

说明与免责

• 本文所述项目已开源，采用 Apache-2.0 许可（一种允许他人自由使用、修改和再分发代码的开源许可协议，企业商用友好）。许可原文以仓库内 LICENSE 文件为准，本文不对许可条款作任何诠释。
• 文中涉及的法律条款（国家标准管理办法、勘察设计注册工程师管理规定、注册建筑师条例等）仅为说明设计依据，不构成法律意见，具体适用以现行有效文本与主管机关解释为准。
• 文中提到的各类编号标准文件，在本项目中仅用于描述来源分级，不代表本项目遵循或引用其具体条文；仓库内也不含其中任何原文或摘录。
• 文中全部配图与封面由程序按固定版式绘制或为页面截图，不含人工智能生成内容，故不适用《人工智能生成合成内容标识办法》的标识义务。
• 本文数据均取自项目当次实测输出。项目处于早期阶段，数字会变，请以仓库实际状态为准。
• 本文不代表任何官方机构立场。使用者应自行核实并遵守本单位的保密规定、数据出域要求与专业执业管理规定。

资料来源

来源分级说明：A 级 = 项目自身可核对的材料与法律法规原文；B 级 = 说明设计约束所依据的部门规章原文；C 级 = 我们的经验观察与粗估，不作依据。

A 级（项目自述，可直接核对）

• 许可为 Apache-2.0 —— 仓库内 LICENSE 文件
• 不含标准原文的声明 —— 仓库内 NOTICE 文件
• 内置语料为虚构编号 —— 仓库内 tests/corpus.py
• 17 条约束及其强制方式 —— 运行中服务的合规约束清单接口
• 分层测试数（245 / 111 / 82 / 38） —— 项目 tools/ 下四个验证脚本的当次输出
• 代码规模、接口数、模型数 —— 项目源码当次统计
• 匿名克隆验收结果（提交数 1、真实编号 0 处） —— 项目发布验收脚本的输出

B 级（法律依据，仅用于说明设计约束）

• 规定标准及外文版受版权保护的条款 —— 部门规章《国家标准管理办法》第十条（引用其法名，非引用其技术内容）
• 设计文件须注册工程师签字盖章后生效 —— 《勘察设计注册工程师管理规定》第二十条
• 注册建筑师执业责任相关规定 —— 《注册建筑师条例》第二十四条、第二十八条

C 级（现象提示，不作依据）

• 设计院日常规范查询与审查流程的具体耗时与习惯，来自我们与从业者的交流，属经验观察，非统计数据。
• 总工每周可投入 4–8 小时、覆盖两本规范需 70–130 小时，为粗估量级，请按各自单位情况重新测算。

原文：全帧派 · 研究撰稿