审计日志

审计日志是您组织内变更的完整历史记录。每一项重要操作（创建、修改、删除、移动、设置更改、计费操作、权限更改）都会作为一条单独的条目被记录，附带操作者、时间和上下文。

您为何需要它：

• 调查 — “谁删除了这篇文章？”、“谁上周更改了某人的角色？”
• 合规 — SOC 2、ISO 27001、GDPR 要求为数据和同意的变更提供审计轨迹
• 回滚变更 — 了解某次更改之前的状态并做出决定
• 团队活动监控 — 谁在做什么，尤其是在团队规模庞大的 Enterprise 组织中

#在哪里打开

左侧菜单 → 审计日志。

对组织的 Owner 和 Admin 角色开放，且仅在 Business 和 Enterprise 套餐上可用（套餐标志 allows_audit_logs）。在 Free、Starter 和 Pro 上，该部分被隐藏。

Editor、User 和 Guest 看不到日志。

#条目的样子

每一条日志行都是一张卡片，包含操作者、操作、资源、时间和简短说明：

条目字段：

#什么会进入日志

日志记录对内容、成员、同意和计费的关键操作。以下是实际的资源类型和操作。

#文章（resource_type=article）

#集合和空间（resource_type=collection）

空间以顶层集合的形式存储，因此它们在同一资源类型下记录。

#团队（resource_type=user）

#GDPR 同意（resource_type=consent）

当 cookie 横幅被更改时，这些条目会自动出现。有关 GDPR 同意的上下文，参见关于注册与入职的文章。

#计费与组织

#筛选器

页面顶部有一个筛选面板，用于快速找到您需要的事件：

• 搜索 — 按 summary 或 resource_title 中的文本（不区分大小写）
• 操作 — 下拉菜单，列出组织日志中出现的所有操作类型
• 资源 — 下拉菜单，列出实际出现在日志中的类型（article / collection / user / consent / billing / tenant）
• 用户 — 按操作的操作者筛选
• 时段 — 一个“从”和“到”的日期范围
• 分页 — 每页最多 200 条

筛选器可以组合：例如，“用户 Anna 在过去一周内的所有 deleted 操作”。

#条目详情

点击一张卡片会在 **“详情”**字段中打开展开的 JSON — 这是数据库中 details 列的内容。您通常能在那里看到：

• 对于 updated — 已更改字段的列表（fields）
• 对于 role_changed — 旧角色和新角色
• 对于 consent updated — 范围（all / essential）
• 对于计费操作 — 对所发生事情的简短 summary

提示。 如果您需要了解一篇文章中究竟更改了什么，请查看 details 中的 fields_changed 字段。文章的完整内容不存储在日志中（那样会占用大量空间）— 有关版本控制，请使用编辑器中文章的版本历史。

#保留与合规

• 日志条目无法通过 UI 删除 — 这是一项刻意的限制（否则审计轨迹会失去意义）
• 非常陈旧的条目会由自动任务在审计保留策略下定期删除 — 日志不会永久保存
• 当组织本身被删除时，日志会随之一起删除（通过 ON DELETE CASCADE）

#什么不会进入日志

为了避免日志臃肿并使日志变成噪音，以下内容不会被记录：

• 用户的搜索查询 — 用于分析请使用分析部分
• 文章浏览 — 同样在分析中
• 编辑器内的 AI 操作（AI Improve、AI Rewrite）— 这是作者的工作流，不是可审计的变更
• 技术事件（后台作业、同步运行）— 它们在后端系统日志中，供平台管理员查看
• 系统用户的操作（例如，在为文档做初始化填充时的 platform-help-system）— 会被过滤掉

#相关部分

• 回收站 — 文章、集合和空间的 trashed / restored / permanently_deleted 事件恰好记录在这里
• 团队管理 — 角色更改和成员移除会以 resource_type=user 记录在日志中
• 分析 — 用于使用指标（查询、浏览）— 这是一个独立的工具，不是日志