日报这件事，表面上很简单，但真正实践起来，问题往往集中在两个关键环节上。
一方面，容易遗漏细节。一天下来，你可能开了好几个 Codex 会话：上午排查 bug，下午调整需求，中间穿插环境验证、版本发布、文档补全。等晚上回忆时，脑海中通常只记得最大的一两项任务，那些零碎的收尾工作全被大脑过滤掉了。另一方面，AI 直接生成的日报往往不够可靠。如果你只是告诉它“我今天完成了某某需求”，它能给你写出一篇漂亮的文章，但内容全是空话。比如“持续优化用户体验”“推进了相关工作”，听起来像那么回事，实际上没有任何实质性证据。
我真正想要的，是让 AI 根据你实际的工作记录来生成日报。所以核心在于先把数据源和规则梳理清楚，让 AI 有据可查、有边界可守。
为什么要做这个
核心原因有两个。第一，手写容易遗漏。一天内你可能启动了多个 Codex 会话：上午排查 bug，下午改需求，中间还穿插测试环境验证、发版、补文档。晚上手写时，大脑往往只记得最重的一两件事，很多收尾动作就被忽略了。第二，AI 直接“编一篇日报”也不靠谱。如果你只告诉 AI “我今天做了某某需求，帮我写日报”，它当然能写得很漂亮，但这类内容很容易变成空洞的套话。比如“推进了相关工作”“完成了问题处理”“持续优化用户体验”，读起来像日报，实际上既没有证据，也没有业务成果。我追求的是：让 AI 基于真实工作记录生成日报。所以这套 skills 的核心思路，就是先把数据源和规则整理好，让 AI 有据可查、有边界可循。
数据来源
Codex 对话信息
平时主要用 Codex 开发，每次会话本身就是一份工作记录。它会保存在本地数据库和 jsonl 文件中，包括线程标题、工作区路径、对话内容、工具执行记录等。我们必须先从这些地方把当天的相关会话抽取出来。
这里有一个关键点：不能只看今天新创建的会话。实际工作中，昨天开了一个会话排查问题，今天继续改代码、继续验证，这是常有的事。如果只按“创建日期”筛选，就会漏掉这些跨天的工作。所以规则应该是根据消息时间判断，只要今天在这个会话里有真实操作发生，就应该纳入统计。
当然，像临时闲聊、个人问题、测试 AI 功能、甚至“帮我生成日报”这类会话，都需要过滤掉。否则日报就会变成“我今天让 AI 帮我写日报”，这完全没有意义。
git 代码记录
另一个可靠的数据源是实际的代码变动。查看当天有哪些提交、哪些未提交的改动、哪些文件被新增或修改，再与 Codex 对话内容互相验证，就能更准确地判断今天到底推动了哪些事情。
我所有工作相关的 git 项目都放在同一个大目录下，这一点非常重要。建议你也这么做：工作仓库放在一个文件夹，个人折腾放在另一个。这样 AI 在抓取数据时，边界清晰，不会把生活和工作混在一起。
Git 是非常好的校准工具。比如会话里说“已经修完并验证”，但 git 里没有任何对应改动，那就要小心了。反过来，如果 git 里有当天的提交，但会话中没有明确记录，也可以反查这次提交到底服务于哪个需求，避免漏项。
需求和 bug 系统
如果公司有需求系统、bug 系统、工单系统，最好也接进去。因为日报中最容易出错的就是类型和进度。一个问题到底是“需求”还是“bug”，不能单看标题猜测；进度到底是 80% 还是 100%，也不能只靠 AI 感觉。最好让 AI 能查到该编号在系统中的真实类型、当前状态、相关评论和上线记录，再决定如何撰写。
私有版本里会按公司内部系统来校正这些信息。公开版做了脱敏处理，只保留了通用规则，需要你自己把这部分换成实际查询方式。
已有日报和周报
如果是生成周报，不建议让 AI 从一整周所有的原始会话重新扫描一遍。更稳定的做法是：每天先生成日报，周报再基于这些已经落盘的日报做归并。这样周报不会机械地拼接每天的内容，也不会因为上下文太多而把重点写乱。周报只需要回答一个问题：这一周哪些需求和 bug 有推进，现在结果是什么。
AI 协作量
我自己还加入了 token 统计，用来粗略表示当天的 AI 协作量。这是一个可选参数，你可以不加。但如果公司正在推动 AI 提效，或者你想量化自己的 AI 参与度，这个数据还是有一定参考价值的。不过要注意，token 不能直接等价于工作量。正确的做法是结合当天的实际动作，比如调研排查、方案文档、代码实现、测试回归、发布协作，再进行相对合理的拆分。否则很容易变成“今天烧了很多 token，所以我很辛苦”，这样的说服力不足。
核心流程
这套 skills 的大致流程如下：
- 确定日期、工作区、总工时和输出位置。用户不说日期则默认今天，不需要每次都追问。
- 筛选会话。从 Codex 本地数据库和 jsonl 文件中找出当天相关的会话。要覆盖跨天会话，同时过滤掉系统提示、环境上下文、重复消息以及生成日报本身的会话。
- 读取关键内容。查看会话内容，判断当天到底做了什么。不能只提取关键词，因为很多结论隐藏在助手回复、工具执行结果和最后总结中。
- 扫描 git 仓库。查看当天的提交、未提交改动和新增文件，用于校正主线、发现漏项。
- 回查系统编号。如果当天工作涉及需求或 bug 编号，就按编号回查真实类型、状态和进度。没有证据支撑的 100%，不能写。
- 合并工作项。将同一个需求下的排查、修复、测试、发布、文档沉淀合并成一条。不能按开了几个会话就写几条。
- 翻译成业务语言。写成非技术同事也能看懂的中文日报。少写接口名、日志名、分支名和命令，重点写业务目标、当天动作和当前结果。
- 自检。最后做一次检查：有没有漏编号、有没有把支撑动作写成主线、工时加起来对不对、进度有没有证据、周报是否与日报口径一致。
真正让这套 rules 好用的原因，就是所有规则叠加之后，AI 不太容易跑偏。
其他规范
需求、bug 命名统一
Codex 会话标题最好都带上需求或 bug 编号。这样无论是人还是 AI，都能快速知道这条会话服务于哪个业务目标。不要把会话名称都写成“优化页面”“修复问题”“继续处理”，短期看没什么，长期会非常混乱。AI 扫描一堆会话时，很难判断它们是否属于同一个需求。比如我们这边经常用 5 位数字 ID 去查询具体内容，那么对话标题、分支名、文档、测试记录也都尽量带上这个 ID。
不要按会话数量写日报
这个点特别重要。AI 很容易犯的错误是：看到今天有 10 个会话，就写 10 条工作项。这样日报会变成流水账，看起来很忙，实际很散乱。正确做法是按真实业务主线归并。同一个 bug 可能开了排查会话、修复会话、测试会话、上线会话，但日报里应该是一条：这个 bug 今天完成了哪些动作，现在结果如何。反过来，如果今天确实处理了 5 个不同需求，那就该拆成 5 条，不要为了显得简洁，把几个不同编号合成“集中处理若干问题”。领导和团队看日报时，关心的是具体哪件事到了什么状态。
技术细节要翻译成业务语言
日报是工作进展说明。如果你把 SQL、接口名、日志系统、构建命令、错误码全写进去，技术同事可能看得懂，但老板和业务同事大概率不关心。这套 skills 里会强制要求 AI 把技术过程翻译成业务语言。比如“HTTP 401”写成“服务配置问题”，“接口复测”写成“测试环境验证”，“调整前端构建命令”写成“补齐多端验证环境”。技术细节在日报里只应该服务于主线。一条好的日报，最好让非技术同事也能看懂三件事：这是什么问题？今天做了什么？现在结果怎么样？
进度不能靠感觉
很多 AI 写日报时，会默认把“修完了”写成 100%，这很危险。规则里会区分几个状态：只是完成调研和方案，进度就不能写太高；已经提交修复但没有完整回归，就不要写 100%；已经测试环境验证但还没上线，也不要直接写 100%；有上线记录、关闭记录、明确收口证据，才适合写 100%。不同公司进度口径不一样，你可以自己调整，但一定要有规则，不能让 AI 凭语气判断。
工时要守恒
如果公司日报需要写工时，就要让 AI 做总工时守恒。比如默认一天 8 小时，那所有条目的工时加起来必须等于 8 小时。删除一条支撑项后，它的时间也要合理分配回真实服务的需求里，不能凭空消失。工时也不能平均分。一个大需求反复排查、改代码、测试验证，肯定比一个已上线的小收尾更重。可以结合会话跨度、消息密度、git 产出、测试和发布证据综合判断。
怎么迁移到你自己的公司
如果你想把这套方法搬到自己公司，建议按以下顺序进行：
第一步，先统一工作目录。把工作相关仓库放在一个稳定目录下，个人项目和生活内容尽量不要混在一起。这样 AI 筛选工作区时会简单很多。
第二步，统一命名习惯。Codex 会话标题、分支名、文档名、测试记录最好都带有同一个需求或 bug 编号。不一定要完全照搬规则，但一定要有一个稳定标识。
第三步，定义你们公司的日报格式。比如标题怎么写，需不需要工时，需不需要进度，需求和 bug 是否分开，周报是按人写还是按项目写。这些都要写进 skills，不要每次靠临场提示词。
第四步，把需求系统接进去。哪怕一开始只是让 AI 根据编号打开网页查一下，也比完全靠会话猜测要靠谱。更进一步，可以做 CLI 或 MCP，让 AI 能直接查询编号、状态、评论和上线记录。
第五步，先人工校对几天。不要一上来就完全信任。先让 AI 生成，再人工修改几版，把“漏了什么”“写太细了什么”“进度写高了什么”这些反馈继续补充到 skills。迭代几次以后，它会越来越贴近你们公司的真实口径。
怎么安装
安装好之后，在 Codex 里可以直接这样说：
使用 $codex-daily-report 生成今天的日报
也可以指定日期、工作区和工时：
使用 $codex-daily-report 生成 2026-06-18 的日报，工作区是 /path/to/workspace，总工时 8h
这个仓库里只有 skill 本体、参考命令和脱敏示例，不需要构建，也不需要额外安装 Python 包。你真正要修改的，主要是 SKILL.md 里的公司规则。
总结
这套生成日报的方案，本质上是把日常工作的证据链整理出来：Codex 对话负责还原上下文，git 负责校正真实产出，需求和 bug 系统负责校正类型和进度，skills 负责把这些规则固定下来。只要数据源和规则稳定，日报就可以从“每天晚上靠记忆补作业”，变成“让 AI 根据真实工作记录自动归纳”。这才是 skills 真正有价值的地方：把那些重复做、容易漏、容易乱的工作流程，沉淀成可复用的自动化规则。