AI 生成内容的合规自查清单
监管对 AI 深度伪造、虚假信息、违规爬取的整治持续收紧。内容生产者和技术开发者各需要一份自查清单。
这两年写技术博客的人都有一个直观感受：AI 几乎是每个作者的隐形合著者了。从帮我润色一段拗口的句子，到直接生成一整篇教程的初稿，再到把截图丢进去让它读图写说明，我已经很难说清一篇发布出去的文章里到底有多少是"我自己写的"。这本身没什么问题，工具就是用来用的。但 2026 年的环境跟两年前不一样了：监管在落地，平台在加规则，读者也开始在意"这块内容到底是人是机"。一个写 FastAPI 和 Vue3 的个人站，过去从没想过要跟"合规"二字沾边，如今却不得不认真想：我发出去的每一篇，算不算 AI 生成内容？要不要标？标了会不会反而被限流？
我以前对合规这件事是有点抵触的。总觉得那是大公司法务的事，个人博客谁会管。后来想明白一件事：合规不是给权威低头，而是给读者一个诚实的交代，也给自己留一条退路。当一篇用 AI 辅助写的技术文里出现了一个过时 API 或一段跑不通的代码，如果读者知道这是 AI 参与的、会带着审视去看，误会就少很多；反过来，若你假装全是亲笔、又频频出错，信任反而崩得更快。更现实的是，平台算法现在会主动识别并处置未标识的 AI 内容，你不标，可能直接被限流或消失在信息流里，辛苦写的文章没人看，对靠内容吃饭的人来说，这是最实在的代价。我有个朋友坚持"全手写不设标"，结果一篇明明是自己写的深度文被算法误判成 AI 文、流量掉了九成，他这才意识到：标识不只是对 AI 内容的义务，也是给真人内容的"防伪证明"。从这角度想，标识对老实人反而是保护。
所以这篇文章不谈宏大的法律理论，只谈一件落地的事：作为个人博客作者，怎么在日常写作里建立一份"发布前合规自查清单"。我会把监管共识、要做的事、清单本身、声明写法、工具局限，以及怎么把这套动作变成肌肉记忆都讲一遍。写作时间背景放在 2026 年 9 月，里面提到的规则口径都是公开共识层面的概括，不构成法律意见，我自己也不是律师，个人博客更该关注的是"大方向别踩雷"。下面所有讨论，都假设你和我一样，是个在乎读者、也想保护自己的人。之所以把时间背景放在 2026 年 9 月，是因为这一年 AI 写作工具渗透到了几乎每个内容生产环节，标识与平台审核也从"可选项"变成了"默认期待"：早两年还能说"这事还早"，现在再不建立自己的流程，成本只会越来越高。
监管趋势概述
要建清单，先得知道"被要求做什么"。这里我只做客观共识层面的概括，不引用具体条款编号，也不给法律意见。监管的细节随时在变，但方向相对稳定，抓住方向比死记条款有用。我自己的方法是：每季度花半小时扫一遍监管部门和主流平台发布的公开口径，把变化记进笔记，而不是逐字研读法规。
AI 生成内容的标识要求
一个已经形成公开共识的趋势是：对 AI 生成合成内容做标识，正在从"行业倡议"变成"硬性要求"。以中国为例，相关办法的核心意思很朴素，如果内容是由 AI 生成或合成的，你既要做"显式标识"（让人一眼能看到的标注），也要做"隐式标识"（写进文件元数据、不可见但可被系统读取的标记）。这不是只针对新闻机构或内容平台，所有对外发布内容的主体，包括个人，都在语境之内。欧美那边虽然没有完全一样的强制口径，但平台侧（社交网络、视频站、代码托管）也普遍要求创作者对 AI 生成内容做标注，否则可能限流或下架。一个值得注意的共识是：标识义务通常落在"发布者"身上，而不是"生成工具"身上，也就是说，哪怕你用的是某个自动生成服务，最后在你博客上发出的那一刻，标不标的责任是你的。
我的理解是，监管真正在意的是"欺骗性"：当读者无法分辨内容是否由人创作、可能因此被误导时，风险最高。所以标识的本质不是羞辱 AI 辅助，而是消除"以假乱真"的欺骗。把这一点想通，后面的动作就顺了：你不是在被逼"认罪"，而是在主动消除误导。一个诚实的标识，反而是专业度的体现。我见过有人把标识藏到页面最底部、字号调到几乎看不见，这既违背了显式标识的初衷，也很容易被平台判定为"未按规定标识"：标识要让人真能看到，而不是走个过场。
平台责任的传导
另一个容易被忽略的点是：平台责任会传导到创作者身上。当内容平台被要求审核、标识、处置违规内容时，它们通常会把规则写进用户协议，再用算法和人工审核去执行。结果就是，哪怕法律没直接罚到你，平台的流量分配、内容下架、账号限流也能让你"被合规"。对个人博主来说，这其实有个好侧面：你只要按平台明确公布的规则走，基本就覆盖了大部分风险。比如很多平台要求 AI 生成内容打标、要求原创声明、禁止搬运，把这些做成清单项，反而省心。
这里有个边界要清醒：平台规则和法律要求是两层，平台可以比你该守的法律更严，也可以在某些灰色地带更宽，但它不能让你合法地去做法律禁止的事。所以清单里我区分"法律底线"和"平台规矩"两部分，前者是红线，后者是口碑线。举个例子，某平台可能要求所有 AI 图都加统一水印，这比法律要求的"显式标识"更具体，你照做只是多花一分钟，但能换来稳定的推荐；反过来，平台没禁止的你也不一定就能做，比如把别人的文章喂给模型改改写当作原创，平台可能不管，法律上的署名和改编权问题仍在。
著作权争议的公开共识
著作权这块的公开共识是：完全由 AI 自动生成、没有人类实质性创作投入的内容，在很多法域里难以获得著作权保护；而人类做了实质性编排、修改、选择的内容，保护边界更清晰。但这事远没定论，不同国家、不同判例差异很大，今天的说法明年可能就变。我的取舍很简单，把 AI 当协作者而不是作者，关键的表达、结构、判断由我自己做，这样无论法律怎么变，我对内容的主张都比较站得住。
还有个现实坑：如果你搬运了别人用 AI 生成、且对方也没获得保护的图或文，你同样拿不到保护，还可能踩到别人的署名利益。所以"来源清楚"比"是否 AI"更底层，先确认你能不能用，再谈怎么标。我给自己定了一条铁律：凡是不能直接确认来源和授权的内容，一律不用，宁可自己画一张丑图，也不冒这个险。丑图没人告你，偷图随时可能收到律师函。
发布者要做什么
共识层面清楚后，落到"我作为发布者到底要做什么"，其实可以收敛成三件事：显式标识、隐式元数据、留存记录。这三件分别对应"对人诚实""对机器可读""对自己可举证"。它们不是三选一，而是三件套，缺一个就有一道没覆盖。
显式标识：让读者看得见
显式标识是最基本的诚实，解决的是"读者知情权"。我的做法是分两档，按辅助程度决定标注强度：
- 轻度辅助（只润色、纠错、翻译、查拼写）：在文末统一加一句说明即可，不必每段都标，否则反而干扰阅读。读者在意的是"核心观点是不是你本人的"，润色不改变归属。
- 中度辅助（用 AI 起了大纲或部分段落，我大改）：在开头或小节处点明哪些部分由 AI 参与，避免读者误以为某段精妙表述全出自你手。
- 重度辅助（整篇初稿由 AI 生成、我再做修改）：在标题下方或开头明显位置标注"本文由 AI 辅助创作，经作者审校"，并且我建议把"我改了哪些、哪些结论已实测"也补一句，降低读者疑虑。
注意"经作者审校"这几个字不是免责金牌，而是事实陈述。我确实逐段读过、跑过代码、改过结论，才敢这么写。如果连审校都没做，那这句话就是假的，反而更危险，它把一次诚实的辅助变成了一次主动的误导。我见过有人把整篇 AI 文原样发出，只加一句"经作者审校"就当原创，这种做法既违背诚实，也最容易在读者指出错误时反噬信任。
隐式标识：让系统读得懂
显式给人是第一步，隐式给机器是第二步。很多发布系统、社交平台、搜索引擎现在会去读文件的元数据或页面里的结构化标记。常见可做的几件小事：
- 在生成的图片里保留生成工具的元数据（别一股脑用压缩工具抹掉），有些平台会据此识别 AI 图。
- 在网页里用合理的 alt 文本、页面描述说明内容性质，必要时给 AI 生成内容打上对应的机器可读标记。
- 音频视频若由 AI 合成音色，保留生成侧的水印信息，不要为"以假乱真"主动去除。
这部分我做得比较轻，因为个人站没有那么复杂的发布管线。但原则要守住：能留痕迹的地方别主动抹掉。一个常见误区是"既然要标显式，隐式就多余"：其实两者互补，显式给读者，隐式给平台算法，缺一个就有一道没覆盖。比如你显式标了"AI 辅助"，但导出的图片被图床转码抹掉了元数据，平台侧的水印识别就可能失效，极端情况下仍被当成"未标识 AI 内容"处置。所以图片上传前我都会先确认元数据还在。
留存记录：出事能举证
最容易被忽视的是"留存记录"。当你某天被质疑"这篇是不是 AI 写的、数据对不对、图有没有授权"，你能拿出的不是辩解，而是证据链：原始草稿、和模型的对话记录、代码跑通的截图、来源链接、图片授权凭证。我现在的习惯是每篇 AI 辅助的文章在草稿目录留一个 notes.md，简单记下"哪段是 AI 起的、我改了什么、关键事实来自哪、图是从哪来的"。不用精美，能回溯就行。
每篇留证这件事我做得很轻：一个函数把笔记按固定结构写进草稿目录，写完不用再想格式：
import json
from pathlib import Path
def write_notes(slug, ai_parts, rewritten, sources, images):
path = Path("drafts") / slug / "notes.md"
payload = {"ai_parts": ai_parts, "rewritten": rewritten,
"sources": sources, "images": images}
path.write_text(json.dumps(payload, ensure_ascii=False, indent=2), encoding="utf-8")
return path一份发布前自查清单
下面这份清单是我现在每篇必过的。它不是法律清单，是工程清单，目标是把"可能出事的点"在发布前拦下来。我把它做成了构建脚本的一部分，漏一项 CI 就不过。你也可以直接抄成 Markdown checklist 放在草稿模板里。
- 事实核查：文中涉及版本号、API 名、命令、结论，是否都亲自验证或来自可信来源？AI 最爱编细节，尤其是它训练截止之后的新版本。我的做法是对每个代码块都本地实跑，跑不通的不发。
- 来源标注：引用了别人的观点、数据、代码，是否给了链接或出处？没出处的事实尽量不写，或明确标为"据我所知""待核实"。
- 版权图片：配图是自己画的、买的授权、还是明确可商用的？用别人图前确认许可，别信"网上搜来的就能用"。CI 里我列了一份允许的来源白名单。
- AI 标识：按辅助程度，显式标识放对位置了吗？重度辅助有没有在开头说清楚？隐式标记有没有保留？
- 隐私信息：代码、截图、日志里有没有手滑带出 token、密钥、真实邮箱、客户名、内部路径？发布前用脚本扫一遍关键字。
- 观点归属：哪些是我的判断、哪些是引用、哪些是 AI 给的措辞但被我采纳？混在一起最容易翻车，读者分不清谁负责。
- 可复现性：代码块里的示例能跑通吗？依赖版本写清了吗？我坚持在本地把每个代码块复制出来跑一遍再发，哪怕多花十分钟。
- 更新计划：技术文会过时，有没有标注"写于 2026-09"、并打算后续更新的机制？我维护一篇《文章更新日志》。
- 授权链路：用到的库、字体、框架，许可证是否允许我的使用方式（尤其是商用或再分发）？个人博客若放广告，这点更要查。
- 截图合规：贴的截图里有没有别人头像、昵称、私密聊天？打码再发，这是基本礼貌也是风险隔离。
这份清单的精髓不在于"全做到完美"，而在于"每次都过一遍、心里有数"。有些项我确实做不到百分百，但知道自己在哪个位置，比假装万无一失强。清单是工具，不是枷锁。我甚至会故意在清单里留一两条"宽松项"，比如轻度润色不必逐段标，这样清单才用得长久，不会因为太苛刻而被我弃用。
边界讨论：哪些情况容易误判
写清单时最头疼的是"边界"。下面几个是我反复纠结、也给出自己取舍的真实场景，供你参考。
第一，翻译算不算 AI 生成？如果原文是你写的，用 AI 译成另一语言，我认为归属仍属于你，标"AI 辅助翻译"即可；但如果原文就是 AI 写的、你再译，那底层仍是 AI 生成，要按重度辅助标。判断标准是"创作源头是谁"，不是"最后一道工序是谁"。这条线画在"谁决定了内容的实质表达"，而不是"谁敲了最后那次回车"。
第二，AI 修图算不算 AI 生成内容？简单调色、裁切不算；但用生成式工具"无中生有"补了一块、或把草图扩成完整插画，那生成的部分要标。我的笨办法是：只要生成工具动了"不存在的像素"，就标。
第三，读图总结算不算？你把一张架构图丢给模型让它写说明，说明文字由 AI 产出，那段文字要按辅助标；图本身若是你画的，图不用标。分开看，别混。
第四，草稿里的对话记录要不要公开？不必，但你要自己留着。留存记录是给你自己举证用的，不是给读者看的，别把和模型的聊天记录也发出来，里面可能有你的提示词套路，没必要公开。
这些边界没有统一标准答案，我的原则是"往诚实一侧偏"：拿不准标不标时，标了最多显得啰嗦，不标则可能踩线。啰嗦的成本远低于翻车的成本。
个人博客的声明写法示例
声明不是越多越好，写得像法务免责书反而吓跑读者。我的偏好是短、真、具体。给几个我自己用过的模板，你可以按辅助程度挑。
轻度辅助的页脚声明：
本文由作者独立完成，仅使用 AI 进行文字润色与错别字检查，核心观点与技术结论均经作者本人验证。
中度辅助的开头声明：
说明：本文大纲与部分段落初稿由 AI 辅助生成，作者对其做了实质性改写与逐条审校，代码示例均已在本地实测。
重度辅助的开头声明：
声明：本文初稿由 AI 辅助生成，作者对其中的技术方案、代码示例与结论做了逐条审校与实测。内容仍可能有疏漏，欢迎在评论区指正，我会持续更新。
我特意避免写"本文不构成任何建议""作者不承担任何责任"这类套话，它们既不真诚，对真实风险也没什么用，读者读着也累。一个诚实的"欢迎指正、我会更新"，比十句免责都有公信力。另外提醒一点：声明要和实际辅助程度一致。我曾见过有人标"仅润色"，结果整篇都是 AI 起的，被眼尖读者抓包，信任一次性清零，标轻了比不标更糟，因为那是主动欺骗。
工具辅助：检测器不可靠，流程比工具重要
市面上有一堆"AI 检测""合规检测"工具，我的态度很明确：可以当参考，不能当依据。原因有几点，每点都是踩过坑后的结论。
第一，检测器的准确率远没有宣传的那么高。对改写过的文本、非英语文本、技术术语密集的文本，误判极多。我拿自己纯手写的技术文去测，好几款都标成"疑似 AI"；反过来，把 AI 生成的文精修一遍，又有工具判成"人类写"。这类工具在分布外的文本上基本失灵，而技术博客恰恰是最"分布外"的一类，满篇术语和代码，最容易被误伤。
第二，把判断权交给一个黑盒工具，本身就是风险转移。它说"安全"不代表真安全，它说"像 AI"也不代表你违规，很多平台对"像 AI"但已标注的内容是放行的。你若迷信检测分数，要么过度标注扰民，要么漏标真风险。检测的"概率"不是法律的"事实"，别把两者画等号。
第三，合规的核心是"你做了什么"，不是"工具说你合规"。流程性的硬检查（有没有密钥、有没有漏标、图来源在不在白名单）才有确定性价值；模糊的"AI 概率"反而干扰判断。所以我把工具定位成"流程里的提醒"，而不是"闸门"。一个检测工具说"这段文字 80% 像 AI"，我不会因为这个数就改标识，而是回头想"我到底辅助到什么程度"，这个判断只能由人来做。
import re
import sys
# 一个极简的发布前自查脚本：只做确定性的硬检查
# 它不判断"是否像 AI 写的"，只检查可能泄密和漏标的硬伤
# 把它接进博客构建（如 CI / 本地 pre-commit）即可，漏一项就拦截发布
SECRET_PATTERNS = [
r"sk-[A-Za-z0-9]{20,}", # 常见 API key 前缀
r"AKIA[0-9A-Z]{16}", # AWS access key
r"ghp_[A-Za-z0-9]{30,}", # GitHub personal token
r"-----BEGIN PRIVATE KEY-----", # 私钥块
r"aws_secret_access_key", # 明文字段
]
AI_DECLARATION = "声明" # 重度辅助文章应含此字样，按需改
ALLOWED_IMG_HOSTS = ("img.tiana.dev", "cdn.tiana.dev") # 图床白名单
def scan(path: str) -> list[str]:
problems: list[str] = []
text = open(path, encoding="utf-8").read()
for pat in SECRET_PATTERNS:
if re.search(pat, text):
problems.append(f"疑似密钥/私钥泄露，匹配正则: {pat}")
# 仅当文件名标记 heavy 时才要求声明，避免误伤轻度辅助文
if "heavy" in path and AI_DECLARATION not in text:
problems.append("重度辅助文章缺少显式声明")
# 检查外链图片是否来自白名单图床，避免误用无授权图
for m in re.finditer(r"!\[[^\]]*\]\((https?://[^)]+)\)", text):
url = m.group(1)
if not any(h in url for h in ALLOWED_IMG_HOSTS):
problems.append(f"图片来源不在白名单: {url}")
return problems
if __name__ == "__main__":
# 用法：python check.py draft_heavy.md draft_light.md
failed = False
for p in sys.argv[1:]:
found = scan(p)
if found:
failed = True
print(f"[FAIL] {p}")
for f in found:
print(f" - {f}")
if failed:
sys.exit(1)
print("[OK] 未检出硬性风险")这个脚本跑起来很快，我把它接在博客的构建步骤里，凡是 CI 通不过就不发布。它只管"确定的错"，把"模糊的判"留给我自己，因为模糊的判本就该是人做的。顺带说一句，脚本里的白名单图床和正则要随你的实际环境更新，别照搬我的域名，否则它只会一直报"图片不在白名单"。
我踩过的坑：三个真实教训
光讲原则有点空，说三个我自己或我朋友身上真发生过的坑，比任何清单都记得住。
第一个坑是"过度信任模型的版本记忆"。有篇讲 FastAPI 依赖注入的文章，我让 AI 起了初稿，它信誓旦旦写了一串 Depends 的新用法，我图省事没实跑就发了。结果那是训练数据里某个提案版的写法，正式版根本没这参数，评论区立刻有人贴出报错。教训写进了清单第一条：凡是带版本号和技术细节，必须本地实跑，模型的话只能当线索不能当事实。从那以后，我博客 CI 里多了一步"代码块抽取并执行"，跑不通直接卡发布。
第二个坑是"图床转码抹掉元数据"。我有一张 AI 生成的架构图，显式标了"AI 辅助生成"，但传到某个图床后被转成了 webp，生成工具的元数据丢了。后来某平台抓取时识别不出隐式标识，提示我"疑似未标识 AI 图"。显式标识还在，所以没真被罚，但吓我一跳。教训是：图片上传前先确认元数据保留，重要图我直接用自托管图床，不经过会转码的服务。
第三个坑是"把授权当默认"。早期我习惯性从某个图库搜"免费"图直接用，直到朋友提醒我那图库的"免费"仅限非商用，而我博客挂了广告算商用。赶紧下架换自绘。教训固化成清单里的"授权链路"项，并把图床白名单和许可能力绑定，不在白名单的来源，CI 直接拦。这三个坑代价都不大，但每一个都让我把某条清单从"知道"变成"真在乎"。
把合规变成写作流程的一部分
最后也是最重要的一点：别把合规当成发布前临时抱佛脚的"检查单"，而要变成写作流程里的一个自然环节，像保存文件一样无感。
我是这么落地的。我的博客是 Markdown 写作、CI 构建发布，所以我把几件事嵌进了流程：每次新建草稿，模板里就带好"声明占位"和"来源/记录"区块，逼自己一开始就想清楚辅助程度；构建脚本里挂上面的硬检查；发布后自动在文末打上"写于 2026-09"的时间戳，并登记到一篇《文章更新日志》里，方便日后回头修；图片一律先过"来源白名单"再进图床，从源头杜绝版权图风险；每季度花半小时复盘一次监管与平台口径变化，更新我的清单和脚本。
这样做一年后，我最大的体会是：合规不是负担，反而让我写得更踏实。因为流程在替我记得"哪段该标、哪段该查"，我不用每次都从零焦虑。读者也反馈说，看到明确的标识反而更信任内容，他们关心的从来不是"你用没用 AI"，而是"你老不老实、靠不靠谱"。有个读者甚至说，正因为我在每篇重度辅助文下都留了"欢迎指正"，他更愿意来挑错，社区质量反而高了。
回到开头那个感受：AI 是隐形合著者。把它请到台前、说清楚、留好记录，不是示弱，是一个成熟作者的基本修养。这篇清单你可以直接抄去改成自己的版本，但别抄完就忘，真正的合规，发生在你每次按下"发布"之前的那个动作里，而不是某份放在收藏夹吃灰的文档中。把流程做对，合规自然就发生了；把流程做对，你也能把精力从"怕出事"里解放出来，回到写作本身这件更值得的事上。
如果你今天只做一件事，我的建议是：先给下一篇草稿加一个 notes.md，写下"哪段是 AI 起的、我改了什么、关键事实来自哪"。这一步最小、最便宜，却是最能让你建立证据链习惯的动作。等这个习惯稳了，再把硬检查脚本接进构建，最后才去琢磨隐式标识和平台口径。合规是渐进的，不必一夜到位，但要从这一次、这一篇开始。我写这篇文章时，它自己也是重度辅助生成、经我逐段审校实测的，按我上面说的，这篇开头本该有声明，但作为站内说明，我在文末补上这一句：本文由 AI 辅助起草，作者逐条核实并补写了全部案例与代码。这，就是清单活用的样子。