为什么不该让同一个 AI 模型既参与设计，又参与独立复核

结构设计里，复核不是把同一份答案再看一遍。

它要换一条思路、一组证据和一套检查路径，去找设计者已经习惯、甚至没有意识到的前提。

这个问题并不只属于结构工程。

写代码、查资料、写报告、整理规范，都可能出现同一种工作流：先让一个 AI 生成，再把结果交还给它，请它“严格检查”。第二次回答往往更完整，也更像一份复核意见。但模型可能只是沿着原来的思路又走了一遍。

更稳妥的分工是：

主模型负责产出，第二个模型负责挑错，确定性工具负责验证，人负责判断和责任。

2026 年 7 月 2 日，英国结构工程师学会（IStructE）发布了一份新指南，讨论软件计算模型在开发、使用和验证中应如何做质量保证与质量控制。与之配套的 LLM 指南把问题说得很直接：

当 LLM 已经参与设计或计算过程，它还能不能又来做“独立复核”？

IStructE 的立场是：现阶段不能把 LLM 当作独立复核者。在 DMRB Category 2 和 Category 3 这类要求人员、过程和工具独立的检查中，复核方不应使用设计阶段的同一个 LLM，也不应使用基于同一底层模型的工具。

这不是中国工程项目的强制规范，不能直接套用为国内审查等级。但它指出的“共同盲区”问题，适用于每一个正在把 AI 接入重要工作的人。

一、同一个模型，容易沿用同一套前提

假设一份结构计算的荷载组合输入错了。

设计人员先让某个 LLM 帮助整理计算思路，后面又让同一个模型“检查一遍”。模型可能会修正格式、单位或明显遗漏，却继续接受最初那个错误前提。

第二次输出看起来更整齐，但没有形成第二条证据链。

编程也一样。主模型如果一开始误解了接口契约，后续让它审查自己的代码，它可能补上异常处理、调整命名，却仍然沿用那个错误的接口假设。

写报告时，模型如果先引用了一个已经废止的标准，再让它核对全文，它也可能只检查前后是否一致，不会主动发现标准版本错了。

文件变了，表达变了，错误的来源没有变。

同一底层模型还可能共享这些问题：

• 对专业概念或任务模式的固定偏差；
• 对版本、条文、接口和适用条件的错误记忆；
• 在信息不足时补齐细节的倾向；
• 对同一类图纸、表格、代码或长文档的相似识别失败；
• 用流畅语言遮住不完整推理。

2023 年的 MT-Bench 与 Chatbot Arena 研究在讨论“用 LLM 评价 LLM”时，也记录了位置偏差、篇幅偏差、自我增强偏差和推理能力限制。这项研究不等于证明每个模型都会偏爱自己的答案。它说明的是：模型评审本身也是一个会出错的环节，不能天然当作客观裁判。

让同一个 AI 再检查一次，仍然有用。它可以抓格式、遗漏和局部不一致。

但这叫自检，不叫独立复核。

二、把四种角色分开，工作流才清楚

“用了两个模型”还不是完整方案。至少要把四种角色分开。

| 角色 | 适合做什么 | 不能独自承担什么 | | --- | --- | --- | | 主模型 | 形成思路、生成初稿、编写代码、整理资料 | 为自己的产出提供独立背书 | | 挑错模型 | 寻找遗漏、反例、错误假设和边界条件 | 把批评意见直接变成最终结论 | | 确定性工具 | 编译、测试、静态分析、规则校验、工程计算 | 判断目标是否正确、结果是否适用于真实场景 | | 专业人员 | 确认目标、输入、证据、异常和责任边界 | 把“模型一致”或“工具已运行”当作结果正确 |

第二个模型的价值，不一定来自综合能力更强。

它可以是一个更适合挑错的模型，也可以只是因为训练来源、提示方式和关注重点不同，提出了主模型没有提出的问题。能力不是一条从低到高的直线。一个模型不擅长完成整项任务，不代表它不能在某个局部发现问题。

确定性工具解决的是另一类问题。

代码可以交给编译器、类型检查、静态分析和测试。结构模型可以交给经过测试的计算内核、基准算例和简化验算。引用可以回到原始文件、官方页面和版本记录。

这些工具也不会替你决定目标是否合理。

一个平面框架模型少了支座，一组荷载方向反了，计算内核仍然可能精确地返回一个错误问题的答案。测试用例如果只覆盖了开发者想到的路径，也可能全部通过。

所以最后还需要人来问：问题定义对不对？证据够不够？异常是否可以接受？谁批准，谁负责？

三、不同模型交叉检查，有价值但有边界

我自己的软件开发流程里，会让 Codex 负责主要编码，再让 Gemini 做红队复核，专门挑错误假设、遗漏和边界条件。

在我当前使用的模型版本和编码任务中，Gemini 承担复杂实现时不如 Codex 稳定，但它仍然发现过 Codex 漏掉的问题。

这正是第二个模型的价值：它未必更强，但可能从另一条路径发问。

红队复核也不能只发一句“请严格检查”。为了减少第二个模型沿用原答案的叙事，至少可以改变三件事：

1. 检查目标：明确要求找错误假设、遗漏条件、反例和无法验证的结论，不要求润色。
2. 上下文顺序：先给任务、约束和验收标准，再给主模型的结果，避免让答案先定义问题。
3. 输出格式：要求逐项给出问题位置、风险、证据和验证办法；查不到就写“不确定”。

即使这样，这仍是异构模型交叉检查，不是工程意义上的独立复核。

两个模型可能错得不同，也可能一起接受同一个错误前提。它们还可能使用了相似的公开资料、代码样例或行业表达。更换模型只改变了工具条件，没有自动改变人员、证据和责任。

IStructE 对独立复核的要求更高。至少要改变以下条件：

