高效生成工作日报的实用技能与经验分享

日报这件事，表面上很简单，但真正实践起来，问题往往集中在两个关键环节上。

一方面，容易遗漏细节。一天下来，你可能开了好几个 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 的大致流程如下：

1. 确定日期、工作区、总工时和输出位置。用户不说日期则默认今天，不需要每次都追问。
2. 筛选会话。从 Codex 本地数据库和 jsonl 文件中找出当天相关的会话。要覆盖跨天会话，同时过滤掉系统提示、环境上下文、重复消息以及生成日报本身的会话。
3. 读取关键内容。查看会话内容，判断当天到底做了什么。不能只提取关键词，因为很多结论隐藏在助手回复、工具执行结果和最后总结中。
4. 扫描 git 仓库。查看当天的提交、未提交改动和新增文件，用于校正主线、发现漏项。
5. 回查系统编号。如果当天工作涉及需求或 bug 编号，就按编号回查真实类型、状态和进度。没有证据支撑的 100%，不能写。
6. 合并工作项。将同一个需求下的排查、修复、测试、发布、文档沉淀合并成一条。不能按开了几个会话就写几条。
7. 翻译成业务语言。写成非技术同事也能看懂的中文日报。少写接口名、日志名、分支名和命令，重点写业务目标、当天动作和当前结果。
8. 自检。最后做一次检查：有没有漏编号、有没有把支撑动作写成主线、工时加起来对不对、进度有没有证据、周报是否与日报口径一致。

真正让这套 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 真正有价值的地方：把那些重复做、容易漏、容易乱的工作流程，沉淀成可复用的自动化规则。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：高效生成工作日报的实用技能与经验分享要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题