---

摘要

随着人工智能系统深度嵌入医疗、金融、交通、司法、教育、能源、公共治理等高风险领域，治理问题不再只是“应当如何”的规范性讨论，而越来越成为“系统如何即时识别、判断、执行、解释和追责”的工程问题。传统治理文本——法律、标准、政策、伦理准则、学术论文——主要面向人类读者，依赖自然语言表达。自然语言具有高度概括力、语境适应力和价值表达能力，却同时具有歧义性、模糊性、隐含性、不完备性和执行依赖性。机器可执行治理则要求规则具备明确主体、对象、条件、行为、权限、优先级、例外、日志和反馈接口。由此产生一个核心问题：自然语言论文能否承载机器可执行治理信息？

本文认为：自然语言论文可以承载机器可执行治理信息，但不能仅以未经结构化处理的自然语言直接充当机器规则。论文可以成为治理知识的规范来源、语义容器和论证场域；机器可执行性则需要通过受控术语、规则抽取、形式化建模、策略引擎、运行时控制、审计日志和制度授权共同实现。换言之，自然语言论文承载的是“可编译的治理信息”，而不是天然可执行的治理指令。本文提出“治理编译”概念，并构建“自然语言层—语义映射层—形式规则层—执行控制层—审计问责层”的五层架构，讨论其在学术论文、标准文本和治理系统中的实现方式、边界与风险。

关键词：自然语言论文；机器可执行治理；治理编译；形式化规则；政策即代码；可审计AI；双层论文；规范推理

---

一、问题提出：治理文本正在从“给人读”走向“给系统用”

过去，治理文本的主要功能是向人类传递规范。法律条文告诉法官如何裁判，伦理准则告诉研究者如何自律，政策文件告诉机构如何行动，学术论文告诉共同体何种主张具有合理性。它们的读者是人，执行者也往往是人。即使文本中存在模糊表达，人类仍然可以借助常识、经验、职业训练和制度语境进行解释。

然而，当治理对象从人的行为扩展到算法系统时，情况发生变化。一个AI系统并不天然理解“审慎”“公平”“适当”“必要时”“原则上”这些词。它需要的是可计算条件：输入什么数据，读取什么字段，判断什么阈值，调用什么接口，触发什么动作，记录什么日志，由谁复核，如何回滚。治理因此出现了一种新的需求：治理文本不仅要能被人类理解，还要能被机器解析、验证和执行。

这种需求在多个领域同时出现。

在医疗AI中，论文可能提出：高风险诊断模型必须保留不确定性表达，并在低置信度情况下触发人工复核。若这一主张只停留在论文中，它只是伦理建议；若它被嵌入模型部署系统，则可能成为实时阻断机制。

在金融风控中，论文可能讨论：自动化信贷决策必须避免基于敏感属性的直接歧视，并应记录拒绝理由。若论文中的原则被转化为策略规则，系统可以在每次决策时检查特征来源、记录解释字段、限制模型使用特定变量。

在自动驾驶中，论文可能提出：系统在无法确认安全时应进入最小风险状态。这个表达看似清楚，但机器仍需知道：什么叫“无法确认安全”？传感器失效达到什么比例？预测置信度低于多少？最小风险状态是停车、减速还是请求接管？

在内容治理中，论文可能主张：平台应对深度伪造内容进行显著标识。机器需要知道：哪些内容属于深度伪造？识别阈值是多少？标识如何嵌入元数据？申诉机制如何触发？

这些例子说明，自然语言论文并非不能承载治理信息；相反，论文经常是治理概念最早、最丰富的来源。真正的问题在于：论文中的治理信息如何跨越“人类理解”与“机器执行”之间的鸿沟？

---

二、概念澄清：自然语言论文、治理信息与机器可执行性

2.1 自然语言论文是什么

本文中的“自然语言论文”并不限于学术期刊论文，而是泛指以自然语言为主要表达形式的规范性或论证性文本，包括：

• 学术论文；
• 政策报告；
• 伦理指南；
• 技术标准；
• 法律释义；
• 机构治理手册；
• 白皮书；
• 风险评估报告；
• 系统卡、模型卡、数据卡；
• 审计说明与事故复盘。

这些文本的共同特征是：它们以段落、章节、引文、图表和自然语言命题组织知识，而不是以代码、形式逻辑或策略语言作为主要执行载体。

2.2 治理信息是什么

治理信息不是普通事实信息。事实信息描述“是什么”，治理信息则规定“谁在什么条件下应当、可以或不得做什么，并承担何种后果”。

一个完整的治理信息通常包含以下要素：

1. 规范主体：规则约束谁，例如模型开发者、部署者、运营者、用户、监管机构。
2. 适用对象：规则适用于什么系统、数据、场景、人群或风险等级。
3. 触发条件：在何种状态下启动规则。
4. 规范模态：必须、禁止、允许、建议、可豁免。
5. 行为要求：需要采取什么动作，例如复核、阻断、披露、记录、降级、停止。
6. 例外条件：哪些情况下规则不适用或可被更高优先级规则覆盖。
7. 优先级：规则冲突时谁优先。
8. 证据要求：执行前需要何种证据，执行后需要何种记录。
9. 责任主体：谁负责执行、解释、申诉和追责。
10. 生命周期：规则何时生效、失效、修订、废止。

论文中的治理信息往往不完整。它可能只强调价值主张，例如“AI应当透明”，却没有说明透明的对象、字段、阈值、频率、成本和例外。因此，论文承载治理信息的能力，取决于其是否包含或能够被合理补全上述要素。

2.3 机器可执行性是什么

机器可执行性不是“机器能读懂这句话”这么简单。它至少包含四个层次：

第一层：机器可读

机器能够解析文本结构，识别标题、段落、术语、实体、关系和规则候选。

第二层：机器可理解

机器能够将自然语言表达映射到稳定概念，例如把“高风险场景”映射为预先定义的风险分类。

第三层：机器可验证

机器能够检查规则是否一致、完整、可满足，是否与其他规则冲突，是否能通过测试样例。

第四层：机器可执行

机器能够在运行时获取输入、判断条件、调用动作、记录结果，并在异常时进入安全状态。

只有达到第四层，治理信息才真正进入系统行为。前三层只是准备条件。

---

三、自然语言论文的优势：为什么它仍是治理信息的重要载体

