独立开发者运维官(devops-officer)
独立开发者往往一人兼顾开发、运维、客服三个角色。本 Skill 将三项最耗时的重复性运维工作自动化:
- 自动从 Git 读取本周提交,生成可直接发送的技术周报
- 将零散用户反馈/日志整理为带优先级的 Bug 工单
- 定期巡检项目健康状态,量化评估并给出改进建议
⚡ 30 秒快速上手
直接复制以下示例,即可开始使用:
✅ "帮我生成本周技术周报,仓库在 /Users/me/myproject"
✅ "把这些用户反馈整理成 Bug 工单:[粘贴反馈内容]"
✅ "帮我对项目做一次健康巡检"
✅ "这周我做了哪些提交?汇总一下"
✅ "我有 5 条用户反馈,帮我分优先级"
✅ "一键生成完整运维周报(周报 + 健康检查)"
口语化表达也同样支持:
✅ "帮我看看这周干了啥" → 触发 Git 周报
✅ "最近提交了啥?汇总一下" → 触发 Git 周报
✅ "这周咋样" → 触发 Git 周报
✅ "项目最近有没有什么问题" → 触发健康巡检
✅ "帮我看看这些 bug 怎么分" → 触发 Bug 工单
✅ "这些反馈优先级怎么排" → 触发 Bug 工单
第一次使用推荐从这里开始:
"帮我生成本周技术周报" —— 告诉我你的 Git 仓库路径即可
能力边界说明
✅ 擅长处理
- Git 技术周报:读取本地仓库提交记录,按类别聚合,生成完整周报 Markdown
- Bug 工单批量生成:将自由文本(用户反馈/崩溃日志/告警通知)转为结构化工单
- Bug 优先级分类:自动判断 P0~P3 级别,给出 SLA 建议
- 项目健康巡检:检查代码管理习惯和项目结构,输出量化评分
- 综合运维周报:一次性生成周报 + 健康检查合并报告
⚠️ 需要素材才能做
- 周报生成:需要提供有效的 Git 仓库路径(含 .git 目录)
- Bug 工单:需要提供反馈文本内容(粘贴或文件路径)
- 健康报告:需要提供项目根目录路径
❌ 超出范围(附替代方案)
- 推送/发布周报:只生成文档,不自动发送到企业微信/Slack → 用企业微信连接器手动发送
- 代码质量静态分析:不分析代码逻辑,只统计 Git 指标 → 使用 SonarQube/ESLint
- Bug 自动修复:只生成工单,不修复代码 → 工单生成后告知开发者位置
触发条件(按场景路由)
| 用户说... | 触发工作流 | |---------|----------| | "周报"、"这周做了什么"、"git 总结"、"weekly report" | 工作流一:Git 周报 | | "这周干了啥"、"最近提交"、"这周咋样"、"最近改了啥" | 工作流一:Git 周报 | | 粘贴反馈文本、"bug 工单"、"分级这些问题"、"用户反馈" | 工作流二:Bug 工单 | | "这些 bug 怎么分"、"反馈优先级"、"帮我看看这些问题" | 工作流二:Bug 工单 | | "项目健康"、"health check"、"代码状态"、"项目巡检" | 工作流三:健康巡检 | | "项目有没有问题"、"项目怎么样"、"帮我看看代码质量" | 工作流三:健康巡检 | | "完整周报"、"一键周报"、"全部"、"运维报告" | 工作流四:综合周报 |
工作流一:Git 技术周报生成
执行步骤
-
确认仓库路径:
- 若用户已提供路径 → 直接使用
- 若未提供 → 询问"请提供 Git 仓库路径,例如 /Users/me/myproject 或 D:\projects\myapp"
-
运行脚本(Windows 使用绝对路径):
# macOS/Linux
python ~/.workbuddy/skills/devops-officer/scripts/git_weekly_report.py \
--repo <仓库路径> --days 7 \
--output weekly_report_$(date +%Y%m%d).md
# Windows(PowerShell)
python "$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\git_weekly_report.py" `
--repo "<仓库路径>" --days 7 `
--output "weekly_report_$(Get-Date -Format 'yyyyMMdd').md"
可选参数:
--days 14:统计两周--author "张三":只统计特定作者--format json:输出 JSON(用于进一步处理)
- 读取并展示报告,直接渲染 Markdown 内容
- 主动分析趋势:如提交数偏少、某类别占比超 50%,主动给出改进建议
输出结构
- 📈 数据概览(总提交数、代码行变化、净变化)
- 👥 贡献者排行
- 🗂️ 活跃模块 Top 5
- 📝 按类别提交明细(✨新功能 / 🐛Bug修复 / ♻️重构优化 / 📝文档 / 🧪测试 / 🔧其他)
工作流二:Bug 工单生成与优先级分配
执行步骤
-
收集反馈内容:
- 用户直接粘贴文本 → 保存为临时文件或直接传
--text - 用户提供文件路径 → 用
--input传入 - 多条反馈可合并成一段文本,脚本自动按空行拆分为独立工单
- 用户直接粘贴文本 → 保存为临时文件或直接传
-
运行脚本:
# macOS/Linux — 从文件读取
python ~/.workbuddy/skills/devops-officer/scripts/bug_triage.py \
--input feedback.txt \
--output bug_tickets_$(date +%Y%m%d).md
# Windows(PowerShell)
python "$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\bug_triage.py" `
--input feedback.txt `
--output "bug_tickets_$(Get-Date -Format 'yyyyMMdd').md"
- 展示工单报告,按优先级 P0→P1→P2→P3 排列
- 询问负责人:对 P0/P1 工单,主动询问"谁来负责这个工单?"
- 给出修复建议:根据工单分类,给出排查方向(如崩溃类建议检查 NPE 堆栈)
优先级规则速查
| 级别 | 典型场景 | 修复 SLA | |------|---------|---------| | 🔴 P0 | 崩溃/OOM/数据丢失/安全漏洞/支付异常/500服务不可用 | ≤ 2h 立即处理 | | 🟠 P1 | 登录失败/核心功能不可用/白屏/API超时/一直转圈 | 24h 内修复 | | 🟡 P2 | 卡顿/偶发性异常/显示错误/表单验证问题/图片裂图 | 本迭代内处理 | | 🟢 P3 | UI样式/错别字/颜色与设计稿不符/交互体验 | 下次迭代排期 |
信息不足时的降级策略:若反馈文本过于模糊(如"系统有问题"),先按 P2 生成工单,并在描述中注明"信息不足,需补充复现步骤"。
工作流三:项目健康巡检
执行步骤
- 运行脚本:
# macOS/Linux
python ~/.workbuddy/skills/devops-officer/scripts/health_check.py \
--repo <仓库路径> --days 7 \
--output health_report_$(date +%Y%m%d).md
# Windows(PowerShell)
python "$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\health_check.py" `
--repo "<仓库路径>" --days 7 `
--output "health_report_$(Get-Date -Format 'yyyyMMdd').md"
-
解读评分等级:
- A(≥90分):🟢 健康,继续保持
- B(75-89分):🟡 良好,有小问题
- C(60-74分):🟠 需关注,建议本周改进
- D(<60分):🔴 问题严重,建议优先修复
-
逐项给出改进方案:根据每个扣分点,给出具体可执行的操作建议
工作流四:综合运维周报(组合模式)
当用户希望一次性生成完整运维报告时:
- 先执行工作流一(Git 周报)→ 生成
weekly_report_YYYYMMDD.md - 再执行工作流三(健康巡检)→ 生成
health_report_YYYYMMDD.md - 将两份报告合并,生成
devops_weekly_YYYYMMDD.md - 如用户提到有用户反馈积压,追加工作流二(Bug 工单)并附在报告末尾
📸 输出示例预览
周报输出示例
# 📊 技术周报 — my-awesome-app
> 统计周期:2026-05-19 ~ 2026-05-26 | 生成时间:2026-05-26 16:00:00
## 📈 本周数据概览
| 指标 | 数值 |
|------|------|
| 总提交数 | **23** |
| 新增代码行 | +1,247 |
| 删除代码行 | -389 |
| 净变化行 | +858 |
## 👥 贡献者排行
- 张三:15 次提交
- 李四:8 次提交
## 🗂️ 最活跃模块 Top 5
- `src/api` — 8 次变更
- `src/components` — 6 次变更
- `docs` — 4 次变更
- `tests` — 3 次变更
- `scripts` — 2 次变更
## 📝 提交明细
### ✨ 新功能(12 条)
- `a1b2c3d4` feat: 添加用户登录功能 _(by 张三, 2026-05-20)_
- `e5f6g7h8` feat: 实现支付模块接口 _(by 张三, 2026-05-21)_
...
### 🐛 Bug 修复(6 条)
- `i9j0k1l2` fix: 修复支付超时未回滚问题 _(by 李四, 2026-05-22)_
...
## 💡 智能洞察
> 🔥 **本周开发节奏较快**:23 次提交,日均 3.3 次,高于上周(15 次)。
> 📈 **新功能占比过半**(52.2%),Bug 修复占 26.1%—— 建议关注新功能的测试覆盖。
> ⚠️ **支付模块改动集中**:src/api/payment 连续 3 天有变更,建议重点回归测试。
Bug 工单输出示例
# 🐛 Bug 工单报告
> 生成时间:2026-05-26 16:00:00 | 共 3 个工单
## 📊 优先级分布
| 优先级 | 数量 | SLA |
|--------|------|-----|
| 🔴 P0 - 紧急 | 1 | 立即处理(≤ 2h) |
| 🟠 P1 - 高优 | 1 | 24h 内修复 |
| 🟡 P2 - 中优 | 1 | 本迭代内处理 |
## 🔴 P0 - 紧急 工单(立即处理 ≤ 2h)
### [BUG-20260526-A1B2C3] 点击支付按钮后 app 直接崩溃
| 字段 | 内容 |
|------|------|
| 工单 ID | `BUG-20260526-A1B2C3` |
| 优先级 | 🔴 P0 - 紧急 |
| SLA | 立即处理(≤ 2h) |
| 分类 | 崩溃/宕机 |
| 影响组件 | 支付 |
| 状态 | OPEN |
| 负责人 | 待分配 |
**问题描述:**
> 点击支付按钮后 app 直接崩溃,用户无法完成支付流程
**修复建议:**
_请开发者根据 崩溃/宕机 类型分析根因并填写修复方案_
🔍 建议排查方向:检查最新提交中支付模块的 NullPointerException 或内存溢出
健康巡检输出示例
# 🏥 项目健康报告 — my-awesome-app
> 巡检时间:2026-05-26 16:00:00 | 统计周期:近 7 天
## 🟡 综合健康评分:**78.0 / 100**(等级 B)
| 检查模块 | 评分 | 主要问题数 |
|----------|------|------------|
| Git 代码管理 | 90 | 0 |
| 项目结构 | 66 | 2 |
## 📋 Git 代码管理(90 分)
✅ 本模块无明显问题
## 📋 项目结构(66 分)
**⚠️ 发现问题:**
- 缺少 README 文档(README.md 或 README.rst)
- 未发现测试目录
**💡 改进建议:**
- 建议添加 README.md,说明项目用途和使用方式
- 建议建立自动化测试(tests/ 或 __tests__/)
常见错误处理(精确指引)
| 错误情况 | 用户友好提示 | |---------|------------| | Git 未安装 / 找不到 git 命令 | "❌ 未找到 git 命令。请先安装 Git:Windows 下载地址 https://git-scm.com/download/win,安装后重启终端" | | 路径不是 Git 仓库 | "❌ [路径] 不是有效的 Git 仓库(找不到 .git 目录)。请确认路径是否正确,或进入项目根目录后重试" | | 统计周期内 0 次提交 | 正常生成报告,在概览中显示"本周无提交记录",并提示"如需查更长周期,可以用 --days 30" | | Python 版本过低 | "❌ 需要 Python 3.6+。当前版本不支持。请升级 Python 或使用 python3 命令" | | 反馈文本过短/无效(< 10 字符) | 仍生成工单,标注"⚠️ 信息不足,建议补充复现步骤和环境信息",优先级默认 P2 |
数据隐私说明
- 所有脚本在本地运行,不上传任何代码、提交记录或用户反馈到外部服务器
- 生成的报告文件存储在用户指定路径,不会自动分享
- Bug 工单中的用户反馈原文:建议在对外发送前手动脱敏(去除手机号/邮箱等个人信息)
- 禁止将包含真实用户个人信息的反馈文本直接传入脚本,建议先脱敏处理
受众说明
| 用户类型 | 推荐使用方式 |
|---------|------------|
| 独立开发者(个人项目) | 每周五用工作流四一键生成完整运维周报 |
| 小团队技术负责人 | 用 --author 参数分别生成每人的周报;统一处理客服反馈 |
| 兼职/副业开发者 | 按需使用,每次提交后用工作流二处理用户反馈 |
| 开源项目维护者 | 定期用工作流三检查项目健康;用工作流二处理 Issue 反馈 |
常见反模式(请避免)
❌ 把整个代码文件粘贴进来让生成周报 → 本 Skill 读取 Git log,不需要源码
❌ 用中文路径作为 --repo 参数 → 建议使用英文路径,避免 Windows 编码问题
❌ 期望自动发邮件/发企微消息 → 只生成文档,发送需要另外配置连接器
❌ 用模糊指令(如"帮我看看")而不提供路径 → 明确提供仓库路径效果更好
❌ 把同一个反馈文本多次传入 → 会导致生成重复工单(因为 ticket_id 基于内容哈希),建议去重后再传入
❌ 期望 Bug 工单自动分配负责人 → 工单生成后默认为"待分配",需手动指定
❌ 在非 Git 仓库目录下运行周报生成 → 会报错"不是有效的 Git 仓库",先 cd 到项目根目录
❌ 一次性传入 500+ 条反馈 → 建议分批处理,每批不超过 100 条,便于人工审核分类结果
脚本路径速查
| 脚本 | 功能 |
|------|------|
| ~/.workbuddy/skills/devops-officer/scripts/git_weekly_report.py | Git 周报生成 |
| ~/.workbuddy/skills/devops-officer/scripts/bug_triage.py | Bug 工单生成 |
| ~/.workbuddy/skills/devops-officer/scripts/health_check.py | 项目健康巡检 |
详细工作流参考:~/.workbuddy/skills/devops-officer/references/workflow_guide.md
FAQ
Q1:Windows 系统下脚本路径怎么写?
用 PowerShell 格式:"$env:USERPROFILE\.workbuddy\skills\devops-officer\scripts\git_weekly_report.py"
Q2:我的仓库是私有的,提交记录会被上传吗? 不会。所有脚本只在本地运行,不联网,不上传任何数据。
Q3:没有 Git 提交也能用 Bug 工单功能吗? 可以。Bug 工单生成(工作流二)和健康巡检(工作流三的结构检查部分)不依赖 Git 提交记录。
Q4:反馈文本里有用户手机号,会被记录吗? 脚本将原文写入工单文件,存在本地。建议在粘贴前手动脱敏,或在输出文件中替换敏感信息。
Q5:一次能处理多少条反馈? 无硬性限制。100 条以内反馈处理速度很快。建议每次处理同一产品/版本的反馈,以便分类更准确。
Q6:优先级判断不准确怎么办? 脚本基于关键词规则判断,可能有误判。查看输出工单时,若发现不对,直接告诉我"把 BUG-xxx 改为 P1"即可修正。
Q7:支持英文项目/英文反馈吗? 支持。脚本同时匹配中英文关键词,英文项目可正常使用。
Q8:项目健康评分 D 意味着什么,会影响功能使用吗? 不影响功能。评分仅供参考,D 级通常意味着缺少基础工程规范(如无 README、无 .gitignore),不代表代码质量差。
Q9:反馈内容太短(少于 10 字),系统会怎么处理? 仍会生成工单,但会标注"⚠️ 信息不足,建议补充复现步骤和环境信息",默认优先级设为 P2。这是因为信息太少无法准确判断严重程度,宁可保守也不误判为 P0。
Q10:能合并多个项目的 Git 提交生成一份综合周报吗? 当前支持对单个仓库生成周报。如需合并多个项目,你可以分别生成各项目的周报后手动合并,或告诉我"把项目 A 和项目 B 的周报合并"。
Q11:生成的周报可以导出成 PDF 或 Word 吗? 周报输出为 Markdown 格式。如需转 PDF,可以用 Typora/Pandoc 等工具转换,或告诉我"把这份周报转成 PDF"。
Q12:健康巡检的评分标准和 CI/CD 工具有什么区别? 健康巡检侧重于 Git 管理习惯和项目结构规范,不分析代码质量和测试覆盖率。它与 SonarQube / Codecov 互补而非替代。建议搭配使用以获得完整视图。
Q13:反馈中如果同时提到"崩溃"和"颜色不对",优先级怎么定? 按最严重的关键词判定。如果同时命中 P0(崩溃)和 P3(颜色),最终优先级为 P0。系统采用"就高不就低"原则。
Q14:生成报告后可以直接通过企业微信发送给团队吗? 可以。报告生成后,使用企业微信连接器发送文件。具体操作:先运行对应脚本生成报告文件,再告诉我"把这份报告发送到 XX 群"。
微信扫一扫