agentleFS
Sign inStart free
peterwangzepeterwangze/software-project-governance/skills/stage-operations/SKILL.md

stage-operations

Skill2 starsChanged 5 months agoMITView on GitHub

运营与反馈——监控、反馈、优化。阶段子工作流，可独立使用。

The file

Create a free account to mount
Files
SKILL.md

运营与反馈 — 子工作流

本文件定义"运营与反馈"阶段的独立子工作流。用户可单独加载本文件执行运营阶段。

阶段目标

收集真实运行数据和用户反馈，为持续改进提供事实依据。运营阶段的核心产出是"运营报告"——用数据回答"上线后表现如何、用户怎么用、有什么问题"。

AI 编程场景特有风险

在 AI 辅助编程项目中，运营阶段存在以下特有风险：

风险说明缓解方向
数据解读偏差AI 可能从运营数据中得出错误结论——相关性当成因果性、短期波动当成长期趋势、样本偏差当成普遍规律关键结论必须标注"相关性/因果性"；趋势判断必须有统计显著性说明；数据来源和样本量必须透明
反馈优先级被"最近"偏差主导AI 倾向于重视最新收到的反馈而忽略历史数据中更重要的信号，导致优先级随新反馈频繁漂移反馈排序必须同时考虑"频率×影响×趋势"三个维度，不能只看时间
优化建议空泛不可执行AI 生成的优化建议倾向于"永远正确但永远无法落地"（如"提升用户体验""优化性能"），缺少具体动作和衡量标准每条优化建议必须满足 SMART 标准（具体、可衡量、可达成、相关、有时限）
用户沉默信号被忽略AI 只分析"用户说了什么"而忽略"用户没说什么"——沉默的流失用户、弃用的功能、未触达的场景运营分析必须包含"流失/弃用/沉默"信号；没反馈≠没问题
指标选择不当AI 可能选择容易衡量但无关的 vanity metrics（如"页面浏览量"），而非真正反映业务价值的 actionable metrics关键指标必须与立项阶段的成功标准对齐；每个指标有"为什么选这个"的理由
改进执行被运营报告替代AI 在产出详尽运营报告后停止——报告本身成为交付物而非改进的起点。运营发现未能转化为可跟踪的改进任务，导致"分析了很多但什么都没变"运营报告 MUST 附带改进任务列表——每个运营发现对应至少 1 条可执行改进任务；无改进任务的报告视为未完成

独立使用时的目标锚定

当本子工作流被独立加载（非通过 main-workflow.md 总入口加载）时，MUST 在执行阶段活动前完成：

  1. 目标确认：读取 .governance/plan-tracker.md，确认项目立项时定义的量化成功标准
  2. 偏离检查：对照成功标准，确认运营数据维度与项目总目标一致。如发现偏离，MUST 先记录到 .governance/decision-log.md 再继续
  3. 质量底线：运营报告必须包含量化数据和非纯定性结论（参考 profile 质量要求）

进入条件

  • 版本已发布（G9 通过）
  • 有监控和反馈收集机制

活动清单

1. 数据收集

活动描述交互边界企业实践
收集运行指标性能（P50/P95/P99 延迟）、可用性（uptime %）、错误率、资源占用需监控环境执行[Google SRE] 监控 4 大黄金信号：延迟、流量、错误、饱和度
收集用户反馈用户反馈渠道（工单、评论、调研、NPS）的汇总数据需用户输入：反馈渠道和关键指标[Amazon] 用户反馈是 Working Backwards 的闭环——发布后验证 PR/FAQ 承诺是否兑现
建立基线对比上线前 vs 上线后数据对比：性能、错误率、用户活跃度自动[ByteDance 数据驱动] 不接受"感觉变好了/变差了"——必须有基线数据和变化幅度
收集沉默信号流失用户数、弃用功能列表、未触达场景自动：从使用数据中提取[Amazon Customer Obsession] 客户不说的痛点也是痛点——主动发现而非等反馈

2. 问题分类

活动描述交互边界企业实践
问题识别从运行数据和用户反馈中识别问题自动：异常检测 → 需用户确认：是否为真实问题[华为] 让听得见炮声的人呼唤炮火——问题识别要基于一线真实数据
严重度分类按影响范围（用户数）× 影响程度（体验/功能/数据）× 趋势（恶化/稳定/改善）三维分类自动：按矩阵初判 → 需用户确认[华为 IPD] 缺陷严重级别量化评分（阻塞/关键/重要/一般/建议）
分配处理人每个问题有明确的负责人和期望响应时间需用户确认[Amazon] 每个问题有 Single-Threaded Owner；[华为] 阻塞/关键问题 48 小时响应
排除噪音标记"观察即可"的问题，避免过度反应需用户确认[Google SRE] 错误预算内的问题不触发紧急响应

3. 运营分析