尽管机器执行需要形式化，但自然语言论文并非落后载体。相反，它在治理信息生成中具有不可替代性。

3.1 论文擅长表达价值权衡

治理不是单纯的技术优化。公平、隐私、安全、效率、自由、责任之间常常没有唯一最优解。论文可以展示不同价值之间的张力，说明某一规则为何在特定语境下成立。

例如，“医疗AI应优先保障安全”这一主张背后，可能涉及误诊成本、患者自主权、医生责任、资源稀缺性和算法可解释性。论文能够呈现这些复杂理由，而形式规则通常只能表达最终选择，难以完整保留论证过程。

3.2 论文擅长处理例外和语境

自然语言可以表达“原则上”“除非”“在紧急情况下”“当且仅当”“考虑到历史不平等”等复杂限定。治理规则往往需要处理例外，而例外本身又需要解释。论文适合承载这种解释。

3.3 论文能够形成公共可讨论性

治理规则若要获得合法性，不能只是黑箱代码。论文提供公共论证空间，使规则可以被批评、引用、反驳和修订。机器可执行规则若缺少论文层，容易变成“不可争论的技术命令”，削弱民主问责。

3.4 论文能够连接经验证据与规范主张

论文可以引用实验、审计、案例、社会调查和事故复盘，说明某项治理要求为何必要。机器规则本身不产生正当性，正当性来自人类共同体对证据和理由的接受。

3.5 论文是治理概念演化的试验场

许多治理概念最初并非成熟规则，而是论文中的概念框架：算法问责、可解释性、数据主体权利、模型卡、红队测试、AI影响评估、安全案例、预期用途、风险分级。论文先提出概念，随后标准、法规和系统才逐步将其制度化。

因此，问题不是“论文能否承载治理信息”，而是“论文如何承载可被机器继承的治理信息”。

---

四、自然语言论文承载机器可执行治理信息的根本障碍

自然语言论文之所以不能天然机器可执行，不是因为论文质量低，而是因为自然语言与机器执行之间存在结构性差异。

4.1 歧义性

自然语言词汇往往一词多义。

例如，“模型应可解释”中的“解释”可以指：

• 特征重要性；
• 反事实解释；
• 自然语言摘要；
• 可视化；
• 决策依据；
• 训练数据披露；
• 面向专家的技术说明；
• 面向用户的通俗说明。

不同解释对应不同实现。机器若没有明确目标函数和接口，就无法执行。

4.2 模糊性

许多治理概念具有边界模糊性。

例如：

• 高风险；
• 显著影响；
• 合理安全措施；
• 及时通知；
• 适当人工监督；
• 实质性修改；
• 敏感数据；
• 弱势群体；
• 可接受风险。

这些概念在人类判断中可以依赖语境，但机器需要边界。边界不一定来自论文本身，而可能来自标准、法规、行业指南或机构政策。

4.3 隐含前提

论文常省略背景假设。

例如，“系统在异常时应停止运行”隐含：

• 系统有停止权限；
• 停止不会造成更大伤害；
• 存在人工接管；
• 异常可被可靠检测；
• 停止动作有日志；
• 停止后有人负责恢复。

如果这些前提缺失，机器执行可能造成新的风险。

4.4 规则不完备

论文通常不会穷举所有情形。人类可以类推，机器不能随意类推。若规则没有默认行为，系统遇到未覆盖输入时可能崩溃、绕过或做出不安全选择。

4.5 规范冲突

论文中可能存在表面一致但实际冲突的要求。

例如：

• 保护隐私，同时要求审计可追溯；
• 提高透明度，同时保护商业秘密；
• 快速响应风险，同时保障用户申诉；
• 最小化数据收集，同时要求充分证据；
• 自动阻断高风险行为，同时避免误伤。

这些冲突需要优先级、比例原则和例外机制。论文可以讨论它们，但机器执行需要明确排序。

4.6 缺少操作接口

论文中的“停止”“披露”“复核”“限制访问”必须映射到系统接口。没有接口，规则只是愿望。

4.7 动态环境导致规则漂移

论文写作时的技术能力、数据分布、威胁模型和组织环境，可能与部署时不同。规则若不能版本化、监控和修订，就会逐渐失效。

---

五、从“可执行”到“可编译”：提出治理编译概念

本文提出一个核心概念：治理编译。

治理编译是指：将自然语言治理文本中的规范主张，经过术语约束、结构抽取、语义映射、形式化、一致性检查、策略生成、运行时绑定和审计记录，转化为可被机器验证与执行的控制规则，同时保留其人类可读来源与论证依据的过程。

它类似软件编译，但对象不是程序逻辑，而是规范逻辑。

5.1 治理编译的输入

输入包括：

• 论文文本；
• 法规标准；
• 机构政策；
• 风险分类；
• 系统架构；
• 数据字典；
• 指标定义；
• 权限模型；
• 日志规范；
• 测试样例；
• 责任矩阵。

5.2 治理编译的中间表示

中间表示不应直接从自然语言跳到代码，而应经过多层结构：

1. 规则候选层：从文本中抽取可能包含规范意义的句子。
2. 治理要素层：识别主体、对象、条件、动作、模态、例外。
3. 本体层：将术语映射到统一概念。
4. 形式规则层：用逻辑或策略语言表达。
5. 策略包层：打包规则、版本、优先级、适用范围。
6. 执行配置层：绑定指标、接口、权限和日志。

5.3 治理编译的输出

输出包括：

• 可执行策略；
• 监控规则；
• 测试用例；
• 审计日志模式；
• 人工复核流程；
• 例外审批流程；
• 规则解释文档；
• 来源追溯链。

5.4 治理编译不是翻译，而是制度化

治理编译不是简单把中文句子翻译成JSON。它要求组织完成一系列制度化工作：

• 谁有权定义“高风险”？
• 谁有权修改阈值？
• 谁有权批准例外？
• 谁负责验证规则？
• 谁承担误判成本？
• 用户如何申诉？
• 规则如何废止？

没有这些制度安排，机器规则只是技术形式，不是治理机制。

---

六、论文中的治理信息如何被机器继承：一个五层架构

为了让自然语言论文承载机器可执行治理信息，可以构建如下五层架构。

6.1 第一层：自然语言层

这一层保留论文原貌，包括：

