# P3 System Building

> AI Native 系统构建 Skill

- Skill: `gabrielmoreira/p3-system-building` (Agent Skill)
- Install (CLI): `npx skillmds@latest add gabrielmoreira/p3-system-building`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/p3-system-building/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/gabrielmoreira/p3-system-building

---



# AI Native 系统构建 Skill

## 使用场景

- 试验展开已验证能力成立，需要转为可维护、可交付、可治理的产品系统
- 需要设计 AI Native 产品架构，而不是简单把模型 API 接入旧系统
- 需要判断实验代码中哪些可以继承，哪些必须重写

## 核心概念

- **系统构建（Building）**：把已验证能力改写为可维护、可治理、可观测系统的阶段
- **能力系统**：由智能体、技能单元、工具、模型、数据、记忆系统、上下文等共同组成的产品能力底座
- **实验代码**：用于快速验证假设的短周期代码
- **产品代码**：用于长期承载能力、支持治理和迭代的系统代码

## 系统构建流程

```
实验证据输入
  → 系统边界定义
    → 能力模块设计
      → 治理与观测补齐
        → 进入审计放行
```

## 第一步：实验证据输入

从试验展开阶段继承：

- 能力边界：哪些场景能稳定成立
- 产品形态建议：问答、Copilot、工作流、智能体
- 资料缺口：已解决和未解决的
- 风险边界：必须人工接管的动作
- 失败案例：已沉淀的失败模式和人工修正

## 第二步：系统边界定义

系统构建不是补工程细节，而是重写系统形态。需要回答：

- 这项能力如何被稳定调用
- 它如何与产品交互、工作流、知识系统和权限体系协同
- 它在失败时如何退回、解释、降级或交还给人
- 它如何被监控、被审计、被持续优化

## 第三步：能力模块设计

### AI Native 架构的核心结构

```
User
  → Agent
    → Skill
      → Tool
        → System
          → Model
            → Data
```

这是一个多层能力系统：

- **智能体（Agent）**：负责理解目标与编排任务
- **技能单元（Skill）**：封装可复用能力
- **工具（Tool）**：连接外部系统
- **模型（Model）**：提供推理能力
- **数据（Data）**：提供知识与记忆基础

### 传统架构 vs AI Native 架构

| 维度 | 传统软件架构 | AI Native 架构 |
|------|------------|---------------|
| 稳定中心 | 功能执行链 | 能力执行链 |
| 抽象单元 | 模块/接口 | 智能体/技能/工具 |
| 输入组织 | 数据库/表单 | 上下文/记忆/知识 |
| 失败处理 | 异常捕获 | 回退/降级/人工接管 |
| 治理重心 | 权限/审计 | 边界/观测/放行 |

## 第四步：治理与观测补齐

系统构建的目标不是尽快交付一个可演示版本，而是形成一个可被审计、可被维护、可被持续优化的系统结构。

### 必须补齐的治理能力

- **可观测性**：系统如何被监控，关键指标是什么
- **可审计性**：如何追溯输入、上下文、模型版本、工具调用、人工接管、最终结果
- **可回退性**：失败时如何降级、回滚、交还给人
- **可更新性**：模型、提示词、知识、工具如何独立更新

## 实验代码 → 产品代码的转换原则

1. 实验代码证明的是"能力在某些条件下可以成立"
2. 产品代码要解决的是"能力如何被稳定调用、失败时如何处理、如何被治理"
3. 很多团队失败不是因为模型不行，而是因为没有完成这次系统形态转换

## 输出物：系统构建方案

1. **系统边界**：能力范围、用户角色、权限分层
2. **能力模块图**：Agent → Skill → Tool 的层级结构
3. **失败处理策略**：回退、降级、人工接管的触发条件
4. **治理与观测方案**：监控指标、审计记录、异常处理
5. **进入审计放行的条件**：什么条件满足后可以进入审计放行

## 使用方式

当用户提供实验结论报告时，自动执行：

1. 检查实验证据是否充分
2. 定义系统边界（能力范围、用户角色、权限）
3. 设计能力模块图（Agent/Skill/Tool 分层）
4. 设计失败处理策略
5. 补齐治理与观测方案
6. 输出系统构建方案

## 示例

### 示例：AI 客服系统从实验到产品

**场景描述**：
基于已完成的实验结论，将 AI 客服原型系统转化为可维护、可治理的生产系统。

**用户输入**：
实验结论报告：AI 客服 Copilot 能力验证

**Skill 执行流程**：

1. **实验证据输入**

```yaml
从实验阶段继承的证据:
  
能力边界:
  - 订单查询: 92%准确率 ✅
  - 物流解释: 85%准确率 ✅
  - 售后政策: 78%准确率 ⚠️（需改进）
  - 投诉处理: 不适合AI ❌
  
产品形态建议:
  - 类型: Copilot（人工确认模式）
  - 界面: 侧边栏候选回复
  - 关键交互: 一键采纳、快速编辑
  
资料缺口:
  - 需补充200条售后政策边界案例
  - 需建立敏感承诺规则库
  
风险边界:
  - 退款、赔付相关: 必须人工确认
  - 价格相关: 必须引用最新数据源
  - 情感升级: 自动转人工
```

