AIGC 与智能合约集成：生成内容上链前先做责任边界

一、上链不是给 AIGC 镀金

AIGC 生成内容和区块链结合，常见说法是版权确权、生成记录可信、内容流转透明。这些方向有价值，但不能把"上链"当万能背书。链上记录能证明某个时间点写入了某个哈希，不等于证明内容原创、不侵权、质量可靠。

我之前和一个做数字藏品的朋友聊，他们的产品页面写着"AI 生成作品，已上链确权"。我问了一句："上链保护的是哪个权利？版权？署名权？还是发行权？"他说不出来。后来细看，链上存的只是一个图片哈希和调用者地址，没有任何版权登记、没有任何法律链接、没有任何内容审核。换句话说，这段链上记录最多证明"某人上传过一个哈希"，离"版权保护"差了十万八千里。

工程落地时，要先定义责任边界：AI 生成什么，用户确认什么，链上记录什么，合约执行什么。不要把模型输出直接写进不可修改的链上状态。链越不可逆，写入前越要谨慎。更关键的是，上链前必须确认用户已经清楚看到了最终版本。如果用户点了"确认"后发现 AI 把日期算错了、把公司名翻译歪了、或者图片里隐含了侵权行为，存储在链上的哈希就成了一个不可抹去的错误记录。

二、业务链路：生成、确认、哈希、上链

flowchart LR
    A[用户发起生成] --> B[AIGC 生成草稿]
    B --> C[人工确认]
    C --> D[计算内容哈希]
    D --> E[内容安全审核]
    E --> F[调用智能合约]
    F --> G[链上记录凭证]
    G --> H[链下存证归档]

这里最关键的是人工确认和内容安全审核两步。AIGC 输出可能包含错误、侵权风险或敏感内容。上链前必须让用户确认最终版本，并保存明确的内容哈希。链上不一定存全文，很多场景只需要存哈希和元数据。

内容安全审核这一步很多人会跳过，理由是"用户自己确认过了"。但不同用户对风险的判断能力差异很大——有的用户能看出 AI 编造的假数据，有的完全依赖系统。如果因为跳过审核，导致违法违规内容被写入不可修改的链上状态，系统的法律责任会非常复杂。上链前至少做一轮关键词扫描、敏感图片检测和基础合规检查，把明显的风险挡在链外。

关于哈希，建议用 SHA-256，并在合约事件里附带 hash 算法标识。如果未来算法升级或者需要支持多重签名，链上记录的元数据就不会被算法变更困扰。

三、合约示例：只记录哈希和所有者，加事件和幂等

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ContentProof {
    struct Proof {
        address owner;
        bytes32 contentHash;
        uint256 createdAt;
    }

    mapping(bytes32 => Proof) public proofs;

    // 业务流水号，防止重复提交
    mapping(string => bool) public registeredBizIds;

    event ProofRegistered(
        bytes32 indexed contentHash,
        address indexed owner,
        string bizId,
        uint256 timestamp
    );

    function register(bytes32 contentHash, string calldata bizId) external {
        require(proofs[contentHash].createdAt == 0, "hash already registered");
        require(!registeredBizIds[bizId], "bizId already used");
        proofs[contentHash] = Proof(msg.sender, contentHash, block.timestamp);
        registeredBizIds[bizId] = true;
        emit ProofRegistered(contentHash, msg.sender, bizId, block.timestamp);
    }
}

这个合约很小，但有清晰边界：它只证明某个地址登记过某个哈希，不证明内容合法。bizId 是链下系统生成的业务流水号，用来做幂等判断——同一个业务操作不会提交两次。ProofRegistered 事件让链下监听器可以同步存证状态，构建完整的审计链路。产品文案必须说清楚，否则用户会误解"上链"等于"版权认证完成"。

四、工程边界：链下系统更复杂

真正复杂的是链下。内容存储在哪里，哈希如何计算，用户如何签名，生成过程如何审计，敏感内容如何拦截，撤回请求如何处理，这些都不是合约能单独解决的。智能合约负责不可篡改记录，业务系统负责合规和体验。

取舍方面，把全文上链透明度高，但成本高、隐私差、不可删除；只存哈希成本低、隐私好，但需要链下存证配合。多数 AIGC 内容凭证场景，存哈希和必要元数据更务实。链上数据越少，未来纠错空间越大。

还要处理生成版本。用户可能多次修改 AI 草稿，最终确认的是第几个版本？每个版本是否都要存证？如果只登记最终版，生成过程如何证明？这些要按业务目标决定，不要为了"完整"把所有中间内容都写上链。

合约调用还要考虑失败和重放。用户确认后，交易可能因为 gas、网络或 nonce 问题失败；前端重试又可能重复提交。链下系统应生成业务流水号，合约侧或服务侧做幂等判断。不要把区块链的不确定性直接暴露给普通用户。

内容审核也不能因为上链而跳过。AIGC 生成的文本、图片、音频都可能有风险，上链前至少要经过基础安全和合规检查。链上不可篡改的特性，会放大错误内容的后果。越不可撤销，越要前置审核。

还有一个容易被忽视的问题：用户撤回。如果用户注册了一条内容哈希后反悔了，链上记录怎么办？技术上无法删除，但可以把原记录标记为"已撤销"，并在链上追加一条新的撤销声明。产品设计一开始就要想好这个流程——不是技术能不能做，而是用户知不知道会发生什么。

另外，哈希计算的输入源必须一致。同一段文字，加不加空格、用什么编码、是否带时间戳，算出来的哈希都不同。建议在业务规范里明确定义：哈希输入 = 原始内容 + 算法标识 + 时间戳，或只取定长内容。避免因为前端和后端计算的哈希不一样，导致"存了但查不到"的尴尬。

五、总结

AIGC 与智能合约集成，重点不是把内容直接上链，而是定义生成、确认、哈希、审核、存证和责任边界。链上记录可信，但内容合规、用户权益和业务流程的完整性，最终要靠链下系统来兜底。上链之前，先想清楚：如果出错了，谁能承担责任。