• 摘要；
• 引言；
• 文献综述；
• 方法；
• 论证；
• 案例；
• 政策建议；
• 局限性；
• 伦理声明。

自然语言层的核心功能不是执行，而是提供：

• 规范正当性；
• 概念解释；
• 证据基础；
• 价值权衡；
• 公共可讨论性。

这一层应允许复杂表达，不必为了机器执行而牺牲论证深度。

6.2 第二层：语义映射层

这一层建立论文表达与治理要素之间的映射。

例如：

论文表达	治理要素	映射对象
“高风险医疗决策”	适用对象	domain=medical_decision AND risk_level=high
“低置信度”	触发条件	confidence < threshold
“必须提交医生复核”	规范模态与动作	must request_human_review
“具备资质的医生”	责任主体	reviewer_role=licensed_physician
“无法复核时”	例外/回退	fallback withhold_decision

语义映射层的关键是：每个映射都必须可追溯、可解释、可修订。

6.3 第三层：形式规则层

这一层使用机器可处理的语言表达规则。常见形式包括：

• JSON/YAML策略；
• RDF/OWL本体；
• 规则语言如Drools、Rego；
• 线性时序逻辑；
• 事件驱动规则；
• 权限策略语言；
• 智能合约；
• 工作流语言。

形式规则层不要求所有论文都完全形式化，但要求关键治理主张具有可验证表示。

6.4 第四层：执行控制层

这一层将规则接入系统。

例如：

• API网关检查请求是否属于高风险场景；
• 模型服务返回置信度字段；
• 策略引擎判断是否触发人工复核；
• 工作流系统将任务分配给医生；
• 权限系统限制未复核结果输出；
• 日志系统记录每次判断；
• 监控系统统计误报率与漏报率。

执行控制层使规则从“应当如此”变成“系统确实如此”。

6.5 第五层：审计问责层

这一层回答：

• 规则来自哪篇论文、哪条法规？
• 谁批准了阈值？
• 规则何时生效？
• 某次执行依据了哪个版本？
• 是否有人工例外？
• 谁批准例外？
• 用户是否被告知？
• 申诉是否处理？
• 规则是否造成系统性偏差？

审计问责层是治理可执行性的最终保障。没有它，机器执行只是自动化，不是治理。

---

七、什么样的论文最适合承载机器可执行治理信息？

并非所有论文都适合作为机器治理规则来源。适合承载机器可执行治理信息的论文通常具有以下特征。

7.1 明确规范对象

论文必须说明规则适用于谁：开发者、部署者、第三方、用户、监管者，还是模型本身。

例如：

“平台应限制未成年人接触高风险推荐系统。”

这里的主体是平台，对象是推荐系统，条件是未成年人使用。

7.2 明确风险边界

论文应区分不同风险等级，而不是笼统说“高风险”。

例如：

• 低风险：内容推荐；
• 中风险：信用评分；
• 高风险：医疗诊断、刑事风险评估、基础设施控制。

7.3 明确可测指标

论文中的治理要求应尽量绑定指标。

例如：

• 公平性：群体误报率差异；
• 鲁棒性：分布外测试性能下降；
• 隐私：成员推断攻击成功率；
• 安全：红队漏洞发现率；
• 可靠性：故障恢复时间；
• 透明度：解释覆盖率。

7.4 明确默认行为

规则必须说明未满足条件时系统怎么办。

例如：

• 拒绝服务；
• 降级为人工；
• 限制输出；
• 要求补充信息；
• 记录并告警；
• 暂停部署。

7.5 明确例外机制

治理规则不能机械执行。论文应说明例外如何申请、审批和记录。

7.6 明确版本与失效条件

论文若被用于治理，应说明其适用技术版本、数据版本、法规版本和时间范围。

7.7 明确责任链

论文若提出治理要求，应说明谁负责落实，谁负责验证，谁负责追责。

---

八、论文治理信息的形式化路径

8.1 规则抽取

规则抽取是从论文中识别治理句子的过程。

治理句子的典型语言特征包括：

• 规范动词：应当、必须、不得、可以、建议、禁止；
• 条件连接：如果、当、除非、在……情况下；
• 责任主体：平台、开发者、用户、机构、监管者；
• 行为动词：记录、披露、阻断、复核、删除、限制、通知；
• 对象名词：数据、模型、用户、系统、场景；
• 指标名词：准确率、延迟、置信度、偏差、漏洞。

例如：

“若系统处理未成年人个人数据，则不得将画像结果用于个性化广告，并应保存处理记录。”

可抽取为：

• 条件：data_subject_age < 18
• 对象：personal_data
• 禁止行为：use_for_personalized_ads
• 必须行为：retain_processing_log

8.2 本体建模

本体用于统一概念。

例如：

• PersonalData
• Minor
• Profiling
• PersonalizedAdvertising
• ProcessingLog
• Consent
• LawfulBasis

本体解决同义词、上下位关系和跨文档映射。

8.3 规则表达

可以用类似下面的策略语言：

rule:
  id: MINOR-ADS-001
  version: 1.0.0
  source:
    document: "论文标题"
    section: "第4.2节"
    quote: "若系统处理未成年人个人数据，则不得将画像结果用于个性化广告，并应保存处理记录。"
  scope:
    data_subject:
      age:
        lt: 18
    data_type: personal_data
  obligations:
    - modality: prohibition
      action: use_for_personalized_ads
    - modality: obligation
      action: retain_processing_log
      retention_days: 180
  exceptions:
    - condition: explicit_guardian_consent AND lawful_basis = contract
      approval_required: data_protection_officer
  enforcement:
    on_violation:
      - block_action
      - alert_dpo
      - write_audit_log

这比原始论文句子更适合机器执行，但它的正当性仍来自论文和制度。

8.4 一致性检查

形式化后，需要检查：

• 规则是否重复；
• 条件是否永真或永假；
• 动作是否冲突；
• 权限是否足够；
• 例外是否过宽；
• 规则是否可测试；
• 是否违反上位法；
• 是否造成不可能状态。

例如，规则A要求“所有请求必须记录”，规则B要求“用户删除数据后不得保留任何记录”。若没有例外或期限，两者可能冲突。

8.5 测试生成

每条规则应生成测试样例：

• 正例：满足条件，应触发；
• 反例：不满足条件，不应触发；
• 边界例：阈值附近；
• 冲突例：多规则同时命中；
• 异常例：字段缺失、接口失败、权限不足；
• 攻击例：伪造标签、绕过网关、篡改日志。

