审计日志是您组织内变更的完整历史记录。每一项重要操作（创建、修改、删除、移动、设置更改、计费操作、权限更改）都会作为一条单独的条目被记录，附带操作者、时间和上下文。
您为何需要它：
- 调查 — “谁删除了这篇文章？”、“谁上周更改了某人的角色？”
- 合规 — SOC 2、ISO 27001、GDPR 要求为数据和同意的变更提供审计轨迹
- 回滚变更 — 了解某次更改之前的状态并做出决定
- 团队活动监控 — 谁在做什么，尤其是在团队规模庞大的 Enterprise 组织中
#在哪里打开
左侧菜单 → 审计日志。
对组织的 Owner 和 Admin 角色开放，且在 Team、Pro、Business 和 Enterprise 套餐上可用（套餐标志 allows_audit_logs）。在 Free 和 Starter 上，Owner 和 Admin 会看到带锁并标注“需要 … 套餐”的菜单项（Owner 点击会进入“套餐与限额”），其他人看不到。
Editor 和 User 默认看不到日志：可以在 设置 → 权限管理 中授予他们“审计日志”权限，之后他们也会看到该菜单项。Guest 始终看不到日志。
与资金和套餐相关的记录（资源类型 billing）仅 Owner 可见：Admin 角色没有支付权限，日志不应成为绕过该限制的途径。
#条目的样子
每一条日志行都是一张卡片，包含操作者、操作、资源、时间和简短说明：
条目字段：
| 字段 | 说明 |
|---|---|
| 操作者 | 执行该操作的用户的姓名 + email |
操作（action） |
发生了什么：created、updated、deleted、restored、moved、published 等 |
资源类型（resource_type） |
操作所针对的对象：article、collection、user、consent、billing、tenant |
| 资源标题 | 文章名称、集合名称、用户名 — 即您在常规 UI 中看到的内容 |
摘要（summary） |
对该操作的人类可读解释 |
详情（details） |
带有附加数据的 JSON：具体更改了什么、旧/新值、IP 地址、幂等键 — 点击“详情”时展开 |
| 时间 | 精确到秒的时间戳 |
#什么会进入日志
日志记录对内容、成员、同意和计费的关键操作。以下是实际的资源类型和操作。
#文章（resource_type=article）
| 操作 | 何时触发 |
|---|---|
created |
创建新文章 |
updated |
保存更改（包括可见性更改 — details 显示哪些字段发生了变化） |
trashed |
将文章移入回收站 |
restored |
从回收站恢复 |
article_moved |
移动文章 |
article_copied |
复制文章 |
permanently_deleted |
从回收站永久删除或保留期到期后删除 |
#集合和空间（resource_type=collection）
空间以顶层集合的形式存储，因此它们在同一资源类型下记录。
| 操作 | 何时 |
|---|---|
created |
创建集合或空间 |
collection_moved |
移动集合（更改其父级） |
collection_copied_recursive |
连同内容复制集合 |
collection_bulk_move_articles |
在集合之间批量移动文章 |
trashed |
移入回收站 |
restored |
从回收站恢复 |
permanently_deleted |
永久删除 |
#团队（resource_type=user）
| 操作 | 何时 |
|---|---|
invited |
邀请加入组织 |
role_changed |
更改成员在组织中的角色 |
deleted |
从组织中移除成员 |
#GDPR 同意（resource_type=consent）
| 操作 | 何时 |
|---|---|
updated |
用户更改了其 cookie 同意（scope: all / essential） |
当 cookie 横幅被更改时，这些条目会自动出现。有关 GDPR 同意的上下文，参见关于注册与入职的文章。
#计费与组织
| 操作 | 资源 | 何时 |
|---|---|---|
subscription_paid |
billing |
支付订阅（首次和续订） |
plan_upgraded |
billing |
升级套餐 |
plan_downgrade_scheduled |
billing |
已计划降级或取消订阅 |
plan_changed_by_provider |
billing |
因支付服务商事件而更改套餐 |
scheduled_change_cancelled |
billing |
取消已计划的变更 |
subscription_cancelled / subscription_cancel_failed |
billing |
取消订阅 / 取消尝试失败 |
reactivated |
billing |
订阅已恢复 |
seats_changed |
billing |
更改席位数量 |
refund_issued |
billing |
退款 |
topup_checkout_started / topup_granted |
billing |
开始购买增值包 / 增值包已发放 |
billing_address_updated |
billing |
账单地址已更改 |
plan_granted / plan_grant_revoked, limit_override_granted / limit_override_revoked, addon_granted_by_operator |
billing |
由 Lynkora 员工进行的更改 |
trash_emptied |
tenant |
完全清空组织的回收站 |
#筛选器
页面顶部有一个筛选面板，用于快速找到您需要的事件：
- 搜索 — 按
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）— 会被过滤掉