agentsclimarketplace
Sign in

P10 production ops

Skill gmaxxxie/ai-native-product-agent-skills/skills/p10-production-ops

'AI Native 产品方法论——生产运行与循环回灌的实操 Skill。From its SKILL.md

Install
npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill p10-production-ops

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

SKILL.md

10.7 KB, ~4.0k tokens by cl100k_base, as published. Nobody here has run it

AI Native 生产运行与循环回灌 Skill

使用场景

  • 产品已上线或即将上线，需要建立生产运行的观测和学习体系
  • 需要设计反馈回灌机制，让生产环境反过来训练产品组织
  • 需要建立价值发现循环、商业循环和客户循环

核心概念

  • 生产运行（Production）：AI 系统进入真实使用、开始暴露真实价值和真实风险的阶段
  • AI 可观测性（AI Observability）：围绕模型输出、上下文、工具调用、成本、人工接管和任务成功率的观测体系
  • 反馈回灌：把生产环境中的失败、修正、行为和价值信号送回上游环节
  • 能力复利：系统随着真实使用不断积累更好资料、评估和能力结构的长期增益

生产运行流程

真实流量进入
  → 可观测性采集
    → 失败与人工修正识别
      → 回灌到方向定界 / 试验展开 / 系统构建 / 审计放行
        → 下一轮优化

这条链路如果断掉，生产运行就只剩被动监控；一旦打通，它才会成为方法论里的学习引擎。

生产运行不是终点，而是现实学习的起点

在传统软件里，上线往往意味着一轮交付完成；在 AI 产品里，上线更像是真实学习的开始。

只有进入真实环境，团队才会看到： n- 用户真正如何提问，而不是测试样本里如何提问

  • 上下文在哪些地方缺失，而不是理论上应当完整
  • 哪些场景任务成功，哪些场景虽然"回答像样"但并没有完成任务
  • 哪些链路的成本、延迟和重试在流量放大后开始失控

生产运行要观测什么：五层观测

1. 基础设施层

  • 可用性、延迟、错误率、吞吐、资源消耗

2. 模型与链路层

  • 模型版本、上下文长度、工具调用成功率、重试次数、令牌和成本

3. 任务质量层

  • 回答质量、任务完成率、人工改写率、命中知识库效果、失败分布

4. 交互行为层

  • 用户真正如何进入系统、在哪一步退出、哪些入口最有价值、哪些问题最常见

5. 业务结果层

  • 是否真的缩短时长、降低成本、提升转化、增加留存或改善服务质量

如果只监控第一层和第二层，团队得到的只是"系统是否活着"；如果连第三层到第五层也看清，团队才知道"系统是否真的在创造价值"。

三张指标表

生产指标至少应该分成三类：

可靠性指标

  • 延迟、错误率、失败分布、人工接管率、回退率

业务价值指标

  • 时长缩短、转化变化、满意度、采纳率、留存或复购

组织学习指标

  • 新增失败样本数、人工修正沉淀量、新评测覆盖率、规则更新速度

这样做的意义在于，团队不会把"系统还在线"误当成"产品已经成功"，也不会把"业务指标暂时好看"误当成"系统已经稳定可复用"。

AI 可观测性：不只是日志

生产观测至少应保留以下信息：

  • 输入与场景：用户问题、任务类型、入口、时间、角色
  • 关键上下文：检索到哪些知识、拼接了哪些上下文、使用了哪个模型和版本
  • 执行轨迹：调用了哪些工具、每一步是否成功、在哪里回退或终止
  • 输出结果：最终回答、执行结果、结构化产物、失败类型
  • 人工信号：人工接管、人工修改、用户反馈、投诉、升级工单

这套观测不是为了国日志，而是为了后续判断问题究竟来自模型、Context、Workflow、Knowledge、权限配置，还是产品入口本身。

反馈回灌机制

生产环境中的失败、修正、行为和价值信号应该回灌到：

  • 方向定界：是否需要重新定义问题或调整战略
  • 试验展开：新的失败模式是否需要新的实验
  • 系统构建：系统边界是否需要调整
  • 审计放行：放行边界是否需要收紧或放宽

三环模型

产品循环（Product Loop）

方向定界 → 试验展开 → 系统构建 → 审计放行 → 生产运行

回答：产品如何被持续构建

价值发现循环（Value Discovery Loop）

试验展开 → 价值发现 → 市场测试 → 定价判断 → 方向调整

回答：价值如何被持续发现

客户循环（Customer Loop）

已验证能力 → 早期客户 → 使用反馈 → 产品改进 → 客户扩张

回答：客户如何推动产品持续成长

三环协同

客户反馈会影响价值判断，价值判断会影响产品方向，产品方向又会反过来决定下一轮实验重点。

治理层与能力层

治理层（Governance Layer）

一套贯穿式机制：方向边界、实验评估、工程安全、审计放行、生产监控。没有治理层，循环会不断转，但转出来的东西不一定可被信任。

能力层（Capability Layer）

智能体、技能单元、记忆、上下文、检索增强生成、知识系统、工具和数据这些能力底座。没有能力层，循环就缺乏真正可以沉淀和复用的系统资产。