8.6 策略部署

策略部署需要灰度、回滚和监控。不能把论文中的治理主张一次性变成硬规则，否则可能引发误伤。

---

九、案例一：医疗AI论文如何变成机器可执行治理规则

假设一篇论文提出：

在辅助诊断场景中，AI系统不得替代医生作出最终医疗决定。当模型输出用于可能影响治疗路径的高风险建议时，系统必须向医生展示不确定性，并记录医生是否采纳、修改或拒绝模型建议。

这句话包含多个治理要素。

9.1 抽取治理要素

要素	内容
主体	AI系统、医生
对象	辅助诊断场景、高风险建议
禁止行为	AI替代医生作最终决定
必须行为	展示不确定性、记录采纳情况
触发条件	模型输出影响治疗路径
责任主体	医生
审计要求	记录采纳、修改、拒绝

9.2 形式化

{
  "rule_id": "MED-AI-DECISION-001",
  "version": "1.0.0",
  "scope": {
    "use_case": "clinical_decision_support",
    "risk_level": "high"
  },
  "prohibitions": [
    {
      "action": "final_medical_decision",
      "actor": "ai_system"
    }
  ],
  "obligations": [
    {
      "action": "display_uncertainty",
      "when": "output.influences_treatment_path == true"
    },
    {
      "action": "record_physician_response",
      "fields": ["accepted", "modified", "rejected", "timestamp", "physician_id"]
    }
  ],
  "fallback": {
    "condition": "uncertainty_unavailable OR physician_response_missing",
    "action": "block_final_recommendation"
  }
}

9.3 系统绑定

系统需要：

• 风险分类器判断是否影响治疗路径；
• 模型输出接口提供不确定性字段；
• 医生端界面展示不确定性；
• 电子病历系统记录医生响应；
• 权限系统禁止AI系统写入最终医嘱；
• 审计系统保存操作日志。

9.4 治理效果

论文主张由此变成可执行控制：

• AI不能越权；
• 医生必须看到不确定性；
• 采纳过程可审计；
• 异常时系统阻断；
• 责任链清晰。

9.5 风险与修正

若不确定性字段缺失，系统不能假装合规。若医生长期忽略模型建议，需要分析是模型问题还是流程问题。若规则导致医生负担过重，需要重新设计界面和阈值。

这说明机器可执行治理不是静态规则，而是持续治理循环。

---

十、案例二：内容平台论文如何变成机器可执行治理规则

假设论文提出：

平台应对可能严重误导公众的合成媒体内容进行显著标识，并限制其推荐范围；若内容被专业事实核查机构判定为虚假，平台应在规定时间内降低其传播权重并通知发布者。

10.1 治理要素

• 主体：平台；
• 对象：合成媒体内容；
• 条件：可能严重误导公众；
• 行为：显著标识、限制推荐；
• 外部证据：专业事实核查机构判定虚假；
• 时限：规定时间内；
• 动作：降低推荐权重、通知发布者。

10.2 形式化

rule:
  id: SYNTHETIC-MEDIA-001
  scope:
    content_type: synthetic_media
    harm_risk: high
  obligations:
    - action: apply_label
      label: "AI生成或合成内容"
      placement: visible
    - action: limit_distribution
      method: reduce_recommendation_weight
  trigger_from_external:
    source: accredited_fact_checker
    verdict: false
    actions:
      - action: reduce_reach
        within_hours: 24
      - action: notify_publisher
  audit:
    fields:
      - content_id
      - detector_score
      - fact_check_source
      - label_applied_at
      - reach_before
      - reach_after

10.3 关键难点

• “严重误导”如何判定？
• 检测器阈值如何设定？
• 事实核查机构如何认证？
• 误判如何申诉？
• 新闻讽刺、艺术创作、教育内容如何豁免？
• 降低推荐权重是否构成审查？

这些问题不能仅靠代码解决。论文和制度必须提供判断框架。

---

十一、案例三：金融AI论文如何变成机器可执行治理规则

假设论文提出：

自动化信贷决策不得基于种族、性别、地域等敏感属性作出歧视性判断。系统应记录决策依据，并在拒绝贷款时提供可理解理由。

11.1 形式化

{
  "rule_id": "CREDIT-AI-001",
  "scope": {
    "decision_type": "automated_credit",
    "jurisdiction": "example_region"
  },
  "prohibitions": [
    {
      "action": "use_directly",
      "features": ["race", "gender", "protected_region"]
    }
  ],
  "obligations": [
    {
      "action": "log_decision_basis",
      "fields": ["model_version", "feature_importance", "policy_hits"]
    },
    {
      "action": "provide_reason",
      "when": "decision == rejected",
      "style": "consumer_understandable"
    }
  ],
  "monitoring": {
    "metric": "disparate_impact_ratio",
    "threshold": 0.8,
    "on_breach": "trigger_fairness_review"
  }
}

11.2 难点

• 敏感属性可能通过代理变量间接使用；
• “可理解理由”可能泄露商业秘密；
• 公平指标有多种定义；
• 不同地区法律不同；
• 拒绝理由可能引发诉讼；
• 模型更新可能改变公平表现。

因此，论文中的“不得歧视”必须转化为持续监控，而不是一次性代码检查。

---

十二、案例四：自动驾驶论文如何变成机器可执行治理规则

假设论文提出：

当自动驾驶系统无法可靠感知环境或无法确认安全时，应进入最小风险状态，并请求人工接管。

12.1 自然语言的问题

“无法可靠感知”“无法确认安全”“最小风险状态”都需要定义。

12.2 形式化

rule:
  id: AV-MRM-001
  triggers:
    any_of:
      - sensor_health < 0.7
      - localization_confidence < 0.8
      - prediction_horizon_confidence < 0.6
      - odometry_disagreement > threshold
  actions:
    - action: request_takeover
      timeout_seconds: 10
    - action: execute_minimal_risk_maneuver
      if: takeover_timeout == true
  logging:
    fields:
      - trigger_reason
      - sensor_state
      - takeover_request_time
      - takeover_response_time
      - mrm_start_time
      - mrm_completion_time

12.3 治理含义

这里论文中的安全原则变成车辆控制策略。其风险极高，因为规则执行直接作用于物理世界。此类规则必须经过仿真测试、封闭场地测试、道路测试、认证和事故审计。

