Skills 分享：生成日报
日报这事儿，看着简单，真上手了，麻烦其实藏在两个地方。
一是容易漏。一天下来开了好几个Codex会话，上午排查bug，下午改需求，中间插空验证个环境、发个版、补个文档。等晚上回想，脑袋里基本只剩最大的一件事，那些零碎的收尾动作全被过滤掉了。二是AI直接编的日报不太靠谱。你告诉它“我今天做了某某需求”，它能给你写出一篇漂亮的文章，但全是空话。什么“持续优化用户体验”、“推进了相关工作”，听起来像回事，实际上没有半点证据。
我想要的，是让AI根据你真正的工作记录来生成。所以核心就是把数据源和规则先理顺，让AI有证据可查，有边界可守。
为什么要做这个
要点有两个。第一，手写很容易漏。一天里面可能开了好几个 Codex 会话，上午排查 bug，下午改需求，中间还穿插测试环境验证、发版、补文档。晚上手写的时候，人脑很容易只记得最重的一两件事，很多收尾动作就被漏掉了。第二，AI 直接帮你“编一篇日报”也不靠谱。如果你只告诉 AI “我今天做了某某需求，帮我写日报”，它当然能写得很漂亮，但这类内容很容易变成空话。比如“推进了相关工作”“完成了问题处理”“持续优化用户体验”，读起来像日报，实际上没有证据，也没有业务结果。我想要的是：
让 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 产出、测试和发布证据综合判断。
怎么迁移到你自己的公司
如果你想把这套东西搬到自己公司，建议按这个顺序来：
第一步，先统一工作目录。
第二步，统一命名习惯。
第三步，定义你们公司的日报格式。
第四步，把需求系统接进去。
第五步，先人工校对几天。
怎么安装
装好之后，在 Codex 里可以直接这样说：
使用 $codex-daily-report 生成今天的日报
也可以指定日期、工作区和工时：
使用 $codex-daily-report 生成 2026-06-18 的日报，工作区是 /path/to/workspace，总工时 8h
这个仓库里只有 skill 本体、参考命令和脱敏示例，不需要构建，也不需要额外安装 Python 包。你真正要改的，主要是 SKILL.md 里的公司规则。
总结
这套生成日报的方案，本质上是把日常工作的证据链整理出来：Codex 对话负责还原上下文，git 负责校正真实产出，需求和 bug 系统负责校正类型和进度，skills 负责把这些规则固定下来。只要数据源和规则稳定，日报就可以从“每天晚上靠记忆补作业”，变成“让 AI 根据真实工作记录自动归纳”。这才是 skills 真正有价值的地方：把那些重复做、容易漏、容易乱的工作流程，沉淀成可复用的自动化规则。
