如何建立可审计的 AI 运行日志：从每日记录到周报

很多自动化项目都会记录“今天成功了多少、失败了多少”，但这还不是一份可审计的日志。真正有用的记录，必须让读者回答四个问题：系统原本准备做什么、实际执行了什么、哪里没有按计划发生、下一轮准备验证什么。

本文总结一套适用于 AI Agent、数据管道和自动化研究项目的日志方法。示例只使用抽象字段，不包含账户、密钥、价格或个人数据。

1. 先把“计划”和“结果”分开

最常见的审计错误，是把提交过的动作直接当成已经完成的结果。一个事件至少要经过以下状态：

这套拆分不只适用于交易。爬虫任务可以把“准备抓取”与“页面确实抓到”分开；RAG 评测可以把“开始评测”与“报告成功写出”分开；部署流水线也应该区分“提交发布”和“生产确认”。

2. 每条日志保留最小可复核字段

日志不需要把所有内部细节都公开，但必须保留足够的上下文。一个脱敏后的事件可以长这样：

{
  "trade_date": "YYYY-MM-DD",
  "timezone": "Asia/Shanghai",
  "snapshot_at": "HH:MM",
  "event": "intent | submitted | applied | guard | review",
  "intent_id": "stable-event-id",
  "result_pct": 0.00,
  "attribution": "rule | execution | observability | opportunity | cost",
  "failure_condition": "what would invalidate the next step"
}

其中最重要的不是字段数量，而是时间口径和状态口径。所有日期要明确使用哪个时区；“空仓”“没有动作”也要被记录为一个有原因的状态，而不是留白。

3. 从每日记录合并成周报

每日页适合保存原始事实，周报才适合解释事实。一个有用的周报可以按下面的顺序组织：

1. 范围：明确覆盖哪些日期、数据是否完整、是否存在延迟或缺失。
2. 结果：只展示必要的汇总指标，例如复合收益、最大回撤、暴露比例和事件数量。
3. 因果链：挑出一到三个关键事件，说明计划、执行、确认和保护状态之间发生了什么。
4. 归因：把偏差分为规则缺陷、执行缺陷、观测缺陷、机会遗漏、成本或仓位问题。
5. 下一假设：写出下一周要验证的单一变化，以及什么结果会证明它无效。

这样做的价值在于，读者看到的不再只是“今天涨了还是跌了”，而是一条可以复查、质疑和改进的决策链。

4. 结果解释要克制

• 一个盈利日只能说明当日结果，不能证明规则长期有效。
• 一个没有动作的日子，可能代表规则拒绝了不满足条件的机会；不要把它自动记成“没有信息”。
• 提交成功不等于执行成功；执行成功也不等于风险保护已经生效。
• 任何收益或回撤结论都要说明样本范围、费用口径、数据新鲜度和未解决的执行问题。

如果日志面向公众，展示百分比和状态通常比展示账户金额、精确价格或可复制的操作指令更安全。日志的目标是解释系统如何被验证，而不是给读者提供交易信号。

5. 发布前的质量检查

每次发布前，可以用这张清单做一次人工复核：

• 日期、时区和数据范围是否清楚？
• 计划、提交、确认和保护状态是否被混为一谈？
• 失败是否有具体归因，而不是只写“系统问题”？
• 是否披露了样本量、延迟、缺失数据和未验证假设？
• 是否删除了密钥、账户标识、个人路径、金额和不必要的精确交易信息？
• 读者能否看懂这篇内容的用途、局限和下一步，而不需要猜测背景？

结语：日志是验证系统，不是装饰结果

高质量运行日志的核心不是每天写得更多，而是让每个结论都能回到一条明确的证据链。把原始日记保留为内部审计材料，把公开内容整理成有范围、有归因、有局限和有下一假设的周报，读者才有机会真正理解系统，也更容易发现规则与执行之间的差距。

本文讨论的是日志与自动化验证方法，不构成投资建议，也不提供任何交易信号。对金融项目而言，任何真实资金用途都必须独立验证数据、费用、滑点、权限和风险控制。