---

十三、案例五：科研论文本身如何成为治理对象

如果讨论的是科研论文，尤其是AI论文，其治理信息不仅包括论文内容中的规则，也包括论文生产过程本身的治理。

例如，论文可能提出：

AI研究应披露数据来源、训练限制、潜在滥用场景和失败案例。

这可以转化为论文模板和发布系统的机器规则：

• 提交论文时必须填写数据卡；
• 模型必须附模型卡；
• 高风险应用必须附影响评估；
• 未披露失败案例的论文不得进入会议评审；
• 审稿人必须检查伦理声明；
• 复现代码必须通过安全扫描。

这样，论文不仅是治理信息的载体，也成为治理流程的一部分。

---

十四、“双层论文”：一种新的学术文本形态

为了兼顾人类论证与机器执行，可以提出“双层论文”。

14.1 第一层：人类论证层

保留传统论文结构：

• 问题；
• 背景；
• 方法；
• 证据；
• 论证；
• 讨论；
• 局限；
• 结论。

这一层面向人类读者，负责说服和解释。

14.2 第二层：机器治理层

包含：

• 规则表；
• 术语表；
• 本体；
• 策略文件；
• 测试样例；
• 版本信息；
• 来源映射；
• 审计字段；
• 执行接口说明。

这一层面向系统和审计机构。

14.3 第三层：映射层

映射层说明：

• 哪个论文主张对应哪条规则；
• 哪个规则来自哪个证据；
• 哪个阈值由谁批准；
• 哪个例外由谁审批；
• 哪个测试验证了哪个主张。

14.4 双层论文的价值

它既能保持学术文本的开放性，又能为治理系统提供可操作接口。

传统论文回答：

我们为什么应当这样做？

双层论文还回答：

如果系统要这样做，具体应当如何配置、验证和追责？

14.5 双层论文的局限

• 增加作者负担；
• 可能制造虚假精确性；
• 规则可能被误用为硬法；
• 形式层可能落后于正文；
• 不同机构本体不一致；
• 开源与保密冲突；
• 审计数据本身可能侵犯隐私。

因此，双层论文不能成为万能格式，而应作为高风险治理领域的可选增强。

---

十五、机器可执行治理信息的标准：什么样的规则才算合格？

机器可执行治理规则应满足以下标准。

15.1 可追溯性

每条规则必须能追溯到论文、法规、标准或审批记录。

15.2 可解释性

系统执行规则时，应能说明：

• 为什么触发；
• 依据哪个字段；
• 哪个版本；
• 哪个动作；
• 是否有例外。

15.3 可测试性

规则必须能通过样例验证。

15.4 可组合性

多条规则同时触发时，系统应能确定优先级和合并方式。

15.5 可撤销性

规则应能暂停、回滚、废止。

15.6 可审计性

执行过程必须留下不可抵赖日志。

15.7 可申诉性

被规则影响的人应有申诉渠道。

15.8 可修订性

规则必须能根据事故、反馈和法律变化更新。

15.9 可降级性

当规则系统自身故障时，系统应进入安全状态。

15.10 可问责性

必须明确人类责任主体，不能把责任推给“算法”。

---

十六、自然语言到形式规则的转换方法

16.1 受控自然语言

受控自然语言限制词汇、句式和术语，使文本更容易抽取。

例如规定：

• 所有义务句必须使用“必须”；
• 所有禁止句必须使用“不得”；
• 所有条件句必须使用“当且仅当”；
• 所有例外必须使用“除非”；
• 所有指标必须引用术语表。

这能显著降低抽取难度。

16.2 模板化论文

论文可以包含固定模板：

• 治理目标；
• 适用对象；
• 风险等级；
• 规范主体；
• 必须行为；
• 禁止行为；
• 例外；
• 指标；
• 测试；
• 责任。

16.3 标注规范

论文文本可加入机器可读标注：

:::governance-rule
id: GR-001
source_sentence: "平台不得将未成年人画像用于个性化广告。"
subject: platform
object: profiling_result
condition: data_subject_age < 18
modality: prohibition
action: use_for_personalized_ads
:::

16.4 人机协同抽取

完全自动抽取容易出错。可采用：

1. 模型抽取候选规则；
2. 领域专家确认；
3. 法务审核；
4. 工程师绑定接口；
5. 测试人员生成样例；
6. 审计人员复核。

16.5 规则评审

规则上线前应进行：

• 法律评审；
• 技术评审；
• 伦理评审；
• 安全评审；
• 隐私评审；
• 用户体验评审；
• 事故推演。

---

十七、形式语言选择：不同治理场景适合什么表示

17.1 JSON/YAML

适合简单策略、配置和日志字段。

优点：

• 易读；
• 易部署；
• 易版本控制。

缺点：

• 复杂推理能力弱；
• 本体表达不足。

17.2 RDF/OWL

适合概念体系、法规本体和跨文档映射。

优点：

• 语义表达强；
• 支持推理。

缺点：

• 工程门槛高；
• 执行性能有限。

17.3 规则引擎语言

如Drools、Rego。

优点：

• 接近策略执行；
• 支持条件判断；
• 适合权限和合规。

缺点：

• 复杂价值权衡困难。

17.4 时序逻辑

适合实时系统、安全状态和事件顺序。

例如：

每次高风险输出前必须完成人工复核。

可表达为：

$$G(\text{high\_risk\_output}\to X(\text{human\_review\_completed}))$$

其中 $G$ 表示“始终”，$X$ 表示“下一步”。

17.5 智能合约

适合链上或多方协作场景。

优点：

• 自动执行；
• 不可抵赖。

缺点：

• 不可轻易修改；
• 法律冲突风险；
• 不适合复杂裁量。

17.6 工作流语言

适合人工复核、申诉、审批。

例如：

• 系统触发复核；
• 专家接收任务；
• 专家提交意见；
• 系统记录结果；
• 用户收到通知；
• 申诉进入二审。

17.7 概率策略

适合不确定环境。

例如：

• 风险分数超过阈值；
• 误报率低于目标；
• 多检测器投票；
• 置信度校准。

但概率策略不能替代法律规则，只能辅助判断。

---

十八、治理编译中的关键难题

18.1 概念边界难题

“高风险”不是自然种类，而是制度建构。不同机构可能定义不同。治理编译必须承认概念的社会性。

