用 Claude Opus 5 + TaoToken 自动整理日报周报:一份可复制的 Skills 配置骨架 1. 为什么我把日报周报交给了 Claude Opus 5写日报、周报最烦的从来不是打字而是回想这周到底干了啥哪个需求推进了哪个问题还卡着下周计划怎么写才不空对研发、产品、运营、项目经理来说工作痕迹散在 Git、任务系统、会议纪要、文档里手工翻一遍很容易漏。我试过直接让模型「帮我写一份本周工作总结」结果就是「完成了相关工作」「推进了项目进展」这种没法交付的套话。问题不在模型在于输入太虚。Claude Opus 5 的上下文窗口和指令遵循能力适合干的是「工作记录分析」这件事先把真实资料收集起来再分类提炼最后按不同汇报对象生成日报、周报、项目进展。这篇就给你一份可复制的 Skills 配置骨架包含config.toml与settings.json并演示一次从 Git 日志到周报输出的完整验证动作照抄就能跑通。适合谁每天要写日报的研发、每周要交周报的产品/运营、要给负责人同步进展的项目经理。核心检索词就三个——Claude Opus 5、Claude Code Skills、Git 日志自动汇总。2. 前置准备TaoToken 接入与 Skills 目录结构Claude Code 的 Skills 本质是一个带SKILL.md的目录模型在需要时按描述自动加载。我们要做的是把「读 Git 历史 → 分类 → 生成汇报」固化成一套流程而不是每次重写提示词。第一步是拿到可用的 API Key。访问 TaoToken 控制台创建密钥地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 创建后复制保存后面写进配置。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到参数问题先查这里。第二步是确认模型名。Claude Opus 5 在请求里用对应的模型标识具体以接入文档的模型列表为准不要凭记忆写。想先验证模型是否通可以直接在模型对话页发一条测试消息 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。第三步是规划目录。我习惯把 Skills 放在项目根目录的.claude/skills/下每个 Skill 一个子目录your-project/ ├── .claude/ │ ├── settings.json │ └── skills/ │ └── weekly-report/ │ ├── SKILL.md │ └── config.tomlsettings.json管全局权限和环境变量config.toml管这个 Skill 自己的参数时间范围、作者、输出模板。分开的好处是换项目只改 config不动全局设置。3. 可复制配置config.toml 与 settings.json 骨架先看config.toml。它定义了这个 Skill 采集什么、按什么分类、输出哪几个版本。字段我尽量写得直白你按注释改就行。# .claude/skills/weekly-report/config.toml [git] # 采集范围day 表示当天week 表示最近 7 天 range week # 只统计指定作者的提交留空则统计全部 author 你的名字 # 提交格式日期 | 短哈希 | 标题 pretty %ad | %h | %s date_format short [classify] # 分类规则模型按关键词把提交归到对应桶里 categories [ { name 功能开发, keywords [feat, add, implement, 新增] }, { name Bug 修复, keywords [fix, bugfix, hotfix, 修复] }, { name 重构优化, keywords [refactor, perf, opt, 优化] }, { name 文档配置, keywords [docs, chore, config, 文档] }, ] [output] # 一次生成三个版本按需取用 formats [daily, weekly, progress] # 不确定的信息统一标注禁止模型自行补全 unknown_marker 需确认 # 每条结论要求标注来源 require_source true [model] # 模型标识以接入文档为准 name claude-opus-5 max_tokens 4096再看settings.json。这里放 API 地址、密钥引用和工具权限。密钥不要硬编码进文件用环境变量引用避免提交到仓库。{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: ${TAOTOKEN_API_KEY}, ANTHROPIC_MODEL: claude-opus-5 }, permissions: { allow: [ Bash(git log:*), Bash(git diff:*), Read ], deny: [ Bash(git push:*), Bash(rm:*) ] } }allow里只放只读的 Git 命令deny挡住推送和删除避免 Skill 在自动执行时误操作。密钥在终端里导出export TAOTOKEN_API_KEY你从控制台复制的密钥如果你打算长期跑编码和 Agent 任务Coding Plan 比按量更划算入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 具体额度以页面说明为准。4. SKILL.md 与提示词骨架SKILL.md是 Skill 的入口模型靠它的描述判断什么时候加载。写法上要写清楚「做什么、什么时候用、输出什么」别写成散文。--- name: weekly-report description: 读取 Git 提交记录按功能/Bug/重构/文档分类生成日报、周报和项目进展三个版本。当用户需要整理工作汇报时使用。 --- # 工作汇报生成 ## 执行步骤 1. 运行 git log 采集指定时间范围的提交 2. 按 config.toml 的 categories 分类 3. 生成 daily / weekly / progress 三个版本 4. 每条结论标注来源不确定信息标「需确认」 ## 约束 - 不编造未提供的信息 - 不自行估算完成率、延期天数 - 保留项目名、模块名、需求编号提示词部分我拆成两段先出事实归类稿再润色成正式汇报。这样模型不容易把没依据的内容混进去。你是项目助理请根据以下工作事实整理一份周报。 要求 1. 不编造未提供的信息 2. 按「本周重点成果、具体工作明细、问题与风险、下周计划」组织 3. 将零散事项合并为有业务含义的成果 4. 保留关键项目名、模块名、需求编号 5. 每条关键结论标注依据来源 6. 信息不足时列出需要补充的问题。 工作事实 [粘贴 Git 记录或事实表]项目进展版本换一套结构重点是让负责人快速判断项目是否按计划走、风险在哪、需要谁拍板请将以下项目资料整理为项目进展汇报。 输出结构 1. 项目总体状态正常 / 有风险 / 阻塞并说明依据 2. 本周期关键进展 3. 里程碑完成情况 4. 当前风险、影响范围和建议处理方式 5. 需要协调的资源或决策 6. 下周期计划。 要求只基于资料判断不自行推断完成率缺少时间、负责人、验收标准的信息标注「需补充」。5. 验证请求从 Git 日志到周报输出配置写完必须验证一次否则你不知道是配置错了还是模型没读到。先手动跑一遍采集命令确认 Git 记录能出来git log --since7 days ago \ --author你的名字 \ --prettyformat:%ad | %h | %s --dateshort正常输出类似这样每行一条提交2026-01-03 | a1b2c3d | fix: 订单状态回调重复触发 2026-01-04 | e4f5g6h | feat: 会员权益二期需求边界梳理 2026-01-05 | i7j8k9l | refactor: 提取订单校验公共方法 2026-01-06 | m0n1o2p | docs: 补充接口联调说明把这段输出粘进提示词让 Claude Opus 5 按 config 里的分类规则处理。预期输出应该长这样## 本周重点成果 - 完善订单回调稳定性修复状态回调重复触发问题来源a1b2c3d并提取订单校验公共方法来源i7j8k9l。 ## 具体工作明细 - 功能开发会员权益二期需求边界梳理来源e4f5g6h。 - Bug 修复订单状态回调重复触发来源a1b2c3d。 - 重构优化订单校验公共方法提取来源i7j8k9l。 - 文档配置补充接口联调说明来源m0n1o2p。 ## 问题与风险 - 订单回调修复待测试回归需确认来源a1b2c3d。 ## 下周计划 - 配合测试验证订单回调修复结果。 - 跟进会员权益二期需求优先级确认。验证成功的标志有三个分类桶对上了、每条结论带了来源、不确定的地方标了「需确认」。如果模型把没提供的完成率也写出来了说明约束没生效回去检查SKILL.md的约束段和提示词。6. 本篇常见错排查报错一401 Unauthorized。多半是密钥没导出或写错了。检查echo $TAOTOKEN_API_KEY有没有值settings.json里的${TAOTOKEN_API_KEY}引用格式对不对。密钥在控制台重新生成即可。报错二model not found。模型标识写错了。别凭记忆写去接入文档的模型列表核对config.toml和settings.json里的模型名要一致。报错三Skill 不加载。检查.claude/skills/weekly-report/SKILL.md路径和文件名description字段不能为空否则模型不知道什么时候用它。报错四Git 记录为空。--author写的是邮箱还是名字Git 里两者都可能先用git log --format%an %ae看一眼实际值再填进 config。报错五输出里出现没依据的数字。这是约束没写死。在提示词里加一句「除非原始资料明确写了否则完成率、延期天数一律标注未提供」并在config.toml里把require_source设为true。报错六分类全堆在一个桶里。关键词太窄。把团队实际的 commit 前缀feat/fix/refactor/docs补进categories的keywords或者干脆让模型按语义分类关键词只做兜底。7. 长期复用与下一步跑通一次之后把流程固定成每周五下午的动作先导出 Git 记录和任务列表补上会议纪要里的关键决策和风险整理成事实表先让模型出事实归类版确认无误再生成主管版和项目进展版人工删敏感信息后发送。事实表建议用统一格式方便模型稳定处理日期项目/模块事项来源状态结果/影响风险/阻塞1月3日订单系统修复回调重复触发Git 缺陷单已完成增加幂等校验待测试回归1月4日会员中心梳理权益二期边界会议纪要进行中明确叠加规则暂缓需产品确认优先级敏感信息先脱敏客户名、金额、账号、内部链接替换成占位符再进提示词。AI 生成的汇报一律当草稿正式发送前检查时间、负责人、风险表述和是否泄露内部信息。想把这套流程接到更多工具里可以看接入文档里的 API 说明长期跑编码和 Agent 任务Coding Plan 的入口在上面给过。配置骨架先照抄跑通再按自己团队的 commit 规范和汇报口径微调比一上来就追求全自动靠谱得多。