独立开发者运维官（devops-officer）

独立开发者往往一人兼顾开发、运维、客服三个角色。本 Skill 将三项最耗时的重复性运维工作自动化：

• 自动从 Git 读取本周提交，生成可直接发送的技术周报
• 将零散用户反馈/日志整理为带优先级的 Bug 工单
• 定期巡检项目健康状态，量化评估并给出改进建议

⚡ 30 秒快速上手

直接复制以下示例，即可开始使用：

✅ "帮我生成本周技术周报，仓库在 /Users/me/myproject"
✅ "把这些用户反馈整理成 Bug 工单：[粘贴反馈内容]"
✅ "帮我对项目做一次健康巡检"
✅ "这周我做了哪些提交？汇总一下"
✅ "我有 5 条用户反馈，帮我分优先级"
✅ "一键生成完整运维周报（周报 + 健康检查）"

口语化表达也同样支持：

✅ "帮我看看这周干了啥"       → 触发 Git 周报
✅ "最近提交了啥？汇总一下"    → 触发 Git 周报
✅ "这周咋样"                 → 触发 Git 周报
✅ "项目最近有没有什么问题"    → 触发健康巡检
✅ "帮我看看这些 bug 怎么分"   → 触发 Bug 工单
✅ "这些反馈优先级怎么排"      → 触发 Bug 工单

第一次使用推荐从这里开始：

> "帮我生成本周技术周报" —— 告诉我你的 Git 仓库路径即可

能力边界说明

✅ 擅长处理

1. Git 技术周报：读取本地仓库提交记录，按类别聚合，生成完整周报 Markdown
2. Bug 工单批量生成：将自由文本（用户反馈/崩溃日志/告警通知）转为结构化工单
3. Bug 优先级分类：自动判断 P0~P3 级别，给出 SLA 建议
4. 项目健康巡检：检查代码管理习惯和项目结构，输出量化评分
5. 综合运维周报：一次性生成周报 + 健康检查合并报告

⚠️ 需要素材才能做

1. 周报生成：需要提供有效的 Git 仓库路径（含 .git 目录）
2. Bug 工单：需要提供反馈文本内容（粘贴或文件路径）
3. 健康报告：需要提供项目根目录路径

❌ 超出范围（附替代方案）

1. 推送/发布周报：只生成文档，不自动发送到企业微信/Slack → 用企业微信连接器手动发送
2. 代码质量静态分析：不分析代码逻辑，只统计 Git 指标 → 使用 SonarQube/ESLint
3. Bug 自动修复：只生成工单，不修复代码 → 工单生成后告知开发者位置

触发条件（按场景路由）

工作流一：Git 技术周报生成

执行步骤

1. 确认仓库路径：
• 若用户已提供路径 → 直接使用
• 若未提供 → 询问"请提供 Git 仓库路径，例如 /Users/me/myproject 或 D:\projects\myapp"

1. 运行脚本（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（用于进一步处理）

1. 读取并展示报告，直接渲染 Markdown 内容
2. 主动分析趋势：如提交数偏少、某类别占比超 50%，主动给出改进建议

输出结构

• 📈 数据概览（总提交数、代码行变化、净变化）
• 👥 贡献者排行
• 🗂️ 活跃模块 Top 5
• 📝 按类别提交明细（✨新功能 / 🐛Bug修复 / ♻️重构优化 / 📝文档 / 🧪测试 / 🔧其他）

工作流二：Bug 工单生成与优先级分配

执行步骤

1. 收集反馈内容：
• 用户直接粘贴文本 → 保存为临时文件或直接传 --text
• 用户提供文件路径 → 用 --input 传入
• 多条反馈可合并成一段文本，脚本自动按空行拆分为独立工单

1. 运行脚本：

# 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"

1. 展示工单报告，按优先级 P0→P1→P2→P3 排列
2. 询问负责人：对 P0/P1 工单，主动询问"谁来负责这个工单？"
3. 给出修复建议：根据工单分类，给出排查方向（如崩溃类建议检查 NPE 堆栈）

优先级规则速查

信息不足时的降级策略：若反馈文本过于模糊（如"系统有问题"），先按 P2 生成工单，并在描述中注明"信息不足，需补充复现步骤"。

工作流三：项目健康巡检

执行步骤

1. 运行脚本：

# 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"

1. 解读评分等级：
• A（≥90分）：🟢 健康，继续保持
• B（75-89分）：🟡 良好，有小问题
• C（60-74分）：🟠 需关注，建议本周改进
• D（<60分）：🔴 问题严重，建议优先修复

1. 逐项给出改进方案：根据每个扣分点，给出具体可执行的操作建议

工作流四：综合运维周报（组合模式）

当用户希望一次性生成完整运维报告时：

1. 先执行工作流一（Git 周报）→ 生成 weekly_report_YYYYMMDD.md
2. 再执行工作流三（健康巡检）→ 生成 health_report_YYYYMMDD.md
3. 将两份报告合并，生成 devops_weekly_YYYYMMDD.md
4. 如用户提到有用户反馈积压，追加工作流二（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__/）

常见错误处理（精确指引）

数据隐私说明

• 所有脚本在本地运行，不上传任何代码、提交记录或用户反馈到外部服务器
• 生成的报告文件存储在用户指定路径，不会自动分享
• Bug 工单中的用户反馈原文：建议在对外发送前手动脱敏（去除手机号/邮箱等个人信息）
• 禁止将包含真实用户个人信息的反馈文本直接传入脚本，建议先脱敏处理

受众说明

常见反模式（请避免）

❌ 把整个代码文件粘贴进来让生成周报 → 本 Skill 读取 Git log，不需要源码

❌ 用中文路径作为 --repo 参数 → 建议使用英文路径，避免 Windows 编码问题

❌ 期望自动发邮件/发企微消息 → 只生成文档，发送需要另外配置连接器

❌ 用模糊指令（如"帮我看看"）而不提供路径 → 明确提供仓库路径效果更好

❌ 把同一个反馈文本多次传入 → 会导致生成重复工单（因为 ticket_id 基于内容哈希），建议去重后再传入

❌ 期望 Bug 工单自动分配负责人 → 工单生成后默认为"待分配"，需手动指定

❌ 在非 Git 仓库目录下运行周报生成 → 会报错"不是有效的 Git 仓库"，先 cd 到项目根目录

❌ 一次性传入 500+ 条反馈 → 建议分批处理，每批不超过 100 条，便于人工审核分类结果

脚本路径速查

详细工作流参考：~/.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 群"。