18.2 指标替代难题

论文中的价值概念常被指标替代，但指标可能偏离原意。

例如：

• 用准确率替代安全；
• 用点击率替代用户福祉；
• 用透明度字段数量替代可理解性；
• 用隐私字段删除替代隐私风险消除。

这会造成“指标治理”而非真正治理。

18.3 规则游戏化

一旦规则机器化，被治理者可能学习绕过规则。

例如：

• 修改内容标签；
• 拆分请求；
• 伪造用户年龄；
• 规避检测阈值；
• 把高风险任务伪装成低风险任务。

因此，治理规则必须包含反规避机制。

18.4 误判成本不对称

阻断错误可能造成严重后果。

例如：

• 错误阻断贷款；
• 错误限制医疗建议；
• 错误标记言论；
• 错误停车；
• 错误冻结账户。

规则必须考虑误判成本，并设置人工复核。

18.5 责任稀释

当论文、标准、模型、策略引擎、平台共同作用时，责任可能分散。

必须建立责任矩阵：

环节	责任主体
规则提出	论文作者/机构
规则批准	治理委员会
规则实现	工程团队
规则测试	安全团队
规则部署	运维团队
异常处置	值班责任人
申诉处理	合规团队
事故追责	法务/监管

18.6 跨法域冲突

同一论文规则在不同国家可能不同。

例如：

• 欧盟强调数据最小化；
• 美国强调行业分散监管；
• 中国强调安全可控与备案；
• 其他地区可能有不同公共政策。

治理编译必须支持辖区参数化。

18.7 论文权威问题

论文不等于法律。论文中的主张可能只是建议。若机器把论文建议硬执行，可能越权。

因此，规则必须标注效力等级：

• 法律强制；
• 标准推荐；
• 机构政策；
• 学术建议；
• 实验性规则。

---

十九、治理编译的制度条件

技术架构不能单独成立。机器可执行治理需要制度基础设施。

19.1 规则治理委员会

负责批准规则、阈值、例外和废止。

19.2 术语委员会

维护统一术语和本体。

19.3 安全评审委员会

评估规则可能造成的新风险。

19.4 申诉委员会

处理被规则误伤的用户。

19.5 审计机构

检查规则是否按版本执行。

19.6 版本管理

规则必须有版本号、生效日期、作者、审批人和变更记录。

19.7 日志标准

日志必须记录：

• 输入；
• 规则版本；
• 判断结果；
• 动作；
• 人工介入；
• 时间戳；
• 操作者；
• 异常状态。

19.8 红队机制

定期测试规则是否可被绕过。

19.9 事故复盘

每次误判都应反推规则缺陷。

19.10 公共解释

规则影响公众时，应提供可理解解释，而不是只给内部代码。

---

二十、论文写作层面的改造建议

如果希望论文更好地承载机器可执行治理信息，可以在写作上采取以下方法。

20.1 区分描述、规范与实现

论文应明确：

• 描述：世界是什么样；
• 规范：应当怎样；
• 实现：系统怎样做到；
• 验证：怎样证明做到了。

不要混写。

20.2 为关键主张编号

例如：

• R1：高风险医疗AI必须保留人工复核；
• R2：低置信度输出不得直接用于治疗决策；
• R3：医生采纳情况必须记录。

编号便于映射到规则文件。

20.3 提供规则表

论文末尾可附规则表：

ID	条件	模态	动作	例外	指标
R1	高风险医疗	必须	人工复核	紧急抢救	复核覆盖率

20.4 提供术语定义

对“高风险”“敏感数据”“显著标识”等词给出定义。

20.5 提供测试样例

给出正例、反例和边界例。

20.6 提供机器可读附件

论文可附：

• JSON策略；
• YAML规则；
• CSV规则表；
• OWL本体；
• 测试集；
• 审计字段说明。

20.7 说明不可形式化部分

论文应诚实说明哪些价值判断无法完全机器化，必须保留人类裁量。

---

二十一、机器可执行治理的边界：哪些内容不应完全交给机器

自然语言论文承载机器可执行治理信息时，必须划定边界。

21.1 价值裁量

公平、尊严、公共利益等概念不能完全由指标替代。

21.2 紧急裁量

某些情况下，机械执行规则可能造成更大伤害。

21.3 复杂情境判断

例如医疗中的患者意愿、家庭压力、临终关怀，不能只靠规则。

21.4 法律解释

法律条文可能依赖判例、比例原则和立法目的，机器只能辅助。

21.5 公共政策选择

规则优先级涉及社会选择，应由民主程序决定。

21.6 不可逆后果

涉及生命、自由、重大财产和名誉的决定，必须有强人工复核。

因此，机器可执行治理的目标不是取消人类判断，而是让人类判断在正确环节出现。

---

二十二、与现有治理工具的关系

22.1 法律

法律提供效力来源。论文不能自动成为法律。

22.2 标准

标准提供术语和测试方法，是治理编译的重要中间层。

22.3 模型卡

模型卡记录模型能力、限制和用途，是论文与系统之间的接口。

22.4 系统卡

系统卡记录系统架构、风险和部署条件。

22.5 数据卡

数据卡记录数据来源、许可、偏差和限制。

22.6 算法备案

备案制度要求披露算法机制和风险，可成为机器治理入口。

22.7 合规自动化

合规自动化是治理编译的一种工程实现。

22.8 政策即代码

政策即代码强调规则可执行，但风险是把政策过度技术化。

22.9 监管沙盒

沙盒允许规则在受控环境中试验。

22.10 审计日志

审计日志是事后追责和事前威慑的关键。

---

二十三、一个完整治理编译流程

下面给出一个可操作流程。

步骤一：论文主张抽取

从论文中提取规范句。

步骤二：治理要素标注

标注主体、对象、条件、模态、动作、例外。

步骤三：术语映射

将术语映射到机构本体。

步骤四：规则草案生成

生成JSON/YAML/规则语言草案。

步骤五：一致性检查

检查冲突、重复、不可满足条件。

步骤六：测试生成

生成正例、反例、边界例、攻击例。

步骤七：专家评审

法律、伦理、安全、工程、业务共同评审。

步骤八：灰度部署

先在低风险环境运行。

步骤九：监控指标

监控误报、漏报、申诉、绕过、性能下降。

步骤十：审计记录