输出物：生产运行方案

  1. 可观测性方案：五层观测的具体指标和工具
  2. 三张指标表：可靠性、业务价值、组织学习指标
  3. 反馈回灌机制：如何把生产信号送回上游环节
  4. 循环优化计划：下一轮优化的方向和重点
  5. 组织学习机制：如何让团队从生产环境中持续学习

使用方式

当用户提供产品已上线或即将上线时，自动执行：

  1. 设计五层可观测性方案
  2. 搭建三张指标表
  3. 设计反馈回灌机制
  4. 设计循环优化计划
  5. 设计组织学习机制
  6. 输出生产运行方案

示例

示例：AI 客服系统生产运行设计

场景描述： AI 客服 Copilot 已上线，需要设计完整的生产观测和反馈回灌体系。

用户输入： "我们的 AI 客服已经上线两周，想建立系统的观测和优化机制"

Skill 执行流程：

  1. 五层可观测性设计
基础设施层:
  - API 响应时间: P50<500ms, P95<1500ms
  - 可用性: 99.9%
  - 错误率: <0.1%
  
模型与链路层:
  - 模型版本追踪: 每次调用记录版本号
  - 上下文长度: 平均 tokens 数
  - 工具调用成功率: 订单查询 99.5%, 物流查询 99%
  - 成本: 每次对话 <$0.02
  
任务质量层:
  - AI 建议采纳率: >60%
  - 人工修改率: <40%
  - 意图识别准确率: >85%
  - 知识库命中率: >70%
  
交互行为层:
  - 会话平均轮数: 3.2轮
  - 用户等待时间: 平均45秒
  - 主动转人工率: 15%
  - 升级投诉率: <2%
  
业务结果层:
  - 首响时间: 从5分钟降至1分钟
  - 会话解决率: 78%
  - 客服满意度: 85分
  - 培训周期: 从2周缩短至5天
  1. 三张指标表
指标类型指标名目标值预警阈值
可靠性服务可用性99.9%<99.5%
可靠性API错误率<0.1%>0.5%
业务价值建议采纳率>60%<50%
业务价值用户满意度>80分<75分
业务价值会话解决率>75%<70%
组织学习新增失败样本/周>50-
组织学习人工修正入库率>30%<20%
  1. 反馈回灌机制
失败识别与回灌:
  
  模式1_意图识别错误:
    识别: 客服修改了AI的意图分类
    回灌: 样本库 → 试验展开（重新评估模型）
    周期: 每周
    
  模式2_知识库缺失:
    识别: "未找到相关信息"触发
    回灌: 缺失信息清单 → 系统构建（补充知识库）
    周期: 每日
    
  模式3_高风险误判:
    识别: 涉及赔付/投诉的建议被人工拦截
    回灌: 审计放行（收紧边界规则）
    周期: 实时
    
  模式4_用户不满意:
    识别: 满意度评分 < 3
    回灌: 方向定界（重新定义问题边界）
    周期: 每周分析
  1. 循环优化计划
阶段目标关键动作成功标准
第1月稳定运行监控+应急响应可用性>99.9%
第2月优化采纳率分析拒用原因采纳率>70%
第3月扩展场景新增售后咨询覆盖场景+2
第4月自动化提升试点自动发送低风险建议自动率20%
  1. 组织学习机制
周度复盘会:
  参与: 产品经理 + 技术 + 客服主管
  内容:
    - 本周采纳率/修改率趋势
    - 典型案例分享（成功+失败）
    - 新发现问题汇总
    - 下周优化重点

月度质量报告:
  自动产出:
    - 指标仪表板
    - Top10 失败类型分析
    - 知识库覆盖度报告
    - 修正样本质量评估

季度能力沉淀:
  产出:
    - 更新客服 SOP
    - 补充知识库规则
    - 优化评估 Rubric
    - 案例库清洗与更新

输出结果：

# 生产运行方案：AI 客服 Copilot

可观测性方案:
  监控工具: Datadog + 自建仪表板
  告警策略:
    - P0: 服务不可用、错误率>1%
    - P1: 响应时间P95>3s、采纳率<50%
    - P2: 成本单次>$0.05、投诉率>3%
    
  日志规范:
    - 每次请求: 请求ID + 模型版本 + 输入摘要
    - 每次回复: 建议内容 + 置信度 + 风险标记
    - 每次人工操作: 采纳/修改/拒绝 + 原因标签

反馈回灌链路:

  生产环境 → 试验展开:
    - 新增失败样本 → 评估数据集扩充
    - 边界案例发现 → 新一轮能力实验
    
  生产环境 → 系统构建:
    - 知识缺口清单 → 知识库更新任务
    - 意图冲突案例 → 分类规则优化
    
  生产环境 → 审计放行:
    - 误判事故 → 边界收紧
    - 新风险场景 → 规则更新

循环优化节奏:
  每周: 指标复盘 + 快速修复
  每月: 质量报告 + 中等优化
  每季: 能力沉淀 + 重大升级

组织学习:
  建立"客服-产品-技术"三方周会
  设立"AI质量专员"角色
  建立知识库贡献激励机制

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most ship operate skills give in ~4.0k tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git tagin 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • design five-layer observability
  • build three metric tables
  • design feedback loop mechanism
  • design continuous optimization plan
  • design organizational learning mechanism
  • output production run plan

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,645. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.