活动描述交互边界企业实践
效果评估对照立项阶段的量化成功标准，逐项评估目标达成度自动：数据 vs 目标值对比[Amazon Working Backwards] 回头验证 PR/FAQ 中承诺的用户价值是否已交付
用户行为分析用户如何使用、哪些功能最常用、哪些功能被忽略自动：使用数据分析 → 需用户判断：分析方向[ByteDance] 数据驱动——用户行为数据决定下一步优化方向
趋势分析关键指标的变化趋势（改善/恶化/稳定），区分短期波动和长期趋势自动：统计趋势检测[ByteDance A/B Test] 趋势判断必须有统计显著性，不接受"看起来在变好"
优化建议基于数据提出改进方向，每条满足 SMART 标准自动：基于分析生成 → 需用户确认[Amazon 6-Pager] 建议必须有数据支撑和预期收益量化

4. 运营报告

活动描述交互边界企业实践
编写运营报告数据汇总 + 问题分析 + 效果评估 + 优化建议自动[Amazon 6-Pager] 结构化叙述——不只是数字堆砌，要有叙事逻辑
归档反馈按类别（bug/需求/体验/安全）归档，去重合并自动通用实践
对比 PR/FAQ 承诺逐条验证立项时的用户价值承诺是否已实现自动：逐项对照 → 需用户确认[Amazon Working Backwards] 闭环验证——回头看清楚当初的承诺兑现了多少

5. 改进执行与跟踪

活动描述交互边界企业实践
改进项优先级排序基于影响范围×严重程度×实现成本的三维评分，排出改进项的执行顺序自动：矩阵评分 → 需用户确认：优先级排序[华为 IPD] 改进项量化排序——有限的资源解决最重要的问题
创建改进任务每个改进项转化为可跟踪的任务（含负责人、预期完成时间、验收标准）自动：从运营建议生成任务模板[Amazon] 每个改进有 Single-Threaded Owner；[ByteDance] 任务化是执行力的前提——没有任务的建议不是建议
跟踪执行进度定期检查改进项执行状态，对超期的阻塞级改进项升级自动：定期扫描 → 需用户确认：超期项处置[华为] 48 小时/1 周分级跟踪——阻塞级改进项不可超期
效果验证与复盘改进上线后验证效果是否达到预期，未达预期的分析根因自动：改进前后数据对比[ByteDance A/B Test] 没有对比的改进不算完成——必须证明"确实变好了"

产出物标准

产出物格式要求质量标准企业实践来源
运营报告包含运行数据（4 大黄金信号）、用户反馈、PR/FAQ 达成验证、优化建议至少 1 周真实运行数据；每个结论有数据支撑[Amazon 6-Pager] + [Google SRE]
问题清单每条有严重级别（三维评分）、状态、处理人、响应时限分类清晰；阻塞/关键级有 48 小时响应时限[华为 IPD] + [Amazon STO]
优化建议每条满足 SMART 标准（具体/可衡量/可达成/相关/有时限）≥1 条可执行建议；每条有预期收益量化[Amazon] + [ByteDance]

退出条件

  • 收集到至少 1 周的真实运营数据
  • 用户反馈已归档分类（含去重和严重度评分）
  • 关键问题已识别和分类（含处理人和响应时限）
  • 优化方向已明确（≥1 条 SMART 标准的改进建议）
  • PR/FAQ 达成验证已完成（逐条对照立项时的用户价值承诺）

Gate 映射

本阶段对应 G10 — 运营回收。

Gate 检查项对应活动判定标准自动化判定
是否收集到真实运营数据？数据收集运营报告包含至少 1 周的真实运行数据（覆盖延迟/流量/错误/饱和度 4 大信号）可自动：检查报告文件存在 + 数据时间跨度 ≥7 天 + 关键字段非空
用户反馈是否已归档？数据收集反馈已归档，有分类和严重度标注可自动：检查反馈文件存在 + 分类字段完整性
关键问题是否已识别和分类？问题分类问题清单存在，每条有严重级别、状态和处理人可自动：检查清单完整性（字段非空）
优化方向是否已明确？运营分析优化建议列表非空，每条满足 SMART 标准可自动：检查建议列表非空 + SMART 字段完整性
PR/FAQ 承诺是否已验证？运营报告立项时的用户价值承诺逐条有验证结论可自动：逐项对照检查 → 需人工判断达成质量

企业实践溯源

本子工作流的设计参考了以下企业实践，每条实践已映射到具体活动步骤：

企业核心实践映射到本工作流
Google SRE4 大黄金信号（延迟/流量/错误/饱和度）+ 错误预算数据收集→收集运行指标必须覆盖 4 大信号；问题分类→错误预算内不触发紧急响应
AmazonWorking Backwards (PR/FAQ 闭环验证)数据收集→用户反馈验证 PR/FAQ 承诺；运营分析→效果评估对照量化目标；运营报告→逐条 PR/FAQ 达成验证
Amazon6-Pager 结构化叙述运营报告→不只是数字堆砌，要有叙事逻辑
AmazonSingle-Threaded Owner问题分类→每个问题有明确负责人
华为IPD 门控量化评分 + 48 小时缺陷响应问题分类→严重级别三维量化评分；阻塞/关键问题 48 小时分配处理人
华为让听得见炮声的人呼唤炮火问题分类→问题识别基于一线真实数据而非管理推测
字节跳动数据驱动——不接受无数字的结论数据收集→上线前后基线对比；运营分析→趋势判断需统计显著性
字节跳动A/B Test 一切运营分析→不靠直觉做决策；用户行为数据决定优化方向

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free