保存每次执行日志。

步骤十一：申诉反馈

将申诉结果反馈给规则维护者。

步骤十二：版本修订

根据反馈更新规则。

---

二十四、示例：从论文句子到完整策略包

论文句子：

对于面向未成年人的生成式AI服务，系统不得生成暴力、色情或自伤内容；当用户表达自伤倾向时，系统应提供求助资源并触发人工支持流程。

24.1 规则抽取

规则1：

• 条件：用户为未成年人；
• 禁止：生成暴力、色情、自伤内容。

规则2：

• 条件：用户表达自伤倾向；
• 必须：提供求助资源；
• 必须：触发人工支持。

24.2 形式化

rules:
  - id: MINOR-GENAI-HARM-001
    scope:
      user_age_group: minor
      service_type: generative_ai
    prohibitions:
      - content_categories: [violence, sexual_content, self_harm]
    enforcement:
      on_violation:
        - block_generation
        - log_event

  - id: MINOR-GENAI-SELFHARM-002
    scope:
      user_age_group: minor
    trigger:
      intent: self_harm_expression
    obligations:
      - action: provide_help_resources
      - action: trigger_human_support
      - action: notify_guardian_if_policy_allows
    audit:
      fields:
        - detected_intent_score
        - resource_shown
        - support_ticket_id
        - guardian_notified

24.3 系统接口

需要：

• 年龄识别模块；
• 内容安全分类器；
• 自伤意图识别器；
• 求助资源库；
• 人工支持工单系统；
• 监护人通知策略；
• 日志系统。

24.4 例外与风险

• 年龄识别可能误判；
• 自伤表达可能误识别；
• 通知监护人可能增加风险；
• 求助资源可能不适配；
• 人工支持可能延迟。

因此，规则必须允许申诉、人工判断和持续优化。

---

二十五、机器可执行治理是否会导致“规则暴政”？

机器可执行治理有潜在风险：规则一旦进入系统，就会自动、持续、大规模地作用。人类可能因为系统效率而不敢挑战规则。

这会产生几种问题。

25.1 规则刚性

系统可能无法处理例外。

25.2 规则不透明

用户不知道自己被哪条规则影响。

25.3 规则漂移

规则版本更新后，用户无法预期。

25.4 规则外包

企业把治理责任外包给供应商，导致问责困难。

25.5 规则指标化

复杂价值被简化为可计算指标。

25.6 规则逃避

被治理者学习绕过规则。

25.7 规则合法化偏差

机器执行会给规则一种“技术必然”的外观，削弱公共争论。

因此，必须保留：

• 人工复核；
• 申诉机制；
• 规则公开；
• 版本变更通知；
• 定期审查；
• 人类最终责任；
• 公共参与。

---

二十六、自然语言论文与机器规则之间的“解释性中间件”

为了让论文不被机械翻译，需要解释性中间件。

26.1 规则说明书

每条机器规则应有说明书：

• 来源；
• 目的；
• 适用条件；
• 不适用条件；
• 误判风险；
• 申诉方式；
• 责任人。

26.2 决策树

可视化规则触发路径。

26.3 反例库

记录规则不应触发的场景。

26.4 事故库

记录规则造成的真实事故。

26.5 影响评估

评估规则对不同群体的影响。

26.6 模拟推演

在部署前模拟规则后果。

---

二十七、学术论文评价标准的变化

如果论文开始承载机器可执行治理信息，学术评价也需要变化。

传统论文评价关注：

• 创新性；
• 严谨性；
• 可复现性；
• 理论贡献；
• 实践意义。

双层论文还应评价：

• 规则可追溯性；
• 形式化质量；
• 测试覆盖；
• 审计字段完整性；
• 例外机制合理性；
• 部署风险说明；
• 申诉机制设计；
• 开源与可验证性。

这并不意味着所有论文都必须附代码和策略文件。高风险治理论文更应如此。

---

二十八、对期刊、会议和出版平台的启示

出版平台可以建设机器治理附件标准。

28.1 提交系统支持治理附件

允许作者上传：

• 规则表；
• 术语表；
• 测试样例；
• 策略文件；
• 审计字段；
• 风险矩阵。

28.2 审稿人检查治理可执行性

审稿问题可包括：

• 论文中的“应当”是否可操作？
• 关键概念是否有定义？
• 规则是否可测试？
• 是否说明误判后果？
• 是否保留人工复核？

28.3 发布后维护

论文发表后，规则可继续更新。出版平台可维护版本链。

28.4 机器可读引用

论文规则可以被系统引用：

策略引擎使用论文《某治理框架》第4.2节规则R3，版本1.2。

这使学术引用进入治理基础设施。

---

二十九、对企业和监管机构的启示

29.1 企业

企业不能只发布伦理原则，而应建立：

• 规则库；
• 策略引擎；
• 审批流程；
• 测试环境；
• 审计日志；
• 申诉系统；
• 事故复盘机制。

29.2 监管机构

监管机构可要求：

• 高风险系统提交规则清单；
• 规则版本备案；
• 关键阈值说明；
• 日志可审计；
• 重大变更报告；
• 第三方测试报告。

29.3 标准组织

标准组织应提供：

• 术语本体；
• 风险分类；
• 测试基准；
• 日志标准；
• 规则交换格式。

---

三十、对AI系统设计的启示

AI系统若要支持论文治理信息落地，应提供以下能力。

30.1 策略引擎

支持规则加载、版本管理和优先级。

30.2 上下文标签

系统应知道当前请求属于什么场景、用户类型、风险等级。

30.3 指标接口

模型输出应包含可治理字段，如置信度、风险分数、敏感标签。

30.4 人工复核接口

规则触发后，可转人工。

30.5 日志接口

所有判断和动作必须记录。

30.6 回滚接口

规则错误时可快速回滚。

30.7 申诉接口

用户可请求人工重新判断。

30.8 模拟接口

上线前可模拟规则影响。

---

三十一、对研究方法的启示

未来研究可以采用以下方法。

31.1 治理文本挖掘

从论文、法规、标准中抽取治理规则。

31.2 规则冲突检测

自动发现规则冲突。

31.3 规则可执行性评估

判断论文主张是否具备机器执行条件。

31.4 规则影响模拟

模拟规则部署后的社会和技术后果。

31.5 人机协同规则评审

让模型辅助抽取，让专家确认。

