メニュー
运营负担分析 - 评估日常运营需求、生活质量影响和自动化可行性
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | operation-burden-analysis |
| description | 运营负担分析 - 评估日常运营需求、生活质量影响和自动化可行性 |
评估产品的日常运营需求,包括客服、监控、内容更新等,分析对生活质量的影响,评估自动化可行性。这是"好生意评估"七维度模型中的第5维度。
任务描述: 回答用户问题、处理投诉、解决使用问题
评估维度:
| 评估项 | 问题 | 选项 |
|---|---|---|
| 响应要求 | 需要多快响应? | 即时(分钟级) / 快速(小时级) / 异步(天级) |
| 工作时间 | 需要24/7吗? | 是 / 工作时间 / 异步即可 |
| 咨询量 | 预估咨询量? | 高(__次/天) / 中(__次/天) / 低(__次/天) |
| 复杂度 | 问题复杂吗? | 高(需专业知识) / 中(需培训) / 低(标准回复) |
| 人力需求 | 需要多少人力? | __小时/周 |
| 自动化可行性 | 能否自动化? | 完全可以 / 部分可以 / 不可以 |
典型场景:
自动化方案:
任务描述: 监控系统状态、处理故障、保障可用性
评估维度:
| 评估项 | 问题 | 选项 |
|---|---|---|
| 监控要求 | 需要24/7监控吗? | 是 / 定期检查即可 |
| 故障影响 | 故障影响严重吗? | 严重(影响核心业务) / 一般 / 轻微 |
| 响应要求 | 必须立即响应吗? | 是(分钟级) / 快速(小时级) / 延后可以 |
| 技术复杂度 | 运维复杂吗? | 高 / 中 / 低 |
| 人力需求 | 需要多少人力? | __小时/周 |
| 自动化可行性 | 能否自动化? | 完全可以 / 部分可以 / 不可以 |
典型场景:
自动化方案:
任务描述: 审核用户生成内容,防止违规内容
评估维度:
| 评估项 | 问题 | 选项 |
|---|---|---|
| 是否需要 | 有UGC内容吗? | 是 / 否 |
| 审核量 | 每天多少内容? | 高(__条/天) / 中(__条/天) / 低(__条/天) |
| 风险等级 | 违规后果严重吗? | 严重(法律责任) / 一般 / 轻微 |
| 审核要求 | 必须人工吗? | 是 / 机器+人工 / 机器即可 |
| 人力需求 | 需要多少人力? | __小时/周 |
| 自动化可行性 | 能否自动化? | 完全可以 / 部分可以 / 不可以 |
典型场景:
自动化方案:
任务描述: 分析用户数据,优化产品,制定策略
评估维度:
| 评估项 | 问题 | 选项 |
|---|---|---|
| 频率要求 | 多久分析一次? | 每天 / 每周 / 每月 |
| 复杂度 | 分析复杂吗? | 高(需专业技能) / 中 / 低(看仪表盘) |
| 人力需求 | 需要多少人力? | __小时/周 |
| 自动化可行性 | 能否自动化? | 完全可以 / 部分可以 / 不可以 |
典型场景:
自动化方案:
任务描述: 更新产品内容(资讯、课程、数据等)
评估维度:
| 评估项 | 问题 | 选项 |
|---|---|---|
| 是否需要 | 需要持续更新内容吗? | 是 / 否 |
| 频率要求 | 多久更新一次? | 每天 / 每周 / 每月 / 不定期 |
| 内容量 | 单次更新量? | 大 / 中 / 小 |
| 专业要求 | 需要专业内容吗? | 是 / 否 |
| 人力需求 | 需要多少人力? | __小时/周 |
| 自动化可行性 | 能否自动化? | 完全可以 / 部分可以 / 不可以 |
典型场景:
自动化方案:
任务描述: 获取新用户,保持用户活跃
评估维度:
| 评估项 | 问题 | 选项 |
|---|---|---|
| 频率要求 | 需要持续营销吗? | 是(每天) / 定期(每周) / 低频 |
| 渠道数量 | 需要多少渠道? | 多(>5个) / 中(2-5个) / 少(1-2个) |
| 人力需求 | 需要多少人力? | __小时/周 |
| 专业要求 | 需要专业技能吗? | 是 / 否 |
典型场景:
□ 需要24/7待命?
□ 故障必须立即响应?
□ 需要人工审核内容?
□ 需要频繁处理纠纷?
□ 需要维护复杂的用户关系?
□ 需要持续产出内容?
复杂度等级:
预估每周运营时间: __小时
评分:
- <10小时: +2分 (低负担)
- 10-20小时: +1分 (适中)
- 20-40小时: 0分 (较重)
- >40小时: -1分 (很重)
能否正常休假?
- 完全可以(产品可以无人看管1周): +2分
- 基本可以(偶尔需要处理问题): +1分
- 困难(需要每天检查): 0分
- 不能(必须时刻待命): -2分
是否影响睡眠?
- 完全不影响: +2分
- 偶尔影响(如半夜告警): 0分
- 经常影响: -2分
心理压力程度?
- 低(产品故障无严重后果): +1分
- 中(有一定压力但可承受): 0分
- 高(担心用户损失、法律问题等): -2分
关键运营任务是否可以外包?
- 完全可以: +2分
- 部分可以: +1分
- 不可以: 0分
运营得分计算 (满分5分):
- 无需24/7待命: +1分
- 客服可以异步处理: +1分
- 大部分任务可自动化: +1分
- 每周运营<20小时: +1分
- 不影响正常生活: +1分
得分解读:
5分: 运营负担极轻
4分: 运营负担较轻
3分: 运营负担适中
2分: 运营负担较重
1分: 运营负担很重
0分: 运营负担不可承受
# 运营负担分析报告
## 项目: [项目名称]
### 1. 运营任务清单
| 任务类型 | 频率 | 人力需求 | 可否自动化 | 优先级 |
|---------|------|---------|-----------|--------|
| 客服支持 | __ | __小时/周 | __ | 高/中/低 |
| 系统监控 | __ | __小时/周 | __ | 高/中/低 |
| 内容审核 | __ | __小时/周 | __ | 高/中/低 |
| 数据分析 | __ | __小时/周 | __ | 高/中/低 |
| 内容更新 | __ | __小时/周 | __ | 高/中/低 |
| 营销推广 | __ | __小时/周 | __ | 高/中/低 |
**总计**: __小时/周
### 2. 运营复杂度
- 需要24/7待命: [是/否]
- 故障必须立即响应: [是/否]
- 需要人工审核内容: [是/否]
- 需要频繁处理纠纷: [是/否]
- 需要维护复杂的用户关系: [是/否]
- 需要持续产出内容: [是/否]
**复杂度等级**: [极高/高/中/低]
### 3. 生活质量影响
| 指标 | 评估 | 得分 |
|------|------|------|
| 每周工作时间 | __小时 | __分 |
| 休假能力 | __ | __分 |
| 睡眠影响 | __ | __分 |
| 心理压力 | __ | __分 |
| 外包可行性 | __ | __分 |
**总体影响**: [极轻/较轻/适中/较重/很重]
### 4. 自动化机会
| 任务 | 自动化方案 | 成本 | 预期效果 |
|------|-----------|------|---------|
| __ | __ | ¥__ | 节省__小时/周 |
### 5. 维度5评分: __/5
**评级**: [极轻/较轻/适中/较重/很重/不可承受]
### 6. 优化建议
**降低运营负担**:
1. ...
2. ...
3. ...
**自动化优先级**:
1. ... (预计节省__小时/周)
2. ...
3. ...
□ 维度5得分 < 2分
□ 需要24/7待命且无法自动化
□ 每周运营 > 40小时
□ 严重影响生活质量
□ 关键任务无法外包且无法自动化
□ 维度5得分 2-3分
□ 有明确的自动化方案
□ 可以通过外包降低负担
□ 可以通过产品调整减少运营需求
□ 维度5得分 ≥ 3分
□ 每周运营 < 20小时
□ 不影响正常生活
□ 大部分任务可自动化或外包
"产品做好后就能自动运行"
"客服需求应该不大"
"我可以周末维护"
"先上线再说,运营问题以后解决"
agents/kuko/docs/好生意.md - 方法论详细说明agents/kuko/SKILLS/business-opportunity-assessment/SKILL.md - 七维度评估Use this skill when debugging complex, multi-factor, or long-running bugs. It maintains a project-root /coe Markdown case file per bug case using a strict Chain-of-Evidence model with only Problem, Hypothesis, and Evidence nodes.
Best practices for Remotion - Video creation in React
Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".
Use when the user needs to design, implement, audit, or govern Storybook stories for frontend components, design systems, page states, interaction tests, accessibility checks, visual baselines, or component-driven UI workflows.
Allows you to view the user's screen as well as several hours of history. Use when the user makes a reference to their recent work, for which it'd be helpful to see the screen. This skill MUST be used whenever you need to resolve ambiguity in a user request, where the user hasn't specified enough context to do the task. Examples include disambiguating the specific user/app/document/error the user is referring to. You must also use this skill if the user asks about any question regarding Chronicle or asks what you can see from the screen.
Use when a frontend redesign or legacy CSS refactor is blocked by global style pollution, selector collisions, unstable DOM reuse, or the need to migrate a page or module to a new UI without breaking the old system.