mbx/mb-ms-doc.git

			@@ -20,6 +20,12 @@
			4. 结果是否和过程、数据、图片一致。
			5. 结论是否过读。

			案例审核员还必须检查案例事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 案例分析规范、项目本地案例分析规范，以及该案例直接声明采用的案例设计、存储、执行和审核规则。

			如果案例设计或执行违反规范中的硬约束，例如跳过必要审核、未记录关键证据链、越权改写正式产物、候选选择与设计不一致、结论超出证据边界，必须反馈为审计问题。

			如果只是命名、格式、表达方式等不影响案例目标、证据链、结论和后续使用的轻微差异，不应作为阻断问题。若规范之间冲突或规范本身不清楚，应标记为规范问题，不得强行按审核员个人理解加规则。

			## 2. 设计审核

			设计审核在正式执行前进行。

			@@ -70,6 +70,12 @@

			如果来源聊天记录里的用户要求和实验目标或实验设计不一致，必须反馈 `来源要求不一致`。不能只按实验设计本身审核。

			实验审核员还必须检查实验事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 实验规范、项目本地实验规范，以及该实验直接声明采用的实验设计、存储、执行和审核规则。

			如果实验设计或执行违反规范中的硬约束，例如跳过必要审核、未记录关键证据链、越权改写正式产物、结论超出证据边界、未按目标判断未来函数要求，必须反馈为审计问题。

			如果只是命名、格式、表达方式等不影响实验目标、证据链、结论和后续使用的轻微差异，不应作为阻断问题。若规范之间冲突或规范本身不清楚，应标记为规范问题，不得强行按审核员个人理解加规则。

			### 2.2 只抓真问题

			实验审核不吹毛求疵。

			@@ -16,6 +16,12 @@

			审核员不应为了形式完美而层层加码。只阻断会影响目标、边界、实现、验证或结论的问题。

			需求审核员还必须检查需求事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 需求规范、项目本地需求规范，以及该需求直接声明采用的需求方案、架构、模块说明、核心流程、执行和审核规则。

			如果需求设计或产物违反规范中的硬约束，例如跳过必要审核、未记录来源聊天或上游依据、越权改写正式产物、需求边界与规范冲突、结论或交付状态超出证据范围，必须反馈为审计问题。

			如果只是命名、格式、表达方式等不影响目标、边界、实现、验收和下游使用的轻微差异，不应作为阻断问题。若规范之间冲突或规范本身不清楚，应标记为规范问题，不得强行按审核员个人理解加规则。

			## 2. 设计审核

			设计审核发生在正式执行或交给下游前。