1. 人员不同：检查者没有参与原方案的形成，能够质疑设计者已经习惯的前提。
2. 路径不同：不只是重跑原模型，而是从荷载传递、数量级、极端工况和简化模型重新建立判断。
3. 工具不同：需要独立性的检查，不把设计阶段的同一 LLM 或同底层模型换个名字再用一次。
4. 证据不同：复核者能够回到图纸、计算假设、设计规范和原始输入，而不是只读 AI 的总结。

换一个模型，可以增加错误暴露的机会。

它不能把 AI 变成签字人。

四、这套分工不只适用于结构计算

结构工程把责任边界说得最清楚，因为错误可能直接影响安全。但“生成、挑错、验证、决策”的分工，可以迁移到更多工作中。

编程：第二个模型挑错，测试系统给证据

主模型可以实现功能、修改代码和补测试。第二个模型适合从失败路径、权限边界、并发、数据迁移和兼容性角度挑问题。

最后不能用“两个模型都认为没问题”作为通过标准。

NIST 的安全软件开发框架把可读代码的审查或分析，与可执行代码的测试列为不同的验证任务。放进 AI 编程流程里，含义很简单：模型意见之后，还要运行编译、类型检查、静态分析、单元测试、集成测试和必要的人工代码审查。

报告和研究：第二个模型找漏洞，原始来源定真伪

主模型可以搭结构、写初稿、整理材料。第二个模型可以检查概念偷换、证据断裂、反例缺失和结论是否超出材料。

但引用是否存在、版本是否现行、数据能否支持结论，要回到论文、规范、公告、合同或原始数据核对。

两个模型写出了同一个条文号，不代表条文号就是真的。

工程计算：LLM 提供线索，求解器返回结果，工程师判断适用性

LLM 可以解释方法、辅助写代码、整理输入和提示遗漏。经过测试的力学求解器按明确方程和数据契约返回可重复结果。

在我们开发 ArchSight Solver 的过程中，v1.6.0 开始让项目契约、模板发现、导出来源和外部宿主交互变得可检查。这解决的是“计算能力怎样被系统接住”，不会自动回答“这个工程模型是不是建对了”。

工程师仍要确认荷载、边界条件、模型维度、规范依据、异常和简化验算。

三个场景的工具不同，底层原则相同：

模型负责提出候选答案，证据负责限制答案，人负责接受或拒绝答案。

五、AI 参与后，交接记录要多说几件事

当 AI 参与代码、计算、报告或资料整理，只交最终文件已经不够了。

一份可复核的交接记录，至少应说清：

• 用了什么：产品、底层模型、版本或使用日期、接入方式；
• 用在哪里：初稿、代码、检索、数据整理、结果解释或红队复核；
• 给了什么上下文：任务目标、地区、版本、约束和关键假设；
• 哪些内容已经人工确认：公式、条文、接口、单位、数据转换和异常值；
• 确定性验证怎么做：测试、静态分析、规则校验、简化模型、另一软件或抽样重算；
• 谁负责：编制、复核、审批人员及其确认状态。

这不是要求团队保存所有对话。真实工作涉及客户资料、设计数据、源代码和个人信息，不应把敏感内容不加选择地长期留存。

要保留的是足以解释工具介入程度、主要假设、验证结果和人工责任的证据。

六、团队现在可以做的五件事

不用先采购一套庞大的“AI 管理平台”。

从五个小动作开始就够了。

1. 给工具分角色

明确哪个模型负责生成，哪个模型负责挑错，哪些工具提供确定性验证，谁做最终判断。

不要让“都能做一点”演变成“谁都没有明确责任”。

2. 给挑错模型单独的检查任务

不要让第二个模型只润色主模型的答案。

给它错误清单、验收标准和失败样例，让它回答“哪里可能错、怎样证明”，而不是回答“看起来是否合理”。

3. 把模型意见落到可执行验证

代码问题要能落到测试或静态分析；计算问题要能落到原始输入、基准算例或简化验算；引用问题要能落到官方来源和版本记录。

如果一个问题只能由另一个模型投票决定，它还没有被验证。

4. 用失败样例测试流程

不要只用条件完整的标准答案测试 AI。

可以故意准备缺少荷载、单位不一致、版本不明、权限不足、接口变化或引用错误的样例，看主模型会不会停下来，看挑错模型能不能指出问题，看验证环节能否阻断。

5. 记录模型、证据和责任

企业内部工具看上去可能是不同产品，底层却调用同一个商业模型。模型和版本不记录，就无法讨论工具独立性。

同样，测试报告、计算输入、来源页面和人工确认状态也要能追溯。只有模型日志，没有验证证据，仍然不能交付。

结语：不要让 AI 既出题，又给自己判满分

结构工程把这个问题说得很严肃：独立复核需要独立的人员、路径、工具和证据。

编程和通用知识工作未必都需要同等级别的审查，但可以借用这套思路。

同一个模型再回答一次，是自检。

换一个模型来挑错，是交叉检查。

编译、测试、计算和原始来源，提供可重复的验证。

人决定哪些证据足够，哪些风险可以接受，并承担最后的责任。

AI 进入的工作越重要，越不能让它既负责产出，又负责证明自己正确。

参考资料

1. The Institution of Structural Engineers, Calculation models – new guidance for the use of software for engineering calculations, 2026-07-02.
2. The Institution of Structural Engineers, Calculation models: artificial intelligence - large language models.
3. The Institution of Structural Engineers, Implementing AI in structural engineering.
4. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023.
5. National Institute of Standards and Technology, Secure Software Development Framework (SSDF) Version 1.1, 2022.
6. ArchSight Solver, 在线体验.

关注我们

欢迎搜索并关注 筑见实验室，获取更多建筑 AI、结构计算与工程数字化实践：