31.6 规则演化追踪

追踪同一概念在不同论文中的变化。

31.7 规则滥用检测

发现规则被规避或武器化的模式。

---

三十二、一个反例：哪些论文不适合直接机器执行

有些论文虽然重要，但不适合直接机器化。

32.1 高度哲学性论文

例如讨论“正义”“主体性”“人的尊严”的论文。它们提供价值框架，但不能直接变成阈值。

32.2 探索性论文

提出概念但未给出稳定定义。

32.3 批评性论文

指出问题但未提出可操作替代方案。

32.4 个案研究

情境特殊，不能泛化为规则。

32.5 未经验证的规范主张

没有证据支持其治理效果。

32.6 政治性文本

表达立场但缺少稳定适用条件。

这些论文仍然重要，只是其作用在于启发、批判和论证，而不是直接执行。

---

三十三、机器可执行治理信息的成熟度模型

可以建立治理可执行性成熟度。

L0：纯价值宣示

例如：“AI应当向善。”

特点：

• 无法执行；
• 无法测试；
• 无法审计。

L1：原则表达

例如：“AI应当公平。”

特点：

• 有方向；
• 无指标；
• 无流程。

L2：概念定义

例如：定义公平为群体误报率差异小于某值。

特点：

• 有指标；
• 缺执行接口。

L3：规则草案

例如：当误报率差异超过阈值时触发审查。

特点：

• 可形式化；
• 缺系统绑定。

L4：可测试规则

具备正例、反例和边界例。

L5：可部署策略

绑定接口、权限、日志。

L6：可审计运行

有版本、日志、申诉和复盘。

L7：自适应治理

规则能根据环境变化自动建议修订，但仍需人类批准。

论文通常位于L1到L3之间。要进入L4以上，需要工程与制度配合。

---

三十四、治理编译的失败模式

34.1 过度形式化

把不可形式化的价值强行写成规则。

34.2 伪精确

用小数点后的阈值制造虚假科学感。

34.3 规则堆叠

规则太多，系统无法维护。

34.4 规则冲突

不同部门规则互相矛盾。

34.5 指标替代

治理目标被指标目标替代。

34.6 日志膨胀

记录大量数据，却无法解释决策。

34.7 权限不足

规则要求动作，但系统没有权限执行。

34.8 人工复核瓶颈

规则触发大量复核，人工无法处理。

34.9 申诉失效

申诉渠道存在，但无人处理。

34.10 规则僵尸化

规则长期不更新，与现实脱节。

---

三十五、如何评估一条机器可执行治理规则的质量？

可用以下指标。

35.1 来源清晰度

规则是否来自明确论文、法规或审批？

35.2 条件可测性

条件是否能被系统读取？

35.3 动作可执行性

系统是否能执行该动作？

35.4 误判可控性

误判是否可发现、可纠正？

35.5 申诉有效性

受影响者是否能申诉？

35.6 审计完整性

是否能重建决策过程？

35.7 社会可接受性

公众是否能理解该规则？

35.8 法律一致性

是否与上位法冲突？

35.9 技术可维护性

规则是否容易更新？

35.10 效果可评估性

是否能评估规则是否达成目标？

---

三十六、自然语言论文承载机器可执行治理信息的理论意义

这个问题不仅是工程问题，也涉及规范理论。

36.1 规范的可计算化边界

哪些规范可以计算化，哪些必须保留解释？

36.2 文本权威与技术权威的关系

论文权威来自论证，技术权威来自执行。二者如何结合？

36.3 人类判断的位置

机器执行治理并不意味着取消人类判断，而是重新安排判断环节。

36.4 责任分配

当规则来自论文、实现来自工程、执行来自系统，责任如何分配？

36.5 合法性来源

机器规则若影响公众，其合法性不能来自代码效率，而必须来自公共论证和制度授权。

36.6 可争议性

好的治理系统必须允许规则被质疑。

---

三十七、一个更准确的命题

因此，本文的核心命题可以表述为：

自然语言论文能够承载机器可执行治理信息，但这种承载是潜在的、条件性的、制度依赖的。论文提供治理信息的规范来源和语义解释；机器可执行性则来自治理编译过程，包括术语标准化、规则形式化、接口绑定、测试验证、运行控制、审计日志和人类问责。

也可以进一步表述为：

自然语言论文不是机器治理规则本身，而是机器治理规则的论证性母体。

这避免了两种极端：

一种极端是认为自然语言论文可以直接变成机器法律；

另一种极端是认为自然语言论文对机器治理毫无作用。

---

三十八、未来展望：论文作为治理基础设施

未来，论文可能不只是知识传播单元，而成为治理基础设施的一部分。

38.1 论文规则库

论文中的治理主张被抽取为规则库，供系统引用。

38.2 规则引用机制

系统日志可引用论文规则版本。

38.3 学术规则市场

不同机构发布经评审的规则包。

38.4 规则影响追踪

论文规则被哪些系统使用，造成哪些效果，可被追踪。

38.5 动态法规映射

论文规则与法规变化自动比对。

38.6 公共规则解释

面向公众解释规则为何存在。

38.7 跨机构治理图谱

论文、标准、法规、策略、事故形成知识图谱。

38.8 人类监督优先

即使规则自动执行，关键决定仍保留人类批准。

---

三十九、结论

自然语言论文能否承载机器可执行治理信息？答案是：能，但必须经过治理编译。

论文可以承载治理信息，因为治理信息首先来自人类对价值、风险、责任和制度的论证。论文最擅长保存这种论证。然而，机器执行需要稳定条件、可测指标、明确接口、优先级、日志和申诉机制。这些不是自然语言论文天然具备的属性。

因此，最合理的路径不是让论文变成代码，也不是让代码取代论文，而是建立双层结构：

• 论文层负责解释、论证和正当性；
• 规则层负责形式化、执行和审计；
• 映射层负责连接二者，并保证可追溯。

在这种架构下，自然语言论文可以成为机器可执行治理的规范来源。机器执行也不再是冷冰冰的自动化，而是被人类论证、制度审批和公共问责包围的治理机制。

最终，机器可执行治理的目标不是让机器替人类作决定，而是让治理规则在关键时刻能够被系统及时识别、执行、解释和追责。论文的价值，则在于确保这些规则仍然来自可讨论、可批评、可修正的人类理性。