我们公司一直要写日报和周报。作为技术人员，工作量其实还算比较好量化：今天改了哪些需求、修了哪些 bug、有没有上线、有没有测试环境验证、有没有沉淀文档，这些东西基本都有迹可循。

所以我做了一个 skills，直接让 AI 根据我本地的 Codex 对话和 git 记录生成日报。真实效果如下：

GitHub 项目在这里：

https://github.com/jianzhangg/codex-daily-report

你可以直接用我的 skills，但每个公司的流程不太一样，需求系统、bug 状态、日报格式、领导关注点都不同，所以大概率还是要按自己公司的情况微调。我先把思路讲清楚，方便你参考。

为什么要做这个

日报这件事看起来很简单，真正麻烦的是两点：

第一，手写很容易漏。

一天里面可能开了好几个 Codex 会话，上午排查 bug，下午改需求，中间还穿插测试环境验证、发版、补文档。晚上手写的时候，人脑很容易只记得最重的一两件事，很多收尾动作就被漏掉了。

第二，AI 直接帮你“编一篇日报”也不靠谱。

如果你只告诉 AI “我今天做了某某需求，帮我写日报”，它当然能写得很漂亮，但这类内容很容易变成空话。比如“推进了相关工作”“完成了问题处理”“持续优化用户体验”，读起来像日报，实际上没有证据，也没有业务结果。

我想要的是：让 AI 根据真实工作记录生成日报。

所以这个 skills 的核心是把数据源和规则先整理好，让 AI 有证据可查、有边界可遵守。

数据来源

Codex 对话信息

我们平时基本都用 Codex 开发，对话上下文本身就是一部分工作记录。

Codex 的会话会存在本地数据库和 jsonl 文件里面，比如线程标题、工作区路径、用户消息、助手回复、工具执行记录等。skills 里面会先从这些地方把当天相关的会话找出来。

这里有一个关键点：不能只看今天新开的会话。

真实工作经常是昨天开的会话，今天继续排查、继续改代码、继续验证。如果只按“会话创建日期”筛选，就会漏掉跨天继续推进的工作。所以我的规则里会按消息时间判断，只要今天在这个工作区里继续发生了真实对话和操作，就要纳入候选。

当然，只有工作相关会话才算日报素材。像临时闲聊、个人问题、测试 AI 能不能用、生成日报本身这些会话，都要过滤掉。否则日报会变成“我今天让 AI 帮我写日报”，这就没意义了。

git 代码记录

另一大数据来源是实际代码变动。

可以看当天有哪些提交、哪些未提交改动、哪些文件被新增或修改，再和 Codex 对话内容做交叉验证。这样就能更准确地识别今天真正推进了什么。

我所有工作相关的 git 项目基本都放在同一个大目录下面，这点很重要。建议你也这么做：工作仓库放一个文件夹，个人折腾放另一个文件夹。这样 AI 抓 Codex 对话和 git 记录时，边界会清楚很多，不容易把生活内容和工作内容混在一起。

git 是很好的校准工具。

比如会话里说“已经修完并验证”，但 git 里没有任何对应改动，那就要谨慎一点；反过来，如果 git 里有当天提交，但会话里没写清楚，也可以反查这次提交到底服务哪个需求，避免漏项。

需求和 bug 系统

如果你们公司有需求系统、bug 系统、工单系统，也建议接进去。

因为日报里最容易出错的是类型和进度。

一个问题到底是“需求”还是“bug”，不能只靠标题猜；进度到底是 80%、90% 还是 100%，也不能只靠 AI 感觉。最好能让 AI 查到这个编号在系统里的真实类型、当前状态、评论记录、上线记录，再决定日报怎么写。

我自己的私有版本会按公司内部系统校正这些信息。公开版本为了脱敏，只保留了通用规则，你需要自己把这部分换成公司的实际查询方式。

已有日报和周报

如果是生成周报，我不建议让 AI 从一整周所有原始会话重新开始扫。

更稳定的方式是：先每天生成好日报，周报再基于这一周已经落盘的日报做归并。这样周报不会机械拼接每天内容，也不会因为上下文太多把重点写乱。

周报只需要回答一个问题：这一周哪些需求和 bug 有推进，现在结果是什么。

AI 协作量

我自己还加了 token 统计，用来粗略表达当天 AI 协作量。

这个是可选项，你可以不加。但如果公司本身就在推进 AI 提效，或者你想量化 AI 参与程度，这个数据还是有参考价值的。

不过这里也要注意，token 不能简单等同于工作量。正确做法是结合当天实际动作，比如调研排查、方案文档、代码实现、测试回归、发布协作，再做一个相对合理的拆分。否则很容易变成“今天烧了很多 token，所以我很辛苦”，这说服力不够。

核心流程

我的 skills 大概会按这个流程走：

1. 确定日期、工作区、总工时和输出位置。用户不说日期就默认今天，不要每次都追问。

2. 从 Codex 本地数据库和 jsonl 文件里筛选当天相关会话。这里要覆盖跨天会话，也要过滤系统提示、环境上下文、重复消息和生成日报本身。

3. 读取关键会话内容，看当天真实做了什么。不能只抽关键词，因为很多工作结论在助手回复、工具执行结果和最后总结里。

4. 扫描工作区里的 git 仓库，看当天提交、未提交改动和新增文件，用来校正主线和漏项。

5. 如果出现需求编号或 bug 编号，就按编号回查真实类型、状态和进度。没有证据支撑的 100%，不要乱写。

6. 把同一个需求下的排查、修复、测试、发布、文档沉淀合并成一条。不要按开了几个会话就写几条。

7. 写成非技术同事也能看懂的中文日报，尽量少写接口名、日志名、分支名和命令，重点写业务目标、当天动作和当前结果。

8. 最后做一次自检：有没有漏编号、有没有把支撑动作写成主线、工时加起来对不对、进度有没有证据、周报是否和日报口径一致。

真正让这个 skills 好用的是这些规则叠在一起之后，AI 不太容易跑偏。

其他规范

需求、bug 命名统一

需求和 bug 的命名一定要统一。

我的 Codex 对话标题基本都会带需求或 bug 编号，方便 AI 直接识别。这样无论是人还是 AI，都能快速知道这条会话服务哪个业务目标。

不要把会话名称都写成“优化页面”“修复问题”“继续处理”这种描述。短期看没什么，长期会非常混乱。AI 扫一堆会话时，也很难判断它们是不是同一个需求。

比如我这边以前常见的是 5 位数字 ID，我可以用这个 ID 去网页上查需求或 bug 的具体内容。那我的对话标题就尽量带这个 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。迭代几次以后，它会越来越贴近你们公司的真实口径。

怎么安装

公开版本已经做了通用化处理，不绑定我公司的内部系统。

git clone https://github.com/jianzhangg/codex-daily-report.git
cd codex-daily-report
cp -R codex-daily-report ~/.codex/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 真正有价值的地方：把你重复做、容易漏、容易乱的工作流程沉淀成可复用的自动化规则。