审计日志字段怎么设计
审计日志要能回答四个问题：谁、在什么时候、对哪个对象做了什么、结果如何。字段包括操作者、动作、对象与其版本、变更前后摘要、结果、来源地址与请求标识。它和调试日志的差别在于关注点不同：调试日志关心过程，审计日志关心可追责与可复现。
基本信息
| 必填字段 | 时间、操作者、动作、对象及版本、结果 |
|---|---|
| 变更留痕 | 前后哈希或摘要，用于判断改了什么 |
| 原则 | 可复现操作，但不记录敏感正文 |
| 存储 | 独立索引、只追加、保留期明确 |
| 告警 | 高风险动作实时通知责任人 |
典型使用场景
- 提示发布：记录谁在何时把哪个版本推上生产，出问题可回退到具体版本
- 权限与白名单调整：高风险动作留痕并触发通知
- 知识库导入：批量覆盖类操作要能追到操作者与批次
- 合规审计：向审计方提供可读的操作时间线，而不是散落的调试日志
- 离职与转岗：核对一段时间内的敏感操作，确认权限使用情况
审计事件示例
审计事件示例
ts: 2026-10-12T10:30:00+08:00
action: prompt.publish
actor: ops-user-12
target: summarize@1.4.0
before_hash: 5a2c... after_hash: 9f81...
result: ok
source_ip: 10.0.3.18 request_id: 7f3a91c2
# 正文不入库: 只存哈希与摘要，避免把敏感内容复制进日志系统字段与用途
| 字段 | 用途 | 缺失后果 |
|---|---|---|
| 时间 | 还原事件顺序 | 无法构建时间线 |
| 操作者 | 追责与复盘 | 不知道是谁改的 |
| 对象与版本 | 定位受影响范围 | 知道谁改了但不知道改了什么 |
| 前后摘要 | 判断变更内容与回滚目标 | 回滚时找不到旧版本 |
| 结果 | 区分成功与失败尝试 | 无法判断操作是否生效 |
审计库若与业务库同权限同实例，操作者可以顺手改掉记录。独立存储与只读访问是审计日志成立的前提。
审计日志要能按对象反查历史：给对象版本建立索引后，“这个提示半年内被谁改过几次”才是一个能直接回答的问题。