AI 日报先做什么：一份输入边界与验证笔记

这是 AI 日报功能的设计笔记与独立示例，不是已经完成的接口调用实践。未提供真实请求、密钥或生产运行结果。

不让模型替记录补事实

日报最重要的不是语气流畅，而是没有编出工作成果。任务标题描述意图，完成状态描述当前状态，更新时间可能只是改了一个字。它们不能自动推导出“今天完成了某项目的全部开发”。

更稳妥的输入是用户明确选择的记录与可验证事件。无法确认日期归属、完成时间或项目关系的数据，应保留其不确定性，而不是通过关键词强行归类。

先做可检查的输入包

下面的数据完全是演示内容。它只展示如何限定输入范围，不连接任何模型服务：

import json

payload = {
    "period": "示例日期",
    "records": [{"id": "demo-1", "text": "整理了方案，仍有两个问题待确认"}],
    "rules": [
        "仅依据 records 整理草稿，不添加完成情况或耗时",
        "区分进展与待确认问题",
        "每条总结保留对应记录 ID",
    ],
}
print(json.dumps(payload, ensure_ascii=False, indent=2))

在真正发送前，需要让用户看到具体内容和目标服务。即使是个人工具，也不应默认把整库、历史日志或与本次总结无关的信息发出去。真实密钥应该由运行环境安全提供，不能写进文章、浏览器脚本或代码仓库。

输出是草稿，不是数据库事实

可以要求输出分为“今日进展”“待确认事项”“下一步”，并为每一条附带来源 ID。但结构正确不等于内容正确，仍需要逐条比对原始记录。

例如原文是“整理了方案，仍有两个问题待确认”，合适的总结应保留未完成部分。“完成方案并解决全部问题”则与原文相矛盾。即使模型把这句话放进合法 JSON，仍然应该拒绝采用。

失败时留下可用的退路

接口超时、额度不足或返回内容无法解析时，本地原始记录应保持不变。生成按钮可以报告失败，并允许用户直接复制已选记录；不要把等待生成变成保存记录的前置条件。

同样，不应在失败后无提示地切换到其他供应商。不同服务意味着不同的数据流向，需要单独说明和选择。

规划到验收之间还差什么

后续需要验证输入选择、脱敏、用户确认、超时与取消、结果校验，以及采用草稿后的撤回方式。本文不宣称这些环节已经实现。

牛马日记的现状和规划边界见项目档案；任务与记录的区别见为什么做效率工具。