2. **系统边界定义**

| 维度 | 实验阶段 | 系统构建后 |
|------|----------|------------|
| 用户范围 | 内部测试客服 | 全部一线客服 |
| 能力范围 | 订单+物流 | 订单+物流+售后（80%+准确率） |
| 权限分层 | 单一角色 | 专员/主管/管理员 |
| 可用时间 | 工作日白天 | 7x24小时 |
| 失败处理 | 直接报错 | 优雅降级+人工接管 |

3. **能力模块设计**

```yaml
# AI Native 架构：AI 客服 Copilot

系统边界:
  
  用户层:
    - 客服专员（主要用户）
    - 客服主管（审核/管理）
    - 系统管理员（配置/监控）
    
  产品层:
    - 客服工作台界面
    - 浏览器插件 / Web端
    
  能力系统层:
    
    Agent层（CustomerServiceAgent）:
      - 目标理解: 识别用户意图、情绪
      - 任务规划: 选择Skill、编排执行顺序
      - 结果组织: 组装回复、标记风险
      
    Skill层:
      - UnderstandIntent: 意图识别（92%准确率）
      - QueryOrder: 订单查询
      - TrackLogistics: 物流追踪
      - GenerateResponse: 回复生成
      - CheckRisk: 风险检测
      
    Tool层:
      - OrderSystem.query: 订单系统查询
      - LogisticsAPI.track: 物流API
      - KnowledgeBase.search: 知识库检索
      - CRM.getUserProfile: 用户画像
      
    Model层:
      - GPT-4o: 主推理模型（意图理解+回复生成）
      - text-embedding-3: 向量化（知识检索）
      
    Data层:
      - 知识库: 政策文档、FAQ
      - 案例库: 成功案例、失败案例
      - 记忆系统: 用户偏好、会话状态
      
  治理层:
    - 可观测性: 指标监控、日志审计
    - 权限控制: RBAC
    - 失败处理: 降级+人工接管
```

4. **失败处理策略**

| 失败场景 | 触发条件 | 处理策略 | 人工接管 |
|----------|----------|----------|----------|
| 意图识别失败 | 置信度<70% | 提示"请重述问题" | 连续2次 → 人工 |
| 订单查询失败 | API超时 | 提供自助查询链接 | 用户要求 → 人工 |
| 高风险内容 | 涉及赔付 | 只生成候选，不发送 | 必须人工确认 |
| 模型服务异常 | API不可用 | 关闭AI建议，纯人工 | 自动 |
| 多轮对话失控 | 超过10轮 | 建议转人工 | 自动转人工 |

5. **治理与观测方案**

```yaml
可观测性:
  
  监控指标:
    - 采纳率: >60%
    - 修改率: <40%
    - 响应延迟: P95<2s
    - 服务可用性: 99.9%
    
  审计日志:
    - 每次请求: 输入摘要、模型版本、上下文
    - 每次输出: 建议内容、置信度、风险标记
    - 每次人工操作: 采纳/修改/拒绝 + 原因
    
可回退性:
  - 功能开关: 可关闭AI建议（5分钟内）
  - 模型降级: 主模型异常时切换备用模型
  - 人工接管: 指定场景自动转人工
  
可更新性:
  - 模型: 支持A/B测试切换
  - 提示词: 独立配置，热更新
  - 知识库: 增量更新，无需重启
  - 规则: 实时生效
```

**输出结果**:

```yaml
# 系统构建方案：AI 客服 Copilot

系统边界:
  用户: 300名一线客服 + 30名主管
  场景: 订单查询(92%)、物流解释(85%)、售后咨询(78%)
  边界: 投诉处理、高风险承诺不在范围内

能力模块:
  
  Agent层:
    - CustomerServiceAgent
    - 负责任务编排、边界控制
    
  Skill层（6个）:
    - UnderstandIntent / QueryOrder / TrackLogistics
    - GenerateResponse / CheckRisk / SummarizeSession
    
  Tool层:
    - 订单系统、物流API、知识库、用户画像
    
  Model层:
    - GPT-4o（主）、Claude-3.5（备）
    
  Data层:
    - 知识库、案例库、记忆系统

失败处理:
  - 12种失败场景定义
  - 分级处理策略
  - 自动转人工机制
  
治理方案:
  - 7大类监控指标
  - 完整审计日志
  - 5分钟热回退能力
  
进入审计放行条件:
  ✅ 实验证据完整
  ✅ 系统边界清晰
  ✅ 失败处理策略完备
  ✅ 治理方案就绪
  ✅ 团队准备就绪（已培训）
```