明确答案:需自动捕获git变更与codex真实工具调用,过滤闲聊调试,限定工作目录,用rules.yaml加权映射文件到业务动作,并人工验证后对接飞书/钉钉推送。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

你需要在不打断日常开发节奏的前提下,自动捕获真实编码行为并生成可汇报的工时记录,而不是靠回忆补填或手动打点。
明确数据源边界,避免过度采集
工时记录的核心不是“你开了几个Codex会话”,而是“你对哪些代码文件做了哪些实质性修改”。因此只采集两类数据:① 本地 Git 工作区中当天有变更(add/modify/delete)的文件路径及提交信息;② Codex 当日线程中调用过 git、edit、run 等工具的真实操作记录。其他如纯问答、闲聊、调试失败的命令行输出一律过滤。
这一步必须做,否则日报里会出现“与AI讨论Python装饰器原理(耗时23分钟)”这类无法向财务或PM解释的条目。
【Git工作区路径必须是单一可信根目录】所有项目需统一放在 ~/work 或 D:\projects 这类固定路径下,不能分散在桌面、下载文件夹、临时解压目录。Codex 无法跨盘符或跨挂载点自动聚合变更,否则会漏掉关键改动。
用Codex CLI快速构建分析骨架
打开终端,进入你的主工作目录(例如 ~/work),执行:codex init --name time-tracker。这会创建一个带基础配置的本地项目,并自动绑定当前目录为上下文边界。
接着运行:codex run "分析今天 git status 输出,列出所有被修改、新增、删除的文件路径,忽略 .gitignore 中的路径"。Codex 会调用本地 git 命令并解析结果,输出结构化路径列表。
注意:不要用 git log --since="24 hours ago",它依赖系统时区和提交时间戳,而你真正要的是“今天编辑过并暂存/提交的文件”,所以应优先读 git status --porcelain 的实时状态。
注入规则引擎,把文件变更映射到业务动作
第一步:在项目根目录新建 rules.yaml,写入如下映射逻辑:
```yaml
patterns:
- name: "后端API开发"
files: ["src/api/**", "routes/*.py", "controllers/**/*.ts"]
weight: 1.5
- name: "数据库迁移"
files: ["migrations/**", "alembic/**", "db/schema.sql"]
weight: 2.0
- name: "前端组件调整"
files: ["src/components/**", "pages/**/*.vue", "assets/scss/"]
weight: 1.2
```
配置 OpenClaw 多提供商认证与 OpenAI Codex OAuth 备用方案,实现自动模型切换,适用于多 OpenAI Codex 账户设置。
第二步:让 Codex 加载该规则,执行自然语言指令:“根据 rules.yaml 中的 patterns,对刚才 git status 提取的文件列表进行匹配,输出每类业务动作的文件数、加权工时估算(按 weight × 文件数 × 0.3 小时)、原始文件路径示例。”
这一步直接产出可读性强的归类结果,比如:“后端API开发 ×3 文件 → 0.9 小时(示例:src/api/user.py, routes/auth.py)”。权重值由你根据团队实际经验设定,不需要精确到分钟,但必须稳定可复现。
对接飞书/钉钉自动生成日报卡片
方法一:启用飞书插件 → 在 Codex 设置中授权飞书多维表格 → 创建一张名为「每日工时」的表格,含列:日期、业务类型、估算工时、文件示例、Codex线程ID。
方法二:用内置 HTTP 工具 POST 到企业微信机器人 Webhook → 编写一行指令:“将本次分析结果格式化为 markdown 卡片,包含标题【今日工时摘要】、三行关键数据、底部附上 codex thread link,然后发给企业微信机器人”。
注意:不要在首次运行时就开启自动推送。先人工检查前3天输出是否合理,确认无误后再勾选“定时每天18:00自动执行并推送”。【自动推送一旦开启,错误规则会导致连续多日错误数据污染群消息】
验证与微调闭环
第一步:打开 Codex 侧边栏的 Threads 列表,找到刚运行的 time-tracker 线程。
第二步:点击该线程右上角的 ⋯ → “Export as JSON”,保存本地为 tracker-20261012.json。
第三步:用文本编辑器打开该 JSON,搜索 "tool_calls" 字段,确认其中是否包含 git status、read_file(rules.yaml)、http_post 等预期调用,且没有意外触发 install、rm、curl 外部链接等高危操作。
第四步:若发现某次误将 node_modules 下的文件计入统计,立即在 rules.yaml 的 patterns 最上方添加排除项:exclude: ["**/node_modules/**", "**/.git/**"],然后重跑。










