{
  "schemaVersion": "1.0",
  "type": "research-article",
  "runtimeAvailable": false,
  "id": "proof21:journal:one-artifact-three-decisions:zh-Hans",
  "inLanguage": "zh-Hans",
  "slug": "one-artifact-three-decisions",
  "title": "一份文件，三种不同决定。",
  "description": "即使界面简单，也要区分完整性、评估与接纳。",
  "datePublished": "2026-09-07",
  "dateModified": "2026-09-07",
  "url": "https://proof21.xyz/zh-hans/journal/one-artifact-three-decisions/",
  "markdownUrl": "https://proof21.xyz/zh-hans/journal/one-artifact-three-decisions/article.md",
  "markdown": "# 一份文件，三种不同决定。\n\n**协议设计笔记 · 2026 年 9 月 7 日**\n\n在网站上写“已验证”很容易，精确使用这个词却困难。验证的是签名、计算、交易包含关系、策略条件，还是采取下一步行动的权限？\n\nProof21 拟议接收方接口有意区分这些问题。用一个绿灯隐藏差别，不适合作为自主金融工作流的基础。\n\n## 1. 验证文件\n\n第一层询问：在认可密钥假设下，文件是否完整并正确绑定？它检查结构、签名、签发方、操作引用及受支持编码规则。\n\n这可以确立签发方签了什么，不能独立证明所有签名声明都为真。PEAC 等现有记录协议明确区分签发方报告证据的边界。[1]\n\n接收系统还需要密钥发现、轮换及吊销策略。对所提供密钥进行离线检查，不是该密钥当前仍获认可的证据。\n\n## 2. 评估具名声明\n\n下一层对明确证据集合应用特定策略。例如比较付款接收方及金额是否符合指令，或根据引用字段和规则复现 DMT 推导。\n\n输出有明确范围：通过、失败或无法判断，并附原因。不能把一个谓词通过，扩展成对智能体安全、投资表现或整个过程轨迹完整性的笼统保证。\n\n证据类型很重要。签名声明、RPC 观察、包含证明及独立验证状态不可互换。共同报告封装应保留差别。\n\n## 3. 应用本地接纳策略\n\n接收方再决定结果是否足够支持下一步。低价值监控任务与高价值金融承诺，对来源、最终性、签发方、新鲜度及人工批准可能有不同要求。\n\n所以 P21 不替代钱包或平台所有防护措施。权力仍归接收方。报告是在既有权限下考虑的证据，不是新的权限授予。\n\n## 对外简单，对内明确\n\n开发体验仍可简洁。一个 SDK 可携带请求、保留原始证据、产生结果并暴露接收方验证器。简单应来自一致接口，而不是消除不确定性。\n\n首个实现里程碑是两个独立进程完成闭环：一个生成报告，另一个复现受支持检查并拒绝篡改证据。当前文档描述的是该目标；已发布 SDK 仍不可用。\n\n## 真实有效的失败报告也是有用证据\n\n假设生成方签署一份报告，说明某次合成付款使用了错误的收款方。独立使用方确认报告未被修改，且签名可在提供的、被接受的密钥下通过验证。此时完整性结果可以是正面的，而付款评估为 `FAIL`。策略随后可以把该报告接受为有用证据，同时拒绝授权与付款有关的下一步操作。这是三个一致的结果，并不矛盾。\n\n反过来，一份完整无损的报告也可能包含生成方没有证据支持的成功主张。评估器不能从签名那里借来确定性。W3C 可验证凭证数据模型是有用的原始参考，帮助区分对凭证机制的验证与依赖方的信任决策；Proof21 并不声称其草案产物格式自动就是一种 W3C 凭证。[2]\n\n这种区分也能改进错误消息。“不支持的证据配置”提示使用方获取兼容的实现或其他证据。“收款方不匹配”描述一个受支持但失败的比较。“本地策略不接受该签发者”涉及权限与信任。如果把三者都压缩为“无效”，可能让补救更困难，并鼓励不安全的重试。\n\n## 签名之前，先确定字节表示\n\n两个 JSON 对象在人看来可以等价，但编码仍然不同。签名需要精确定义的消息，而不是屏幕截图或读者的理解。RFC 8785 定义了 JSON 规范化方案，包括数据限制与确定性的序列化规则。它是相关的设计参考，却不能替代为具体实现选择并测试确切的序列化配置。[3]\n\n对于金融配置，大额货币数量应保留为表示原子单位整数的十进制字符串，而不是随意通过浮点运算转换。被接受的模式必须定义类型并拒绝歧义。它还应把网络、确切资产、操作标识、策略版本、指令摘要和结果摘要绑定到被认证的上下文之内，而不是把重要标签留在外面。\n\n解析器应依据其公开规则拒绝不支持的版本以及重复或冲突的字段。进行昂贵计算之前，应限制输入大小。应使用成熟的密码学库及其测试向量，而不是让大语言模型发明签名验证方法。RFC 8032 提供 EdDSA 的参考与测试向量；选择 Ed25519 本身并不能证明密钥所有权、撤销状态或行动权限。[4]\n\n## 接受决定属于一个明确命名的使用方策略\n\n设想两个使用方收到同一份报告。监控面板允许在回顾性分析中展示一份已明确标记的过时观察。资金控制器则要求当前证据、特定签发者、足够的确认条件以及人工批准。面板展示报告、控制器拒绝与交易有关的行动，是合理的不同决定。\n\n报告不能代替控制器悄悄选择更弱的策略。应记录评估了哪个策略、是否满足其前提，以及实际授权了哪一个后续动作。后来的策略更新不能改写先前决策的历史含义。应保留原版本以供重放，并在需要重新评估时记录一项新决定。\n\n试点中，让生成方与使用方作为独立进程运行，并使用独立配置。测试真实有效的负面报告、被修改的证据、错误的操作标识、未知版本、缺失的观察，以及不被接受的签发者。教育用途的离线演示已经提供有限完整性与策略检查的合成示例，但这不代表动态密钥发现、所有证据适配器或生产级接受服务已经存在。\n\n## 常见问题\n\n### 签名验证能通过，而付款检查失败吗？\n\n能。正确签名的报告可以如实描述一个失败的付款条件。完整性涉及经过认证的产物；评估涉及指定的主张与证据。界面应明确显示两种结果。\n\n### 接受一份报告就授权智能体花钱了吗？\n\n并不是。使用方可以接受一份报告用于存储或审查，而不授予转移资金的权限。行动权限属于应用明确的授权策略与控制措施。\n\n### 所有证据类型都能归结为一个信任分数吗？\n\n这样做会掩盖重要差异。签名断言、RPC 观察和独立验证的状态支持不同的主张。通用封装应保留原始证据类型、来源、限制与尚未解决的问题。\n\n## 补充原始参考资料\n\n- [2：W3C 可验证凭证数据模型 v2.0](https://www.w3.org/TR/vc-data-model-2.0/)\n- [3：RFC 8785 — JSON 规范化方案](https://www.rfc-editor.org/rfc/rfc8785.html)\n- [4：RFC 8032 — Edwards 曲线数字签名算法](https://www.rfc-editor.org/rfc/rfc8032.html)\n\n## 继续阅读\n\n- [接收方验证模型](https://proof21.xyz/zh-hans/docs/protocol/verification/)\n- [安全与信任边界](https://proof21.xyz/zh-hans/docs/protocol/security/)\n- [1：PEAC 范围与证据边界](https://www.peacprotocol.org/)\n",
  "articleBody": "协议设计笔记 · 2026 年 9 月 7 日 在网站上写“已验证”很容易，精确使用这个词却困难。验证的是签名、计算、交易包含关系、策略条件，还是采取下一步行动的权限？ Proof21 拟议接收方接口有意区分这些问题。用一个绿灯隐藏差别，不适合作为自主金融工作流的基础。 1. 验证文件 第一层询问：在认可密钥假设下，文件是否完整并正确绑定？它检查结构、签名、签发方、操作引用及受支持编码规则。 这可以确立签发方签了什么，不能独立证明所有签名声明都为真。PEAC 等现有记录协议明确区分签发方报告证据的边界。[1] 接收系统还需要密钥发现、轮换及吊销策略。对所提供密钥进行离线检查，不是该密钥当前仍获认可的证据。 2. 评估具名声明 下一层对明确证据集合应用特定策略。例如比较付款接收方及金额是否符合指令，或根据引用字段和规则复现 DMT 推导。 输出有明确范围：通过、失败或无法判断，并附原因。不能把一个谓词通过，扩展成对智能体安全、投资表现或整个过程轨迹完整性的笼统保证。 证据类型很重要。签名声明、RPC 观察、包含证明及独立验证状态不可互换。共同报告封装应保留差别。 3. 应用本地接纳策略 接收方再决定结果是否足够支持下一步。低价值监控任务与高价值金融承诺，对来源、最终性、签发方、新鲜度及人工批准可能有不同要求。 所以 P21 不替代钱包或平台所有防护措施。权力仍归接收方。报告是在既有权限下考虑的证据，不是新的权限授予。 对外简单，对内明确 开发体验仍可简洁。一个 SDK 可携带请求、保留原始证据、产生结果并暴露接收方验证器。简单应来自一致接口，而不是消除不确定性。 首个实现里程碑是两个独立进程完成闭环：一个生成报告，另一个复现受支持检查并拒绝篡改证据。当前文档描述的是该目标；已发布 SDK 仍不可用。 真实有效的失败报告也是有用证据 假设生成方签署一份报告，说明某次合成付款使用了错误的收款方。独立使用方确认报告未被修改，且签名可在提供的、被接受的密钥下通过验证。此时完整性结果可以是正面的，而付款评估为 FAIL 。策略随后可以把该报告接受为有用证据，同时拒绝授权与付款有关的下一步操作。这是三个一致的结果，并不矛盾。 反过来，一份完整无损的报告也可能包含生成方没有证据支持的成功主张。评估器不能从签名那里借来确定性。W3C 可验证凭证数据模型是有用的原始参考，帮助区分对凭证机制的验证与依赖方的信任决策；Proof21 并不声称其草案产物格式自动就是一种 W3C 凭证。[2] 这种区分也能改进错误消息。“不支持的证据配置”提示使用方获取兼容的实现或其他证据。“收款方不匹配”描述一个受支持但失败的比较。“本地策略不接受该签发者”涉及权限与信任。如果把三者都压缩为“无效”，可能让补救更困难，并鼓励不安全的重试。 签名之前，先确定字节表示 两个 JSON 对象在人看来可以等价，但编码仍然不同。签名需要精确定义的消息，而不是屏幕截图或读者的理解。RFC 8785 定义了 JSON 规范化方案，包括数据限制与确定性的序列化规则。它是相关的设计参考，却不能替代为具体实现选择并测试确切的序列化配置。[3] 对于金融配置，大额货币数量应保留为表示原子单位整数的十进制字符串，而不是随意通过浮点运算转换。被接受的模式必须定义类型并拒绝歧义。它还应把网络、确切资产、操作标识、策略版本、指令摘要和结果摘要绑定到被认证的上下文之内，而不是把重要标签留在外面。 解析器应依据其公开规则拒绝不支持的版本以及重复或冲突的字段。进行昂贵计算之前，应限制输入大小。应使用成熟的密码学库及其测试向量，而不是让大语言模型发明签名验证方法。RFC 8032 提供 EdDSA 的参考与测试向量；选择 Ed25519 本身并不能证明密钥所有权、撤销状态或行动权限。[4] 接受决定属于一个明确命名的使用方策略 设想两个使用方收到同一份报告。监控面板允许在回顾性分析中展示一份已明确标记的过时观察。资金控制器则要求当前证据、特定签发者、足够的确认条件以及人工批准。面板展示报告、控制器拒绝与交易有关的行动，是合理的不同决定。 报告不能代替控制器悄悄选择更弱的策略。应记录评估了哪个策略、是否满足其前提，以及实际授权了哪一个后续动作。后来的策略更新不能改写先前决策的历史含义。应保留原版本以供重放，并在需要重新评估时记录一项新决定。 试点中，让生成方与使用方作为独立进程运行，并使用独立配置。测试真实有效的负面报告、被修改的证据、错误的操作标识、未知版本、缺失的观察，以及不被接受的签发者。教育用途的离线演示已经提供有限完整性与策略检查的合成示例，但这不代表动态密钥发现、所有证据适配器或生产级接受服务已经存在。 常见问题 签名验证能通过，而付款检查失败吗？ 能。正确签名的报告可以如实描述一个失败的付款条件。完整性涉及经过认证的产物；评估涉及指定的主张与证据。界面应明确显示两种结果。 接受一份报告就授权智能体花钱了吗？ 并不是。使用方可以接受一份报告用于存储或审查，而不授予转移资金的权限。行动权限属于应用明确的授权策略与控制措施。 所有证据类型都能归结为一个信任分数吗？ 这样做会掩盖重要差异。签名断言、RPC 观察和独立验证的状态支持不同的主张。通用封装应保留原始证据类型、来源、限制与尚未解决的问题。 补充原始参考资料 2：W3C 可验证凭证数据模型 v2.0 3：RFC 8785 — JSON 规范化方案 4：RFC 8032 — Edwards 曲线数字签名算法 继续阅读 接收方验证模型 安全与信任边界 1：PEAC 范围与证据边界",
  "citations": [
    "https://www.w3.org/TR/vc-data-model-2.0/",
    "https://www.rfc-editor.org/rfc/rfc8785.html",
    "https://www.rfc-editor.org/rfc/rfc8032.html",
    "https://www.peacprotocol.org/"
  ],
  "faq": [
    {
      "question": "签名验证能通过，而付款检查失败吗？",
      "answer": "能。正确签名的报告可以如实描述一个失败的付款条件。完整性涉及经过认证的产物；评估涉及指定的主张与证据。界面应明确显示两种结果。"
    },
    {
      "question": "接受一份报告就授权智能体花钱了吗？",
      "answer": "并不是。使用方可以接受一份报告用于存储或审查，而不授予转移资金的权限。行动权限属于应用明确的授权策略与控制措施。"
    },
    {
      "question": "所有证据类型都能归结为一个信任分数吗？",
      "answer": "这样做会掩盖重要差异。签名断言、RPC 观察和独立验证的状态支持不同的主张。通用封装应保留原始证据类型、来源、限制与尚未解决的问题。"
    }
  ],
  "sourceSha256": "001d1d86547ae12669b394e68d2f07863f1c65aee3801dfd3d1d24efaa905da8",
  "markdownSha256": "d2b4c3ee7c3d439945b4b8cd4235d740152ae7c9df89f584376927bd45f0a963",
  "translationReview": "完整简体中文译文，由 AI 辅助准备，尚未完成独立母语技术审阅。存在歧义时以英文规范为准。代码、字段和权限不因翻译而改变。",
  "image": {
    "url": "https://proof21.xyz/assets/journal/verdict.png",
    "caption": "三道独立关卡分别代表产物完整性、主张评估和使用方接受。通过其中一道，不意味着通过下一道。",
    "sha256": "0e0f3f9f2bd48d65b0f629d46ed5da6ef4e636f98f93cf9b907d0ee9a7ebc92e"
  },
  "motion": {
    "url": "https://proof21.xyz/assets/journal/verdict.mp4",
    "engine": "Remotion",
    "sourceSha256": "13a909f4267d8147386045cbd90df732a42679342c16e04c5725e09e953d3728",
    "sha256": "08e845dff21811c106caf90103805e17df6d2c9851520b7c622ae0df50591d1b",
    "seconds": 7.2,
    "loop": true,
    "audio": false
  },
  "availableLanguages": [
    "en",
    "zh-Hans",
    "th",
    "ar"
  ],
  "editions": {
    "en": "https://proof21.xyz/journal/one-artifact-three-decisions/",
    "zh-Hans": "https://proof21.xyz/zh-hans/journal/one-artifact-three-decisions/",
    "th": "https://proof21.xyz/th/journal/one-artifact-three-decisions/",
    "ar": "https://proof21.xyz/ar/journal/one-artifact-three-decisions/"
  }
}